Зачем хэшировать пароли?

Зачем хэшировать пароли? Сбербанк, Сбербанк Онлайн, Информационная безопасность, Безопасность, Пароль, Длиннопост, Скриншот, Twitter
Вы смотрите срез комментариев. Показать все
51
Автор поста оценил этот комментарий
Добрый день. Уточнила у коллег. Для удобства пользователей, все пароли приводятся к виду "qwerty" и хранятся в базе в виде хеша
раскрыть ветку (6)
17
DELETED
Автор поста оценил этот комментарий
Не к виду, а просто к "qwerty"
20
Автор поста оценил этот комментарий

Это российский сервис. Поэтому не qwerty, а йцукен.

раскрыть ветку (4)
6
Автор поста оценил этот комментарий
В сбербанк- бизнесонлайне к "йцукен олдж".
раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Ээээ блэээт туох дьигин дэ
4
Автор поста оценил этот комментарий

-Тьфу, рейнджер! Этот транспорт моя добыча.

-Меня интересует не твоя добыча, меня интересуешь ты, Йцукен!

раскрыть ветку (1)
6
Автор поста оценил этот комментарий
Предпросмотр
YouTube3:01
8
Автор поста оценил этот комментарий

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

12
Автор поста оценил этот комментарий
Хэширование — это, фактически, одностороннее (необратимое) шифрование. Пихаешь в функцию "Qwerty", а она тебе выдаёт "acbd9ab2f68bea3f5291f825416546a1" (если скормить этой функции "войну и мир", она тоже превратится в 32 знака).

Короче, фишка в том, что сравниваются не пароли, введённый пользователем и хранящийся в базе, сравниваются их хэши — поэтому если кто-то украдёт из базы хранящийся там хэш, использовать его вместо пароля он не сможет.
раскрыть ветку (3)
Автор поста оценил этот комментарий
Потому-что, чтобы взломать нужно обязательно умыкнуть пароль?)
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

В нормальных системах типа банка - да

Автор поста оценил этот комментарий

Шифрование предполагает ключ же.

11
DELETED
Автор поста оценил этот комментарий

Функция которая производит какие то действия со строкой. Для каждой уникальной строки уникальный результат. И что самое важное из результата нельзя восстановить первичную строку

раскрыть ветку (20)
14
Автор поста оценил этот комментарий
Где-то смеётся одна коллизия
раскрыть ветку (6)
11
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
4
Автор поста оценил этот комментарий
Да потому что это не детали. Хеш функция принимает на вход строку любой длины и алфавита и возвращает строку фиксированной длины и алфавита. Ни о какой уникальности речи принципиально идти не может.
раскрыть ветку (3)
11
DELETED
Автор поста оценил этот комментарий

И при этом с вашим объяснением, со стороны - нихуя не понятно. Человек выше просто дал объяснение для обыватели, а вы приебались к деталям.

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

1
Автор поста оценил этот комментарий

Но при этом совпадение маловероятно.

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

При росте количества символов хешируемой строки, количество уникальных хешей будет стремится к 0, так как невозможно "запихнуть" строку произвольной длины в уникальную строку фиксированной длины.

1
Автор поста оценил этот комментарий

Одиноко плачет в бесконечности. Если существует, конечно.

3
Автор поста оценил этот комментарий
С уникальным результатом -- это сильно))
раскрыть ветку (12)
3
DELETED
Автор поста оценил этот комментарий

В рамках объяснения для человека не в теме. Этого достаточно.

Это как с замком. У всех замков есть уникальных ключ. То что есть отмычки, бампинг, или можно открыть другим ключом, вопрос реализации и эксплуатации.

раскрыть ветку (11)
2
Автор поста оценил этот комментарий
В том-то и дело, что у замков ключ не уникальный. Точно так же, как никто не может гарантировать, что у двух разных паролей не совпадет хеш.
раскрыть ветку (10)
2
DELETED
Автор поста оценил этот комментарий

Это важно для обьяснения принципа?
Вспомните математику.
Вначале вам говорят есть только положительные числа и ноль.
потом появляются отрицательные.
потом говорят что корень из числа может быть только положительным
потом выясняется что есть мнимые числа.

Для обьяснения принципа, можно сказать что они уникальны. Можно сказать, что они псевдоуникальные. В рамках топика, важно что это механизм, который позволяет превратить пароль, во что то не читаемое, и что если его украдут, то пользователь не потеряет деньги.

Не надо плодить детали и сущности там где они нахер никому не нужны))

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

раскрыть ветку (9)
Автор поста оценил этот комментарий

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

раскрыть ветку (8)
DELETED
Автор поста оценил этот комментарий

Окей. Давайте поиграем. Какой шанс коллизей у sha-256 или sha-512.?

раскрыть ветку (7)
Автор поста оценил этот комментарий
Во-первых, коллизий. А во-вторых, хешмапы используются не только для шифрования паролей, но и для быстрого поиска. Если для первой цели можно использовать sha-512, то для поиска использовать такой длинный хеш нельзя, так что коллизии в хешировании -- это очень частое явление.
раскрыть ветку (6)
3
Автор поста оценил этот комментарий
Хэш, хэш, они курят хэш, я бы тоже покурил, но у меня нету кэш
Автор поста оценил этот комментарий

Запароливание пароля.

Автор поста оценил этот комментарий

Необратимое однозначное преобразование информации. Или вас нижний регистр напрягает?

Автор поста оценил этот комментарий
Предпросмотр
YouTube0:15
13
Автор поста оценил этот комментарий

Ну конечно хэшируют, решение с lowercase тоже весьма элегантное.


Во всяком случае намного приятнее чем @бнутые требования вносить пароль разным регистром, использовать буквы, цифры и специальные знаки. Так достали эти требования, что сил нет. Если я хочу использоваться пароль password, дайте мне это сделать и отъебитесь со своей валидацией, тем более что все действия защищены вторым фактором (смс пароль).

7
Автор поста оценил этот комментарий
Не в нижний, а в верхний. Потом солят. И только потом хэшируют.
раскрыть ветку (6)
Автор поста оценил этот комментарий
Какая разница в нижний или верхний?
раскрыть ветку (5)
12
Автор поста оценил этот комментарий
Перевод в верхний регистр более однозначен, может увеличить длину пароля (straße -> STRASSE), а сравнение символов верхнего регистра более эффективно (это особенность системных библиотек сравнения строк).
раскрыть ветку (4)
5
Автор поста оценил этот комментарий

ß -> SS

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

1
Автор поста оценил этот комментарий

Спасибо.

1
Автор поста оценил этот комментарий

Так сравнивается хэш или апкейс?

раскрыть ветку (1)
Автор поста оценил этот комментарий
Поздновато, конечно, но отвечу.
Сбер, если мне не изменяет память, при изменении пароля проверяет, что пароль не совпадает с логином, что в нём нет запрещённых символов и что его нет в списке «плохих» паролей. При такой базе клиентов, как у Сбера, даже одна наносекунда экономии времени на одну проверку очень важна. А раз функция нормализации регистра уже есть в одном месте, писать другую для другого места никто не станет.
ещё комментарии
Автор поста оценил этот комментарий
Оч похоже на то, что она по скрипту отвечает
Автор поста оценил этот комментарий

SMM-щик может этого не знать. Я работала "по ту сторону" (не Сбера, но крупного бренда), там адовые правила. Тебя нанимают вести страницу и следить, что там про сбер говорят в соцсетях. Для коммуникации и сложных проблем есть связь с менеджером Сбера, который перенаправит к компетентным сотрудниками, которые знают, например, про хэширование. Но на деле оказывается так: у девочки спрашивают вот это, по правилам у нее 1-3 часа на ответ. И вот она пишет менеджеру, менеджер проебался, потому что на него навалились другие проблемы, максимум что можно сделать - загуглить, ну или забить, сославшись на менеджера, но они это не любят. Поэтому человек рискнул, у него не вышло, но мало ли что случилось по ту сторону. Когда мне отвечают в комментарии, я всегда пишу "передайте начальству", потому что знаю, что мой негатив обрабатывают ни в чем не повинные люди))

1
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Я погромист.)
Автор поста оценил этот комментарий

Всм? Дак тогда ни с каким регистром кроме нижнего не получится залогинится.

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Например, пользователь вводит пароль PIKaBu, на сервер отправляется POST-запрос с паролем PIKaBu, потом сервер делает "PIKaBu".toLowerCase(), хеширует, сравнивает хеш с хешем в бд.

toLowerCase() можно и на стороне клиента делать джаваскриптом и отправлять запрос уже с паролем в нижнем регистре.


Вообще пароли прям открыто запросом не отправляют, обычно. Это я для упрощения.

8
Автор поста оценил этот комментарий

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

раскрыть ветку (9)
2
Автор поста оценил этот комментарий
Только регистонезависимость уменьшает число вариантов в ~100 раз
раскрыть ветку (8)
3
Автор поста оценил этот комментарий

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

1
Автор поста оценил этот комментарий

Мало людей которые создают регистрозависимые пароли. Максимум первая буква заглавная.

раскрыть ветку (6)
1
Автор поста оценил этот комментарий
Это статистические данные?
раскрыть ветку (3)
Автор поста оценил этот комментарий

Вы только в статистику верите?

Ну тогда приведите их.

Я кроме программистов ни у кого из знакомых не видел пароли у которых бы регистр менялся в середине пароля.

раскрыть ветку (2)
2
Автор поста оценил этот комментарий
Зачем вы подсматривание пароли знакомых?
раскрыть ветку (1)
Автор поста оценил этот комментарий

Работа такая.

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

Автор поста оценил этот комментарий
Есть сервисы, которые требуют, чтобы пароль содержал буквы разного регистры, цифры, спец символы и не более 2 повторений любого символа. Иначе просто не зарегаться или не поменять пароль
раскрыть ветку (1)
Автор поста оценил этот комментарий

Да, в этом случае делается первая заглавной

6
Автор поста оценил этот комментарий

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

ещё комментарии
ещё комментарии
35
Автор поста оценил этот комментарий

Осталось выяснить, почему у сбера раз в полгода базы угоняют..

раскрыть ветку (9)
14
Автор поста оценил этот комментарий

Я только один раз видел, и то это сотрудник - админ напрямую с базы дернул. Вы другие случаи видели?

раскрыть ветку (8)
9
Автор поста оценил этот комментарий
Всегда подозревал, что базы пиздят именно админы, но права почему-то постоянно урезают пользователям.
раскрыть ветку (1)
41
Автор поста оценил этот комментарий
Иначе бы пиздили ещё и пользователи)
2
Автор поста оценил этот комментарий
Видел, даже несколько баз. Возможно, вспомню место, где их можно скачать. Сам никогда не делал, так как противозаконно.
раскрыть ветку (5)
3
Автор поста оценил этот комментарий

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

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

я и говорю - один раз такое было и это была новость на неделю. после и до - тишина

раскрыть ветку (2)
Автор поста оценил этот комментарий
Какая разница? Данные слиты. Ещё бы они, блять, сливались раз в неделю. Вам и одного слива хватит, если попадете в список
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

И в той утечке не было паролей от аккаунтов (ибо они захешированы), а. Были номера карт и много чего ещё. Косяк? Косяк. Но с паролями не связан.

21
DELETED
Автор поста оценил этот комментарий

Может быть, ей стоило тогда уточнить у компетентных коллег? Вопрос довольно важный.

раскрыть ветку (8)
26
DELETED
Автор поста оценил этот комментарий
Это не так просто, как кажется. Они не за соседними столами сидят, и даже не в одном городе. Что бы найти человека который ответит на ее вопрос, она убьет дофига времени, если вообще сможет его найти среди десятков тысяч ИТшников.

Плюс в Сбере, ИТшники вроде как в отдельных конторах сидят и офисах. То есть простой девочке до них, возможно даже достучаться не получится.
раскрыть ветку (7)
10
DELETED
Автор поста оценил этот комментарий

Это и не так сложно как кажется, у нее есть руководитель/куратор, она пишет/звонит ему, тот оперативно пересылает запрос на службу Безопасности или АйТи поддержку, те отвечают. Можно сразу в хелпдеск написать, но тогда реально могут сутки отвечать, так то информация не секретная.

раскрыть ветку (2)
8
DELETED
Автор поста оценил этот комментарий
А могут не сутки, могут вообще не ответить из за подписанного NDA.
раскрыть ветку (1)
3
DELETED
Автор поста оценил этот комментарий

Хелпдеск не может не ответить, они скорее всего по СРМ какому-то работают, это тебе не техподдержка пользователей в Ростелекоме.

3
DELETED
Автор поста оценил этот комментарий

В таком случае лучше тогда совсем не отвечать, чем отвечать во вред.

Автор поста оценил этот комментарий
Я работала в дежурной смене по сопровождению автоматизированных систем для работников сбера. Айтишники из смены сидели в одной огромной комнате с админами, все необходимые номера телефонов (например, администраторов баз данных наших систем) мы знали наизусть + листок с этими номерами лежал на рабочем месте. Так что тот, кто отвечал в чате без особого труда мог уточнить инфу у администраторов
раскрыть ветку (2)
DELETED
Автор поста оценил этот комментарий
Конечно же, тот кто отвечал сидел где то рядом с вами и вашим направлением)))) И конечно у каждого рядового сотрудника есть номера телефонов, админов баз данных))))

А вы, конечно же в свою очередь без труда могли найти номер телефона нужного сотрудника отдела качества, к примеру))))
раскрыть ветку (1)
1
Автор поста оценил этот комментарий
У сотрудников есть доступ к системе с почтой и телефонами всех работников сбера ... Так что, да, можно было найти номер телефона любого сотрудника
13
Автор поста оценил этот комментарий
Так то и мальчик может этого не знать. Но спросить у старших, прежде чем ответить, должен был.
раскрыть ветку (2)
7
DELETED
Автор поста оценил этот комментарий
Пойди спроси, когда их там 200 тысяч, они в разных организациях/на аутсорсе, и не понятно в целом кому идти и имеет ли он право рассказывать.
раскрыть ветку (1)
DELETED
Автор поста оценил этот комментарий

Ну блин, не в коридор же выходят спросить, чё вы уж

6
Автор поста оценил этот комментарий
А почему обязательно девочка? Тупых мальчиков априори не бывает? Или мальчики не работают сммщиками?
10
Автор поста оценил этот комментарий

Разжую непонятную дичь для людей и ЛЛ.
Девушка не довольна уровнем безопасности хранимых Сбербанком личных данных. Дело в том, что для сохранности данных от злоумышленников пароли шифруются так называемым "HASH'ем", то-есть созданный вами пароль проходит процедуру шифрования и записывается в базу данных учетных записей в измененном виде.

Предположим пароль PasSwOrd в виде хеша будет записан как 472c782e2ea863cf9c98efe3984f908a

а пароль password будет представлен в виде 5f4dcc3b5aa765d61d8327deb882cf99.


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


Как видите хеш суммы паролей разные, злоумышленник получив ваш пароль в виде хеш суммы будет озадачен подбором всех вариаций паролей. Но @Sberbank хранит наши пароли в открытом виде, это чревато тем что у сотрудника банка или злоумышленника при наличии доступа к базе данных будет одна из самых больших баз данных логинов и паролей, и ему не нужно напрягаться с взломом пароля ведь все в открытом виде username:password

раскрыть ветку (2)
2
Автор поста оценил этот комментарий
Судя по всему, Вы не из ЛЛ, поэтому прошу перечитать ветку. Уже допустили, что хеширование вероятно, так как возможно приведение пароля к единому регистру и на этапе регистрации, и на этапе авторизации. Я для личного проекта писал функцию регистрации с подсаливанием и хешированием - и разум подсказывает мне, что такая серьезная и большая компания не будет игнорировать такие элементарные приемы. Единственное, что мы знаем точно - это тот маленький факт, что пароль регистронезависим. Все остальное - фантазии на основе этого маленького факта.
Автор поста оценил этот комментарий
На самом деле не факт что они хранят в открытом виде. Они могут как и при регистрации, так и при проверке приводить пароль к нижнему или верхнему регистру. Но всё-таки вероятно что хранят в открытом виде.
1
Автор поста оценил этот комментарий
В нашей говноподелке пароли хэшируются и они тоже не чувствительны к регистру)
7
Автор поста оценил этот комментарий

Хеши слов с разным регистром не совпадают. Любое изменение в регистре приводит к новому хешу. Комбинации такого рода посчитайте сами. И в целом безопасностью тут не пахнет.

раскрыть ветку (19)
27
Автор поста оценил этот комментарий

Я не спец по защите информации поэтому спрошу у вас. Может быть такое, что пароль из формы по https летит на сервер, а там его toLowCase и уже потом хешируют и хранят хеш?

раскрыть ветку (9)
20
Автор поста оценил этот комментарий

Может даже быть что его и на вашем устройстве унижают в нижний регистр переводят.

9
Автор поста оценил этот комментарий
Да не, быть такого не может.
Автор поста оценил этот комментарий

Хоть вопрос и не был адресован мне: что там у них на сервере, одним им известно, но пароль уходит в том виде, в каком его вводишь в поле:

{"password":"TEST","pageInputType":"INDEX","login":"TEST","loginInputType":"BY_LOGIN","storeLogin":false}

1
Автор поста оценил этот комментарий

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

ещё комментарии
4
Автор поста оценил этот комментарий

Сразу видно что вы нубас :)

раскрыть ветку (6)
2
Автор поста оценил этот комментарий

Ну вот мне про аперкейс и ловкейс подсказали. Что не отнимает того факта что такого рода пароль теперь легче своровать/подобрать.
#comment_179277286

раскрыть ветку (5)
3
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
Автор поста оценил этот комментарий

Каждый символ увеличивает достаточно сильно время подбора. Своровав бд с хешами очень просто понять там в каком регистре всё захешировано. А дальше с этими же паролями но с разными регистрами ломимся на другие сайты и сервисы.

раскрыть ветку (3)
2
Автор поста оценил этот комментарий

вы отвечаете не понимая сути, да? потому что каша.
"Каждый символ увеличивает достаточно сильно время подбора" - и? даже предположив, что вы имеете ввиду не кол-во символов, а набор символов (ну типо с регистром 50, без регистра 25) вы все равно пишете не разобравшись в моем ответе - там на брутфорс и с таким "укороченным) алфавитом не хватит времени на взлом.
"Своровав бд с хешами очень просто понять там в каком регистре всё захэшировано." - как своровать это и с чего вы решили что по хэшу легко понять регистр пароля??? К чему этот комментарий? (я говорю что на воровство не влияет криптостойкость и насрать на регистрозависимость, а вы пишете просто текст какой-то)

раскрыть ветку (2)
4
Автор поста оценил этот комментарий

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

1
Автор поста оценил этот комментарий

просто добавляешь функцию приведения к нижнему или верхнему регистру перед хешированием.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Мать с ним я об другом, ну да похер. Всё равно это не правильно.

4
Автор поста оценил этот комментарий

Проверил  - действительно регистронезависимые.

Даже если "20 летняя девочка не знает что такое хеширование", то варинта два:

1. пароли хранятся в открытом виде/сравниваются расшифрованные (что почти одинаково)

2. хешируются все варианты пароля, во что я не верю :D

Подскажите, м.б. я чего то не знаю?

раскрыть ветку (7)
35
Автор поста оценил этот комментарий

Вариант 3, в функции хеширования первой строкой to_lower().

раскрыть ветку (4)
9
Автор поста оценил этот комментарий
Самый очевидный вариант. Но кому-то надо было выпендриться и показать всем, что он знает, что такое хэширование.
раскрыть ветку (3)
Автор поста оценил этот комментарий

Судя по второму варианту, не знает

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

Да, может быть и меньше, если меньше букв, но в принципе число показательно

раскрыть ветку (2)
Автор поста оценил этот комментарий
Не 8! , а 2^8
раскрыть ветку (1)
Автор поста оценил этот комментарий

Не 2^8, а (длина алфавита хеша)^(длина хеша в символах алфавита). Например, 64^8, если брать восемь символов вида [a-zA-Z0-9_+].


Ну или проще 2^(длина хеша в битах), но это вряд ли 8.


У популярного md5 (не пытайтесь повторить это дома) это 2^128.

8
Автор поста оценил этот комментарий
Сначала приводится к нижнему регистру, потом хешируется. Введеный потом пароль перед сравнением хеша тоже приводится к нижнему регистру.
3
Автор поста оценил этот комментарий
3. Пароль переводится в нижний регистр и хешируется. Как при регистрации, так и при авторизации. Или в верхний регистр. Или регистр меняется через один символ.
Автор поста оценил этот комментарий

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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку