Плохо ли использовать bcrypt (md5 (pwd) + соль)?

Я пытаюсь поделиться логинами между моим приложением и форумом IPB.

Я видел, что Invision предоставляет модуль для обмена учетными данными: Подключение IPS

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

Дело в том, что для методов register или login IPB отправляет md5 хэш пароля. Я никак не могу хранить md5 в своей БД, поэтому я подумал использовать bcrypt в хэше md5, делая что-то вроде

$storedPassword = bcrypt(md5(pwd) + salt);

Что вы думаете об этой альтернативе, является ли хорошей практикой хеширование с помощью bcrypt поверх хэша md5?


php passwords md5 bcrypt password-protection
person darkheir    schedule 06.05.2013    source источник
comment
Плохая идея, многократное хеширование увеличивает вероятность столкновения   -  person Daniel Mensing    schedule 06.05.2013
comment
Я слышал об этом, но сильно ли это увеличивает вероятность столкновения?   -  person darkheir    schedule 06.05.2013
comment
Два пользователя также могут иметь один и тот же пароль перед его хешированием, поэтому это не имеет значения для коллизии. И вероятность того, что два пользователя с разными паролями и одинаковым хэшем md5 близка к нулю   -  person Hugo Delsing    schedule 06.05.2013
comment
@DanielMensing Просто искренне любопытно, что заставляет тебя так думать?   -  person likeitlikeit    schedule 04.06.2013

Ответы (2)


arrow_upward
1
arrow_downward

Хотя вполне нормально использовать $storedPassword = bcrypt(md5(pwd) + salt); в вашем приложении, с точки зрения безопасности это мало что дает. Также нет необходимости добавлять свою собственную соль в шифрование. bcrypt позаботится об этом внутри, и вам не нужно где-либо сохранять соль.

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

Но затем снова. Закрыть одну дверь все же лучше, чем оставить все открытыми.

person Hugo Delsing    schedule 06.05.2013
comment
Да, но другой сайт не сохранит его, он только отправит пароль (используя md5) при регистрации или когда пользователь попытается войти в систему. Так что для меня слабым звеном будет прослушивание соединения между двумя серверами во время отправки учетных данных. - person darkheir; 06.05.2013
comment
Тогда ваш подход в порядке, если вы бросите соль. Для всего, что вам нужно, пользователь сам ввел 32 символа в качестве своего пароля. - person Hugo Delsing; 06.05.2013
comment
Почему я должен бросать соль? Я думаю, что именно это делает хеш уникальным, не так ли? - person darkheir; 06.05.2013
comment
Если вы добавляете соль, вам также необходимо хранить соль отдельно в базе данных, чтобы иметь возможность проверить действующий пароль. Однако bCrypt имеет встроенную соль. Нет необходимости добавлять его. См. stackoverflow.com/questions/ 6832445/ или en.wikipedia.org/wiki/Bcrypt - person Hugo Delsing; 06.05.2013

arrow_upward
1
arrow_downward

Это снижает безопасность.

Хэш MD5 обычно сокращает пароль. Это означает, что злоумышленнику нужно только перебрать пространство MD5. Даже если вы считаете пространство MD5 большим, отобразить в него словарь слов тривиально. Это просто не добавляет пользы, но потенциально уменьшает пространство.

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

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

Немного странно, что ваш источник отправляет только хеши MD5. Обычно я рекомендую отправлять пароль (открытым текстом) через зашифрованное соединение:

  • Если соединение зашифровано, безопасно отправлять его в виде открытого текста.
  • Если он не зашифрован, не имеет значения, хешируете ли вы пароль первым, злоумышленник все равно может прочитать его из сети.
person mafu    schedule 18.02.2016