Клиент / сервер NIO надежно аутентифицирует учетные данные - PullRequest
Новая
       34

Клиент / сервер NIO надежно аутентифицирует учетные данные

0 голосов
/ 06 февраля 2019

Я использую Java NIO, защищенный SSL для соединения клиента и сервера.Для подключения к серверу пользователю предлагается ввести хост, порт, имя пользователя и пароль.Пока я могу соединить клиент и сервер (они успешно завершили рукопожатие SSL) и теоретически начать отправку данных туда-обратно.Я еще не написал механизм для проверки учетных данных (имя пользователя, пароль).

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

Вопрос 1: Когда следует проверять учетные данные?Я предполагаю, что это должно произойти после рукопожатия SSL.

Вопрос 2: Как безопасно упаковать учетные данные перед их сериализацией и отправкой на сервер?Я предполагаю, что должен хешировать пароль.Должен ли я тоже хэшировать имя пользователя?

Достаточно ли чего-нибудь такого, как это? 

public class LoginCredentials implements Serializable {

    private static final long serialVersionUID = 1026410425432118798L;

    private final String username;
    private final byte[] passwordHash;

    public LoginCredentials(String username, byte[] passwordHash) {
        this.username = username;
        this.passwordHash = passwordHash;
    }

    public final String getUsername() {
        return username;
    }

    public final byte[] getPasswordHash() {
        return passwordHash;
    }

}

Вопрос 3: Аутентификация учетных данных должна выполняться один раз за сеанс, правильно?Я прочитал несколько постов, которые, казалось, указывали, что учетные данные должны проверяться для каждого запроса.

Вопрос 4: Какой алгоритм хеширования мне следует использовать?SHA-512, кажется, очень популярен.

1 Ответ

0 голосов
/ 06 февраля 2019
  1. конечно, что после рукопожатия ssl, когда соединение ssl установлено, это делает его более безопасным
  2. Не многие приложения действительно так делают, большинство из них просто посылает пароль через ssl, не хешируя егосовсем.Да, вы можете сгенерировать хеш, но хеш должен быть сгенерирован для каждого входа в систему, поэтому он не всегда будет одинаковым, это требует некоторого кода на стороне клиента для решения некоторой проблемы, которая включает в себя правильный пароль и некоторую случайную вещь, отправленную сервероминаче это не сильно отличается от обычной аутентификации по паролю.Но существует множество механизмов аутентификации - пароли, хеши, токены, ssl-сертификаты и другие.
  3. вам нужно проверить, есть ли у аутентифицированного пользователя права доступа к ресурсу, к которому он пытается получить доступ - это для каждогозапрос, не входить в систему пользователя для каждого запроса, если у вас есть сеанс.Если вам нужно управлять правами доступа пользователей, чтобы предоставлять или отзывать доступ во время одного сеанса, вам нужно читать права доступа пользователей для каждого запроса, если вам не нужна такая детализация, тогда можно прочитать их один раз для всего сеанса.Иногда есть бессессионные услуги, например.немного REST, тогда обычно вам нужно отправлять учетные данные при каждом вызове.
  4. Вы можете использовать любой алгоритм хеширования, который не так просто расшифровать.
...