Хэш пароля и солящий - действительно ли это - хороший метод?

Соль не обязательно должна быть секретной. Это действительно должно быть непредсказуемо для данного пароля.

Получение соли из пароля полностью упускает из виду.

Я задал аналогичный вопрос ранее. Консенсус был следующим:

Неважно, как вы солите, если вы:

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

Вы даже можете хранить свою соль рядом с вашими хешированными паролями и чувствовать себя чертовски уверенно.

Лично я считаю, что идентификаторы GUID (в строковом формате) отлично подходят для Salts. Для их генерации требуется строка кода, а их размер в строковом формате более чем достаточно, чтобы вычисление радужных таблиц заняло тысячелетия.

Ниже приведен код, который я использовал для добавления некоторых свойств к вершины, ребра и графы. Обратите внимание, что имя вершины и имя графа являются предопределенными свойствами (полный список см. В boost / properties.hpp), так что vertex_name_t и graph_name_t уже определены. Однако vertex_location_t , edge_length_t и graph_notes_t являются моими собственными свойствами и, следовательно, нуждаются в определении.

Мне кажется, что я просто добавил обфускацию , больше не безопасность к (как указал Чад Берч неправильно понятым ]) соленый хеш-метод.

(Отредактированный ответ, потому что я сначала неправильно прочитал статью и подумал, что он просто смешивал соль с несоленым хешем)

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

На самом деле, это может быть довольно легко для злоумышленников. злоумышленник, чтобы выяснить эти функции, во многих случаях. Если это сайт с публичной регистрацией, злоумышленник может неоднократно регистрировать учетные записи с известными паролями, а затем использовать известные хэши md5 для этих паролей, чтобы реконструировать алгоритм скремблирования паролей. Я смогу сделать это очень легко, даже глядя на результат его «Попытки 4.»

Если вы хотите действительно надежно хранить свои пароли, откажитесь от MD5 и даже SHA1 и перейдите к соленой, более медленной хэш-функции. Это отличная статья по теме: Достаточно радужных таблиц: что нужно знать о схемах безопасных паролей

Интересно, что это не просто обфускация, не больше безопасность , а фактически запутывание, меньшая безопасность , потому что «Попытка 4» хороша лишь функция CRC32, которую он использует (CRC32 передается ТОЛЬКО пароль, а не пароль + соль) - это провал.

Согласно сообщению Чада, чтобы взломать «Попытку 4», все, что нужно сделать, это CRC32 множество паролей и затем отмените закодированную им функцию, оставив вам соленый хеш md5 и соль (которую вы затем проверяете на валидность). Просто проверьте эту пару, вычислив md5 (пароль + соль) (где пароль - это пароль, который вы пытаетесь использовать), а соль - это соль, которую вы вычислили, изменив алгоритм. Если md5 соответствует первым 32 символам хеша, вы взломали пароль.

«Попытка 4»

I can't view the link in the original question (the website just returns a 404 not found error), but the method described in the question is not really using a salted hash.

In essence, this method is just using a non-standard hash: given a specific password, there is one unique value that will be stored in the database. This is all that is needed to make a rainbow tables attack work: I can precompute the hash value for a dictionary of likely passwords and look for any matches. Now, I will have to precompute rainbow tables specifically for this non-standard hash function.

In a proper implementation of salted hashes, when the passord is created, a random salt is combined with the password and hashed. Then random salt used and the hash are stored. Even if I know the password, I cannot predict what the hash will be since there will be a different hash for each of the many possible salt values. Now an attacker needs to precompute a rainbow table for each possible salt value: this takes a much larger effort.