AL
Мне одному кажется, что это делал какой-то, простите, мудак? о.О
Size: a a a
2020 September 08
SL
это уменьшает стойкость пароля.
SL
Мне одному кажется, что это делал какой-то, простите, мудак? о.О
ой. я что-то похожее делал (не уверен что для паролей), но принудительно делал lcase и потом хешировал, что бы пользователи-мудаки не путались в регистре
AL
ой. я что-то похожее делал (не уверен что для паролей), но принудительно делал lcase и потом хешировал, что бы пользователи-мудаки не путались в регистре
Эмм.... я как-то... смущён, что-ли... В общем такие дырки делать странно.
SL
я не спец в крипто стойкости, но имхо уменьшение "стойкости пароля" тут не критичное.
но уменьшает количество звонков в поддержку когда какой-то пользователь забыл какой регистр он использовал когда писал имя своей собаки в качестве пароля.
но уменьшает количество звонков в поддержку когда какой-то пользователь забыл какой регистр он использовал когда писал имя своей собаки в качестве пароля.
F
Эмм.... я как-то... смущён, что-ли... В общем такие дырки делать странно.
Ну это не дырка, на самом деле ерунда, с теми методами которые есть для разбора хэша, и современных мощностях, увеличение диапазона вообще UC или LC не имеет значения
AL
Ну это не дырка, на самом деле ерунда, с теми методами которые есть для разбора хэша, и современных мощностях, увеличение диапазона вообще UC или LC не имеет значения
Зависит от алгоритма хэширования сильно.
AL
Размер алфавита для создания хэша влияет на скорость подбора экспоненциально же.
AP
Размер алфавита для создания хэша влияет на скорость подбора экспоненциально же.
формально да, но есть такая штука, как rainbow table
AS
Много всего влияет: соль, алгоритм хеширования (например, какой либо pbkdf2 заколебутся "в лоб" ломать). Также к паролю можно дописать уникальный идентификатор пользователя, который вообще хранится в другой системе. Кроме того, реальная массовая опасность может возникнуть только при утечке базы, только тогда применимы радужные таблицы и вот это вот все.
AP
в любом случае, хэширование на сервере совершенно никак не связано со стойкостью пароля или устойчивостью к перебору.
Оно имеет совершенно другую цель - снижение вероятности утечки plaintext-паролей при взломах
Оно имеет совершенно другую цель - снижение вероятности утечки plaintext-паролей при взломах
AP
очень грубо - хэш от админов, а не от юзеров )
AS
Ага, и ещё чтобы выиграть время, если какой-то админ сольет БД 😂
AP
так я об этом и
AP
Мне одному кажется, что это делал какой-то, простите, мудак? о.О
кстати, скорее всего, это просто делали два разных человека - один выполнил требования безопасников по составу пароля на фронте, а другой выполнил требования бизнеса про "чтоб юзеры не путались в строчных и заглавных буквах" )
A
кстати, скорее всего, это просто делали два разных человека - один выполнил требования безопасников по составу пароля на фронте, а другой выполнил требования бизнеса про "чтоб юзеры не путались в строчных и заглавных буквах" )
🤣🤣🤣 Не удивлюсь, если даже 2 разных Департамента.
AP
Ну да, скорее всего
AG
На самом деле стойкость пароля к перебору не так уж важна в данном случае, потому что основная защита - двухфакторная аутентификация. Теоретически можно сделать пароль 6 цифр и смс-код 6 цифр, угадать или подобрать через интерфейс невозможно. А через базу- там такая длина пароля, что с современными средствами можно считать, что пароли открытые лежат.
RT
Много всего влияет: соль, алгоритм хеширования (например, какой либо pbkdf2 заколебутся "в лоб" ломать). Также к паролю можно дописать уникальный идентификатор пользователя, который вообще хранится в другой системе. Кроме того, реальная массовая опасность может возникнуть только при утечке базы, только тогда применимы радужные таблицы и вот это вот все.
rainbow table будет неприменимы, если используются уникальные случайные соли (salt) для каждой записи о пароле и случайная соль сервиса как секрет (pepper). Современные хэш-функции для хранения паролей сразу имеют в аргументах параметры salt & pepper
AS
Я вроде так и сказал - зависит от соли и вообще реализации всего этого дела. Мы же не знаем как в Сбере это сделано на самом деле, но по крайней мере по откровенно провокационному сообщению в твиттере уже сделали вывод, что Сбер - полное дно 😂