2012-10-23 3 views
1

Извините, если это глупый вопрос, я просто хочу знать: в чем суть соли в bcrypt? Я имею в виду, если у вас есть следующий код для создания хэш от пароля:Точка с солью в bcrypt

function generateSalt() { 
$salt = '$2a$13$'; 
$salt = $salt . '1111111111111111111111'; 
return $salt; 
} 

function generateHash($salt, $password) { 
$hash = crypt($password, $salt); 

return $hash; 
} 

$salt = generateSalt(); 

$providedPassword = generateHash($salt, rand(3,29)); 

echo $providedPassword; 

Вышеуказанные выходы, например:.

$ 2a $ 13 $ 111111111111111111111uDdpsIcwCVOwEyNueskskXkniY5206fW

$ 2a $ 13 $ 111111111111111111111udcvrNt9quPukFRl8/jXRzDGfE9lw0W

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

ответ

3

Идея, стоящая за salt, заключается в том, что даже если два входа одинаковы, хеш не будет идентичным, если каждый раз используется другая соль.

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

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

+0

Я показал код в своем вопросе, и я получил код с этого сайта http://www.nathandavison.com/posts/view/13/php-bcrypt-hash-a-password-with-a-logical-salt Возможно, я внедряю это неправильно, потому что соль заканчивается только в начале хэша до «$ 2a $ 13 $» – DannyCruzeira

+0

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

+0

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

0

Солить хэш - это средство для усиления хэша от атак, которые могут привести к тому, что хеш будет изменен на свое первоначальное значение, тогда как хэш будет отправлен между хостами в Интернете. в этом сценарии подслушиватель мог бы захватить хэш, но без знания ценности соли никогда не сможет отменить хэш независимо от техники.

+0

Но соль только что включена отдельно от фактического хэша в начале, как я показал, или пароль хэшируется вместе с солью? – DannyCruzeira

+1

@FrankThomas: Это не совсем правильно. Соль на самом деле не существует, чтобы усилить хэш, это сделать невозможным предварительные атаки. В принципе, он предотвращает атаки «радужного стола» и защищает пользователей, которые используют один и тот же пароль. Он защищает пароли, которые хранятся. SSL обычно используется для защиты информации на проводе. –

Смежные вопросы