Использование хэша пароля с SSL

Question

ОК, это может звучать странно. Пожалуйста, прочитайте внимательно, прежде чем прыгать на меня, хорошо? ; -)

Представьте себе такую ​​ситуацию:

1. У нас есть сервер и клиент.
2. Они подключаются с использованием SSL.
3. Клиент создает учетную запись на сервере с паролем.
4. Но на самом деле он передает серверу по проводам хеш (+ соль) пароля (НЕ пароля)
5. Сервер сохраняет полученный хэш пароля в БД (СНОВА хешируется с солью)
6. Во время входа в систему для аутентификации пользователь повторно отправляет хэш пароля (НЕ пароль!).

Хорошо, да, я понимаю, это звучит странно. Да, весь разговор происходит в SSL, так что вы МОЖЕТЕ просто отправить пароль открытым текстом. И да, я понимаю, что можно безопасно хранить открытый текст в хешированном виде.

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

Заметьте, я НЕ говорю "мы не храним ваш пароль в открытом тексте", но мы действительно никогда этого не узнаем; Вы никогда не даете это нам.

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

Да, я понимаю, что вы могли бы сказать, что при обычном способе сделать это "хорошо, пароль будет только в виде открытого текста в памяти в течение 5 мс, пока вы выполняете хеширование", но это больше об отрицании. то есть, мы можем сказать, что 100% мы даже не получаем ваш пароль.

Хорошо, вот вопрос:

• Кто-нибудь делал или слышал о подобных вещах раньше?

• Каковы последствия этого для безопасности?

Я изо всех сил пытаюсь увидеть обратную сторону. Например:

• Нет повторных атак (поскольку разговор зашифрован с использованием SSL, злоумышленник не может увидеть хеш)
• Не могу посмотреть в БД, потому что хеш сам по себе, хм ..., хешируется

ОК, теперь вы можете прыгнуть на меня:)

Мысли, комментарии приветствуются.

Спасибо

John

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

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

Answer 1

Рассмотрим несколько вещей:

1. Что-то на стороне клиента должно определиться с солью и хешем.
2. Независимо от того, что создает хеш в (1), злоумышленнику будет легко обнаружить
3. Эта соль и хэш должны быть последовательными. Если соль изменится, изменится и хэш, и ваш сервер не сможет вернуть его обратно в исходное состояние.
4. Эта соль + хеш по сути стала новым паролем пользователя.
5. Если их исходный пароль был длиннее хеша salt +, возможно, вы только что снизили безопасность их пароля (предполагая, что хороший пароль и игнорируя коллизии хеша).
6. Но, если у них плохой пароль, возможно, вы только что повысили качество его пароля (игнорируя коллизии хешей и 1 и 2 выше), вроде.

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

Answer 2

Мне кажется, что в этой схеме есть одно преимущество, о котором я не упомянул (может быть, я пропустил его). Можно, конечно, утверждать, что хеш + соль становится настоящим паролем. Тем не менее, с точки зрения безопасности для людей, которые повторно используют пароли, это добавляет ценность. Если я использую свой пароль «asdfasdf» на вашем сайте, и кто-то скомпрометирует ваш сервер, он не сможет извлечь мой пароль, который я использую на dubdubdub.superfinance.com.

Answer 3

Это именно то, что хэши паролей делают для веб-браузеров.

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

Answer 4

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

Answer 5

Так что на данный момент, это действительно не помогает вообще. Предположим, что ваш SSL был скомпрометирован. Они нюхают хешированный + соленый пароль. Затем они могут просто отправить это, поскольку ваш сервер принимает хешированный + соленый пароль в качестве своего пароля. Что вы делаете, это просто добавляете один слой сложности (не можете ввести пароль в поле пароля), и в этом случае они могут вручную отправить его на ваш сервер.

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

Резюме: В моем разуме нет большой пользы, хотя я могу ошибаться.

Я лично реализую хеширование + соление на стороне сервера и принудительно использую SSLv3 / TLSv1 на страницах входа в систему.