Java – шифрование / дешифрование имени пользователя и пароля из файла конфигурации

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

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

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

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

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

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

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

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

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

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

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

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

Вот как это могло бы работать с шифрованием 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));