Обработка обновлений пароля в Java SSL

Question

У меня есть клиент-серверное Java-приложение, в котором связь происходит по SSL.Сейчас я создаю пары ключей вручную, но мне нужна программная система для управления ключами.

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

• Когда пользователь вводит пароль в первый раз, как мне зашифровать эту передачу?Потому что на этом этапе не будет ключей и, следовательно, SSL.

Тогда возникает проблема, когда пользователь меняет свой пароль.Идея состоит в том, что они пройдут через веб-интерфейс, чтобы изменить свой пароль на сервере.Затем в следующий раз, когда клиент подключится, его старые ключи не будут работать, и их попросят ввести новый пароль.Это подводит меня к следующему вопросу:

• Каков наилучший способ обработки изменения пароля при работе с SSL?

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

Answer 1

Хотя SSL-соединение может проверять подлинность клиента с помощью сертификата на стороне клиента, чаще всего оно используется только для проверки подлинности сервера и создания зашифрованного соединения между идентифицированным сервером (на основании сертификата, привязанного к имени домена) и анонимного клиента.

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

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

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

РЕДАКТИРОВАТЬ: Чтобы уточнить, даже если вы генерируете пары ключей PKCS, не делая это на стороне клиентаи связывание их в сертификат, это не аутентификация сертификата на стороне клиента.Это просто криптографически надежный, сгенерированный машиной эфемерный пароль .

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

Answer 2

Поскольку использование SSL для аутентификации клиента требует, чтобы ключи уже были предоставлены для совместного использования, у вас есть два варианта: либо не использовать SSL для обеспечения аутентификации клиента, либо пересмотреть условия после передачи клиентского сертификата клиенту.

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

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

Answer 3

Вы по-прежнему можете иметь SSL между клиентом и сервером.На самом деле, вы должны.

Сервер пока не сможет доверять клиенту.Клиент может доверять серверу, потому что сертификат сервера доступен клиенту.

Например, посмотрите, как реализовано большинство входов в сеть: вы еще не прошли аутентификацию, но заходите в HTTPS.Это односторонний SSL.Клиент использует временный ключ.Пароль передается по зашифрованному соединению.Это защищает от подслушивания.

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

ОБНОВЛЕНИЕ

Я вижу некоторую путаницу в потоке из-за неясной формулировки«требований».Позвольте мне записать сотрудничество между клиентом и сервером:

Сессия 1:

1. Клиент должен общаться с сервером
2. Клиент генерирует временную пару частного и открытогоключ
3. Клиент подключается к серверу через SSL и передает открытый ключ на сервер для сеанса
4. Клиент получает открытый ключ / сертификат сервера и сравнивает его с тем, который ему известен априори;выручить при несоответствии.
5. На данный момент установлено одностороннее SSL-соединение;клиент точно знает, что он общается с сервером, а сервер не знает, кто его клиент.Однако соединение зашифровано.
6. Клиент передает учетные данные (вероятно, идентификатор пользователя и пароль).
7. Сервер проверяет их и выдает их, если они не совпадают.
8. Сервер сейчасдоверяет клиенту, скажем, Джону Смиту из Небраски.
9. Клиент просит сервер сохранить текущий открытый ключ как постоянный открытый ключ клиента ИЛИ генерирует другую пару ключей и отправляет открытый ключ на сервер (я не вижу проблемыиспользовать тот же ключ, но я могу что-то пропустить).
10. Конец сеанса.

Сессия 2:

1. Клиент подключается к серверу черезSSL
2. Клиент предоставляет свой открытый ключ / сертификат
3. Сервер сравнивает его с тем, который хранится на стороне сервера
4. Сервер предоставляет свой открытый ключ / сертификат
5. Клиентсравнивает его с известным.
6. Установлено взаимное доверие, соединение зашифровано, сервер знает, что клиент - Джон Смит из Небраски.
7. Тем не менее, для безопасности, сервервсе еще может попросить Джона ввести пароль.