Безопасное хранение и передача пароля

Question

Я разрабатываю новый пользовательский магазин для своей организации и сейчас занимаюсь хранением паролей. Концепции посола, HMAC и т. Д. Меня устраивают - и я хочу хранить пароли пользователей как соленые, так и хэшированные, хэшированные в HMAC или соленые и хэшированные в HMAC - не уверен, какой будет лучший путь, - но теоретически он победил Это не имеет значения, так как оно может меняться со временем, если потребуется.

Я хочу иметь службу XML & JSON, которая может выступать в качестве службы маркеров безопасности для клиентских приложений.

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

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

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

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

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

Очень ценю любой вклад.

Answer 1

HTTPS - лучшее решение для этой проблемы.

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

Самая большая проблема заключается в передаче секретов между клиентом и сервером. Для правильной реализации вам необходимо использовать обмен ключами Диффи-Хеллмана. К счастью, один уже написан на javascript:
http://enanocms.org/News:Article/2008/02/20/Diffie_Hellman_key_exchange_implemented

Другая проблема заключается в том, что я не вижу, как клиент может определить, что он общается с правильным сервером. SSL использует асимметричную криптографию, поддерживаемую PKI, которую вы не сможете реализовать в JavaScript.

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

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

Answer 2

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

По моему мнению, я бы использовал функцию получения ключа на основе пароля (PBKDF) с большим количеством итераций и солью.

http://www.bing.com/search?q=pbkdf2

Вот пример кода на C #, но он доступен в большинстве популярных сегодня фреймворков. http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx