Вход на сайт: как отправлять учетные данные пользователя на сервер для проверки?

Question

Я работаю над проектом, в котором удаленным клиентам необходимо войти на веб-сервер. Я не ищу примеров на каком-либо конкретном языке; просто общее представление о проблемах безопасности.

Основной вопрос:
Как передавать учетные данные пользователя на веб-сервер для проверки?

Я представляю ваш типичный логин на сайте. Одно поле для имени пользователя, а другое для пароля. Вы вводите оба и нажимаете «Войти». Что будет дальше?

Я могу представить несколько сценариев:

1. Учетные данные отправляются на сервер в виде простого текста. Серверный скрипт создает хэш пароля и сравнивает его с сохраненным хешем для пользователя.
2. Учетные данные шифруются локально, а результат отправляется на сервер. Сервер расшифровывает учетные данные и продолжает, как в # 1
3. Что-то, о чем я еще не подумал? Я новичок в этом. Полегче на меня!

Вариант № 1 кажется мне слабым, поскольку учетные данные отправляются через Интернет в виде простого текста.

Я вижу вариант № 2 не намного лучше, чем вариант № 1. Если кто-то перехватывает зашифрованные учетные данные, могут ли они не просто отправить их на сервер в другой раз, но все же удается войти в систему?

Любое понимание приветствуется.

edit: боковая панель «Связанные» предлагает этот вопрос , в котором упоминается рукопожатие клиент / сервер с добавлением соли к паролю. Это правильный путь?

Answer 1

Вариант 1 является по умолчанию. Слабость открытого текста обычно преодолевается путем применения SSL во время входа в систему, чтобы пароль был как минимум зашифрован во время передачи.

Редактировать: Предлагаю вам следовать принятому ответу на этот вопрос.

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

Отредактируйте второе: Вейн вдумчиво упомянул, что вы должны подсолить свой пароль, прежде чем хешировать. Вот несколько основных советов:

1. Не имеет значения, является ли ваша соль префиксом, постфиксом или инфиксом
2. Ваша соль должна быть большой, случайной и сложной.
3. Ваша соль должна быть уникальной по соленой стоимости. Сама соль не нуждается в шифровании.

Answer 2

Почему не SSL связь? Возможность наблюдать за беседой дает мне представление о вашем приложении. Зашифруйте все сообщение, а не только учетные данные.

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

Answer 3

Самый простой ответ - получить сертификат SSL для вашего сервера. Там действительно нет причин возиться с созданием ваших собственных методов шифрования в этом конкретном приложении. Как вы заметили, если соединение не зашифровано, вы оставляете себя открытым для атак «человек посередине», независимо от того, выполняет ли клиент или сервер шифрование пароля. Зашифруйте соединение, и вам не нужно об этом беспокоиться.

Answer 4

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

Answer 5

На стороне клиента у вас есть только браузер, который может отображать HTML и отправлять формы. Кто будет шифровать вещи?

Отправьте логин и пароль в виде обычного текста (SSL, если у вас есть проблемы). На стороне сервера вы можете делать с ней все, что захотите (желательно, чтобы хеш-пароль и солт-пароль были сохранены в базе данных).