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

Зачем хэшировать пароли? Сбербанк, Сбербанк Онлайн, Информационная безопасность, Безопасность, Пароль, Длиннопост, Скриншот, Twitter
Вы смотрите срез комментариев. Показать все
309
Автор поста оценил этот комментарий

Если она не поняла вопроса и при этом говорит "нет" - это, в любом случае, минус Сбербанку, ведь он не нанимает компетентных сотрудников.

А пароли может и хешируют - переводят в нижний реестр, а потом хешируют. А может и нет. Мы вряд ли узнаем.

раскрыть ветку (209)
309
Автор поста оценил этот комментарий
Да что это за хеширование блять такое, а?
раскрыть ветку (168)
2145
Автор поста оценил этот комментарий

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


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


Например: md5("password") = "5f4dcc3b5aa765d61d8327deb882cf99".

(md5 - алгоритм хеширования, не самый лучший но для примера норм)


У хеширующих функций есть 2 важных свойства:

1) необратимость - т.е. нельзя из "5f4dcc3b5aa765d61d8327deb882cf99" получить "password" никак, кроме как методом перебора (по этому с ростом производительности железа появляются всё более сложные алгоритмы хеширования - что бы перебор был слишком долгим)

2) идемпотентность - т.е. сколько бы раз вы не вызывали функцию md5 с аргументом "password" каждый раз будете получать один и тот же результат, на любом компьютере в мире.


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


Зачем это делается? Допустим злоумышленник украл базу пользователей нашего сайта. Теперь у него есть логины и хеши паролей. Если он попытается авторизоваться под вашим логином и хешом на сайте, то произойдет следующее:


1) вводит логин и украденный хешь "5f4dcc3b5aa765d61d8327deb882cf99" в качестве пароля

2) наш сайт вычисляет хешь для введённого пароль, т.е. md5 для строки "5f4dcc3b5aa765d61d8327deb882cf99" - получаем "696d29e0940a4957748fe3fc9efd22a3". Совсем не то, что сохранено в нашей базе - в авторизации отказано.


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


Алгоритм вычисления хеша может быть сложнее, например хешь может вычисляться последовательно 10 000 раз (т.е для вашего "password" вычисляется хешь, потом для этого хеша вычисляется хешь, потом ещё раз и так 10 000 итераций).


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


Хешь могут вычислять с приминением ключей шифрования.


Ну и т.д. и т.п.

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

Лучшее объяснение хеша в этой ветке, плюс

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

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

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

Типа как как сваривать две детали под потолком (хоть я и не сварщик).

Или как работать на очень редком ЧПУ станке, которых осталось всего 2 штуки и обе они в Гваделупе.

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

Это тот пост где был нереально идеальный шов но не там где надо?)

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

А можно скинуть водички попить?

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

А можете скинуть три цифры с задней стороны кредитки?

раскрыть ветку (1)
14
Автор поста оценил этот комментарий
247, всегда пожалуйста!
8
Автор поста оценил этот комментарий

А можете скинуть ссылку на второе?

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

и пи ра жооок

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

И компот.

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

А можно скинуть еще и на десерт?

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

Спасибо, так понятнее))

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

Хорошо прямо написали, почти для домохозяек.


Еще чуть попроще бы, а также объяснить на пальцах соль и радужные таблицы, и можно выводить в продакшн :-)

раскрыть ветку (8)
13
Автор поста оценил этот комментарий
а также объяснить на пальцах соль и радужные таблицы, и можно выводить в продакшн :-)
звучит как призыв к закладкам
раскрыть ветку (3)
8
Автор поста оценил этот комментарий

Обколются своими солёными хэшами и ябут друг друга в жопы :-)

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

... и смотрят в свои радужные таблицы :)

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

в продакшн же

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

Про "соль":

Вот например одно из самых простых хэширований:

четные - ставим 1

нечетные - ставим 7

все буквы считаем по номеру в алфавите и складываем до одного числа.

Берем пароль - test123

его хэш получается:

t - 20, соответственно число 2

e - 5,

s - 19, 2

t - 2

1 - 7 (нечетные у нас же под 7)

2 - 1

3 - 7

Итого Хэш нашего "test123" получается - 2522717

Тепер мы решили "посолить" - усложнить, по определенному алгоритму, хэш.... Даже не знаю... Пусть если в хэше было изначально 2 символа, после него полявится цифра 7. У нас с 2-мя символами были t и s

соответственно теперь получается 27527217, заметили разницу?

Вот этим и отличаются хэш и "засоленный" хэш.


Это самый примитивный вариант, конечно же.

Но в программировании, каждый символ имеет свой id, и он из многих символов, таким образом "А" и "а" может отличаться, поэтому многие сайты требуют в pass'e символы обоих регистров.

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

s - 19 => 1+9=10 => 1+0=1, откуда двойка у вас?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Да, все верно)) напрограммировал бы 😀
на ночь глядя писал, допустил ошибку
Автор поста оценил этот комментарий

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


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

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

Без мягкого знака

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

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

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

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

легко отловить даже изменение одного бита

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

Ну, при помощи биты можно узнать даже самый криптостойкий пароль.

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

ХешЬ?!? О мои глоза!

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

Орешьки хешью. С солью.

Сьешь йих.

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

СПАЙСибо

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

Написано прекрасно, но есть одно зчмечание. Идемпотентность — это другое свойство. Функция f нащывается идемпотентной, если f(f(x)) = f(x) для любого x. А способность давать всегда один результкт на одном аргументе — свойство вообще любой функции (функции в математическом смысле, разумеется)

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

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

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

Именно. На эту неточность я и указал

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

Чо вы несёте то.


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

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

КЧДерево то же самое написал:

f(f(x)) = f(x)

Что именно тебя не устроило?

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

Вот это:

Согласно этому определению, хеш-функции как раз таки не должны быть идемпотентными, чтобы можно было вызывать функцию с хешем в виде аргумента.
DELETED
Автор поста оценил этот комментарий
Он написал функцию из функции
А имелось ввиду, что хоть на каком компьютере используй функцию, ответ будет тот же при одном Х
Автор поста оценил этот комментарий

Тогда в посте Как защищают наши пароли в сети рекомендую сделать апдейт через модератора, указав ссылку на это уточнение)

1
Автор поста оценил этот комментарий
Рад что не мне одному глаза резануло )
4
Автор поста оценил этот комментарий
Спасибо. Буквально вчера пытался посмотреть пароль к админке через БД. Пароль нашел, как тут и описано, в хешированом виде. И конечно же он не подошёл. А тут коммент много чего объяснил.
PS: Сам не программист, так, верстаю и натягиваю как говорится.
3
Автор поста оценил этот комментарий

Понял. А при чём тут тогда регистр о котором идёт в посте речь?

Если система всё приводит в условный нижний регистр (т.е. будет "PaSSWorD' = 'password') - всё равно итоговый хеш будет всё также чертовски невозможно взломать не имея ключей хеширования?

раскрыть ветку (16)
20
Автор поста оценил этот комментарий
Для верхнего и нижнего регистра хеши будут отличатся, поскольку "А" и "а" в таблице кодирования символов - это разные символы со своим уникальным кодом. В случае, если системе все равно, в каком регистре вводится пароль, то это значит, что он не хэшируется либо принудительно переводится в нижний или верхний регистр. И то и другое - не очень хорошая практика.
раскрыть ветку (15)
5
Автор поста оценил этот комментарий

Ну не хешировать пароли это понятно почему вредно. Взломали - и сразу все карты на руках.

А если хешировать, пусть и уже ПОСЛЕ принудительного перевода в нижний регистр, то всё равно ведь - без ключа хеширования хрен получишь, данные, даже если взломал базу.

Я вот к чему: какая разница большой или маленький регистр, если главное что нужно получить - это не столько саму базу, сколько ключ хеширования. И если он получен - то уже пофигу, хешируют они с учётом регистра или без него.

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

Без перевода в нижний регистр сложнее подобрать пароль, если хэш утек.

Автор поста оценил этот комментарий
Меня вот тоже именно эта недосказанность заинтересовала. Подожду здесь ответа.
DELETED
Автор поста оценил этот комментарий

Я правильно понимаю - если пароль не чувствителен к регистру и всё таки проходит хеширование, то получается, что для одного пароля будет n-ое количество хешей, т.к. как один и тот же пароль в разных регистрах будет иметь разное значение хеша? Т.е., к примеру для пароля 1qw имеется 4 варианта: 1qw, 1Qw, 1QW, 1qW и каждый будет иметь свой уникальный хеш? Это же сколько хешей на каждый пароль нужно хранить в БД. Или я не правильно всё понял?

раскрыть ветку (9)
4
Автор поста оценил этот комментарий
Нет если пароль не чувствителен к регистр, есть два варианта. В первом хэширования нет вообще. Юзер вводит пароль, тот сверяется с паролем в базе данных, причём одинаковые буквы разных регистров приравниваются. Безопасность на дне. Во втором случае все символы принудительно переводятся в один из регистров. Например, если пароль чувствителен к регистру, то варианты пароля АА, Аа и Аа дадут три разных хеша. Если пароль не чувствителен к регистру за счёт принудительного приведения регистра, то любой из этих вариантов даст одинаковый хэш, потому что система переведёт или все маленькие буквы в большие, или наоборот и у нас получится АА, АА и АА, или аа, аа и аа. Даже для такого короткого пароля из 2 одинаковых букв число возможных вариантов пароля упало втрое, а это значит, что брутфорс, то есть попытка перебора паролей стала эффективнее в три раза. Во сколько раз это упрощает подбор более сложных и длинных паролей - сложно даже предположить. А цель хэширования - защититься именно от утечки базы паролей, от перебора самих паролей защищает только многообразие их вариантов.
раскрыть ветку (7)
DELETED
Автор поста оценил этот комментарий
Ага, спасибо вам, начинаю понимать. Но у меня тогда следующий вопрос: получается, что появляется ещё одна уязвимость - это система принудительного перевода в один регистр? Получается легче перехватить пароль из этой системы перевода (зная api), чем пытаться извлечь хеш или пароль из бд? И ещё, подскажите, пожалуйста, можно ли, теоретически, если известен хеш пароля путём инъекции или другим способом перейти к этапу сравнения известного хеша с хешем в БД для дальнейшей авторизации минуя этап ввода поля password? Извините за дилетанские вопросы, я не специалист, но пытаюсь навести порядок в голове. Спасибо.
раскрыть ветку (6)
3
Автор поста оценил этот комментарий
Я вообще юрист, поэтому больше вам ничем не помогу, увы. Я и с хэшированием-то знаком только благодаря тому, что интересовался одно время технологией блокчейн, криптовалютой и возможностями этой системы для ведения различных реестров.
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Вы в кучу немного намешали всё.


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


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


Если же у вас уже есть доступ к БД для инъекции, то вы уже можете достать оттуда нужные данные, зачем вам пароль? Но если вопрос был, можно ли в БД заменить хэш, против которого будет сравнение идти На нужный вам, то да, можно, не во всех системах, но, например Оракл вплоть до 9 версии так делать позволял.

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

Нет. записывают в базу хэш для 1qw, независимо от того ввел ты 1qw, 1Qw, 1qW или 1QW.

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

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

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

Регистр, верхний регистр это заглавные буквы, нижний регистр это строчные буквы. Реестр это таблица, перечень или список.


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

6
Автор поста оценил этот комментарий
Простите, доебусь.
Хэш с применением ключей не вычисляют. Хэш с ключами - это уже mac
5
Автор поста оценил этот комментарий
Вам спасибо, ничего не понял, но это просто я тупой, а так было интересно
раскрыть ветку (6)
49
Автор поста оценил этот комментарий

Есть Вася и Петя. Петя предоставляет услуги удаленной телефонной книги. Клиент может позвонить Пете, авторизоваться по имени и паролю и просить Петю сохранять или запрашивать у Пети номера телефонов своих блядей =)


"Небезопасный сценарий"


Шаг 1. Регистрация


Вася звонит Пете и говорит:

- Привет. Я хочу пользоваться твоими услугами, зарегистрируй меня. Меня зовут Вася и мой пароль "12345".

Петя берёт тетрадку с надписью "Пользователи", в которой разлинована таблица, и в ней 2 столбца: имя_пользователя и пароль и записывает в неё:

имя_пользователя: Вася

пароль: 12345


Шаг 2. Запрос и сохранение данных


Вот настал час Х, жена Васи уехала к маме в деревню и Вася хочет вызвонить Клаву на предмет провести приятно время. Он звонит Пете и говорит:

- Привет! Это Вася, пароль 12345. Мне нужен телефон Клавы.

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


Тут на сцену выходит Жулик. Жулик, незаметно от Пети копирует его тетрадку "Пользователи". Теперь у него есть копия тетрадки и он находит там пользователя с именем "Вася" и звонит Пети:

- Привет! Это Вася. - говорит Жулик Пете - Мой пароль 12345.

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


"Безопасный сценарий"


Шаг 1. Регистрация


Вася звонит Пете и говорит:

- Привет. Я хочу пользоваться твоими услугами, зарегистрируй меня. Меня зовут Вася и мой пароль "12345".

Петя берёт тетрадку с надписью "Пользователи" и записывает "имя пользователя: Вася", а вот вместо пароля Петя записывет его хешь. Т.е. Петя, не сообщая об этом Васе, вычисляет для "12345" md5-хешь, который равен "827ccb0eea8a706c4c34a16891f84e7b" и именно это значение записывает в свою тетрадку.


Шаг 2. Запрос и сохранение данных


Вот настал час Х, жена Васи уехала к маме в деревню и Вася хочет вызвонить Клаву на предмет провести приятно время. Он звонит Пете и говорит:

- Привет! Это Вася, пароль 12345. Мне нужен телефон Клавы.

Петя опять, по тому же алгоритму вычисляет для продиктованного пароля md5-хеш. Затем открывает тетрадку "Пользователи", находит там Васю и сверяет только что рассчитаны хеш с тем, что записан в тетрадке. Если совпадают - значит всё ок.


Тут на сцену выходит Жулик. Жулик, незаметно от Пети копирует его тетрадку "Пользователи". Теперь у него есть копия тетрадки и он находит там пользователя с именем "Вася" и звонит Пети:

- Привет! Это Вася. - говорит Жулик Пете - Мой пароль "827ccb0eea8a706c4c34a16891f84e7b" (ведь именно это записал Петя в свою тетрадку когда Вася регистрировался).

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


Может ли Жулик, зная хеш васиного пароля восстановить исходный? Теоретически да, но только методом перебора. Чем длиннее у Васи пароль, чем больше там специальных символов, чем пароль необычнее - тем больше времени у Жулика уйдёт на подбор. А если Петя не дурак, то он использует сложную хешь функцию и всякие другие хитрости, что бы Жулику и всей жизни не хватило на перебор всех возможных комбинаций символов.


Т.е. скопированная тетрадка для Жулика бесполезна.

раскрыть ветку (5)
10
Автор поста оценил этот комментарий
От души) на блядях в разы понятней) допер в общих чертах
9
Автор поста оценил этот комментарий
Я тут доебусь. Хеш.
2
Автор поста оценил этот комментарий
васины бляди в безопасности
И слава Пете)
1
Автор поста оценил этот комментарий
ХЭШ или ХЕШ!
без мягкого знака, это же транслит с латиницы на кириллицу слова HASH.
1
DELETED
Автор поста оценил этот комментарий
Оказывается это понятно.... а почему так лекции не читают? 🤔

Спасибо, дорогой человек! Заморочились ну совсем не зря!
1
Автор поста оценил этот комментарий
Нашёл, держи плюс
1
Автор поста оценил этот комментарий
Спасибо, но только хэш пишется без мягкого знака, а за пояснение спасибо 🙂
Автор поста оценил этот комментарий
Спасибо, познавательно.
Автор поста оценил этот комментарий
Пили пост!) Все доступно и по полочкам
Автор поста оценил этот комментарий

Спасибо!

Автор поста оценил этот комментарий
Т.е. получения немецкая "Энигма" хешировала сообщения? Каждый день по новому алгоритму хеширования?
раскрыть ветку (2)
8
Автор поста оценил этот комментарий

Нет, потому что они поддавались расшифровке ) Не путайте шифрование и хэширование. Хэширование не имеет возможности обратно получить исходное сообщение, а шифрование - имеет.

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

Шифровала. Обратимо. По ключу.

Автор поста оценил этот комментарий
Такое чувство ,что сча диплом на дом привезут...)
Автор поста оценил этот комментарий
вот взял и по человечески объяснил! РЕСПЕКТ, ЧЕЛОВЕЧИЩЕ!
Автор поста оценил этот комментарий
Так, а в чем отличие хеширования от зашифровки?
раскрыть ветку (2)
2
Автор поста оценил этот комментарий

шифрование - обратимая операция, хеширование - не обратимая

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

Я на хабре прочитал и нихуя не понял.

А тут вроде как дошло

Спс

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

Здравствуйте. Подскажите, пожалуйста, если известен хеш пароля, то возможно ли и путём sql инъекции или другим способом сразу перейти к этапу сравнению моего хеша и хеша в базе сайта для дальнейшей авторизации минуя поле введения пароля? Спасибо.

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

Да, иногда можно.

раскрыть ветку (2)
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)
Автор поста оценил этот комментарий

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

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

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