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

Question

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

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

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

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

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

Answer 1

Оформить Аутентификация ответа на вызов

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

Answer 2

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

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

md5(login_name +  domain_or_appname_salt + password);

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

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

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

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

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

Счастливого взлома!

Huibert

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

1. Сервер отправляет случайную строку
2. Клиент отправляет хэш случайной строки + пароль
3. Сервер проверяет хеш.

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