Соль и перемешивание, почему бы не использовать имя пользователя?

Question

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

Возьми этот сайт: http://www.15seconds.com/issue/000217.htm

Это немного показывает, что они хранят значение соли в таблице, я понимаю принципы и математику , используя соль, но мне интересно вот это:

• Почему они не просто использовали имя пользователя в качестве солт-значения вместо его генерации?

Answer 1

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

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

Имя пользователя не соответственно уникально:

• Имя пользователя не меняется, когда пользователь меняет свой пароль. Злоумышленник, увидев старый хешированный пароль и новый хешированный пароль, может атаковать как по стоимости, вдвое превышающей стоимость атаки одного.
• В данный момент имена пользователей уникальны для всей системы, а не для всего мира. Существует множество «bob» (в системе Unix рассмотрим «root»). Использование имени пользователя может позволить атакующему атаковать несколько систем одновременно.

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

Answer 2

Поскольку имена пользователей имеют меньшую энтропию, чем случайная соль, они распространяют ваши хеши меньше, чем обычная соль.

Не то чтобы пример на этой странице был очень впечатляющим в любом случае. Я всегда просто генерирую GUID и использую его.

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

Answer 3

Как насчет:

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

Казалось бы, преимущество

1. в том, что нет необходимости хранить соль, так как ее можно рассчитать динамически,

2. при сохранении хорошей энтропии (основанной на хэшах вместо открытого текста), а

3. дает соль, равную криптографическому хешу, например, 128-512 бит?

Одна проблема была бы, если бы система позволила двум пользователям иметь имя пользователя и пароль (хотя это не произойдет с адресом электронной почты), но есть ли другие проблемы с этой схемой?