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

Зачем хэшировать пароли? Сбербанк, Сбербанк Онлайн, Информационная безопасность, Безопасность, Пароль, Длиннопост, Скриншот, Twitter
Вы смотрите срез комментариев. Показать все
DELETED
Автор поста оценил этот комментарий
Подскажите, а с чем связано иногда? С какими-то конкретными уязвимостями в определённых api?
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Да

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

Автор поста оценил этот комментарий
Отлично объяснил, спасибо)
Автор поста оценил этот комментарий
Вы гений объяснений, сохранила коммент, спасибо
Автор поста оценил этот комментарий
Хорошего тебе хэша
Автор поста оценил этот комментарий
Очень подробно и правильно.

забыл только упомянуть про радужные таблицы для подбора пароля и коллизии хеш функций.

а так очень подробно!
Автор поста оценил этот комментарий
Вот за этим я и зашел в комменты (=
Автор поста оценил этот комментарий
А чё, реально пишется"хешь" а не хэш? Как то глазки режет немного. А так да обьяснил доступно
раскрыть ветку (1)
Автор поста оценил этот комментарий
Хешь оно писалось бы если бы было женского рода как мышь, дрожь и речь. У существительных мужского рода мягкого знака после шипящих нет, тип грач, гараж, камыш.
DELETED
Автор поста оценил этот комментарий
хешь...
Автор поста оценил этот комментарий
Спасибо добрый человек.
Автор поста оценил этот комментарий

спасибо,  просто и доступно. точно так же как и с вакциной для С19

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

Все хорошо, только хэш пишется без мягкого знака

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

Нет, ведь он возьмёт от хеша хеш и хеш хеша не совпадёт с хешем.

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

Хэш бола бола бала бола болала

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

Чую, чую, я кочую..

2
Автор поста оценил этот комментарий
Это-то понятно, но я имею ввиду, что если программу рассматривать как черный ящик и в качестве выходных данных при авторизации является хеш пароля пользователя, то почему бы не перехватить его и не использовать на своей версии программе в качестве выходных данных. Я понимаю, что там ещё есть дополнительные средства защиты, но вроде бы для такого фокуа ничего не мешает.
раскрыть ветку (4)
13
Автор поста оценил этот комментарий

Потому что хеш вычисляется на стороне сервера.

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

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

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

хеш вычисляется на сервере, но если вы можете перехватить чтото - то просто берите сам пароль и шлите его на сервер - сработает

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

Хэш защищает от воровства базы данных на сервере. От перехвата сообщения хеширование не помогает.

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

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

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

Верно мыслите. Признает. Но: хэш передаётся внутри защищенного соединения обязательно, иначе нет большого смысла в этом. https:// отлично подойдёт


Ошибся: хэш, скорее всего, считается на сервере, как верно сказали ниже #comment_179284521 . Но, тем не менее, в некоторых реализациях атака перехвата хэша имеет место быть.

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

Нет. Т.к. наш алгоритм авторизации вычисляет для любой строки, введённой в качестве пароля, хешь. Т.ч. что бы получить хешь "5f4dcc3b5aa765d61d8327deb882cf99" вы должны передать в качестве пароля "password", только "password" и ничего кроме "password". И проблема злоумышленника как раз в том, что он не знает ничего о вашем пароле, ведь у него есть только логин и хешь.

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

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

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

Для бесконечного числа хэшей существует бесконечное число коллизий.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий
Так они не бесконечны. Сравнение идёт только с результатами хэширования, хранязимися на сервере, то есть только с хэшфункциями паролей, которые пользователи вводили при регистрации.
раскрыть ветку (2)
1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Ну, это да. Если для на пароля не ограничена. А она ограничена почти всегда. Поэтому число коллизий все ещё не бесконечно.
Автор поста оценил этот комментарий
@moderator, добавьте в тело поста . Это очень важное пояснение.
Автор поста оценил этот комментарий

Спасибо! Теперь всё предельно ясно!

Предпросмотр
GIF186 Кб
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
Автор поста оценил этот комментарий
В нашей говноподелке пароли хэшируются и они тоже не чувствительны к регистру)
ещё комментарии
Автор поста оценил этот комментарий

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

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