Случайный проход salt + hashed или случайный проход salt + crypt ()?

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

$staticsalt = '$%*#)$*)^A#$#543667ggfdf\#$%x';  
$random = md5(uniqid(mt_rand(), true));
$salt = hash('sha512',$random.$_POST['password'].microtime().$staticsalt);

либо (где наличие $ salt в базе данных не обязательно ...)

$password = crypt($_POST['password'], '$2a$12$'.$salt);

или (где мне также понадобится $ salt в базе данных ...)

$password = hash('sha512',$salt.$_POST['password']);

php security bcrypt hash salt
person wark91    schedule 14.08.2011    source источник
comment
Планируете ли вы сохранить добавляемый microtime(), чтобы вы могли добавить его обратно при проверке пароля?   -  person Jared Farrish    schedule 14.08.2011
comment
нет, мне не нужно, в первом случае сгенерированный $ password уже содержит копию соли (т.е. для проверки вам нужно всего лишь $ password = crypt ($ _ POST ['password'], $ password);), во втором в случае, если $ salt хранится в базе данных для каждого пользователя.   -  person wark91    schedule 14.08.2011
comment
Судя по тому, что это демонстрирует, если вы не сохраните сгенерированное значение microtime(), вы никогда не сможете проверить сгенерированный хэш, включая его. У вас должна быть возможность восстановить весь ввод.   -  person Jared Farrish    schedule 14.08.2011
comment
@Jared Он генерирует соль, используя microtime в качестве рандомизатора. Я тоже сначала упустил это из виду ...   -  person deceze♦    schedule 14.08.2011
comment
Вы можете использовать mcrypt_create_iv для генерации случайной соли. Он использует данные из /dev/random или /dev/urandom.   -  person Mike    schedule 14.08.2011

Ответы (3)


arrow_upward
3
arrow_downward

  1. SHA512 - довольно быстрый алгоритм, который обычно является нежелательным атрибутом для алгоритмов хеширования паролей.
  2. Использование предсказуемого значения, такого как microtime, в качестве случайного начального числа для соли может открыть вас для некоторых сложных атак, которые предотвратит более случайное значение.

Я рекомендую phpass, который является хорошей существующей реализацией системы хеширования паролей.
http://www.openwall.com/phpass/

person deceze♦    schedule 14.08.2011
comment
Когда крипта не используется, соль, очевидно, сохраняется в базе данных вместе с паролем $. - person wark91; 14.08.2011
comment
@wark Да, извини, я совершенно неверно истолковал то, что ты делаешь с твоей солью. Я удалил эти точки. - person deceze♦; 14.08.2011
comment
@ wark91 - Также есть возможность использовать дату и время, созданные пользователем, если вы их сохраните. Тогда вам не нужно будет хранить соль. - person Jared Farrish; 14.08.2011
comment
@Jared Тогда дата / время - это в основном соль, причем с очень низкой энтропией. - person deceze♦; 14.08.2011
comment
Я говорю о генерации соли таким же образом, просто вставляя созданную временную метку вместо microtime(). Я просто не знаю, хочу ли я хранить соль рядом с паролем в базе данных. Но, честно говоря, я не знаю, какой из них был бы менее безопасным. - person Jared Farrish; 14.08.2011
comment
@Jared Итак, вы сохраняете значение в своей базе данных (отметку времени), которое вы вводите с помощью простого алгоритма, а затем используете в качестве соли. Сравните это с хранением значения в вашей базе данных (соли), которое вы можете или не можете пропустить через алгоритм, а затем использовать в качестве соли. На самом деле это то же самое, поэтому временная метка, по сути, стала солью. Кроме того, соли не секрет. Они должны повышать вычислительную сложность, чтобы не быть дополнительным секретом. - person deceze♦; 14.08.2011
comment
@Jared Правильное использование солей может предотвратить ряд атак, в том числе: Возможность опробовать пароли-кандидаты против нескольких хэшей по цене одного; Использование предварительно хешированных списков (или более умных радужных таблиц) возможных паролей; Возможность определять, имеют ли два пользователя (или две учетные записи одного пользователя) одинаковые или разные пароли, без необходимости угадывать один из паролей. Соли обычно хранятся вместе с хешами. Они не секрет. openwall.com/articles/PHP-Users-Passwords - person deceze♦; 14.08.2011
comment
Может какой-нибудь $ random = md5 (uniqid (mt_rand (0x19A100, 0x39AA3FF), true)); или $ random = md5 (uniqid (mt_rand (), true)); добавили в $ соль? И tnx я посмотрю ссылку phpass. - person wark91; 14.08.2011
comment
@wark Также см. stackoverflow.com/q/7047741/476, на который пока нет определенного ответа. .. - person deceze♦; 14.08.2011
comment
@deceze - я вообще этого не делаю. Но я понимаю, что, наверное, не стоит. ;) - person Jared Farrish; 14.08.2011

arrow_upward
0
arrow_downward

Не взбивай так соль.

Хеширование Blowfish crypt принимает 22-символьную строку в кодировке base64 (с использованием символов [./0-9A-Za-z]) в качестве соли, которая составляет 128 бит энтропии.

Хеш SHA-512, который вы используете для создания своей соли, имеет 512 бит энтропии. Но вы выбрасываете более 80% этого, поскольку crypt теперь будет использовать только 22 строчных шестнадцатеричных символа. Это оставляет вам только около 85 бит энтропии, несмотря на всю причудливую генерацию случайности, которую вы делаете.

И если вам достаточно 85 бит, вы можете просто сделать что-то вроде этого:

$salt = str_replace("+", ".", base64_encode(md5(uniqid(mt_rand(), true), true)));

Я действительно не осмеливаюсь давать вам какие-либо советы о том, как сгенерировать соль, которая использует полные 128 бит, поскольку я не эксперт по криптографии.

person mercator    schedule 14.08.2011
comment
Изначально я использовал $ password = hash ('sha512', $ salt. $ _ POST ['пароль']); что для меня звучит нормально в сочетании с некоторой задержкой + ограничением последующих попыток, попыток в день и т.д. быть лучшим способом пойти. - person wark91; 14.08.2011

arrow_upward
-2
arrow_downward

На самом деле нет смысла объявлять такую ​​большую безопасность. Вы должны знать, для чего создана ваша система. Если это просто поболтать, то с md5 все будет в порядке. Если это банковская система, тогда у вас должна быть какая-то настоящая система аутентификации, я имею в виду карту с солями или генератор кода.

РЕДАКТИРОВАТЬ: Я не думаю, что есть одна хорошая политика безопасности. «Верхний ответ - отличный», - подумал он.

person Ernestas Stankevičius    schedule 14.08.2011
comment
Безопасность идет в обоих направлениях. Проблема в том, что многие пользователи используют один и тот же пароль во всех сетях. Если база данных вашей чат-системы попадает в чужие руки и пароли могут быть реконструированы, значит, вы поставили под угрозу безопасность своих пользователей в других веб-службах с помощью своего md5, для меня этого достаточно. Да, проблема заключается в том, что пользователи повторно используют одни и те же пароли, но это реальность, и это будет плохо для вас. - person deceze♦; 14.08.2011
comment
Следует различать чрезмерно спроектированную / плохо спроектированную систему и систему, реализующую надлежащие методы безопасности. Таким образом, двухфакторный вход (со случайными ключевыми ключами или чем-то еще) для настройки чата, вероятно, не понадобится, но следует сохранять пароли с должной осторожностью и использовать надежные и современные методы. Назначение новичков ответственными за систему входа в систему может привести больше к машине Руба Голдберга, что бесполезно. Но это не обязательно. - person Jared Farrish; 14.08.2011
comment
Согласен. Но md5 и некоторые планки - это неплохо, пока вы не знаете, как защитить весь свой сайт. - person Ernestas Stankevičius; 14.08.2011