Является ли хеш (site || пароль || salt) на самом деле плохой идеей?

Question

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

соль || хэш (сайт || пароль || соль)

где site - это уникальный идентификатор моего сайта, password - пароль пользователя, а salt - пользовательская случайная соль, а hash - криптографическая хеш-функция общего назначения, такая как SHA-1, и || указывает на конкатенацию.

Мне известны некоторые проблемы, которые возникают при использовании этой схемы.

• Хеш (должен быть спроектирован) быстро оценивать, и одна итерация оставит определенные слабые пароли угадываемыми.

• Одна только конкатенация может привести к "каламбурам" в общем вводе хеша.

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

Но действительно ли я должен? У меня есть немного контраргумента здесь.

• Это, вероятно, не будет самым слабым звеном в моем сервисе. У кого-то, действительно настроенного взломать, есть много других возможностей, и я должен расставить приоритеты в своем времени, чтобы обезопасить более слабых.

• Экономическая выгода уже против пользы злоумышленника, если мой сайт имеет небольшую внутреннюю ценность. Насколько практической проблемой является то, что большой кластер / ботнет может восстановить слабый пароль за день / неделю? Конечно, в этот день / неделю у него есть более ценные вещи.

• Скомпрометированные учетные записи более вероятны из-за троянов, клавиатурных шпионов, атак социальной инженерии, что у вас есть. Технология не является ограничивающим фактором в этой безопасности.

• Чем сложнее моя схема, тем сложнее может быть переход / расширение на другую платформу. Если бы я использовал bcrypt (гипотетически), мне, возможно, пришлось бы написать упаковщик bcrypt и включить его.

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

Если бы я делал что-то не так здесь, я был бы очень признателен, если бы кто-то указал на это, особенно с точки зрения практических и реальных проблем.

Благодарю.

Answer 1

См. В чем смысл соли и хэширования, если база данных доступна?

Соли предотвращают (некоторые) атаки радужных таблиц, но они не предотвращают словарные или грубые атаки.

Вместо этого используйте Scrypt или bcrypt, где Scrypt намного сильнее, но оба используют систему Proof of Work, чтобы усложнить взлом пароля. См. Шпаргалку для хранения паролей OWASP

Answer 2

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

Тогда есть старый аргумент о том, какой алгоритм хеширования является наиболее безопасным, и, конечно, bcrypt превзойдет SHA - и, в частности, MD5 - из-за его адаптивного натива и способности увеличивать продолжительность процесса хеширования, чтобы отразить атаки методом перебора.

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

Показательный пример: поставщик членства ASP.NET от Microsoft использует SHA1 и очень широко используется. Отсутствует встроенная поддержка bcrypt (хотя доступны сторонние библиотеки), что, вероятно, должно рассказать вам о том, как Microsoft рассматривает проблему.

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