Как можно надежно защитить пароль аутентификации сервера на стороне клиента?

Question

В моем приложении клиент подключается к серверу через SSLSocket. Для аутентификации сервер отправляет соль, а клиент отправляет пароль, зашифрованный с помощью данной соли.

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

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

Что было бы безопасным и удобным для пользователя решением?

Answer 1

Если я правильно понимаю, ваш текущий протокол выглядит следующим образом:

server -> client: random nonce
server <- client: encrypted password
server <- client: encrypted password

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

server <- client: encrypted password
server -> client: 256-bit access token
server <- client: 256-bit access token
server <- client: 256-bit access token

Это управление сеансом. NIST предоставляет рекомендации по управлению сеансами: https://pages.nist.gov/800-63-3/sp800-63b.html#sec7

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

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

1. Android: KeyStore.
2. iOS: цепочка для ключей.
3. Linux / Windows / MacOS: здесь сложно - просто держите токен в памяти как можно дольше, не помещайте в файл, заставляйте приложение работать как можно дольше.

В любом случае, токен доступа должен истечь через некоторое время, и даже если он по какой-то причине просочится, клиент получит новый через некоторое время. См. Часть о повторной аутентификации в NIST .