Авторизация с использованием куки

Как правильно делать авторизацию на сайте с помощью куки? Очевидно, что просто записывать в куки id пользователя нельзя. Можно сохранять специальный пароль. Но тогда придётся на каждой странице сравнивать пароль с хешированой строкой из базы данных. А это нагрузка на сервер, ведь хеширование производится долго. Получается, нужно один раз авторизацию делать и записывать данные в сессию? Или как это делается?

0

Сообщение от Step01 Какой смысл хешировать один пароль, если есть другой незашифрованный. Если их украдут, то оба))

Потому что пароль есть только 1. То что другое, это не пароль, и сам пользователь его не знает, а угадать его не возможно.

Сообщение от tarasalk БД могут угнать или какой-то сотрудник воспользуется доступом к БД в своих целях...

Если до такого дошло, то защита авторизационного ключа уже никак не поможет, раз уж злоумышленник смог пробраться. Пароли хешируют по другой причине - чтобы данная утечка не привела к взлому других ресурсов, на которых у пользователя может быть такой же логин и пароль.
Хотя иногда хеш может быть удобен - например в токен можно вшить дополнительные параметры, типа id пользователя или срок действия токена, или чтобы сам токен не хранить, а вычислять по другим данным.

0

Сообщение от Jewbacabra Если до такого дошло, то защита авторизационного ключа уже никак не поможет

Не согласен. У нас в компании применяется несколько уровней шифрования. Чтобы расшифровать данные нужно иметь исходный код, соль из окружения и соль из БД (уникальная для каждого юзера). А то что не зашифровано особой ценности не имеет.

0

Сообщение от Jewbacabra угадать его не возможно

Угадать невозможно, а подобрать без шифрования легко

0

Step01, сложность подбора что с шифрованием, что без одинаковая.

Допустим, я сгенерировал рандомную строку из 60 символов и записал в куку. Либо я взял эту строку, зашифровал, получил на выходе другие 60 символов и записал в куку.

Какая разница для злоумышленника, что лежит в куке, строка или её шифр? Если он хочет подобрать эту куку перебором - никакой, в любом случае нужно угадать 60 символов.

0

Сообщение от tarasalk У нас в компании применяется несколько уровней шифрования. Чтобы расшифровать данные нужно иметь исходный код, соль из окружения и соль из БД (уникальная для каждого юзера).

И как это поможет, если недобросовестный сотрудник добрался до бд и знает все данные. Токен - последнее, что будет его интересовать.

Сообщение от Step01 а подобрать без шифрования легко

Сколько вариантов строки из 32 символов из букв латинского алфавита и цифр? И сколько времени уйднт на перебор всех возможных комбинаций? Естественно надо генерировать нормальные токены, а не что-то типа 'aaaaaaaaaaaaaaaaaaaaaa'
https://secure.php.net/manual/... -bytes.php - вот, напрмер, функция, которая позволяет это сделать
И что мешает угадать значение токена до шифрования?

Step01, и кстати, стандартная реализация сессий так и работает - id сессии это случайная строка, хранящаяся без шифрования в файловой системе

Добавлено через 18 минут
Но если в куках хранить кеш, то можно делать вот интересную вещь - изменив общую соль всех сразу разлогинить, что иногда может понадобиться

0

Сообщение от Jewbacabra И как это поможет, если недобросовестный сотрудник добрался до бд и знает все данные. Токен - последнее, что будет его интересовать.

В том то и дело что не знает. Все секретное - шифруется.
Если он узнает допустим сколько денег у юзера, это пол беды. А вот если он с помощью куки переведет эти деньги к себе, вот это уже реально проблема. Конечно он может нарисовать себе миллион и вывести, но ему придется делать это со своего аккаунта, а это уже палево.
Конечно это не 100% защита, но по крайней мере нельзя просто взять и слить всю приватную инфу на черном рынке.

0

Сообщение от tarasalk В том то и дело что не знает. Все секретное - шифруется.

Так мы сейчас рассматриваем именно такую гипотетическую ситуацию

Сообщение от tarasalk БД могут угнать или какой-то сотрудник воспользуется доступом к БД в своих целях

тогда вся бд уже известна, и врядли взломщика заинтересуют токены. Ну а если дело связано с деньгами, то авторизации по токену из кук явно недостаточно. Необходимо дополнительное подтверждение переводов.

0

Сообщение от Jodah Какая разница для злоумышленника, что лежит в куке, строка или её шифр?

Вам нужно почитать о хешировании и алгоритмической стоимости. Если бы разницы не было, хеш никто бы не использовал. Вы упорно не желаете разобраться в вопросе и спорите о том, в чём не разбираетесь. Хорошо, что в этом офтопе нашёлся человек, который подсказал ответ на вопрос. Но так бывает не всегда. Хотите, чтобы вам что-то объяснили, создайте свою тему

0

Сообщение от Step01 Вы упорно не желаете разобраться в вопросе и спорите о том, в чём не разбираетесь

Нет, тут именно ты не понял для чего нужен хеш и для чего хешируются пароли.

0

Сообщение от Step01 Вам нужно почитать о хешировании и алгоритмической стоимости.

Очень жаль, что вы всё время пытаетесь доказать мою некомпетентность какими-то общими фразами про "так делать нельзя", "вам нужно почитать" и пр, без каких-либо фактов. Здесь такие методы не работают.

Создаётся ощущение, что вы что-то почитали про хеширование и пытаетесь впихнуть его куда только можно, не задумываясь о целесообразности.

Сообщение от Step01 Если бы разницы не было, хеш никто бы не использовал.

Хеширование используют. Но не для защиты от подбора, про которую вы написали выше:

Сообщение от Step01 Угадать невозможно, а подобрать без шифрования легко

И я нигде в этой теме не вижу, чтобы кто-то говорил обратное моим словам. Да, выше предлагают шифровать куку, чтобы при взломе базы данных злоумышленник не мог залогиниться от имени пользователя и я согласен, что такой подход имеет смысл. Но если злоумышленник захочет подобрать куку, сгенерированную из случайных символов, шифрование или хеширование никак не поможет.

Вернее, не так. Если длина хеша будет больше исходной строки - то поможет, если меньше - то только ухудшит ситуацию. Потому что на выходе хеширующий или шифрующий алгоритм всегда выдаёт значения из одного и того же диапазона.

Пример:
Мы сгенерировали рандомную строку, затем получили её хеш, затем ещё несколько раз захешировали с добавлением случайных данных. А теперь объясните, почему для злоумышленника подбор этой строки:
будет сложней, чем подбор этой:
Разницы нет потому что ему нужно подобрать сам хеш, а не исходную строку.

В интернете иногда можно встретить примеры вроде таких:
Здесь это имеет смысл потому что разработчик боится, что злоумышленник может попытаться получить исходную строку. Но этот подход изначально неверен, потому что если тебе нужна рандомная строка - генерируй рандомную строку, не нужно совать логин и пароль пароль куда попало.

И более того, если мы расширим алфавит рандомной строки, т.е. к стандартным символам md5 0-9a-f добавим g-z, а также спецсимволы вроде -?#/ и т.д., то такой подход, в отличие от применения md5, как раз усложнит подбор, потому что за счёт расширения алфавита увеличивается диапазон возможных значений.

Надеюсь, после этой простыни вы хоть раз решите также подкрепить свои слова хоть чем-то, потому что доказывать, что не верблюд, уже немного надоело.

2

Сообщение от Jodah пытаетесь доказать мою некомпетентность

Я ничего не пытаюсь доказать. Я хотел узнать ответ на вопрос. А вместо этого вынужден объяснять элементарные вещи. Функции хэширования выполняются долго и поэтому не позволяют подобрать пароль. Здесь писали про MD5, но видно вы не знаете, что он устарел, как раз потому, что выполняется слишком быстро. Хэширование применяется именно потому, что не позволяет подобрать пароль. Ещё раз говорю, разберитесь в вопросе

0

Сообщение от Step01 А вместо этого вынужден объяснять элементарные вещи.

Сначала научитесь понимать элементарные вещи, а потом уже пробуйте их объяснить. Так будет проще

0

Сообщение от Step01 Функции хэширования выполняются долго и поэтому не позволяют подобрать пароль.

Отлично, остался всего один вопрос. Зачем злоумышленнику пытаться из хеша токена получить исходный токен? Зачем?

Ему даром не нужен исходный токен, он берёт хеш, подставляет его в куки и авторизуется от имени юзера.

Ещё раз, взломщику не нужный исходный пароль, как вы его называете, ему нужен сам хеш. Я не знаю, как донести это до вас.

Сообщение от Step01 Здесь писали про MD5, но видно вы не знаете, что он устарел

Я специально взял эту функцию для упрощения примера. Возьмите password_hash и будет тот же результат.

0

Jodah, если сделать предположение, о чем он пишет, то речь, видимо, о хэшировании токена только на сервере.

Добавлено через 2 минуты
А в ваши объяснения, что это делать не нужно, он не хочет или не может вникнуть.

1

0

Step01, можно сделать (частично) различными токен на клиенте и соответствующий ему токен на сервере и без (сложного) хэширования. Ну, и почаще сбрасывайте токены, раз не можете обеспечить конфиденциальность при их хранении на сервере.

0

Сообщение от estic видимо, о хэшировании токена только на сервере

Что значит видимо? Об этом прямо сказано в топе. Человек увлечён спором и не желает вникать в такие мелочи))

Сообщение от estic объяснения, что это делать не нужно, он не хочет или не может вникнуть

Это не объяснение а заблуждение, вызванное тем, что человек отказывается понять, что хеш препятствует подбору и поэтому необходим при хранении паролей в базе данных

Сообщение от Jodah специально взял эту функцию для упрощения примера

Вы взяли эту функцию, потому что не понимаете, чем она отличается от современных. И не хотите понимать.)) В использование MD5 действительно нет смысла. Тут я с вами согласен. А вот современные функции выполняют свое назначение и защищают данные

0

Сообщение от Step01 Об этом прямо сказано в топе. Человек увлечён спором и не желает вникать в такие мелочи))

Не вводите в заблуждение.

Я предложил хранить токен в базе и куках. Чуть далее вам сказали, что угадать куку с токеном невозможно. Вы ответили, что угадать невозможно, а подобрать без шифрования легко.

А вариант с шифрованием предложен был только один - хранить токен в базе и шифровать его в куке пользователя. И именно про эту ситуацию я сказал, что ни шифрование, ни хеширование токена не поможет в защите от подбора, потому что подбор здесь может быть только самой куки, подбирать исходный токен бессмысленно. И именно эту ситуацию мы всё это время мусолили.

Если под шифрованием вы имели ввиду хеширование - в этом уж точно нет моей вины, учитесь грамотно формулировать свои мысли. Отсюда и ваши слова:

Сообщение от Step01 что человек отказывается понять, что хеш препятствует подбору и поэтому необходим при хранении паролей в базе данных

неверны, поскольку мы говорим о разных ситуациях и подразумеваем под "подбором" разные действия. Я - подбор кук методом перебора, вы - подбор исходной строки хеша.

Сообщение от Step01 Вы взяли эту функцию, потому что не понимаете, чем она отличается от современных.

Чем кидаться голословными обвинениями, вспомните лучше, кто автор темы и кто хотел хранить "специальный пароль" в сессиях.

На этом можно закончить, вряд ли здесь будет конструктивное продолжение темы.

0

Сообщение от Jodah вспомните лучше, кто автор темы и кто хотел хранить "специальный пароль" в сессиях

Пока вы засоряли мою тему я нашёл человека, который работает в конторе по созданию сайтов. Он сказал, что на php так и делают. При входе пароль берётся из куки, дальше всё через сессии, как я и говорил. Только я про обновление куки не совсем понял, но разбирусь сам. Можно на каждой странице обновлять

0

Пока вы засоряли мою тему

Jodah, получайте благодарность
Step01, вы идиот (не оскорбление, констатация факта).

Сообщение от Step01 я нашёл человека, который работает в конторе по созданию сайтов

Знаем, видели. Люди деньги зарабатывают, а не языком чешут, как мы тут. Только в нынешних реалиях между "работает в конторе" и квалификацией человека нет никакой связи. Вы, как обычно, опять не понимаете простых вещей и гнете свою линию. Хорошо хоть, что нашли способного вам угодить консультанта, поэтому появился шанс, что перестанете доставать форумчан.

2