Является ли отправка хешированного пароля по проводу защитной дырой?

Question

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

У них есть веб-сервис, с которым нам нужно будет интегрироваться.

Мое текущее понимание правильного управления именем пользователя / паролем заключается в том, что имя пользователя может храниться в виде открытого текста в базе данных. У каждого пользователя должна быть уникальная псевдослучайная соль, которая также может храниться в виде открытого текста. Текст их пароля должен быть соединен с солью, а затем эта объединенная строка может быть хеширована и сохранена в базе данных в поле nvarchar. Пока пароли отправляются на веб-сайт (или веб-сервис) через SSL , все должно быть просто прекрасно.

Не стесняйтесь проникнуть в мое понимание, как описано выше, если я ошибаюсь.

Во всяком случае, вернемся к предмету под рукой. WebService, запущенный этим потенциальным партнером, не принимает имя пользователя и пароль, которые я ожидал. Вместо этого он принимает два строковых поля с именами «Имя пользователя» и «Пароль». Значение «PasswordHash», которое мне было дано, действительно выглядит как хеш, а не просто как значение для поля с неверно названным паролем.

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

EDIT

Меня смущали некоторые комментарии ниже, пока я не перечитал свой пост.

В оригинале у меня была фраза: «Пока пароли отправляются на веб-сайт (или веб-сервис) через обычный текст , все должно быть просто прекрасно».

Я клянусь, поскольку думал, что я думаю о термине «SSL». По какой-то причине я набрал слово «открытый текст». Ничего себе.

Worst. Опечатка. Когда-либо.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

За исключением деталей, на этот вопрос легко ответить:

Вы можете приложить все усилия в мире, но если вы не используете SSL, ваш процесс аутентификации может быть использован ЛЕГКО .