Хранение истории паролей.

[noobieyii]

Добрый всем день. В одном проекте есть следующее требование к изменению паролей пользователей - пароль не должен совпадать ни с одним из последних 5 паролей этого пользователя (ага, действительно дурацкое требование). Соответственно, как я себе представляю реализацию - добавляю таблицу, в которой храню хеши старых паролей для пользователя(добавляю в эту таблицу при каждой смене). И, соответственно при смене пароля валидатором проверяю, а не было ли у пользователя уже такого хеша. С md5 это бы запросто сработало, но если использовать встроенный в Yii generatePasswordHash, то хеши создаются с использованием рандомной соли, соответственно, для одно пароля будут разные хеши, и просто сделать SELECT FROM old_passwords WHERE user_id = id AND hash='hash' не будет иметь смысла. Можно конечно сделать запрос всех паролей для этого пользователя из old_passwords и каждый проверить с помощью validatePassword, но если в требовании будет не 5, а 25, или 100 - то такой метод будет неприятным костылем. Второй вариант - хранить соль и для создания пароля не использовать Yii-шный generatePasswordHash, а использовать напрямую crypt(). Может быть кто-то посоветует альтернативные варианты?

[samdark]

Выбирать все и проверять по очереди — самое безопасное решение из предложенных.

[rugabarbo]

Можно конечно сделать запрос всех паролей для этого пользователя из old_passwords и каждый проверить с помощью validatePassword, но если в требовании будет не 5, а 25, или 100 - то такой метод будет неприятным костылем.

Почему такой метод считаете "неприятным костылём"?

[ElisDN]

Почему такой метод считаете "неприятным костылём"?

С учётом медленности crypt() выйдет по 0,2..0,3 секунды на каждую проверку. Для пяти паролей ещё терпимо.

[rugabarbo]

Почему такой метод считаете "неприятным костылём"?

С учётом медленности crypt() выйдет по 0,2..0,3 секунды на каждую проверку. Для пяти паролей ещё терпимо.

Даже больше.
>0,6s на процессоре не адаптированном под криптографию.
Просто я неправильно посчитал конечную цифру для обработки 100 паролей (60s, а я посчитал сначала 6s по ошибке...)

Автор, может всё-таки ТЗ на 100 паролей маловероятно? С точки зрения здравого смысла пользователь уже после смены 5 паролей поймёт, что в этой системе невозможно вбить свой старый пароль и оставит попытки это делать. Нет никакого смысла проверять последние 25, а тем более 100 паролей.

[noobieyii]

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

[zelenin]

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

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

[rugabarbo]

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

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

Для заказчика это будет звучать как попытка завуалировать свою неспособность реализовать задуманное. Лучше уж оценить каждый подход в часах/рисках и дать расклад по ним. Например:

1) Можем сделать проверку 5 последних паролей
Безопасность: высокая
Время реализации: 1 час

2) Можем сделать строго по ТЗ
Безопасность: средняя
Время реализации: 8 часов

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

Но пытаться объяснять заказчику технические нюансы (необходимость перебора паролей, скорость шифрования, etc.) - имхо, не самая лучшая идея.

[zelenin]

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

ок, принято. вы считаете заказчика дураком

Лучше уж оценить каждый подход в часах/рисках и дать расклад по ним.

конечно же. я это и написал. риски, предложения, фидбэк.

Но пытаться объяснять заказчику технические нюансы (необходимость перебора паролей, скорость шифрования, etc.) - имхо, не самая лучшая идея.

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

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

Исходить надо изначально из того, что исполнитель выбран за то, что он охеренен и поэтому неприкосновенен в технических вопросах. Аналогично, заказчик - главный в вопросах ux и ui. Если есть проблема, что выполнение ТЗ невозможно без визуального косяка (ожидание смены пароля 10+ сек/возможное длительное ожидание при ужесточении ТЗ в будущем), то заказчик должен узнать об этом и принять решение.

[rugabarbo]

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

ок, принято. вы считаете заказчика дураком

Я этого не говорил.
Заказчик зачастую некомпетентен в технических вопросах, но это не делает его дураком.

Но пытаться объяснять заказчику технические нюансы (необходимость перебора паролей, скорость шифрования, etc.) - имхо, не самая лучшая идея.

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

Если линейный программист сможет доступно объяснить эту техническую проблему заказчику далёкому от техники, то ОК. Это отличная идея. На практике, увы, программисты говорят на разных языках с заказывающей стороной.

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

Исходить надо изначально из того, что исполнитель выбран за то, что он охеренен и поэтому неприкосновенен в технических вопросах. Аналогично, заказчик - главный в вопросах ux и ui. Если есть проблема, что выполнение ТЗ невозможно без визуального косяка (ожидание смены пароля 10+ сек/возможное длительное ожидание при ужесточении ТЗ в будущем), то заказчик должен узнать об этом и принять решение.

Александр, нагнетаете обстановку на пустом месте (: По части UX полностью согласен, проблемы UX/UI можно и даже нужно включить в расклады. Например, так:

1) Можем сделать проверку 5 последних паролей
Безопасность: высокая
Время реализации: 1 час
Проблемы UX/UI: ожидание во время смены > 3-х секунд; чем больше было смен паролей, тем больше ожидание

2) Можем сделать строго по ТЗ
Безопасность: средняя
Время реализации: 8 часов
Проблемы UX/UI: нет проблем

(Напомню, что в варианте 2 реализация более длительная за счёт проработки шифрования без соли в обход Yii2-механизмов, за счёт этого же и безопасность стала ниже.)

Ну и про неприкосновенность технического специалиста в России я бы поспорил... Увы, у нас почему-то CEO считают себя умнее технарей (наверно, как нигде в мире), а технари упорно работают на таких CEO, если те посягают на их техническую неприкосновенность Но это отдельная тема. Я то с вами согласен, а автор явно сомневается в своей неприкосновенности, если до сих пор заказчику не объяснил всей тупости такого ТЗ

[zelenin]

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

ок, принято. вы считаете заказчика дураком

Я этого не говорил.
Заказчик зачастую некомпетентен в технических вопросах, но это не делает его дураком.

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

Если линейный программист сможет доступно объяснить эту техническую проблему заказчику далёкому от техники, то ОК. Это отличная идея. На практике, увы, программисты говорят на разных языках с заказывающей стороной.

"Техническая реализация будет заметна визуально в виде 10 секундного ожидания. Подробности рассказать?" - не "рокет сайнс".

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

Исходить надо изначально из того, что исполнитель выбран за то, что он охеренен и поэтому неприкосновенен в технических вопросах. Аналогично, заказчик - главный в вопросах ux и ui. Если есть проблема, что выполнение ТЗ невозможно без визуального косяка (ожидание смены пароля 10+ сек/возможное длительное ожидание при ужесточении ТЗ в будущем), то заказчик должен узнать об этом и принять решение.

Александр, нагнетаете обстановку на пустом месте (: По части UX полностью согласен, проблемы UX/UI можно и даже нужно включить в расклады. Например, так:

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

Ну и про неприкосновенность технического специалиста в России я бы поспорил... Увы, у нас почему-то CEO считают себя умнее технарей (наверно, как нигде в мире), а технари упорно работают на таких CEO, если те посягают на их техническую неприкосновенность Но это отдельная тема. Я то с вами согласен, а автор явно сомневается в своей неприкосновенности, если до сих пор заказчику не объяснил всей тупости такого ТЗ

ситуация проста: профессиональное уважение к себе зачастую коррелирует с профессиональными скиллами. Но все это касается только вольнонаемной работы - в офисе уравнение добавляется еще несколькими переменными )

[rugabarbo]

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

Максимально исключить технические подробности о длительности шифрования, необходимости перебора, солях всяких и прочем подобном. Не понимают они их. В силу технической некомпетентности, а не глупости.

[zelenin]

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

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

[rugabarbo]

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

Долго объяснять и писать - лень (:

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

Я думаю, что для ТС наш диалог итак послужит хорошей пищей для размышлений (;

[rugabarbo]

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

Саша, кстати, в качестве оффтопа в ответ на это захотелось скинуть тебе такую статью: http://megamozg.ru/post/4556/
В частности, интересен вывод автора:

Итак, вкратце выводы: мозг нужен человеку для поддержания социальных связей и манипулирования другими людьми; а речь — средство для социальных взаимодействий. Способность лгать, мошенничать, читерить, а равно и дружить (с кем-то и против кого-то), заключать союзы и действовать сообща — это именно то, что отличает человека (и в какой-то степени приматов) от животных; и, вполне возможно, самосознание также появилось для того, чтобы лучше манипулировать другими людьми.

Поэтому, когда я читаю пафосные рассуждения очередного философа-моралиста о низменности человеческой природы и о том, что человек хуже зверя — мне, если честно, становится смешно. Наши древние предки, по большому счёту, потому и стали людьми, что научились обманывать (см. false belief test) и интриговать. Не нравится? Ищите другой глобус.

Для меня, например, он немного объясняет происходящее вокруг ))

[zelenin]

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

Саша, кстати, в качестве оффтопа в ответ на это захотелось скинуть тебе такую статью: http://megamozg.ru/post/4556/
В частности, интересен вывод автора:

Итак, вкратце выводы: мозг нужен человеку для поддержания социальных связей и манипулирования другими людьми; а речь — средство для социальных взаимодействий. Способность лгать, мошенничать, читерить, а равно и дружить (с кем-то и против кого-то), заключать союзы и действовать сообща — это именно то, что отличает человека (и в какой-то степени приматов) от животных; и, вполне возможно, самосознание также появилось для того, чтобы лучше манипулировать другими людьми.

Поэтому, когда я читаю пафосные рассуждения очередного философа-моралиста о низменности человеческой природы и о том, что человек хуже зверя — мне, если честно, становится смешно. Наши древние предки, по большому счёту, потому и стали людьми, что научились обманывать (см. false belief test) и интриговать. Не нравится? Ищите другой глобус.

Для меня, например, он немного объясняет происходящее вокруг ))

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

[samdark]

Ушли в оффтоп

Если вернуться к нашим баранам... я видел «не должно совпадать с предыдущими паролями за 2 месяца» у Microsoft и оно работало относительно быстро. Значит ли это, что у них не blowfish, а что-то вроде PBKDF2 с не сильно большим количеством итераций?

[noobieyii]

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

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

А почему вы считаете, что я не пытался объяснить заказчику, что это проблемный момент? Заказчик может быть и дураком и гением и седобородым волшебником Гендальфом, тем не менее он остается человеком, который ставит набор требований и оплачивает разработчику реализацию этих самых требований. Если они абсолютно невменяемые - всегда есть возможность не браться за эту работу. В моем же случае, кроме этого момента - меня все устраивает. На самом деле, если говорить совсем уж откровенно, то и это требование не является совсем уж идиотским, просто это такой "привет из энтерпрайза", не совсем уместный и необходимый. Тем более, в первом сообщении я как раз и интересовался у коллег, может быть есть какой-то более "быстрый" способ для решения этой проблемы - выяснилось, что я шел в правильном направлении, и фактически, альтернативного метода сделать эту проверку нет. В итоге, заказчика все-таки удалось склонить к проверке 5 последних паролей, что более-менее приемлемо.

[noobieyii]

И все еще раз большое спасибо за интерес к теме и советы.

[rugabarbo]

Если вернуться к нашим баранам... я видел «не должно совпадать с предыдущими паролями за 2 месяца» у Microsoft и оно работало относительно быстро. Значит ли это, что у них не blowfish, а что-то вроде PBKDF2 с не сильно большим количеством итераций?

Вероятно, делают ставку на более защищённое хранилище данных, используя при этом более простые алгоритмы, которые позволяют точно сопоставить одному паролю один хэш (соответственно поиск пароля в истории сводится к одному запросу).

Иначе мне не представляется возможным быстро пройтись по истории паролей.

Это же Microsoft