То, что ведущая твиттер 20летняя девочка не знает что такое хеширование - не значит, что сама компания не использует хеширование.
- Скажите, девушка, вам нравится Пинк Флойд?
- Пинк Флойд? Какой Пинк Флойд?
- Да неважно :)
(с)
Флойд? Да, я слышал про Флойда. Я думаю полицейский должен понести наказание за свое преступление.
Если она не поняла вопроса и при этом говорит "нет" - это, в любом случае, минус Сбербанку, ведь он не нанимает компетентных сотрудников.
А пароли может и хешируют - переводят в нижний реестр, а потом хешируют. А может и нет. Мы вряд ли узнаем.
Пользователь при регистрации вводит пароль "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 итераций).
Пароли могут "солить" (т.е. добавлять к ним произвольную строку перед вычислением хеша).
Хешь могут вычислять с приминением ключей шифрования.
Ну и т.д. и т.п.
А на пикабу достаточно часто в разных темах встречаются подробные, спокойные объяснения "для дебилов", я лично так очень много нужных и интересных вещей узнал именно через комментарии на пикабу.
Типа как как сваривать две детали под потолком (хоть я и не сварщик).
Или как работать на очень редком ЧПУ станке, которых осталось всего 2 штуки и обе они в Гваделупе.
Жаловаться на качество контента на данном ресурсе (не пытаясь прилагать усилия для его формирования) - нелогично. Вы подобных действий не принимаете.
Ввиду того, что контент, основанный на неверных жёнах и мужьях популярен - значит общественность его любит.
Юзер вводит пароль. Просто так пароль хранить нельзя (админ может быть куплен или сайт взломан) поэтому пароль превращается в месиво с помощью однонаправленной функции, как будто перемалывается мясо в фарш. Когда юзер приходит на сайт снова - его пароль снова пропускают на фарш и сравнивают. Получился такой же фарш? Окей, значит и пароль тот же. Получился другой фарш - значит пароль не тот.
Фарш нельзя провернуть обратно, поэтому ваш пароль восстановить нельзя.
Хорошо прямо написали, почти для домохозяек.
Еще чуть попроще бы, а также объяснить на пальцах соль и радужные таблицы, и можно выводить в продакшн :-)
а также объяснить на пальцах соль и радужные таблицы, и можно выводить в продакшн :-)звучит как призыв к закладкам
Про "соль":
Вот например одно из самых простых хэширований:
четные - ставим 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 символы обоих регистров.
Только в реальной жизни соль это кусок (зашитый в коде или генерируемый на лету), который подмешивается к изначальному паролю целиком или кусками в несколько циклов хеширования, а хеш-функции используют стандартные без изменения. Разработка своего "секретного" алгоритма хеширования это чаще всего плохая идея.
Если соль везде одинаковая, то усложняется жизнь злоумышленникам с перебором по таблицам. Если соль генерируется каждый раз, то бонусом ещё и одинаковые пароли будут иметь разные хеши, затрудняя например частотный анализ.
О, правильно, чем занимается грамманацист в этом прекрасном объяснении хеширования паролей - проверяет правописание!
А "вычислять с приминением" почему пропустили!?
Как же вы похожи на того чувака со значком, который на ранчо пришел, и думал, что ему везде ходить можно, раз у него "значок"
Потому что я такой же технарь, как и человек выше. Но такие ошибки в терминах - недопустимы
не заметил еще одного важного принципа: при малейшем изменении исходных данных хеш должен очень сильно меняться, чтобы затруднить перебор.
а в случае с передачей файлов и подсчетом хеш-суммы, чтобы легко отловить даже небольшую "битость"
Написано прекрасно, но есть одно зчмечание. Идемпотентность — это другое свойство. Функция f нащывается идемпотентной, если f(f(x)) = f(x) для любого x. А способность давать всегда один результкт на одном аргументе — свойство вообще любой функции (функции в математическом смысле, разумеется)
Согласно этому определению, хеш-функции как раз таки не должны быть идемпотентными, чтобы можно было вызывать функцию с хешем в виде аргумента.
Чо вы несёте то.
Идемпотентность - свойство объекта или операции при повторном вызове давать тот же результат, что и при первом вызове.
Вот это:
Согласно этому определению, хеш-функции как раз таки не должны быть идемпотентными, чтобы можно было вызывать функцию с хешем в виде аргумента.
Тогда в посте Как защищают наши пароли в сети рекомендую сделать апдейт через модератора, указав ссылку на это уточнение)
PS: Сам не программист, так, верстаю и натягиваю как говорится.
Понял. А при чём тут тогда регистр о котором идёт в посте речь?
Если система всё приводит в условный нижний регистр (т.е. будет "PaSSWorD' = 'password') - всё равно итоговый хеш будет всё также чертовски невозможно взломать не имея ключей хеширования?
Ну не хешировать пароли это понятно почему вредно. Взломали - и сразу все карты на руках.
А если хешировать, пусть и уже ПОСЛЕ принудительного перевода в нижний регистр, то всё равно ведь - без ключа хеширования хрен получишь, данные, даже если взломал базу.
Я вот к чему: какая разница большой или маленький регистр, если главное что нужно получить - это не столько саму базу, сколько ключ хеширования. И если он получен - то уже пофигу, хешируют они с учётом регистра или без него.
Я правильно понимаю - если пароль не чувствителен к регистру и всё таки проходит хеширование, то получается, что для одного пароля будет n-ое количество хешей, т.к. как один и тот же пароль в разных регистрах будет иметь разное значение хеша? Т.е., к примеру для пароля 1qw имеется 4 варианта: 1qw, 1Qw, 1QW, 1qW и каждый будет иметь свой уникальный хеш? Это же сколько хешей на каждый пароль нужно хранить в БД. Или я не правильно всё понял?
Вы в кучу немного намешали всё.
Если есть принудительная система перевода в другой регистр, то это не уязвимость, а просто понижение уровня безопасности.
Существует гигантская база хэшей в даркнете, сопоставлений слово-хэш, то есть, если вам уже известен хэш, то можно сравнить его с этой базой и есть ненулевая вероятность, что вы увидите нужный вам пароль.
Если же у вас уже есть доступ к БД для инъекции, то вы уже можете достать оттуда нужные данные, зачем вам пароль? Но если вопрос был, можно ли в БД заменить хэш, против которого будет сравнение идти На нужный вам, то да, можно, не во всех системах, но, например Оракл вплоть до 9 версии так делать позволял.
Когда пароль переводят в какой-либо реестр перед хэшированием, то его значение где-то остаётся системе и можно его перехватить.
Регистр, верхний регистр это заглавные буквы, нижний регистр это строчные буквы. Реестр это таблица, перечень или список.
Он может остаться только в оперативной памяти сервера, но то же самое может быть и с самим паролем. Если у злоумышленника есть возможность свободно ковырять оперативку сервера, то обычно уже давно всё пропало.
Есть Вася и Петя. Петя предоставляет услуги удаленной телефонной книги. Клиент может позвонить Пете, авторизоваться по имени и паролю и просить Петю сохранять или запрашивать у Пети номера телефонов своих блядей =)
"Небезопасный сценарий"
Шаг 1. Регистрация
Вася звонит Пете и говорит:
- Привет. Я хочу пользоваться твоими услугами, зарегистрируй меня. Меня зовут Вася и мой пароль "12345".
Петя берёт тетрадку с надписью "Пользователи", в которой разлинована таблица, и в ней 2 столбца: имя_пользователя и пароль и записывает в неё:
имя_пользователя: Вася
пароль: 12345
Шаг 2. Запрос и сохранение данных
Вот настал час Х, жена Васи уехала к маме в деревню и Вася хочет вызвонить Клаву на предмет провести приятно время. Он звонит Пете и говорит:
- Привет! Это Вася, пароль 12345. Мне нужен телефон Клавы.
Петя открывает свою тетрадку "Пользователи", находит там пользователя с именем "Вася" и сверяет пароль, который ему Вася только что продиктовал с тем, который записан у него в тетради. Если пароли совпали, значит Вася - это Вася и ему можно сообщить телефон Клавы.
Тут на сцену выходит Жулик. Жулик, незаметно от Пети копирует его тетрадку "Пользователи". Теперь у него есть копия тетрадки и он находит там пользователя с именем "Вася" и звонит Пети:
- Привет! Это Вася. - говорит Жулик Пете - Мой пароль 12345.
Петя открывает свою тетрадку "Пользователи", находит там пользователя с именем "Вася" и сверяет пароль, который ему псевдо-Вася только что продиктовал с тем, который записан у него в тетради. Пароли совпадают, ведь у Жулика полная копия петиной тетрадки "Пользователи". Петя решает что перед ним действительно Вася и сливает ему васины данные."Безопасный сценарий"
Шаг 1. Регистрация
Вася звонит Пете и говорит:
- Привет. Я хочу пользоваться твоими услугами, зарегистрируй меня. Меня зовут Вася и мой пароль "12345".
Петя берёт тетрадку с надписью "Пользователи" и записывает "имя пользователя: Вася", а вот вместо пароля Петя записывет его хешь. Т.е. Петя, не сообщая об этом Васе, вычисляет для "12345" md5-хешь, который равен "827ccb0eea8a706c4c34a16891f84e7b" и именно это значение записывает в свою тетрадку.
Шаг 2. Запрос и сохранение данных
Вот настал час Х, жена Васи уехала к маме в деревню и Вася хочет вызвонить Клаву на предмет провести приятно время. Он звонит Пете и говорит:
- Привет! Это Вася, пароль 12345. Мне нужен телефон Клавы.
Петя опять, по тому же алгоритму вычисляет для продиктованного пароля md5-хеш. Затем открывает тетрадку "Пользователи", находит там Васю и сверяет только что рассчитаны хеш с тем, что записан в тетрадке. Если совпадают - значит всё ок.
Тут на сцену выходит Жулик. Жулик, незаметно от Пети копирует его тетрадку "Пользователи". Теперь у него есть копия тетрадки и он находит там пользователя с именем "Вася" и звонит Пети:
- Привет! Это Вася. - говорит Жулик Пете - Мой пароль "827ccb0eea8a706c4c34a16891f84e7b" (ведь именно это записал Петя в свою тетрадку когда Вася регистрировался).
Петя опять, по тому же алгоритму вычисляет для продиктованного Жуликом пароля md5-хеш. Т.к. строка, переданная на вход функции хеширования отличается от "12345" результат хеширования будет отличаться от того, который записан в тетрадке. Жулик не проходит авторизацию и васины бляди в безопасности.
Может ли Жулик, зная хеш васиного пароля восстановить исходный? Теоретически да, но только методом перебора. Чем длиннее у Васи пароль, чем больше там специальных символов, чем пароль необычнее - тем больше времени у Жулика уйдёт на подбор. А если Петя не дурак, то он использует сложную хешь функцию и всякие другие хитрости, что бы Жулику и всей жизни не хватило на перебор всех возможных комбинаций символов.
Т.е. скопированная тетрадка для Жулика бесполезна.
Нет, потому что они поддавались расшифровке ) Не путайте шифрование и хэширование. Хэширование не имеет возможности обратно получить исходное сообщение, а шифрование - имеет.
Здравствуйте. Подскажите, пожалуйста, если известен хеш пароля, то возможно ли и путём sql инъекции или другим способом сразу перейти к этапу сравнению моего хеша и хеша в базе сайта для дальнейшей авторизации минуя поле введения пароля? Спасибо.
Да
Иногда системе можно скормить сам хэш, иногда подставить его в сетевой пакет. Иногда вместо хэша используются просто зашифрованные данные, которые легко можно расшифровать.
забыл только упомянуть про радужные таблицы для подбора пароля и коллизии хеш функций.
а так очень подробно!
Серверу передается пароль в открытом виде, и уже сервер при проверки сначала переводит в хэш, а потом только сравнивает их(само приложение на телефоне не генерирует хэш), так что когда ты пользуешься авторизацией через http, есть вероятность, что твой пароль в открытом виде улетеит куда-нибудь(например провайдеру). Другое дело, что человеку, если он получил базу, не нужно что-то делать с твоим аккаунтом, это делается в первую очередб для того, что бы у человека, зарегестрированно на твоем сайте, не угнали аккаунт где-нибудь еще, потому что очень часто пользователи используют одинаковые пароли для разных ресурсов
Хэш защищает от воровства базы данных на сервере. От перехвата сообщения хеширование не помогает.
Сам пароль можно защитить, если хешировать его сначала на стороне клиента, а потом на стороне сервера. Но доступ к серверу от вашего имени злоумышленник все равно получит.
От злоумышленника между вами и сервером (к примеру государства, которое читает вашу переписку в месенджерах) может помочь только сквозное шифрование, как в телеграмме в секретном чате. Но при этом нужно проверить по резервному каналу что некоторый открытый ключ совпадает на обоих клиентах, если число отличается, значит между вами посредник вклинился.
Верно мыслите. Признает. Но: хэш передаётся внутри защищенного соединения обязательно, иначе нет большого смысла в этом. https:// отлично подойдёт
Ошибся: хэш, скорее всего, считается на сервере, как верно сказали ниже #comment_179284521 . Но, тем не менее, в некоторых реализациях атака перехвата хэша имеет место быть.
Нет. Т.к. наш алгоритм авторизации вычисляет для любой строки, введённой в качестве пароля, хешь. Т.ч. что бы получить хешь "5f4dcc3b5aa765d61d8327deb882cf99" вы должны передать в качестве пароля "password", только "password" и ничего кроме "password". И проблема злоумышленника как раз в том, что он не знает ничего о вашем пароле, ведь у него есть только логин и хешь.
Ну тут вы не совсем правы, не изучал особо друге методы кроме md5, но в нем к пример хэши разных слов могут совпадать, самое обидное когда хэш твоего пароля может совпасть с хэшем какого нибудь аааааааааа который чуть ли не первый влетит при переборе
Да, я не так написал. Так как число хэшей ограниченно (фиксированная длина), то существует бесконечное число коллизий, дающих один и тот же хэш.
-Тьфу, рейнджер! Этот транспорт моя добыча.
-Меня интересует не твоя добыча, меня интересуешь ты, Йцукен!
Для проверки правильности введения пароля его нужно с чем-то сравнивать, а значит где-то хранить. И вот, чтобы какой-нибудь хрен с горы получивший доступ к базе (или даже сотрудник, или даже администратор) не могли узнать что там у тебя за пароль (кто знает, что может прийти в голову этим мясным ублюдкам) и нужно то самое хеширование. По сути это шифрование "в одну сторону", то есть зашифровать можно - расшифровать нельзя (есть нюансы, но в данном примере - это не важно). Таким образом введенный пароль так же хешируется и сравнивается с тем, что хранится.
Короче, фишка в том, что сравниваются не пароли, введённый пользователем и хранящийся в базе, сравниваются их хэши — поэтому если кто-то украдёт из базы хранящийся там хэш, использовать его вместо пароля он не сможет.
Функция которая производит какие то действия со строкой. Для каждой уникальной строки уникальный результат. И что самое важное из результата нельзя восстановить первичную строку
Ну так и знал что кто то это скажет. Там много нюансов. Но если человеку просто надо понять, о чем речь эти детали ему не нужны
И при этом с вашим объяснением, со стороны - нихуя не понятно. Человек выше просто дал объяснение для обыватели, а вы приебались к деталям.
Хотя нет, даже для меня ваше объяснение - сюр. Если я вам скажу, определение чему это
"принимает на вход строку любой длины и алфавита и возвращает строку фиксированной длины и алфавита", сможете восстановить?
Но при этом совпадение маловероятно.
Используется это, кстати, не только для паролей, но и для больших объемов данных для поиска дублей.
При росте количества символов хешируемой строки, количество уникальных хешей будет стремится к 0, так как невозможно "запихнуть" строку произвольной длины в уникальную строку фиксированной длины.
В рамках объяснения для человека не в теме. Этого достаточно.
Это как с замком. У всех замков есть уникальных ключ. То что есть отмычки, бампинг, или можно открыть другим ключом, вопрос реализации и эксплуатации.
Это важно для обьяснения принципа?
Вспомните математику.
Вначале вам говорят есть только положительные числа и ноль.
потом появляются отрицательные.
потом говорят что корень из числа может быть только положительным
потом выясняется что есть мнимые числа.
Для обьяснения принципа, можно сказать что они уникальны. Можно сказать, что они псевдоуникальные. В рамках топика, важно что это механизм, который позволяет превратить пароль, во что то не читаемое, и что если его украдут, то пользователь не потеряет деньги.
Не надо плодить детали и сущности там где они нахер никому не нужны))
Но если вам будет легче. я тупой, я не прав. хэши не дают уникальный результат
Лучше вообще опустить детали, чем сделать заведомо неверное утверждение. Тогда не будут создаваться ложные убеждения у неэкспертов.
Необратимое однозначное преобразование информации. Или вас нижний регистр напрягает?
Ну конечно хэшируют, решение с lowercase тоже весьма элегантное.
Во всяком случае намного приятнее чем @бнутые требования вносить пароль разным регистром, использовать буквы, цифры и специальные знаки. Так достали эти требования, что сил нет. Если я хочу использоваться пароль password, дайте мне это сделать и отъебитесь со своей валидацией, тем более что все действия защищены вторым фактором (смс пароль).
Сбер, если мне не изменяет память, при изменении пароля проверяет, что пароль не совпадает с логином, что в нём нет запрещённых символов и что его нет в списке «плохих» паролей. При такой базе клиентов, как у Сбера, даже одна наносекунда экономии времени на одну проверку очень важна. А раз функция нормализации регистра уже есть в одном месте, писать другую для другого места никто не станет.
если она не знает, не нужно отвечать на вопрос - в этом компетенция. Можно было бы ответить "данный вопрос вне компетенции службы поддержки клиентов" или как-то так, чем отвечать уверенно на вопрос, в которым ты не разбираешся.
А я считаю, что тот кто выдумывает слова за других людей, переводя диалог с темы на собственно выдуманные рельсы - дурак и балабол.
категорично заявлять о чем-то, в чем не имеешь понятия - не ошибка, а дурость и некомпетентность.
Свои ошибки валить на других и отмазываться от них - дурость и некомпетентность.
Ну она как ответственная за связи с общественностью могла бы и спросить или погуглить или ответить, что вопросы не в моей компетенции.
Так то если подумать, она вообще ничего знать не должна, тогда зачем этот аккаунт нужен?
Для решения конфликтных ситуаций. У нее скорее всего есть контакты отдела который экстренно разруливает спорные/конфликтные ситуации клиентов.
Ну так на лицо создание конфликтной ситуации и вероятный инфоповод для негативного контента, самое время, что нибудь сделать?)
Я когда читаю очередные посты, про крупнейшей банк страны, что у кого-то банкомат деньги не выдал, что служба безопасности ЧБ из СИЗО в очередной раз развела на деньги пенсионеров, ипотеки хрен пойми как списываются, карты блокируются когда люди в других регионах, прочие негативные новости, тоже не воспринимаю в серьез, та и тут, хз, ну возможный проеб с технологией хранения паролей, ерунда же, максимум посмеюсь, чё это зануды возбуждаются постоянно, всем не угодишь.
нет, но она как минимум должна уточнить это у тех кто знает, прежде чем выдавать однозначный ответ
SMM-щик может этого не знать. Я работала "по ту сторону" (не Сбера, но крупного бренда), там адовые правила. Тебя нанимают вести страницу и следить, что там про сбер говорят в соцсетях. Для коммуникации и сложных проблем есть связь с менеджером Сбера, который перенаправит к компетентным сотрудниками, которые знают, например, про хэширование. Но на деле оказывается так: у девочки спрашивают вот это, по правилам у нее 1-3 часа на ответ. И вот она пишет менеджеру, менеджер проебался, потому что на него навалились другие проблемы, максимум что можно сделать - загуглить, ну или забить, сославшись на менеджера, но они это не любят. Поэтому человек рискнул, у него не вышло, но мало ли что случилось по ту сторону. Когда мне отвечают в комментарии, я всегда пишу "передайте начальству", потому что знаю, что мой негатив обрабатывают ни в чем не повинные люди))
Ну давайте ещё, рассказывая какие в банке некомпетентные люди работают, путать регистр с реестром. Вы случайно не авокадо?
Получится и очень просто. И разными способами можно реализовать.
Например, пользователь вводит пароль PIKaBu, на сервер отправляется POST-запрос с паролем PIKaBu, потом сервер делает "PIKaBu".toLowerCase(), хеширует, сравнивает хеш с хешем в бд.
toLowerCase() можно и на стороне клиента делать джаваскриптом и отправлять запрос уже с паролем в нижнем регистре.
Вообще пароли прям открыто запросом не отправляют, обычно. Это я для упрощения.
Только хеширование никаким образом не связано с регистрозависимостью. Перед сохранением пароля он мог быть переведен в lowercase, после чего было выполнено хеширование. Соответственно при авторизации введенный пароль так же переводится в lowercase после чего уже идет сравнение хешей.
При чем здесь это? Я говорю о том что делать вывод о нехэшируемых паролях, потому что они регистронезависимые - это глупо. Пост - фейк, или как там правильно говорится?
Вы только в статистику верите?
Ну тогда приведите их.
Я кроме программистов ни у кого из знакомых не видел пароли у которых бы регистр менялся в середине пароля.
Работа такая.
Единственный понимающий в компах человек в семье знает пароли, почти все они на бумажках записаны.
Да и вообще не увидел связи хеширования с регистрации. Никто не мешает на стороне сервера перед проверкой паролей привести его к любому из регистров, далее получить хеш и сравнить его с хеш ем из БД
А вы охуенно удивитесь, когда узнаете что гоняют в открытом виде. По https естественно. Мало кто хэш на компе скриптом в браузере считает. Все на сервере. Откройте консоль и проверьте параметры post запроса сами...
При утечке данных (если БД сопрут), то пароли узнать не получиться, т.к. на руках только хеши .По хешу восстановить пароль невозможно (если правильно конечно все сделано).
Кто сопрёт БД и в чем смысл её красть, если можно просто увести логи сервера, где всё будет в открытом виде (привет хэширование на стороне сервера)?
Плять, мамкины криптографисты))
а что пугать? в большинстве случаев хэширования на бэке, они будут падать в логи.
toLowerCase вас же почему-то не пугает (причём при ограничениях на длину и состав пароля)...
Ну это надо быть очень одаренным, чтобы на проде в логи скидывать не маскированный пароль. Вы хоть 1 систему масштабные интернат магазина погремушек сопровождали/проектировали? Lowercase совершенно не пугает, когда есть 2ой фактор и нормально работающий siem
Ну да, давайте сознательно делать дыры в безопасности, нам же смс-ка ещё придёт, если что...
Ограничение на состав пароля - это дыра! Я уже одной банковской СБ это объяснял. Когда ты вынуждаешь юзера задавать не тот пароль, который ему хочется (мало символов, нет спец.символов и т.п.) - очень высока вероятность того, что на следующем сеансе авторизации он запустит процедуру восстановления пароля, ну и т.д. А процедура восстановления - это довольно рисковая затея, тут уже и двухфакторная авторизация может не спасти (плюхнется токен на почту и привет!).
И при всём при этом, эти ограничения на пароль вдруг начинают игнорироваться самим инициатором выбора "не словарного пароля". С аргументацией "чтобы не забыли". Мля, ну серьёзно? И куча народу тут пытается оправдать эту херобору?
P.S. Я фронтом занимаюсь, так что нет - не сопровождал и не проектировал (ну кроме клиентской части, разумеется).
Обычно данные идут как пост данные, а это значит что в обычных лигах они не светятся (передаваемые параметры)
Какая разница, если тут все кричат что алгоритм прежде всего должен быть необратимым? Да и не так уж и много этих алгоритмов.
Нормальная практика.
ЗЫ - По мне так вообще FaceID и отпечаток пальца не являются секьюрной защитой, т.к. злоумышленнику ничего не составить показать ему твое лицо или заставить приложить твой палец. Намного надежней старый добрый пинкод или графический ключ.
Я только один раз видел, и то это сотрудник - админ напрямую с базы дернул. Вы другие случаи видели?
именно базы с картами и т.п. или просто телефоны? потому что во второе я поверю, а вот первое - тут скорее всего у вас эффект манделы (все говорят, что Сбер по швам трещит, но на самом деле эпизодов дай бог раз в пятилетку)
Вы соотносите, пожалуйста, контекст и комментарии. Речь про то, что то, как сбер работает с паролями - и там все хорошо. А вот утечка, которая была сделана админом, никак с этим фактом о паролях не связана.
И в той утечке не было паролей от аккаунтов (ибо они захешированы), а. Были номера карт и много чего ещё. Косяк? Косяк. Но с паролями не связан.
Плюс в Сбере, ИТшники вроде как в отдельных конторах сидят и офисах. То есть простой девочке до них, возможно даже достучаться не получится.
Это и не так сложно как кажется, у нее есть руководитель/куратор, она пишет/звонит ему, тот оперативно пересылает запрос на службу Безопасности или АйТи поддержку, те отвечают. Можно сразу в хелпдеск написать, но тогда реально могут сутки отвечать, так то информация не секретная.
А вы, конечно же в свою очередь без труда могли найти номер телефона нужного сотрудника отдела качества, к примеру))))
Разжую непонятную дичь для людей и ЛЛ.
Девушка не довольна уровнем безопасности хранимых Сбербанком личных данных. Дело в том, что для сохранности данных от злоумышленников пароли шифруются так называемым "HASH'ем", то-есть созданный вами пароль проходит процедуру шифрования и записывается в базу данных учетных записей в измененном виде.
Предположим пароль PasSwOrd в виде хеша будет записан как 472c782e2ea863cf9c98efe3984f908a
а пароль password будет представлен в виде 5f4dcc3b5aa765d61d8327deb882cf99.
При входе на сайт/приложение, ваш браузер передает по защищенному протоколу ваш пароль в открытом виде, а сайт на сервере с помощью инструкций преобразует пароль в хеш сумму и сравнивает её с записью в базе данных, если суммы совпадают - вы авторизованны, но судя по всему у Сбербанка не так...
Как видите хеш суммы паролей разные, злоумышленник получив ваш пароль в виде хеш суммы будет озадачен подбором всех вариаций паролей. Но @Sberbank хранит наши пароли в открытом виде, это чревато тем что у сотрудника банка или злоумышленника при наличии доступа к базе данных будет одна из самых больших баз данных логинов и паролей, и ему не нужно напрягаться с взломом пароля ведь все в открытом виде username:password
Хеши слов с разным регистром не совпадают. Любое изменение в регистре приводит к новому хешу. Комбинации такого рода посчитайте сами. И в целом безопасностью тут не пахнет.
Я не спец по защите информации поэтому спрошу у вас. Может быть такое, что пароль из формы по https летит на сервер, а там его toLowCase и уже потом хешируют и хранят хеш?
Хоть вопрос и не был адресован мне: что там у них на сервере, одним им известно, но пароль уходит в том виде, в каком его вводишь в поле:
{"password":"TEST","pageInputType":"INDEX","login":"TEST","loginInputType":"BY_LOGIN","storeLogin":false}
Всяко это менее безопасно. 1 дело ты каким-то образом пароль "подглядел" и теперь бьёшь как хочешь и он проходит, а другое ты размер символов не снял и пользователю летит уведомление что кто-то пытается войти.
В системах инфобезопасности кейсы уровня «подглядел пароль» ну вот минимально критичны, честно говоря. Вернее, критичны, но от утёкших паролей спасает 2FA.
Тогда бы в обратную сторону не работало. А так получается что я могу заглавными буквами набрать свой пароль и меня пустит, если бы его tolowcase так бы не работало
Ну просто твой пароль, который ты вводишь при входе, перед вычислением хеша тоже toLowCase.
Ну вот мне про аперкейс и ловкейс подсказали. Что не отнимает того факта что такого рода пароль теперь легче своровать/подобрать.
#comment_179277286
на своровать сложность пароля не влияет вообще. А на подбор - если говорить про реальный мир, а не математический, то "легче" это очень условно. Гораздо легче подобрать цифровой пароль от твоей мобилы и от мобильного же банка со всеми функциями, не?
Каждый символ увеличивает достаточно сильно время подбора. Своровав бд с хешами очень просто понять там в каком регистре всё захешировано. А дальше с этими же паролями но с разными регистрами ломимся на другие сайты и сервисы.
вы отвечаете не понимая сути, да? потому что каша.
"Каждый символ увеличивает достаточно сильно время подбора" - и? даже предположив, что вы имеете ввиду не кол-во символов, а набор символов (ну типо с регистром 50, без регистра 25) вы все равно пишете не разобравшись в моем ответе - там на брутфорс и с таким "укороченным) алфавитом не хватит времени на взлом.
"Своровав бд с хешами очень просто понять там в каком регистре всё захэшировано." - как своровать это и с чего вы решили что по хэшу легко понять регистр пароля??? К чему этот комментарий? (я говорю что на воровство не влияет криптостойкость и насрать на регистрозависимость, а вы пишете просто текст какой-то)
Либо человек не шарит, либо из безопасников уровня совы, которые до сих пор заставляют людей каждые 90 дней менять пароль, хотя миф о полезности сей процедуры развенчали уже хуй знает когда.
Для решения проблем с утечкой паролей придумали 2FA, а криптостойкостью эту проблему ну никак не решишь.
По базе с хешами гоняешь популярные пароли и быренько выясняешь в каком регистре.
И как бы то ни было разница 62 в 6 степени на порядок меньше 36 в 6. Что в в вычислительных мощностях множит просто на бешеные цифры.
Суть угонов состоит не столько даже в этом сервисе нагадить, как выяснить пароль пользователя в целом ибо в основном люди гоняют одни и те же пароли.
Всё же я вижу главную задачу хеша не дать посторонним людям, в случае утечки и т.п., заполучить пароли пользователей, а не просто так ради развлечения и потому что так кто-то сказал что нужно, обрезать на пополам количество символов и хешировать .
Проверил - действительно регистронезависимые.
Даже если "20 летняя девочка не знает что такое хеширование", то варинта два:
1. пароли хранятся в открытом виде/сравниваются расшифрованные (что почти одинаково)
2. хешируются все варианты пароля, во что я не верю :D
Подскажите, м.б. я чего то не знаю?