Comments 100
Обратите внимание, повышая сложность вычисления хеша, вы увеличиваете нагрузку на сервер, на котором он будет считаться. т.е. можно будет весьма эффективно досить портал, через логин форму.
Эта проблема решается очень просто — принимать не более 3/5/10 запросов на регистрацию в час/сутки с одного ip.
я и не говорил, что это нерешаемая проблема, а лишь обратил внимание на неё.
А принимая не более 3/5/10 запросов в t, вы можете прикрыть юзеров за проксями.
А принимая не более 3/5/10 запросов в t, вы можете прикрыть юзеров за проксями.
Проблема будет не столько в регистрации, сколько в авторизации — ведь в ней вы используете ту же самую функцию
А что мешает поставить такое-же ограничение на количество авторизаций с одного ip?
Нужно понимать, что IP — это не ID конкретного пользователя.
Речь же вроде о вредительской нагрузке на сервер? Обычным пользователям такое ограничение не повредит, а вот блокировка по ip убережет сайт от ддоса через форму регистрации/авторизации если не на 100%, то на число близкое к нему. А юзать тысячи временных ip ради ддоса через форму авторизации — зачем? Есть более удобные цели для атак.
По IP нельзя ограничивать регистрацию. Пользователи, сидящие через серые IP (wifi — adsl — свистки от сотовых операторов) после таких приколов могут и не суметь зарегаться.
Ботнету без разницы.
Раньше мы хранили пароли через md5, но озаботившись проблемой обеспечения безопасности пользовательских данных (т.к. ввели систему платежей), решили использовать crypt(sha1*100)
Рост нагрузки был в пределах погрешности измерения.
А если вы собрались бороться с ddos, то просто отключите страницу, на которую идет атака.
Рост нагрузки был в пределах погрешности измерения.
А если вы собрались бороться с ddos, то просто отключите страницу, на которую идет атака.
я думаю что в 99.99% случаев злоумышленнику проще будет выбрать другую страницу с более сильной нагрузкой на сервер где даже не нужно будет моделировать пост запрос
Сорри за саморекламу, но вот еще статейка на эту тему
habrahabr.ru/post/100138/
habrahabr.ru/post/100138/
Хм, благодарю, очень интересно, не видел, потому что искал только PHP-реализацию
Тогда уж вот в продолжение темы:
habrahabr.ru/post/100301/
habrahabr.ru/post/100301/
Раз уж начали, то и мои 5 копеек: mrthe.name/2009/08/kak-hranit-paroli-polzovatelej/
Все пункты(кроме модуля) были опробованы на реальном проекте, нагрузка из-за долгой генерации пароля крайне мала.
Все пункты(кроме модуля) были опробованы на реальном проекте, нагрузка из-за долгой генерации пароля крайне мала.
UFO just landed and posted this here
Собственно, мои пять копеек
H = AES(K, IV, SHA(login)), где K — ключ равный SHA256(password), IV — вектор инициализации, равный MD5(login).
Да, CMAC-подобно.
H = AES(K, IV, SHA(login)), где K — ключ равный SHA256(password), IV — вектор инициализации, равный MD5(login).
Да, CMAC-подобно.
Исправьте пожалуйста
«на даже получив доступ»
«на даже получив доступ»
А мне казалось, что все уже прочли это.
Я использую хеш от пароля, соли пользователя, и соли сервера которая храниться в файле. Таким образом слив только базы не даст доступа к паролю.
упоминать в контексте хранения паролей crc32 — это конечно позор…
В бою пользовался конструкцией:
$salt = hash('sha256', $email);
$hashingString = $salt. $password;
$pwdHash = hash('whirlpool', $hashingString);
Когда-то посчитал, что это одно из самых безопасных решений. А выбор алгоритмов далеко не случайный.
$salt = hash('sha256', $email);
$hashingString = $salt. $password;
$pwdHash = hash('whirlpool', $hashingString);
Когда-то посчитал, что это одно из самых безопасных решений. А выбор алгоритмов далеко не случайный.
А можно поподробнее про выбор алгоритмов? Интересно.
Сейчас слабо помню, но когда выбирал, выбирал таким образом, чтобы
а) каждый по отдельности был защищенным и не было возможности взломать его по таблицам или подобной фигне.
б) подбирались по длине. whirpool хорошо хеширует даже очень длинные пароли. А популярный мд5 быстро расходует свою вариативность. Или как оно там правильно называется.
а) каждый по отдельности был защищенным и не было возможности взломать его по таблицам или подобной фигне.
б) подбирались по длине. whirpool хорошо хеширует даже очень длинные пароли. А популярный мд5 быстро расходует свою вариативность. Или как оно там правильно называется.
А не проще чем замедлять генерацию пароля просто сделать таймаут некий полечком в базке например, прикрутить к пользователю и при неверной попытке авторизации выставлять его в N-секунд, скажем 5. А при следующих авторизацию просто читать таймаут этот, и если он еще не прошел — сразу отлуп давать.
Так и сервер грузить не будете излишними вычислениями 1кк хэшэй.
Так и сервер грузить не будете излишними вычислениями 1кк хэшэй.
1кк хэшей и прочие замедляторы нужны не для того, чтобы замедлить авторизацию, а на тот случай, если злоумышленник сольёт базу с хэшами и начнет ее брутить. Тогда он будет вынужден на каждую попытку потратить не 1 мкс (условно), а 1 секунду.
Если злоумышленник слил базу с хэшами — сушите весла.
Собственно, почему?
Все описанные в статье механизмы направлены на защиту как раз в случае утечки базы.
Все описанные в статье механизмы направлены на защиту как раз в случае утечки базы.
Потому что вероятность слить базу с хэшами и не слить все остальное стремится к нулю :)
Потому что если злоумышленник слил базу с хэшами — вы об этом не узнаете, и ничего не предпримите (в отличии от попытки брутфорса логина). Узнаете когда он ее поломает, а он ее поломает. Социальная инженерия убедительно побеждает любую криптостойкость. Ведь у истоков создания пароля стоит тетя Маша, которая или выдумывает пароли из головы, или записывает выданный ей не читаемый набор букв-цифр-спецсимволов на бумажку.
Хотите безопасности — отключите сервер от сети. Или накупите вот такого рутокен-web и всем пользователя раздайте. И SMS-КИ шлите с временным токеном при логине, как это банкиры практикуют. И таймауты сделайте, и 1000к генерацию хэшей подписей, и капчи. Но все равно гарантий нет. Хотите гарантий — купите тостер :)
Потому что если злоумышленник слил базу с хэшами — вы об этом не узнаете, и ничего не предпримите (в отличии от попытки брутфорса логина). Узнаете когда он ее поломает, а он ее поломает. Социальная инженерия убедительно побеждает любую криптостойкость. Ведь у истоков создания пароля стоит тетя Маша, которая или выдумывает пароли из головы, или записывает выданный ей не читаемый набор букв-цифр-спецсимволов на бумажку.
Хотите безопасности — отключите сервер от сети. Или накупите вот такого рутокен-web и всем пользователя раздайте. И SMS-КИ шлите с временным токеном при логине, как это банкиры практикуют. И таймауты сделайте, и 1000к генерацию хэшей подписей, и капчи. Но все равно гарантий нет. Хотите гарантий — купите тостер :)
Всегда считал, что нужно исходить из наихудших условий — того что у хакера есть полный рутовый доступ на сервер. И если с тем что он сделает в порыве бессильной ярости, после неудавшегося брутфорса паролей, мы ничего поделать не можем, то уж пароли наших юзеров хотя бы убережем.
А вам не кажется, что имея полный рутовый доступ на сервер хакер может например вписать код в ваш авторизационный скрипт (мы ведь про php говорим), который будет все входы пользователей в какой-нибудь лог складывать? И ему в таком случае вообще ничего подбирать не нужно.
Ну, с этим программно невозможно бороться.
Разве что написать:
где-нибудь в хорошо запрятанном файле, и писать весь код учитывая это. У постороннего человека, пытающегося что-то отредактировать ничего, соответственно работать не будет. ;)
Разве что написать:
<?php define ('true', false); ?>где-нибудь в хорошо запрятанном файле, и писать весь код учитывая это. У постороннего человека, пытающегося что-то отредактировать ничего, соответственно работать не будет. ;)
Еще один этап защиты будет если при авторизации/регистрации сам пароль на сервак вообще не отправляется, а шлется уже хеш от него.
Я например делал так: джаваскриптом вычислял easyHash = md5( pass + easySalt ) и запросом на сервак отправлялся уже easyHash. На серваке же уже после создания в бд пользователя делал примерно finishHash = md5( userId + strongSalt + easyHash ) и уже его хранил в бд.
Это немного спасет от сниффалок трафика. А вынеся js файл отвечающий за отправку логина пароля на какой нить code.google.com мы усложним жизнь чуваку получившему рут на нашем серваке, по крайней мере ему придется потрудится чтобы написать свою форму и свой обработчик и чтобы старая схема не сломалась и пользователи ничего не заподозрили.
Я например делал так: джаваскриптом вычислял easyHash = md5( pass + easySalt ) и запросом на сервак отправлялся уже easyHash. На серваке же уже после создания в бд пользователя делал примерно finishHash = md5( userId + strongSalt + easyHash ) и уже его хранил в бд.
Это немного спасет от сниффалок трафика. А вынеся js файл отвечающий за отправку логина пароля на какой нить code.google.com мы усложним жизнь чуваку получившему рут на нашем серваке, по крайней мере ему придется потрудится чтобы написать свою форму и свой обработчик и чтобы старая схема не сломалась и пользователи ничего не заподозрили.
Вы правы, это в любом случае безопаснее.
Еще безопаснее если сравнение идет не по запрошенному из базы хэшу, а путем вызова хранимой процедуры, в которой и сама база еще хэш от того что ей дает сервак вычисляет и лишь затем сравнивает.
Но в данном случае речь шла о рутовом доступе, и про считывание пароля я привел в качестве примера. В этом случае хэш не поможет, поскольку если я на стороне сервера считал хэш, ничто не мешает мне на стороне клиента слать вам прямо хэш напрямую через POST запрос (минуя промежуточные вычисления из оригинального пароля). Да, я не буду знать оригинальный пароль, но доступ получу.
Еще безопаснее если сравнение идет не по запрошенному из базы хэшу, а путем вызова хранимой процедуры, в которой и сама база еще хэш от того что ей дает сервак вычисляет и лишь затем сравнивает.
Но в данном случае речь шла о рутовом доступе, и про считывание пароля я привел в качестве примера. В этом случае хэш не поможет, поскольку если я на стороне сервера считал хэш, ничто не мешает мне на стороне клиента слать вам прямо хэш напрямую через POST запрос (минуя промежуточные вычисления из оригинального пароля). Да, я не буду знать оригинальный пароль, но доступ получу.
Для того чтобы не взломали пароли на других сайтах. Для этого и делаем
Не нужно изобретать собственные алгоритмы. Используйте:
— bcrypt,
— PBKDF2 с HMAC-SHA256 (рекомендовано NIST в SP 800-132),
— scrypt.
Рекомендованная длина хеша.
Множественное хеширование слегка замедляет подбор пароля, но и снижает криптографическую стойкость (сужает выходное множество значений).
— bcrypt,
— PBKDF2 с HMAC-SHA256 (рекомендовано NIST в SP 800-132),
— scrypt.
Рекомендованная длина хеша.
Множественное хеширование слегка замедляет подбор пароля, но и снижает криптографическую стойкость (сужает выходное множество значений).
Собственно приведенный код — это почти bcrypt :)
Вот полная реализация bcrypt на php: stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php
Вот полная реализация bcrypt на php: stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php
Статическая соль и тому подобные конструкции могут служить достаточно хорошо… пока структура этих конструкций и соль хранятся в тайне. Если же злоумышленник вызнает секрет хэширования — он с легкостью сможет модифицировать под него свою «радужную таблицу»Что подразумевается под лёгкостью? Как можно модифицировать таблицу быстрее, чем повторным вычислением хеша для всех значений (т.е. быстрее того же брутфорса)?
«Канадский алфавит» это как? :/
Как-то вы неаккуратно о crc32: не стоит ставить его в один ряд со всякими md5, sha1 и проч. — они являются криптографическими хэш-функциями, а crc32 вроде как для контроля целостности данных. Если его кто-то использует не по назначению, это его проблема. И здесь не только проблема в том, что он 32-х битный, а то, что легко подвержен атакам на критрохэш-функции. Да и вроде не устаревший он, а вовсю применяется по назначению. Несмотря на солидный возраст, crc32 все еще обнаруживает одиночные ошибки, двойные ошибки и ошибки в нечетном числе битов.
Это будет называться не брутфорс а поиск коллизии, это раз. Уникальная соль это бред — где вы будете её хранить? в базе? С crc32 вы тоже загнули.
Далее «использование алгоритма Blowfish» — брееед. Хеш на то и любим разработчиками, что занимает фиксированное место в базе. Blowfish это симметрический шифр, результат которого мало того что может конфликтовать с кодировкой базы, так ещё и вовсе не поместится в строку.
Самый простой и проверенный временем вариант — md5($password. $sault). Однако надо знать, что часто через SQL-инъекции можно получить доступ даже к файловой системе.
Далее «использование алгоритма Blowfish» — брееед. Хеш на то и любим разработчиками, что занимает фиксированное место в базе. Blowfish это симметрический шифр, результат которого мало того что может конфликтовать с кодировкой базы, так ещё и вовсе не поместится в строку.
Самый простой и проверенный временем вариант — md5($password. $sault). Однако надо знать, что часто через SQL-инъекции можно получить доступ даже к файловой системе.
Далее «использование алгоритма Blowfish» — брееед.
А ничего, что реализация bcrypt основана на blowfish?
где вы будете её хранить? в базе?
В ней, родимой. А что?
Blowfish это симметрический шифр, результат которого мало того что может конфликтовать с кодировкой базы, так ещё и вовсе не поместится в строку.
На основе блочного шифра элементарно делается хеш-функция.
MD5 вообще-то тоже 16 байт выдает, которые в кривых руках будут конфликтовать с кодировкой базы.
md5($password. $sault)
Не, стаття, конечно, целиком из баянов состоит, но это не повод размахивать в комментариях своей губной гармошкой как последним словом аккордеоностроения.
Однако надо знать, что часто через SQL-инъекции можно получить доступ даже к файловой системе.
А еще в огороде бузина и в Киеве дядька.
for ($i = 0; $i < 1000; $i++) {
$hash = sha1($hash);
}
Что за бред?
Если вы хотите замедлить авторизацию не страдайте херней, а делайте увеличивающийся таймаут, записываемый в доп поле таблицы. Правда тогда есть риск, что юзера тупо заддосят, чтобы он не мог авторизоваться.
Если вашу базу и код слили, то это замедление не спасет ну ни разу.
$hash = sha1($hash);
}
Что за бред?
Если вы хотите замедлить авторизацию не страдайте херней, а делайте увеличивающийся таймаут, записываемый в доп поле таблицы. Правда тогда есть риск, что юзера тупо заддосят, чтобы он не мог авторизоваться.
Если вашу базу и код слили, то это замедление не спасет ну ни разу.
Почти 200 человек добавили статью в Избранное.
Удивительный Хабр.
Удивительный Хабр.
Капчу уже отменили?
Респект за статью! Уровень вовлеченности в тему сильно больше, чем у многих «маститых» авторов Хабра.
PS: Гляньте на дату рождения топикстартера в профиле! Горжусь, что у нас такая молодежь осталась, а не только «сходить за клинским»…
PS: Гляньте на дату рождения топикстартера в профиле! Горжусь, что у нас такая молодежь осталась, а не только «сходить за клинским»…
Два небольших замечания.
1. К безопасности собственно сайта безопасность хранения паролей имеет весьма опосредованное отношение. И выстрелит раззве что в случае, если злоумышленнику удалось получить дамп БД. Разумеется, это не повод не хэшировать пароли, но просто почему-то всегда в разговоре о паролях подразумевается безопасность сайта, а не сохранность собственно паролей.
2. Множество «короткие и простые пароли» НЕ тождественно множеству «8-символьный пароль, который будут ломать 7 лет». Пароль «12345» будут ломать пару секунд. Так что все эти «тыщу раз захешируем» НЕ являются альтернативой запрету простых паролей.
1. К безопасности собственно сайта безопасность хранения паролей имеет весьма опосредованное отношение. И выстрелит раззве что в случае, если злоумышленнику удалось получить дамп БД. Разумеется, это не повод не хэшировать пароли, но просто почему-то всегда в разговоре о паролях подразумевается безопасность сайта, а не сохранность собственно паролей.
2. Множество «короткие и простые пароли» НЕ тождественно множеству «8-символьный пароль, который будут ломать 7 лет». Пароль «12345» будут ломать пару секунд. Так что все эти «тыщу раз захешируем» НЕ являются альтернативой запрету простых паролей.
2. При наличии соли и медленного алгоритма даже перебор словарных паролей сильно затянется. Как пример можно привести запароленные rar-архивы, которые крайне медленно брутятся.
И за это время, если на сервере настроено крутое логирование озаглавливающее подозрительные запросы, можно успеть принудительно поменять пароли всем пользователям и залатать дыру.
И за это время, если на сервере настроено крутое логирование озаглавливающее подозрительные запросы, можно успеть принудительно поменять пароли всем пользователям и залатать дыру.
А зачем тысячу раз переписывать хэш? Не лучше ли дать процессу поспать с точки зрения быстродействия — тогда нагрузка на сервер будет меньше. Я не спец в ПХП, но здравый смысл подсказывает…
Нет. Тогда злоумышленник зная процес хеширования просто уберёт функциию sleep из алгоритма. А так — он реально будет тратить бОльшее время на взлом каждого пароля.
Процитирую себя же:
Процитирую себя же:
Перебор 1000 паролей на компьютере средней мощности должен занимать больше 1 секунды.
Всё равно не совсем понял (извините, туплю), можете ответить в ЛС? Я так понимаю по условию задачи у злоумышленника нет доступа к коду на стороне сервера и, соответственно, возможности его имзенить — он просто стучится в веб-сервис, который записывает пароль в базу, предварительно обработав аглоритмом F(password). В данном случае ведь неважно как замедлять, разве нет?
Ещё раз, простите если вопрос слишком глупый — но очень хочется разобраться.
Ещё раз, простите если вопрос слишком глупый — но очень хочется разобраться.
Ну я думал, что у злоумышленника есть база и известный алгоритм. Тогда выходит так:
Можно взять как пример какой-то известный движок, код которого злоумышленник может найти.
Тут становится известен алгоритм генерации хеша пароля.
Далее, сливается база с уязвимого сайта и используя известный алгоритм нужные хеши перебираются, что бы узнать исходный пароль. Часто нужен пароль, например, админа, что бы открыть себе бОльшие возможности, чем просто копия базы.
А если так как у вас, то тогда лучше даже не замедлять, а просто ограничивать кол-во запросов на авторизацию в минуту с одного ip, например.
Можно взять как пример какой-то известный движок, код которого злоумышленник может найти.
Тут становится известен алгоритм генерации хеша пароля.
Далее, сливается база с уязвимого сайта и используя известный алгоритм нужные хеши перебираются, что бы узнать исходный пароль. Часто нужен пароль, например, админа, что бы открыть себе бОльшие возможности, чем просто копия базы.
А если так как у вас, то тогда лучше даже не замедлять, а просто ограничивать кол-во запросов на авторизацию в минуту с одного ip, например.
Хороший получился пост! Тут тебе и всевозможные методы защиты беспечных пользователей (да и что говорить — сайтов в целом), и методы защиты от хакеров, и методы взлома, куча полезных ссылок! Нет, ну однозначно в избранное!
Сегодня процессе разработки системы авторизации для своего проекта...
Вы авторизацию с аутенфикацией не перепутали?
ru.wikipedia.org/wiki/Авторизация
ru.wikipedia.org/wiki/Аутентификация
Многие путают эти понятия, поэтому в комментариях напишу про это.
Вы авторизацию с аутенфикацией не перепутали?
ru.wikipedia.org/wiki/Авторизация
ru.wikipedia.org/wiki/Аутентификация
Многие путают эти понятия, поэтому в комментариях напишу про это.
Вопрос: ведь если слить базу, с паролями и с солью, то нам ведь все равно нужен алгоритм хеширования пароля, чтобы производить брутфорс?
То есть если я напишу, что-то типа: md5($p. sha1(md5($p). md5($salt)). $salt), то нам необходим ещё и этот алгоритм и доступ к файлам, а просто база нам ничего не даст?
То есть если я напишу, что-то типа: md5($p. sha1(md5($p). md5($salt)). $salt), то нам необходим ещё и этот алгоритм и доступ к файлам, а просто база нам ничего не даст?
А чего мелочиться, можно еще и символы хеша местами поменять. Допустим, сначала все четные, потом все нечетные. И после пятого — восьмой вставить. «Никто ведь не допетрит, Гендальф!»(с)
То, что вы предлагаете, называется Security through obscurity — безопасность через неизвестность.
То, что вы предлагаете, называется Security through obscurity — безопасность через неизвестность.
использую, sha256, ИМХО соль уже лишнее подобрать коллизию на такой хеш в данный момент практический нереально
Соль — для защиты от радужных таблиц, а не от коллизий.
Почему так делать не стоит а еще лучше использовать две соли.
Такое чувство, что комментарии пишут одни люди (у которых уже голосов не осталось, а голосуют совсем другие.
Всё просто — ставить задержку в одну секунду перед попыткой авторизации (т. е. банальный sleep(1) в пхп). И тогда никто и никогда не забрутфорсит ни одного пароля.
Sign up to leave a comment.
Немного о хэшах и безопасном хранении паролей