2012-02-03 4 views
1

Я читал о том, как реализовать безопасность на веб-сайте с помощью хэширования, и я не создаю ничего ужасно чувствительного, как банк или хранящего кредитные карты. Однако мне хотелось бы узнать лучшие практики. Мой сайт имеет сертификат TLS с AES 256Хеширование и меры безопасности в PHP

Основные вопросы:

1.) Отправка хэш пароля хэшированного снова через сессии, кажется, единственный способ, которым я могу думать, чтобы держать сессию достаточно безопасным. На мой взгляд, меня не волнует, нашел ли пользователь эту ценность, но мне было бы интересно, нашел ли пользователь какой-то способ увидеть базу данных и точно знал, что такое мой алгоритм шифрования.

2.) Должен ли я просто полностью вынуть свой алгоритм до хэширования пароля или использовать разные методы хэширования?

Можно ли использовать sha512 до или после bcrypt, поскольку оба эти звука являются достаточными для столкновений и грубой силы?

+0

A (действительно) хороший способ генерации хэшей это умножить его на какой-то алгоритм времени, например «60x60x24» или что-то в этом роде. Лично я использую некоторые десятичные числа, такие как «1.02401 x секунд x минут x часов». Все это в верхней части текущей системы у вас на месте. Вы также можете использовать закрытый ключ как свое семя, которое вы должны защищать своей жизнью или, по крайней мере, менять его один раз в неделю. – ionFish

+2

Что вы имеете в виду, умножив его? –

+0

Вы имеете в виду включение времени в исходное хеширование? если да, как бы вы проверили его против db? –

ответ

1

Лично я просто пароли SHA512 для хранения и сравнения при входе в систему, а для отслеживания сеанса я храню ключ hash('sha512', $username.$salt.$password);, этот ключ хранится в сеансе и сравнивается с ключом пользователя в базе данных для аутентификации их сеанса.

Я еще не сталкивался с какими-либо проблемами безопасности с этим, не удалось подделать ключ, если вы не знаете имя пользователя пользователя, пароль и их соль пользователя (которые, очевидно, не должны храниться в базе данных) поэтому он должен быть безопасным, пока кто-то не получает доступ к вашей базе данных и вашему коду (в этом случае у вас есть больше проблем, чем защита паролей пользователей;))

+0

да, это неплохая идея. все, что я делаю, создавая свой собственный алгоритм, - это создать уникальную соль, но кто скажет, что у нее нет никаких столкновений? Я надеялся, что с тех пор все будет конкатенировано. На мой взгляд, если бы у него были столкновения, это было бы почти ничтожно полезно. –

+1

То, что я обычно делаю для соли, хранит временную метку, когда пользователь входит в систему, затем объединяет это с твердой кодированной солью, хеширует соль с именем пользователя и паролем, а затем сохраняет ее в сеансе. Таким образом, соль уникальна для каждого входа в систему, поэтому, даже если кому-то злоумышленнику удается получить ключ от ключа, он действителен только до следующего входа пользователя в систему (потому что, когда они войдут в систему, он будет создавать новую временную метку, новый уникальный сеансовый ключ) – wyqydsyq