Лучшая практика для хранения пароля в базе данных?

Я создаю новую систему входа в систему для своего одностраничного приложения. Эта система потребует от администратора создания учетной записи для пользователей. Как только они настроят учетную запись для пользователя, я отправлю им электронное письмо, в котором они должны ввести свою информацию, такую ​​​​как контрольный вопрос и пароль. Поэтому я провел небольшое исследование и изучил нашу существующую систему. Есть функция hash, которая используется вместе с salt. Я прочитал несколько статей, и было много споров об уязвимости хеша. Также я вижу, что в этом случае хранится хешированный пароль, а также соль. Они находятся в отдельных столбцах. Является ли это хорошей практикой для хранения соли в БД? Также есть ли лучший способ хранить пароль в базе данных? Вот пример логики, которую я нашел:

<cfset password = trim(FORM.password)>
<cfset salt = randomSalt()> //This is function that generates random salt.
<cfset totPW = password & salt>
<cfset hashedPW = hash(totPW,"SHA-256")>

В настоящее время я использую Cold Fusion 2016. Я не уверен, есть ли лучший способ зашифровать пароль в CF. Если кто-то может предоставить какой-нибудь полезный ресурс или пример, пожалуйста, дайте мне знать. Спасибо.


passwords coldfusion-2016 hash coldfusion salt
person espresso_coffee    schedule 16.02.2018    source источник
comment
См. Памятку по хранению паролей OWASP   -  person Miguel-F    schedule 17.02.2018
comment
При сохранении средства проверки пароля простого использования хеш-функции недостаточно, а простое добавление соли мало что дает для повышения безопасности. Вместо этого повторите HMAC со случайной солью в течение примерно 100 мс и сохраните соль с хэшем. Еще лучше использовать такие функции, как PBKDF2, Rfc2898DeriveBytes, Argon2, password_hash, Bcrypt или аналогичные функции. Суть в том, чтобы заставить злоумышленника потратить значительное время на поиск паролей методом грубой силы.   -  person zaph    schedule 17.02.2018
comment
Этот вопрос больше похож на вопрос информационной безопасности. Многое из этого описано в: security.stackexchange .com/questions/211/ . Если у вас есть вопросы о том, как реализовать это в ColdFusion, этот вопрос, вероятно, не будет закрыт.   -  person James A Mohler    schedule 17.02.2018

Ответы (1)


arrow_upward
4
arrow_downward

Вообще говоря, хеширование по-прежнему хорошо в наши дни. Здесь важно, какой алгоритм хеширования вы используете (и сколько итераций). В случае утечки базы данных вы хотите максимально затруднить сопоставление входных данных (атака на основе общего пароля/словаря). Соление действительно немного помогает, так же как и наличие соли с нерегулярным шаблоном или скрытого количества итераций на основе имени пользователя и т. Д. Наличие различных стратегий хеширования помогает, если злоумышленник не знает, как реализовано ваше хеширование. (Одно дело — доступ к серверу базы данных, другое — доступ к вашему исходному коду.) Речь идет о приложении усилий злоумышленнику.

Теперь об алгоритмах хеширования: SHA-2 легче атаковать, чем, например, bcrypt, из-за того, что на него могут нацеливаться графические процессоры. Количество итераций хэша потребует от злоумышленника больше времени для каждого пароля. bcrypt не поддерживается hash(), но по крайней мере SHA-512 поддерживается. hash() поддерживает итерации (см. документы). Эмпирическое правило заключается в том, что счетчик итераций обрабатывается на вашем серверном оборудовании не менее секунды.

На заметку: не обрезайте ввод пароля, люди могут захотеть использовать начальные/конечные пробелы.

person Alex    schedule 16.02.2018
comment
1. Как правило, ~100 мс является разумным значением использования ЦП, намного выше этого, и это становится раздражающим, и большой выигрыш от ~ 1 мкс только для криптографического хэша, и это большой выигрыш: от 1 до 100 000, дополнительные 10x действительно обычно плохой компромисс против пользовательского опыта. 2. Секретный метод хеширования и/или количество итераций или соль не обеспечивают безопасность, безопасность обеспечивают время итерации и случайная соль. - person zaph; 17.02.2018
comment
Как упоминалось в ответе, обрезка предоставленного пользователем пароля - плохая идея, но удаление символов пробела приемлемо в соответствии с NIST и, вероятно, хорошая идея, поскольку они невидимы. Плюсом также является возможность отображать пароль по мере его ввода и разрешать использование символов Юникода. - person zaph; 17.02.2018
comment
@zaph Даже несколько мкс, умноженные на огромное количество попыток на пароль, умноженное на количество записей, являются выигрышем. Одна секунда — это не проблема UX. Если пользователь забыл свой пароль и перебирает его 10 вариантов, у него есть эти лишние 10 секунд, не волнуйтесь. Нерегулярные соли невероятно хорошо помогают замедлить атаки (например, с помощью hashcat). И речь идет не о безопасности, а о хранении паролей и том, чтобы взломщику было мучительно их разгадывать. В конце концов, каждый хэш можно обратить, так что это вопрос времени/усилий. - person Alex; 17.02.2018