Простой, среднезащищенный протокол входа в систему?

Question

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

Ребята, можете ли вы указать мне на какой-нибудь очень простой протокол входа в систему (я не разбираюсь в криптографических системах)??Я разрабатываю как серверную, так и клиентскую часть приложения, и у меня есть собственная система обмена сообщениями, поэтому у меня достаточно свободы.

Только 2 специальные характеристики для ваших предложений.

1. Простой:сеть, в которой будет работать это приложение, не является особенно небезопасной, и я только хочу избежать отправки пароля в виде обычного текста

2. По возможности не слишком долгий обмен сообщениями.Чем короче, тем лучше.

Answer 1

Проверить Аутентификация ответа на запрос

• Сервер включает случайную строку запроса в форму входа.
• Когда вы входите в систему, javascript хеширует пароль, а затем хеширует его с помощью запроса.
• Затем сервер выполняет ту же проверку (ваша БД должна хранить хешированные пароли, но этот метод не позволяет вам эффективно использовать соль для этого хеша, поскольку вам придется транслировать это)

Answer 2

Трехпроходной протокол было бы удобно.По сути, это сводится к:

• Человек А шифрует свой пароль и отправляет его лицу Б.
• Человек Б шифрует зашифрованный пароль и отправляет его обратно человеку А.
• Человек А расшифровывает его и отправляет обратно.
• Человек Б расшифровывает его и получает пароль в открытом виде.

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

Answer 3

Хранение хэша пароля в базе данных не является оптимально безопасным на случай, если содержимое базы данных попадет в несанкционированные руки.Невозможно напрямую перевернуть хэш, но в Интернете есть словари (нравиться здесь) для изменения хешированных слов (паролей).

В БД вы должны хранить что-то вроде:

md5(login_name +  domain_or_appname_salt + password);

Соль в середине предотвращает многие формы словарных атак.

На стороне клиента (в браузере) у вас будет форма входа с именем пользователя и паролем.Небольшой фрагмент javascript будет хэшировать имя пользователя + app_salt_ и пароль, поэтому на сервер отправляются только имя пользователя и сгенерированный хэш.

Теперь пароль в виде открытого текста никогда не будет отправляться на сервер в виде обычного текста.Поэтому вам не следует полагаться здесь на HTTPS.

Тот же метод можно использовать и в форме обновления пароля.Таким образом, сервер никогда не знает пароль в виде открытого текста.

Надеюсь, вы получили вдохновение от этого и других ответов.

Удачного взлома!

Хьюберт

Answer 4

Если ваш протокол работает по протоколу TCP, вы можете просто написать аутентификацию в открытом виде, а затем обернуть соединение с помощью SSL. Например, если вы используете порт 1234 для своего протокола, вы можете закрыть этот порт на сервере и позволить клиентам туннелировать его по SSH. Это можно сделать программно, и это очень распространенное решение.

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

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

<Ол>

Сервер отправляет случайную строку

Клиент отправляет хэш случайной строки + пароль

Сервер проверяет хеш.

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

Answer 5

SASL - это безопасный механизм аутентификации. Поддержка SASL предоставляется в стандартных библиотеках Java для выпусков 1.5+.