программа выдала постороннему логин другого пользователя, и сообщила, что введенный им пароль - именно от того логина.
Не факт. А логин- это просто почта. Он, что, её никому не даёт?
аккаунт это ведь связка логин-пароль.
вот человек набрал случайный набор символов.
программа говорит: этот набор является паролем в аккаунте, логин которого такой-то.
Олег всем дает почту, но ведь он никому не говорит, что именно она является логином в его аккаунте. это сказала программа.
Да бред и лохматая хохма. Уж если данный ресурс хранит пароли в нешифрованном виде, то уж хоть эту ботву с надписью выпилили бы, сказали - пароль неверен. Как уже раньше написали - Баян и ненастоящий скорее всего. Шоб такое накостылять, надо ещё постараться.
Если просто написать "пароль неверен" то это будет обычная форма авторизации, нахрена она здесь?) да как собственно и изначальный боян
А не надо куки сохранять, запоминалки паролей включенными держать, если так о безопасности печёшься.
а что, в кукисах пароли кто-то хранит?
даже если и хранится идентификатор сессии с указанием даты, то нормальный программист в БД хранит ещё и IP текущей сессии, так что толку не будет от того, что твои кукисы кто-то украдёт.
все эти страшилки о вреде кукисов актуальны только в случае если сайт купили на авите за ₽5000
Программисты ориджина меня улыбнули ещё больше. Это, кто не знает, стим от Electronic Arts. После очередного апдейта не могу логиниться. Захожу на сайт, в поддержку. Выбираю категорию: проблема со входом в ориджин. ТАм выбираю, что не могу залогинится вообще. И следующее сообщение поставило меня в тупик: для того, чтобы послать эту петицию, пожалуйста, залогиньтесь
программа выдала постороннему логин другого пользователя, и сообщила, что введенный им пароль - именно от того логина.
Не факт. А логин- это просто почта. Он, что, её никому не даёт?
аккаунт это ведь связка логин-пароль.
вот человек набрал случайный набор символов.
программа говорит: этот набор является паролем в аккаунте, логин которого такой-то.
Олег всем дает почту, но ведь он никому не говорит, что именно она является логином в его аккаунте. это сказала программа.
Да бред и лохматая хохма. Уж если данный ресурс хранит пароли в нешифрованном виде, то уж хоть эту ботву с надписью выпилили бы, сказали - пароль неверен. Как уже раньше написали - Баян и ненастоящий скорее всего. Шоб такое накостылять, надо ещё постараться.
Если просто написать "пароль неверен" то это будет обычная форма авторизации, нахрена она здесь?) да как собственно и изначальный боян
Насколько я помню Апач(а иже с ними и всяческие энджингсы етц.), то он даже в базовой авторизации - не вернет, что пароль от другого пользуна :) То есть формально тут речь не идет о базовой авторизации любого веб-сервера. Значит пилили сами :) Раз пилили сами - значит что-то на сервере лазеет в БД, и делает
И да, я был не прав, чёт не подумал. Ровно такая же фигня - если пароль зашифрован ну скажем MD5. Сам пароль останется тайной для веб-сервера и БД, но валидацию пройдет
вводишь любой пароль, если в БД такой есть, то сайт тебе подскажет какой логин соответствует этому паролю
И что, система в БД хранит пароли в открытом виде?
нет никакой разницы какой функцией зашифрован пароль перед попаданием в БД и шифруется ли он вообще.
если система сравнивает хэши, то сути это не меняет - на совпадение хэша система вернёт тот же самый ответ - есть совпадение со строкой в которой такой то никнейм указан. для пользователя это тоже не имеет значения - он вводит пароль, а не хэш
программа выдала постороннему логин другого пользователя, и сообщила, что введенный им пароль - именно от того логина.
Не факт. А логин- это просто почта. Он, что, её никому не даёт?
аккаунт это ведь связка логин-пароль.
вот человек набрал случайный набор символов.
программа говорит: этот набор является паролем в аккаунте, логин которого такой-то.
Олег всем дает почту, но ведь он никому не говорит, что именно она является логином в его аккаунте. это сказала программа.
Да бред и лохматая хохма. Уж если данный ресурс хранит пароли в нешифрованном виде, то уж хоть эту ботву с надписью выпилили бы, сказали - пароль неверен. Как уже раньше написали - Баян и ненастоящий скорее всего. Шоб такое накостылять, надо ещё постараться.
Если просто написать "пароль неверен" то это будет обычная форма авторизации, нахрена она здесь?) да как собственно и изначальный боян
Насколько я помню Апач(а иже с ними и всяческие энджингсы етц.), то он даже в базовой авторизации - не вернет, что пароль от другого пользуна :) То есть формально тут речь не идет о базовой авторизации любого веб-сервера. Значит пилили сами :) Раз пилили сами - значит что-то на сервере лазеет в БД, и делает
И да, я был не прав, чёт не подумал. Ровно такая же фигня - если пароль зашифрован ну скажем MD5. Сам пароль останется тайной для веб-сервера и БД, но валидацию пройдет
Про взлом МД5 прошу не пинать :)
Ты 1С-ник или просто ленивый? Или ленивый 1С-ник?!
вводишь любой пароль, если в БД такой есть, то сайт тебе подскажет какой логин соответствует этому паролю
И что, система в БД хранит пароли в открытом виде?
нет никакой разницы какой функцией зашифрован пароль перед попаданием в БД и шифруется ли он вообще.
если система сравнивает хэши, то сути это не меняет - на совпадение хэша система вернёт тот же самый ответ - есть совпадение со строкой в которой такой то никнейм указан. для пользователя это тоже не имеет значения - он вводит пароль, а не хэш
Разница есть и огромная, если у тебя серьезный сайт или система, то хеши там будут считаться взрослыми алгоритмами, а не каким нибудь басяцким MD5, SHAXXX и и т.д. А фишка там в том что алгоритмы key derivation намеренно долго считают хеш (насколько долго определяется коэффициентом сложности и может настраиваться), это сделано для усложнения процесса брутфорса (нельзя так просто взять и перебрать миллиард паролей, если на проверку одного у тебя может уйти несколько секунд). Соответственно и в базу ты запрос с конкретным условием на значение хеша кинуть не можешь, так как там еще присутствует соль, тебе придется перебирать каждую учетку, хешировать введенный пароль посолив солью от этой учетки, и сравнивать с хешем в этой учетке, соответственно чтобы показать к какой еще учетке подходит пароль тебе придется пробрутфорсить всю базу, что невозможно сделать за вменяемое время
вводишь любой пароль, если в БД такой есть, то сайт тебе подскажет какой логин соответствует этому паролю
И что, система в БД хранит пароли в открытом виде?
нет никакой разницы какой функцией зашифрован пароль перед попаданием в БД и шифруется ли он вообще.
если система сравнивает хэши, то сути это не меняет - на совпадение хэша система вернёт тот же самый ответ - есть совпадение со строкой в которой такой то никнейм указан. для пользователя это тоже не имеет значения - он вводит пароль, а не хэш
Разница есть и огромная, если у тебя серьезный сайт или система, то хеши там будут считаться взрослыми алгоритмами, а не каким нибудь басяцким MD5, SHAXXX и и т.д. А фишка там в том что алгоритмы key derivation намеренно долго считают хеш (насколько долго определяется коэффициентом сложности и может настраиваться), это сделано для усложнения процесса брутфорса (нельзя так просто взять и перебрать миллиард паролей, если на проверку одного у тебя может уйти несколько секунд). Соответственно и в базу ты запрос с конкретным условием на значение хеша кинуть не можешь, так как там еще присутствует соль, тебе придется перебирать каждую учетку, хешировать введенный пароль посолив солью от этой учетки, и сравнивать с хешем в этой учетке, соответственно чтобы показать к какой еще учетке подходит пароль тебе придется пробрутфорсить всю базу, что невозможно сделать за вменяемое время
дядя петя, ты дурак?
ты о чём вообще?
главное, где ты взял, что хэш намеренно долго считается? таймаут выставляют на повторную попытку, но вот чтобы замедлять алгоритм...
в данном конкретном случае нет никакой разницы - результат всегда будет один: сайт выдаст имя пользователя
и какие нафиг серьёзные сайты? тут же явно не какой-нибудь password_hash с Argon2 и автоматической генерацией соли. а значит, что нет разнцы пароль в БД или его хэш, соль всё равно своя и явно не хранится вместе с хэшем.
про "пробрутфорсить": ещё раз подумай про таймаут (его возможное отсутствие) и чем наличие хорошего алгоритма с персональной солью к каждому хэшу помешает перебору? никто в здравом уме на "серьёзном сайте" не станет выставлять максимальную цену хэша, а скорее наборот ограничат цену, чтобы не тормозить систему.
и про серьёзные сайты вообще смешно - совсем же недавно скандалили из-за того, что фейсбук хранил в БД пароли в открытом виде
вводишь любой пароль, если в БД такой есть, то сайт тебе подскажет какой логин соответствует этому паролю
И что, система в БД хранит пароли в открытом виде?
нет никакой разницы какой функцией зашифрован пароль перед попаданием в БД и шифруется ли он вообще.
если система сравнивает хэши, то сути это не меняет - на совпадение хэша система вернёт тот же самый ответ - есть совпадение со строкой в которой такой то никнейм указан. для пользователя это тоже не имеет значения - он вводит пароль, а не хэш
Разница есть и огромная, если у тебя серьезный сайт или система, то хеши там будут считаться взрослыми алгоритмами, а не каким нибудь басяцким MD5, SHAXXX и и т.д. А фишка там в том что алгоритмы key derivation намеренно долго считают хеш (насколько долго определяется коэффициентом сложности и может настраиваться), это сделано для усложнения процесса брутфорса (нельзя так просто взять и перебрать миллиард паролей, если на проверку одного у тебя может уйти несколько секунд). Соответственно и в базу ты запрос с конкретным условием на значение хеша кинуть не можешь, так как там еще присутствует соль, тебе придется перебирать каждую учетку, хешировать введенный пароль посолив солью от этой учетки, и сравнивать с хешем в этой учетке, соответственно чтобы показать к какой еще учетке подходит пароль тебе придется пробрутфорсить всю базу, что невозможно сделать за вменяемое время
дядя петя, ты дурак?
ты о чём вообще?
главное, где ты взял, что хэш намеренно долго считается? таймаут выставляют на повторную попытку, но вот чтобы замедлять алгоритм...
в данном конкретном случае нет никакой разницы - результат всегда будет один: сайт выдаст имя пользователя
и какие нафиг серьёзные сайты? тут же явно не какой-нибудь password_hash с Argon2 и автоматической генерацией соли. а значит, что нет разнцы пароль в БД или его хэш, соль всё равно своя и явно не хранится вместе с хэшем.
про "пробрутфорсить": ещё раз подумай про таймаут (его возможное отсутствие) и чем наличие хорошего алгоритма с персональной солью к каждому хэшу помешает перебору? никто в здравом уме на "серьёзном сайте" не станет выставлять максимальную цену хэша, а скорее наборот ограничат цену, чтобы не тормозить систему.
и про серьёзные сайты вообще смешно - совсем же недавно скандалили из-за того, что фейсбук хранил в БД пароли в открытом виде
Ты откуда вылез такой умник то? Я к этому делу непосредственное отношение имею, можешь посмотреть вот эту статью на хабре https://habr.com/ru/post/210760 можешь погуглить например bcrypt или scrypt, и с какой скоростью они хэширует. Серьезные сайты и системы - это там где есть твои персональные данные или финансовые операции, а не там где ты бложик ведешь. И да, представь себе люди в здравом уме намеренно замедляют свою алгоритмы, ты же наверно не хотел бы чтобы твой пароль от Сбербанк Онлайн хранился в каком нибудь MD5 и подбирался на космических скоростях. Соль нужна только чтобы отсечь уже готовые таблицы и хранится как раз таки вместе с хэщем. Про таймаут вообще смешно, учитывая что защита эта делается в первую очередь чтобы пароли не были скомпрометированы при условии физической утечки ВСЕЙ БАЗЫ со всеми логинами и паролями, а не просто защиты от перебора через обращение на твой ресурс. Когда злоумышленники получат твою базу, ковырять они ее будут своими проверенными средствами, на полной скорость которую дает твой алгоритм, без каких либо таймаутов, поэтому задержка ДОЛЖНА БЫТЬ в самом алгоритме, а не сбоку прикручена. Обсуждать тут защищенность фейсбука я не собираюсь, да и вообще обсуждать информационную безопасность с человеком который даже не удосужился загуглить о чем пишет другой человек, тем более в шуточной теме.
Это сообщение отредактировал Gexxo - 20 окт 2020 в 09:49
вводишь любой пароль, если в БД такой есть, то сайт тебе подскажет какой логин соответствует этому паролю
И что, система в БД хранит пароли в открытом виде?
нет никакой разницы какой функцией зашифрован пароль перед попаданием в БД и шифруется ли он вообще.
если система сравнивает хэши, то сути это не меняет - на совпадение хэша система вернёт тот же самый ответ - есть совпадение со строкой в которой такой то никнейм указан. для пользователя это тоже не имеет значения - он вводит пароль, а не хэш
Разница есть и огромная, если у тебя серьезный сайт или система, то хеши там будут считаться взрослыми алгоритмами, а не каким нибудь басяцким MD5, SHAXXX и и т.д. А фишка там в том что алгоритмы key derivation намеренно долго считают хеш (насколько долго определяется коэффициентом сложности и может настраиваться), это сделано для усложнения процесса брутфорса (нельзя так просто взять и перебрать миллиард паролей, если на проверку одного у тебя может уйти несколько секунд). Соответственно и в базу ты запрос с конкретным условием на значение хеша кинуть не можешь, так как там еще присутствует соль, тебе придется перебирать каждую учетку, хешировать введенный пароль посолив солью от этой учетки, и сравнивать с хешем в этой учетке, соответственно чтобы показать к какой еще учетке подходит пароль тебе придется пробрутфорсить всю базу, что невозможно сделать за вменяемое время
дядя петя, ты дурак?
ты о чём вообще?
главное, где ты взял, что хэш намеренно долго считается? таймаут выставляют на повторную попытку, но вот чтобы замедлять алгоритм...
в данном конкретном случае нет никакой разницы - результат всегда будет один: сайт выдаст имя пользователя
и какие нафиг серьёзные сайты? тут же явно не какой-нибудь password_hash с Argon2 и автоматической генерацией соли. а значит, что нет разнцы пароль в БД или его хэш, соль всё равно своя и явно не хранится вместе с хэшем.
про "пробрутфорсить": ещё раз подумай про таймаут (его возможное отсутствие) и чем наличие хорошего алгоритма с персональной солью к каждому хэшу помешает перебору? никто в здравом уме на "серьёзном сайте" не станет выставлять максимальную цену хэша, а скорее наборот ограничат цену, чтобы не тормозить систему.
и про серьёзные сайты вообще смешно - совсем же недавно скандалили из-за того, что фейсбук хранил в БД пароли в открытом виде
Чувак, в данном случае, ты не прав. Тот же bcrypt заебешься перебирать. А если он еще в несколько слоев, то ваще овчинка выделки не стоит.
Усложнение перебора хешей за счет ресурсоемкости их расчета применятеся много где. Например, во всяких алгоритмах, связанных с криптовалютой - чтобы до невозможного усложнить возможности подбора.
Это сообщение отредактировал Abrazina - 20 окт 2020 в 09:53
Я тут недавно в свой гугл акк пытался зайти. Все верно ввожу, а мне выдает типа, мы вам верим, что это вы, но подтвердите еще и через смс. А симки нет и она с другого региона. Короче неделю проебался и случайно зашел с другого телефона.
вводишь любой пароль, если в БД такой есть, то сайт тебе подскажет какой логин соответствует этому паролю
И что, система в БД хранит пароли в открытом виде?
нет никакой разницы какой функцией зашифрован пароль перед попаданием в БД и шифруется ли он вообще.
если система сравнивает хэши, то сути это не меняет - на совпадение хэша система вернёт тот же самый ответ - есть совпадение со строкой в которой такой то никнейм указан. для пользователя это тоже не имеет значения - он вводит пароль, а не хэш
Разница есть и огромная, если у тебя серьезный сайт или система, то хеши там будут считаться взрослыми алгоритмами, а не каким нибудь басяцким MD5, SHAXXX и и т.д. А фишка там в том что алгоритмы key derivation намеренно долго считают хеш (насколько долго определяется коэффициентом сложности и может настраиваться), это сделано для усложнения процесса брутфорса (нельзя так просто взять и перебрать миллиард паролей, если на проверку одного у тебя может уйти несколько секунд). Соответственно и в базу ты запрос с конкретным условием на значение хеша кинуть не можешь, так как там еще присутствует соль, тебе придется перебирать каждую учетку, хешировать введенный пароль посолив солью от этой учетки, и сравнивать с хешем в этой учетке, соответственно чтобы показать к какой еще учетке подходит пароль тебе придется пробрутфорсить всю базу, что невозможно сделать за вменяемое время
дядя петя, ты дурак?
ты о чём вообще?
главное, где ты взял, что хэш намеренно долго считается? таймаут выставляют на повторную попытку, но вот чтобы замедлять алгоритм...
в данном конкретном случае нет никакой разницы - результат всегда будет один: сайт выдаст имя пользователя
и какие нафиг серьёзные сайты? тут же явно не какой-нибудь password_hash с Argon2 и автоматической генерацией соли. а значит, что нет разнцы пароль в БД или его хэш, соль всё равно своя и явно не хранится вместе с хэшем.
про "пробрутфорсить": ещё раз подумай про таймаут (его возможное отсутствие) и чем наличие хорошего алгоритма с персональной солью к каждому хэшу помешает перебору? никто в здравом уме на "серьёзном сайте" не станет выставлять максимальную цену хэша, а скорее наборот ограничат цену, чтобы не тормозить систему.
и про серьёзные сайты вообще смешно - совсем же недавно скандалили из-за того, что фейсбук хранил в БД пароли в открытом виде
Чувак, в данном случае, ты не прав. Тот же bcrypt заебешься перебирать. А если он еще в несколько слоев, то ваще овчинка выделки не стоит.
Усложнение перебора хешей за счет ресурсоемкости их расчета применятеся много где. Например, во всяких алгоритмах, связанных с криптовалютой - чтобы до невозможного усложнить возможности подбора.
Вот человек в теме У нас тут сейчас проект СЭД на ~50К пользователей переписывается с нуля, сразу прикрутил HMACSHA1 для хэшей, так как на предложение использовать например MD5 был бы послан нах еще на этапе согласования с ИБ. Ну а на предложение просто хранить в открытом виде был бы послан на биржу труда по собственному желанию
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
Что происходит с самим Олегом в это время пока не изучено!
yaplakal.com