Comments 30
Предполагаю что к паролю была добавлена соль и поэтому хеш пароля уже не так страшен. Хотя в жизни всякое бывает.
Ситуация не приятная конечно. Если смогли слить, возможно могли и чего ни будь залить.
1 создается юзер с паролем, база сохраняет его hashvalue как "hash(user + password)"
Система знает свою "постоянную" соль (которую нельзя потерять иначе не проверить пароль) и хранит hash(password + salt). И получаются получив хеши - пароли уже труднее искать по разным наработанным таблицам.
В случаи взлома можно быстро поменять "постоянную" соль и ни кто уже не сможет получить доступ по паролю, только после смены пароля. Но это я так думаю, и могу ошибаться.
Только в таком случаи клиент отправляет пароль по сети и предполагается что его нельзя перехватить (https).
Короче, хеширование паролей в целом организованы так, как я описал
Нет, у вас множество ошибок в понимании соли. Рекомендую почитать подробнее про соли.
Например, п.1 - база нигде не должна сохранять исходный пароль или хеш пароля. Только сразу солированный пароль и соль.
П.3 - база не отправляет клиенту (если клиент для это пользователь, а не сервер) соль. Соль может знать только сервер, который будет все это хешировать и проверять.
клиент не должен отправлять пароль по сети
Почему нет? Ssl защищает от перехвата, а соль защищает от утечек.
И да, https тоже обходится через mitm ssl proxy
Только если есть доступ к компьютеру жертвы и туда удалось установить свой доверенный корневой сертификат.
поможет только смена пароля или алгоритма хеширования
Посмотрите например PBKDF2. Там в одной строке хранится исходная соль, алгоритм хеширования, количество проходов хэширования, и результат соли. Получается , на вход подаём пароль, его много много раз хешируем и сравниваем с результатом.
Вся прелесть в том, что алгоритм хешированря иногда надо менять, и если вам нужно заменить например sha1 на sha512, то при следующем успешном входе пользователя, вы можете этот сделать, сохраняя обратную совместимость со старыми паролями. Повторюсь , на клиент ничего не передается, все проверки должны происходить на сервере.
Тоже почитал тредик выше, и малость вау! ))
Для тех, кто хочет почитать про нормальные хеширования - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
Про подбор паролей для хеша https://hashcat.net/hashcat/
Про тему с mitm не понял, это же нужно в реальном времени отлавливать тогда, но и тут можно подсмотреть реализацию у других, например протон https://account.proton.me/login
Давайте подумаем, чем эта утечка опасна, вероятно:
Есть те, у которых пароли находятся в публичных словарях и самой почты/телефона достаточно, чтобы попасть в их лк https://github.com/danielmiessler/SecLists/tree/master/Passwords
Есть те, которые используют один пароль дважды (и более раз) - https://owasp.org/www-community/attacks/Credential_stuffing, соответственно через эту утечку можно подобрать пароль к другим ресурсам
Даже если нет, то можно положиться на этот ресёрч https://passwordpolicies.cs.princeton.edu/ и добавить единичку в конце, восклицательный знак или первую букву пароля сделать большой для стандартного словаря
Ещё проще - проверить, в каких утечках почта/телефон уже засветились https://haveibeenpwned.com/, поможет понять алгоритм хеширования (или подобрать соль, или вовсе заюзать пасс as is)
Вероятности не самые большие, но количество строк нормальное такое )
Забавно, что год уже 2023, а люди хранят почты/телефоны в БД без шифрования на стороне приложения!
Передайте парням из Альфа-страхования, что как бы сегодня это уже моветон
Да и ограничивать пароль длиной в 21 символ - это почему?
У вас функция хеширования больше не переваривает или её результат зависит от длины пасса?
Давайте глянем, что рекомендует NIST https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers:
5.1.1.2 Memorized Secret Verifiers
Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length.
Надежды мало, но может пунктик у них хоть как-то реализован "Best practices from prior research: Do check users' passwords against lists of leaked and easily-guessed passwords"
И при следующем входе будет запрошен усиленный сброс пароля
Регу опробовал, забавно - нет рейт-лимитов на вводе смс-кода при подтверждении, а при самой реге хотяб рекапча на месте
Это не все адреса - корпоративные , например ngs.ru, это вполне себе бесплатный почтовик в Новосибирске.
Первые два в списке это перепродажники услуг страхования. Не думаю что у них есть столько сотрудников с корпоративными адресами - скорее всего боты.
ngs.ru – это не корпоративные адреса. На этом сайте есть почтовый сервис для любого желающего.
А где скачать базу?
Да, у меня тоже друг спрашивает, где вообще искать такие вещи?
Это так не работает. Если вы не знаете, где такие вещи искать, то, скорее всего, такая база не для вас. А по сути: это практически всегда даркнет.
Эту базу ищут обычные люди, чтобы проверить, если ли там их данные. Поэтому, запрещать ссылки на базу, суть, идиотизм. Все мошенники ее уже скачали.
Допустим, что я нашёл базу, проверил и обнаружил в ней свои данные.
Подскажите, что мне делать дальше?
Извините, ну, вот, вы нашли базу. Вот, вы себя там нашли.. Например, с правильным адресом, или не совсем правильным, или вообще неправильным. Дальше что?
И где, извините, вы нашли какой-то запрет на базу? Вы саму новость-то читали? Кто-то где-то получил инфо, куда-то слил. О каком запрете ваще речь? У меня её нет, мне по барабану вообще эти сливандосы.
Сорри, но ваше сообщение отдаёт либо старческой наивностью либ инфантильным геронто-троллингом.. Вам сколько лет, что вы в публичном доступе пишете, что на слитую базу клиентов вам обязательно нужно получить ссылку на "эксель"-файл и что сокрытие слитой базы клиентов, - это идиотизм?
В телеге, в группе этих хакеров, niceleakbro канал называется, надеюсь не нахватаю минусов...
del
Возможно заказ.. На одну из организаций.. Остальное просто пыль в глаза..
Хакеры выложили в открытый доступ персональные данные 1 млн клиентов «Альфастрахования»