Как бы вы внедрили систему безопасных статических учетных данных для входа в Java?

Question

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

«Старый» способ заключался в том, чтобы сгенерировать (неверный) пароль, дать его партнеру с идентификатором, а затем они отправили бы этот идентификатор и копию этого пароля в кодировке Base 64 вместе со всем своим XML запросы через https. Затем мы декодируем их и проверяем.

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

В основном это сводится к двум вещам: мне нужна более безопасная система генерации паролей Java и для обеспечения их безопасной передачи.

Я нашел несколько созданных вручную генераторов паролей, но ничего, что действительно выделялось как стандартный способ сделать это (возможно, по уважительной причине). Также может быть более безопасный способ их передачи, чем простая кодировка Base 64 через https.

Что бы вы сделали для генератора паролей и считаете ли вы, что способ передачи на месте достаточно безопасен для него?

Редактировать: XML приходит в сообщении SOAP, а учетные данные находятся в заголовке, а не в самом XML. Кроме того, поскольку пароли являются разовой операцией для каждого партнера, когда мы их настраиваем, мы не слишком беспокоимся об эффективности генератора.

Answer 1

Генерация пароля

Что касается кодирования пароля для передачи, единственной кодировкой, которая действительно добавит безопасность, является шифрование. Использование Base-64 или шестнадцатеричного не для безопасности, а просто для возможности включить его в текстовый формат, такой как XML.

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

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

Для Base-64 используйте что-то вроде этого:

  SecureRandom rnd = new SecureRandom();
  /* Byte array length is multiple of LCM(log2(64), 8) / 8 = 3. */
  byte[] password = new byte[18];
  rnd.nextBytes(password);
  String encoded = Base64.encode(password);

Следующее не требует от вас кодера Base-64. Результирующая кодировка не такая компактная (26 символов вместо 24), и пароль не имеет такой большой энтропии. (Но 130 бит - это уже много, сравнимо с паролем, по крайней мере, из 30 символов, выбранных человеком.)

SecureRandom rnd = new SecureRandom();
/* Bit length is multiple of log2(32) = 5. */
String encoded = new BigInteger(130, rnd).toString(32); 

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

Лучший подход

Встраивание пароля в сам XML кажется ошибкой.

Прежде всего, похоже, что вы захотите аутентифицировать отправителя перед обработкой любых документов, которые вам отправляют. Предположим, я ненавижу твои внутренности и начинаю отправлять тебе гигантские XML-файлы для выполнения атаки типа «отказ в обслуживании». Вы хотите проанализировать XML только для того, чтобы узнать, что я не являюсь законным партнером? Разве не было бы лучше, если бы сервлет просто отклонял запросы от неаутентифицированных пользователей сразу?

Во-вторых, пароли ваших законных партнеров были защищены во время передачи по протоколу HTTPS, но теперь они, вероятно, где-то хранятся в открытом виде в вашей системе. Это плохая безопасность.

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

Базовая аутентификация HTTP проста, широко поддерживается и будет намного проще для вас и ваших партнеров, чем клиентские сертификаты SSL.

Защита содержимого документа

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

Answer 2

Не могли бы вы использовать SSL-ключи для аутентификации?

Answer 3

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

Вы должны создавать и подписывать индивидуальные сертификаты для каждого клиента. В рукопожатии SSL вы запрашиваете сертификат клиента и проверяете его. В случае сбоя соединение завершается кодом состояния 401.

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

Поскольку все это происходит во время рукопожатия до связи, невозможно залить ваш сервер данными.

Answer 4

Мне непонятно, почему передача паролей по SSL - через HTTPS - считается вашей командой по аудиту "небезопасной". Поэтому, когда вы спрашиваете о двух вещах, кажется, что второе - обеспечение безопасной передачи паролей - уже отлично обрабатывается.

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