Да
Иногда системе можно скормить сам хэш, иногда подставить его в сетевой пакет. Иногда вместо хэша используются просто зашифрованные данные, которые легко можно расшифровать.
забыл только упомянуть про радужные таблицы для подбора пароля и коллизии хеш функций.
а так очень подробно!
Серверу передается пароль в открытом виде, и уже сервер при проверки сначала переводит в хэш, а потом только сравнивает их(само приложение на телефоне не генерирует хэш), так что когда ты пользуешься авторизацией через 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
Подскажите, м.б. я чего то не знаю?
Судя по второму варианту, не знает
Ну ладно. Я тоже знаю о хэшировании минуты три, с верхней ветки. Но если подумать... 8 символов минимум, все варианты регистров 8!=40320, если я хоть что-то знаю в комбинаторике. Замечательное число хэшей и это только начало
Да, может быть и меньше, если меньше букв, но в принципе число показательно
Не 2^8, а (длина алфавита хеша)^(длина хеша в символах алфавита). Например, 64^8, если брать восемь символов вида [a-zA-Z0-9_+].
Ну или проще 2^(длина хеша в битах), но это вряд ли 8.
У популярного md5 (не пытайтесь повторить это дома) это 2^128.