Якщо припустити, що я намагаюся отримати з RESTful API, який використовує базову автентифікацію / основні сертифікати, який найкращий спосіб зберегти це ім'я користувача та пароль у моїй програмі? Зараз це просто сидить там у відкритому тексті.
UsernamePasswordCredentials creds = new UsernamePasswordCredentials("myName@myserver","myPassword1234");
Чи є якийсь спосіб зробити це, що більше стосується безпеки?
Дякую
Відповіді:
Якщо ви розробляєте систему автентифікації в цілому, вам не слід зберігати паролі, навіть якщо вони зашифровані. Ви зберігаєте хеш і перевіряєте, чи відповідають паролі, введені під час входу, тому самому хешу. Таким чином, порушення безпеки вашої бази даних дозволяє уникнути виявлення паролів ваших користувачів.
З огляду на це, з внутрішньо-зовнішнім мисленням, ось кілька кроків для захисту вашого процесу:
Першим кроком, вам слід змінити обробку паролів з Stringна character array.
Причиною цього є те, що a Stringє immutableоб'єктом, і тому його дані не будуть очищені відразу, навіть якщо для об'єкта встановлено значення null; Натомість дані встановлені для збору сміття, і це створює проблеми із безпекою, оскільки шкідливі програми можуть отримати доступ до цих String(парольних) даних перед тим, як їх очистити.
Це основна причина, чому метод JPasswordField SwinggetText() застарілий, і чому getPassword()використовуються масиви символів .
Другий крок - це шифрування ваших облікових даних, лише тимчасове їх розшифрування під час процесу автентифікації. Або хешувати їх на стороні сервера, зберігати цей хеш і "забувати" оригінальний пароль.
Це, подібно до першого кроку, гарантує, що час вразливості є якомога меншим.
Рекомендується, щоб ваші облікові дані не були жорстко закодовані, а замість цього ви зберігали їх у централізованому, конфігуруваному та легко підтримуваному способі, наприклад, у файлі конфігурації чи властивостей або в базі даних.
Перед збереженням файлу слід зашифрувати свої облікові дані, а крім того, ви можете застосувати друге шифрування до самого файлу (2-шарове шифрування до облікових даних та 1-шарове до іншого вмісту файлу).
Зверніть увагу, що кожен із двох згаданих вище процесів шифрування може бути багатошаровим. Кожне шифрування може бути окремим додатком стандарту потрійного шифрування даних (AKA TDES та 3DES) , як концептуальний приклад.
Після того, як ваше локальне середовище буде належним чином захищене (але пам’ятайте, воно ніколи не буде «безпечним»!), Третім кроком є застосування базового захисту до вашого процесу передачі за допомогою TLS (Transport Layer Security) або SSL (Secure Sockets Layer) .
Четвертим кроком є застосування інших методів захисту.
Наприклад, застосовуючи прийоми затухання до вашої компіляції "для використання", щоб уникнути (навіть невдовзі) впливу ваших заходів безпеки у випадку, якщо ваша програма отримана пані Євою, містером Меллорі або кимось іншим (погано хлопці) і декомпілювали.
ОНОВЛЕННЯ 1:
За запитом @ Damien.Bell, ось приклад, який охоплює перший та другий кроки:
//These will be used as the source of the configuration file's stored attributes.
private static final Map<String, String> COMMON_ATTRIBUTES = new HashMap<String, String>();
private static final Map<String, char[]> SECURE_ATTRIBUTES = new HashMap<String, char[]>();
//Ciphering (encryption and decryption) password/key.
private static final char[] PASSWORD = "Unauthorized_Personel_Is_Unauthorized".toCharArray();
//Cipher salt.
private static final byte[] SALT = {
(byte) 0xde, (byte) 0x33, (byte) 0x10, (byte) 0x12,
(byte) 0xde, (byte) 0x33, (byte) 0x10, (byte) 0x12,};
//Desktop dir:
private static final File DESKTOP = new File(System.getProperty("user.home") + "/Desktop");
//File names:
private static final String NO_ENCRYPTION = "no_layers.txt";
private static final String SINGLE_LAYER = "single_layer.txt";
private static final String DOUBLE_LAYER = "double_layer.txt";
/**
* @param args the command line arguments
*/
public static void main(String[] args) throws GeneralSecurityException, FileNotFoundException, IOException {
//Set common attributes.
COMMON_ATTRIBUTES.put("Gender", "Male");
COMMON_ATTRIBUTES.put("Age", "21");
COMMON_ATTRIBUTES.put("Name", "Hypot Hetical");
COMMON_ATTRIBUTES.put("Nickname", "HH");
/*
* Set secure attributes.
* NOTE: Ignore the use of Strings here, it's being used for convenience only.
* In real implementations, JPasswordField.getPassword() would send the arrays directly.
*/
SECURE_ATTRIBUTES.put("Username", "Hypothetical".toCharArray());
SECURE_ATTRIBUTES.put("Password", "LetMePass_Word".toCharArray());
/*
* For demosntration purposes, I make the three encryption layer-levels I mention.
* To leave no doubt the code works, I use real file IO.
*/
//File without encryption.
create_EncryptedFile(NO_ENCRYPTION, COMMON_ATTRIBUTES, SECURE_ATTRIBUTES, 0);
//File with encryption to secure attributes only.
create_EncryptedFile(SINGLE_LAYER, COMMON_ATTRIBUTES, SECURE_ATTRIBUTES, 1);
//File completely encrypted, including re-encryption of secure attributes.
create_EncryptedFile(DOUBLE_LAYER, COMMON_ATTRIBUTES, SECURE_ATTRIBUTES, 2);
/*
* Show contents of all three encryption levels, from file.
*/
System.out.println("NO ENCRYPTION: \n" + readFile_NoDecryption(NO_ENCRYPTION) + "\n\n\n");
System.out.println("SINGLE LAYER ENCRYPTION: \n" + readFile_NoDecryption(SINGLE_LAYER) + "\n\n\n");
System.out.println("DOUBLE LAYER ENCRYPTION: \n" + readFile_NoDecryption(DOUBLE_LAYER) + "\n\n\n");
/*
* Decryption is demonstrated with the Double-Layer encryption file.
*/
//Descrypt first layer. (file content) (REMEMBER: Layers are in reverse order from writing).
String decryptedContent = readFile_ApplyDecryption(DOUBLE_LAYER);
System.out.println("READ: [first layer decrypted]\n" + decryptedContent + "\n\n\n");
//Decrypt second layer (secure data).
for (String line : decryptedContent.split("\n")) {
String[] pair = line.split(": ", 2);
if (pair[0].equalsIgnoreCase("Username") || pair[0].equalsIgnoreCase("Password")) {
System.out.println("Decrypted: " + pair[0] + ": " + decrypt(pair[1]));
}
}
}
private static String encrypt(byte[] property) throws GeneralSecurityException {
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
SecretKey key = keyFactory.generateSecret(new PBEKeySpec(PASSWORD));
Cipher pbeCipher = Cipher.getInstance("PBEWithMD5AndDES");
pbeCipher.init(Cipher.ENCRYPT_MODE, key, new PBEParameterSpec(SALT, 20));
//Encrypt and save to temporary storage.
String encrypted = Base64.encodeBytes(pbeCipher.doFinal(property));
//Cleanup data-sources - Leave no traces behind.
for (int i = 0; i < property.length; i++) {
property[i] = 0;
}
property = null;
System.gc();
//Return encryption result.
return encrypted;
}
private static String encrypt(char[] property) throws GeneralSecurityException {
//Prepare and encrypt.
byte[] bytes = new byte[property.length];
for (int i = 0; i < property.length; i++) {
bytes[i] = (byte) property[i];
}
String encrypted = encrypt(bytes);
/*
* Cleanup property here. (child data-source 'bytes' is cleaned inside 'encrypt(byte[])').
* It's not being done because the sources are being used multiple times for the different layer samples.
*/
// for (int i = 0; i < property.length; i++) { //cleanup allocated data.
// property[i] = 0;
// }
// property = null; //de-allocate data (set for GC).
// System.gc(); //Attempt triggering garbage-collection.
return encrypted;
}
private static String encrypt(String property) throws GeneralSecurityException {
String encrypted = encrypt(property.getBytes());
/*
* Strings can't really have their allocated data cleaned before CG,
* that's why secure data should be handled with char[] or byte[].
* Still, don't forget to set for GC, even for data of sesser importancy;
* You are making everything safer still, and freeing up memory as bonus.
*/
property = null;
return encrypted;
}
private static String decrypt(String property) throws GeneralSecurityException, IOException {
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
SecretKey key = keyFactory.generateSecret(new PBEKeySpec(PASSWORD));
Cipher pbeCipher = Cipher.getInstance("PBEWithMD5AndDES");
pbeCipher.init(Cipher.DECRYPT_MODE, key, new PBEParameterSpec(SALT, 20));
return new String(pbeCipher.doFinal(Base64.decode(property)));
}
private static void create_EncryptedFile(
String fileName,
Map<String, String> commonAttributes,
Map<String, char[]> secureAttributes,
int layers)
throws GeneralSecurityException, FileNotFoundException, IOException {
StringBuilder sb = new StringBuilder();
for (String k : commonAttributes.keySet()) {
sb.append(k).append(": ").append(commonAttributes.get(k)).append(System.lineSeparator());
}
//First encryption layer. Encrypts secure attribute values only.
for (String k : secureAttributes.keySet()) {
String encryptedValue;
if (layers >= 1) {
encryptedValue = encrypt(secureAttributes.get(k));
} else {
encryptedValue = new String(secureAttributes.get(k));
}
sb.append(k).append(": ").append(encryptedValue).append(System.lineSeparator());
}
//Prepare file and file-writing process.
File f = new File(DESKTOP, fileName);
if (!f.getParentFile().exists()) {
f.getParentFile().mkdirs();
} else if (f.exists()) {
f.delete();
}
BufferedWriter bw = new BufferedWriter(new FileWriter(f));
//Second encryption layer. Encrypts whole file content including previously encrypted stuff.
if (layers >= 2) {
bw.append(encrypt(sb.toString().trim()));
} else {
bw.append(sb.toString().trim());
}
bw.flush();
bw.close();
}
private static String readFile_NoDecryption(String fileName) throws FileNotFoundException, IOException, GeneralSecurityException {
File f = new File(DESKTOP, fileName);
BufferedReader br = new BufferedReader(new FileReader(f));
StringBuilder sb = new StringBuilder();
while (br.ready()) {
sb.append(br.readLine()).append(System.lineSeparator());
}
return sb.toString();
}
private static String readFile_ApplyDecryption(String fileName) throws FileNotFoundException, IOException, GeneralSecurityException {
File f = new File(DESKTOP, fileName);
BufferedReader br = new BufferedReader(new FileReader(f));
StringBuilder sb = new StringBuilder();
while (br.ready()) {
sb.append(br.readLine()).append(System.lineSeparator());
}
return decrypt(sb.toString());
}
Повний приклад, що стосується кожного кроку захисту, набагато перевищує те, що, на мою думку, є розумним для цього питання, оскільки мова йде про "які етапи" , а не "як їх застосовувати" .
Це могло б значно перевищити мою відповідь (нарешті, вибірку), тоді як інші питання тут, на тему SO, вже спрямовані на те, "як робити" ці кроки, будучи набагато більш доречними, і пропонуючи набагато кращі пояснення та вибірку щодо впровадження кожен окремий крок.
[*]- @ Damien.Bell Щоб не залишити ваш запит без уваги, я включив приклад, який охоплює перший (~) та другий кроки. --- Що стосується того, чому не всі кроки, ну, як ви бачите, це не те, що ви можете взяти за допомогою маленького маленького фрагмента коду; А приклад для захисту мережі потребує навіть більше, ніж місцевий обсяг, навіть якщо він частково псевдокодований. Обфускація також має дуже широкий спектр методів реалізації, і хоча це просто за задумом, той факт, що він застосовується до самого вихідного коду, означає, що це важко пояснити у зразках.
CharBufferспеціально зафіксовано , але, якщо це не є незмінним (можна отримати внутрішні дані, переписані на nullабо нулі без чекаючи GC), ви можете використовувати його, якщо не забудете очистити.
Якщо ви використовуєте базову автентифікацію, вам слід поєднати це з SSL, щоб уникнути передачі своїх облікових даних у простому тексті, закодованому base64. Ви не хочете, щоб хтось нюхав ваші пакети, щоб отримати ваші облікові дані. Крім того, не кодуйте свої облікові дані у своєму вихідному коді. Зробіть їх налаштованими. прочитати їх з конфігураційного файлу. Вам слід зашифрувати облікові дані, перш ніж зберігати їх у файлі конфігурації, а програма повинна розшифрувати облікові дані, як тільки прочитає їх із конфігураційного файлу.
Як правило, не є доброю порадою шифрувати облікові дані. Щось, що зашифровано, можна розшифрувати. Найпоширенішою практикою є зберігання паролів як засоленого хешу . Хеш не можна розшифрувати. Сіль додається, щоб перемогти грубу силу вгадування за допомогою Веселкових Столів . Поки кожен UserId має власну випадкову сіль, зловмисникові доведеться створити набір таблиць для кожного можливого значення солі, швидко роблячи цю атаку неможливою протягом тривалості життя Всесвіту. Це причина, через яку веб-сайти зазвичай не можуть надіслати вам ваш пароль, якщо ви його забули, але вони можуть лише "скинути" його. У них не зберігається ваш пароль, лише його хеш.
Хешування паролів не дуже складно реалізувати самостійно, але вирішити настільки типову проблему, що незліченна кількість людей зробили це за вас. Я знайшов jBcrypt простим у використанні.
Як додатковий захист від грубої сили вгадування паролів, загальноприйнятою практикою є змусити userId або віддалений IP зачекати кілька секунд після певної кількості спроб входу за допомогою неправильного пароля. Без цього зловмисник грубої сили може вгадати стільки паролів за секунду, скільки може обробити ваш сервер. Існує величезна різниця між можливістю вгадати 100 паролів за 10 секунд або мільйон.
У мене складається враження, що ви включили комбінацію ім’я користувача / пароль у свій вихідний код. Це означає, що якщо ви коли-небудь захочете змінити пароль, вам доведеться перекомпілювати, зупинити та перезапустити службу, а також означає, що кожен, хто отримає ваш вихідний код, також має ваші паролі. Найпоширенішою практикою є ніколи не робити цього, а зберігати облікові дані (ім’я користувача, хеш пароля, сіль пароля) у вашому сховищі даних
security.Providerнавіть у старих версіях, тому я все ще не бачу потреби в сторонніх API.
плюс, мабуть, тисячі речей, про які я забув :)
Якщо ви не можете довіряти середовищу, в якому працює ваша програма, але вам потрібно пройти автентифікацію за допомогою простих паролів або сертифікатів, ви нічого не можете зробити для захисту своїх облікових даних. Найбільше, що ви можете зробити, це затуманити їх методами, описаними в інших відповідях.
Як обхідний шлях, я б запустив усі запити до RESTful api через проксі-сервер, якому ви можете довіряти, і здійснити автентифікацію пароля чистого тексту звідти.
0і 1в пам'яті, що досягається за певним набором логічних правил, які за своєю суттю завжди якимось чином оборотні. ___ Основою криптографічної безпеки є, завжди була і, мабуть, буде завжди, "робити це настільки складно, що не варто витрачати зусилля". ___ Нарешті, ви помиляєтесь із автоматичним заповненням / входом браузера (що стосується веб-сайтів) із автоматичним авторизацією / входом програми (який зберігається у зашифрованих файлах і лише там).
чому люди говорять про хешування. OP хоче зберігати облікові дані своїх користувачів для доступу до зовнішнього ресурсу. Хешування його пароля не допоможе.
Зараз це зі шляху. Я б просто прості найкращі практики для кожного шару.
1. Зберігання пароля в програмі Java. : Зберігайте як Char Array. Створіть клас зберігання паролів і збережіть пароль як хеш-карту з ключем як ресурсом, до якого ви хочете отримати доступ, і визначте його як об’єкт, що містить ім’я користувача та пароль. Обмежте точку входу до цього API з деякою автентифікацією Приклад: прийміть облікові дані користувачів, що увійшли, щоб перевірити рівень доступу цього користувача до цього ресурсу (просто відобразіть користувача до списку паролів, до яких вони можуть отримати доступ. Якщо вас багато, створіть групу і зіставити ключ мапи пароля з цією групою) Будь-що поза цим, щоб зберігати пароль, залежить від того, наскільки параноїчно ви налаштовані на те, щоб сам jvm його просочив.