Комментарии 35
Это была исторически первая функция хеширования. Аббревиатура SHA-1 расшифровывается как «безопасный алгоритм хеширования»А куда MD5 исчез — который появился на 3 года раньше? А до MD5 был MD4. А до MD4…
И ведь до сих пор горе-разработчики, насмотревшиеся «курсов PHP», пишут:
$hash = md5(md5($password));А после SHA-2 был создан SHA-3 — и о нём в статье тоже ни слова.
Отсутствие MD5 говорит о том, когда автор начал первые шаги в хешировании паролей.
Ждём статью от «метров безопасности», которые скажут, что первый был DES из 70-х. Главное, что бы они не сказали, что MD5 — это самый последний.
Ждём статью от «метров безопасности», которые скажут, что первый был DES из 70-х. Главное, что бы они не сказали, что MD5 — это самый последний.
А после SHA-2 был создан SHA-3 — и о нём в статье тоже ни слова.
Да, как же давно это было, вы прямо совсем в историю закопались! Сейчас-то все уже на SHA-256, а некоторые и на SHA-512 сидят! [/sarcasm]
мы старались писать всё таки о новейшей, так сказать, истории. Поэтому MD5 не взяли по временным характеристикам, SHA-2 и SHA-3 по причине схожести логики работы
Почему в статье о хешировании паролей в PHP ни слова про функцию password_hash?
Ответа на вопрос «где» хранить пароли — в статье не содержится, статья не соответствует заголовку.
Ответа на вопрос «где» хранить пароли — в статье не содержится, статья не соответствует заголовку.
За отсутствие упоминания о password_hash() — однозначный минус.
От таких «статей» больше вреда, чем пользы.
От таких «статей» больше вреда, чем пользы.
Такое ощущение, что этот вот сценарий копипастят не особо понимая, т.к. звучит он красиво и весомо «заказчик знает как лучше, увольняет разработчика, ввернуто пара умных слов про хэширование, круто чё»
Сотрудник может и не знать пароль, то что Вам пришло с паролем от него, не означает что он его знает. Но даже если он его знал — где тут проблема неясно абсолютно, Вы что, неспособны его поменять?
Сотрудник может и не хранить пароль в чистом виде, классический сценарий подразумевает посылку пароля и сохранение его в шифрованном виде. Мало того, в некоторых (редко применяемых случаях) возможность присылки пароля в открытом виде не означает хранения его в чистом виде.
Сотрудник понимает, что если задание пароля завязано на е-маил и только на него, то одна и только одна «парольная точка», а «многократная присылка на почту ссылок для изменения» это «карго-культ» создающий иллюзию безопасности, а не «повышающий ее благодаря простым шагам».
По поводу того, как должен был поступить веб-разработчик.
Он должен был поступить соответственно ТЗ предоставленному заказчиком.
Неожиданно, да? Но абсолютно верно. Если поступил по ТЗ — прав, если не по ТЗ — не прав.
Если у разработчика спрашивают мнение по поводу ТЗ, он может его высказывать, но после принятия ТЗ — он должен делать всё по ТЗ и только так. Всё на этом.
мы про этот сценарий
Многократно неверно.Представьте, что вы клиент и вы нанимаете разработчика, чтобы он создал для вашего бизнеса симпатичный сайт электронной коммерции. Этот разработчик прислал вам е-мейл, который содержит пароль для вашего сайта. Теперь вам известно три вещи о вашем сотруднике:
Он знает ваш пароль.
Он хранит ваш пароль в чистом виде, не используя никакого шифрования.
Он не испытывает ни малейшего беспокойства при пересылке паролей через интернет.
В ответ ничего не остаётся, как уволить такого сотрудника.
А вот как должен поступить веб-разработчик:
Создайте в вашем веб-приложении страницу, куда пользователь сможет ввести свой е-мейл в случае, если он забыл пароль, и таким образом запросить новый пароль.
Ваше приложение сгенерирует уникальные права доступа и привяжет его к пользователю, сделавшему запрос (лично я пользуюсь универсальным индивидуальным идентификатором).
Приложение отправит пользователю е-мейл со ссылкой, ведущей к праву доступа.
Как только пользователь перейдет по ссылке, приложение подтвердит правильность доступа и даст пользователю возможность поменять пароль.
Видите, насколько возросла безопасность приложения благодаря этим простым шагам?
Он знает ваш пароль.
Он хранит ваш пароль в чистом виде, не используя никакого шифрования.
Он не испытывает ни малейшего беспокойства при пересылке паролей через интернет.
В ответ ничего не остаётся, как уволить такого сотрудника.
А вот как должен поступить веб-разработчик:
Создайте в вашем веб-приложении страницу, куда пользователь сможет ввести свой е-мейл в случае, если он забыл пароль, и таким образом запросить новый пароль.
Ваше приложение сгенерирует уникальные права доступа и привяжет его к пользователю, сделавшему запрос (лично я пользуюсь универсальным индивидуальным идентификатором).
Приложение отправит пользователю е-мейл со ссылкой, ведущей к праву доступа.
Как только пользователь перейдет по ссылке, приложение подтвердит правильность доступа и даст пользователю возможность поменять пароль.
Видите, насколько возросла безопасность приложения благодаря этим простым шагам?
Сотрудник может и не знать пароль, то что Вам пришло с паролем от него, не означает что он его знает. Но даже если он его знал — где тут проблема неясно абсолютно, Вы что, неспособны его поменять?
Сотрудник может и не хранить пароль в чистом виде, классический сценарий подразумевает посылку пароля и сохранение его в шифрованном виде. Мало того, в некоторых (редко применяемых случаях) возможность присылки пароля в открытом виде не означает хранения его в чистом виде.
Сотрудник понимает, что если задание пароля завязано на е-маил и только на него, то одна и только одна «парольная точка», а «многократная присылка на почту ссылок для изменения» это «карго-культ» создающий иллюзию безопасности, а не «повышающий ее благодаря простым шагам».
По поводу того, как должен был поступить веб-разработчик.
Он должен был поступить соответственно ТЗ предоставленному заказчиком.
Неожиданно, да? Но абсолютно верно. Если поступил по ТЗ — прав, если не по ТЗ — не прав.
Если у разработчика спрашивают мнение по поводу ТЗ, он может его высказывать, но после принятия ТЗ — он должен делать всё по ТЗ и только так. Всё на этом.
А если нет ТЗ? Да и заказчика нет, есть начальство.
В таком случае, скорее всего вы должны написать ТЗ, или ваше непосредственное начальство, буде оно обладает необходимым техническим бэкграундом. Иначе рискуете получить продукт, резко отличающийся от того что хотело начальство и долгие разговоры на тему «Я же ясно объяснил, что сайт должен быть как у ХХХ, а он не как у ХХХ, мне пофиг что они за это время 3 раза сменили стиль и функционал!». В случае конторы условного дяди Коли с 1 «программистом», клепающим сайты на вордпресс, я думаю вопрос ТЗ стоит не настолько остро.
Какая разница между "написать себе ТЗ по решению бизнес-задачи и имплементировать его в коде" и "решить бизнес-задачу в коде"? Сунуть его на подпись человеку, который не понимает ничего в нём и прикрыть тем самым себе разные места?
Сунуть его на подпись человеку, который не понимает ничего в нём и прикрыть тем самым себе разные места?Вы удивитесь — суть технического задания не в том чтобы описать себе процессы разработки, а в том чтобы согласовать «задумку» условного заказчика с реально работающим кодом. И ТЗ — это не только про «реализовать контроллеры a, b, и c, используя протоколы x, y, z», но и «В верхней части сайта расположено меню, содержащее следующие пункты:…, в дизайне представленном в приложении (6). При клике на пункт… ». То есть вполне себе сценарий использования, который доступен обывателю.
Вы удивитесь, но для некоторых сценарии использования — это входные данные для составления ТЗ, если оно составляется. Может в мире госзаказов и гостов всё несколько по другому, конечно.
Сценарии использования являются неотъемлемой частью ТЗ, так как функционал внутренний описывает ЧТО делать, а кейсы описывают механизмы взаимодействия с интерфейсом. И именно это будет проверять конечный заказчик перед приемкой и подписанием акта выполненных работ, а вовсе не то насколько тонкие у вас контроллеры.
Передача паролей в открытом виде имеет право на жизнь. Например в случае телефонной (голос или смс), почтовой (бумажной) или офисной поддержки. Но это должен быть одноразовый пароль.
Технологии, где даже сотрудник не знает такого пороля есть (очень надеюсь, что банки, дающие конверты с паролями и пинами их используют), но дороги.
А я вот вообще отказался от паролей.
В приложении хранится только email или телефон, при входе отправляется письмо (или смс) с одноразовым кодом, код валиден только 1 час + связан с email или телефоном.
Плюсы (из-за отсутствия паролей):
+ Пользователи не смогут делать простые пароли
+ Пользователь никогда не забудет свой пароль, не нужно делать механизм восстановления пароля
+ При краже базы пользователей не получится узнать пароли пользователей от других сервисов (а то ведь многие используют на сторонних сервисах почту и пароль от этой почты)
Минусы:
— Получив доступ к почте пользователя можно войти в любой сервис, но тут уже итак полный провал, если получили доступ к вашей почте то пиши пропало, даже там где есть пароли, там можно использовать восстановление
В приложении хранится только email или телефон, при входе отправляется письмо (или смс) с одноразовым кодом, код валиден только 1 час + связан с email или телефоном.
Плюсы (из-за отсутствия паролей):
+ Пользователи не смогут делать простые пароли
+ Пользователь никогда не забудет свой пароль, не нужно делать механизм восстановления пароля
+ При краже базы пользователей не получится узнать пароли пользователей от других сервисов (а то ведь многие используют на сторонних сервисах почту и пароль от этой почты)
Минусы:
— Получив доступ к почте пользователя можно войти в любой сервис, но тут уже итак полный провал, если получили доступ к вашей почте то пиши пропало, даже там где есть пароли, там можно использовать восстановление
Чем ваш «код» отличается от «пароля»?
Ммм, временем жизни (либо протух, либо использовали) он тут же удаляется из базы, т.к. вход произведён и выдана сессия. Коды не хранятся вечно.
Ах да, если по одному аккаунту 3 раза ввели неверный код, то все верные активные коды этого аккаунта автоматически удаляются, во избежание возможного брутфорса
Ах да, если по одному аккаунту 3 раза ввели неверный код, то все верные активные коды этого аккаунта автоматически удаляются, во избежание возможного брутфорса
То есть только наличие «времени действия»? Или попыток ввода? Что то это мне напоминает… ах да! Политику паролей. Вот так сюрприз, то есть по сути пароль от кода отличается политикой действия, которую просто можно усложнить. На самом деле пользоваться сервисом который каждый раз для входа будет присылать тебе В СТОРОННИЙ СЕРВИС твой «код», кроме того что сверхнеудобно, так еще и не так уж и безопасно.
Теперь вам известно три вещи о вашем сотруднике:Надо добавить что еще вам следует проверить себя на наличие параноидального синдрома.
Он знает ваш пароль.
Он хранит ваш пароль в чистом виде, не используя никакого шифрования.
Пароль обычно рандомно генерируется системой и ей же автоматически отправляется, и следовательно «сотрудник» про ваш пароль ни сном ни духом. И естественно пароль не хранится в открытом виде, после отсылки в базе останется только хеш пароля. В остальном — отправлять разовый ключ доступа или сгенерированный системой пароль почти одно и то же, разница в том что поведением разового ключа мы можем управлять (например не пускать второй раз, что впрочем можно реализовать и с временным паролем).
PS: В итоге в статье не только не рассказано как (точнее рассказано как не надо) хранить, но и тема где совершенно не раскрыта. Ожидал откровения и хитромудрых подходов, получил тухлый помидор, которым только и можно что пульнуть в автора сего опуса.
А как вы смотрите, чтобы в авторизационной куке хранить хеш пароля?
Чтобы слить базу и подставлять из неё?
Да, Вы правы.
Как я понял, хранить подписанную куку, основанную на хеше пароля, уже норм идея?
Зачем в ней хэш пароля? Пароль проверился при выдаче куки. В куке лежит подписанный юзерид, срок действия, возможно какой-то отпечаток окружения (айпи, юзерагент и т. п.), возможно конкретный набор прав пользователя. Сервер проверяет только подпись (свою же или доверенного аутентифицирующего/авторизационного сервера) без всяких обращений к базе и дальше полученным данным доверяет (вариант — ещё проверяет в списке отозванных, как правило в какой-то быстрой базе типа редиса)
НЛО прилетело и опубликовало эту надпись здесь
Такой алгоритм применяет форум SMF, правда там чуть сложнее — sha1(хеш пароля + сессионый хеш), вроде так. Минус в том, что имея SQL дамп, можно входить от любого пользователя, не тратя время на брут пароля и соли. Хотя, если слит дамп базы, то дела уже весьма плохи…
Автор, почему ничего не сказано про соль (salt)? Вы считаете это неактуальным или как? Под веб пишу редко, но помню, что раньше делали md5(pass.salt) и было нормально, т.е. от радужных таблиц уже спасало.
Автор, почему ничего не сказано про соль (salt)? Вы считаете это неактуальным или как? Под веб пишу редко, но помню, что раньше делали md5(pass.salt) и было нормально, т.е. от радужных таблиц уже спасало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
РНР-безопасность: где и как хранить пароли. Часть 1