Java - зашифровать / расшифровать имя пользователя и пароль из файла конфигурации - PullRequest
14 голосов
/ 04 декабря 2008

Мы заняты разработкой веб-службы Java для клиента. Есть два возможных варианта:

  • Сохраните зашифрованное имя пользователя / пароль на клиенте веб-службы. Читайте из конфига. файл на стороне клиента, расшифровать и отправить.

  • Сохраните зашифрованное имя пользователя / пароль на веб-сервере. Читайте из конфига. файл на веб-сервере, расшифровать и использовать в веб-службе.

Имя пользователя / пароль используется веб-службой для доступа к стороннему приложению.

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

Итак, нам нужно что-то быстрое и легкое в Java.

Есть рекомендации?

Сервер Tomkat 5.5. Веб-сервис Axis2.

  • Какой пакет шифрования / дешифрования мы должны использовать?
  • А как насчет хранилища ключей?
  • Какой механизм конфигурации мы должны использовать?
  • Будет ли это легко развернуть?

Ответы [ 2 ]

25 голосов
/ 04 декабря 2008

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

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

Я бы определенно хранил его на стороне сервера (файловая система или дБ), а не распространял и поддерживал его на нескольких клиентах.

Вот как это может работать с шифрованием "DES":

// only the first 8 Bytes of the constructor argument are used 
// as material for generating the keySpec
DESKeySpec keySpec = new DESKeySpec("YourSecr".getBytes("UTF8")); 
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
SecretKey key = keyFactory.generateSecret(keySpec);
sun.misc.BASE64Encoder base64encoder = new BASE64Encoder();
sun.misc.BASE64Decoder base64decoder = new BASE64Decoder();
.........

// ENCODE plainTextPassword String
byte[] cleartext = plainTextPassword.getBytes("UTF8");      

Cipher cipher = Cipher.getInstance("DES"); // cipher is not thread safe
cipher.init(Cipher.ENCRYPT_MODE, key);
String encrypedPwd = base64encoder.encode(cipher.doFinal(cleartext));
// now you can store it 
......

// DECODE encryptedPwd String
byte[] encrypedPwdBytes = base64decoder.decodeBuffer(encryptedPwd);

Cipher cipher = Cipher.getInstance("DES");// cipher is not thread safe
cipher.init(Cipher.DECRYPT_MODE, key);
byte[] plainTextPwdBytes = (cipher.doFinal(encrypedPwdBytes));
18 голосов
/ 04 декабря 2008

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

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

Не распространяйте сторонний пароль за пределы вашего веб-сервера.

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

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

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

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

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

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

...