Ніколи не вводьте жорсткий код паролів у свій код. Це нещодавно було піднято в Топ-25 найнебезпечніших помилок програмування :
Твердо кодувати секретний рахунок і пароль у своєму програмному забезпеченні надзвичайно зручно - для досвідчених інженерів-реверсистів. Якщо пароль однаковий у всьому вашому програмному забезпеченні, тоді кожен клієнт стає вразливим, коли цей пароль неминуче стає відомим. І оскільки це жорстко закодовано, виправити це величезний біль.
Ви повинні зберігати інформацію про конфігурацію, включаючи паролі, в окремому файлі, який програма читає під час запуску. Це єдиний реальний спосіб запобігти витоку пароля в результаті декомпіляції (ніколи не компілюйте його в двійковий файл для початку).
Для отримання додаткової інформації про цю поширену помилку ви можете прочитати статтю CWE-259 . Стаття містить більш ретельне визначення, приклади та багато іншої інформації про проблему.
У Java один з найпростіших способів це зробити - використовувати клас Preferences. Він призначений для зберігання всіляких налаштувань програми, деякі з яких можуть містити ім’я користувача та пароль.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
У наведеному вище коді ви можете викликати setCredentialsметод після відображення діалогового вікна askign для імені користувача та пароля. Коли вам потрібно підключитися до бази даних, ви можете просто використовувати методи getUsernameі getPasswordдля отримання збережених значень. Реєстраційні дані не будуть жорстко закодовані у ваші двійкові файли, тому декомпіляція не представлятиме ризику для безпеки.
Важлива примітка: Файли налаштувань - це просто текстові XML-файли. Обов’язково вживайте відповідних заходів, щоб не дозволити несанкціонованим користувачам переглядати необроблені файли (дозволи UNIX, дозволи Windows тощо). Принаймні, в Linux це не проблема, оскільки виклик Preferences.userNodeForPackageстворить файл XML у домашньому каталозі поточного користувача, який і так не читається іншими користувачами. У Windows ситуація може бути іншою.
Більш важливі примітки: У коментарях до цієї відповіді та інших було багато дискусій щодо того, яка правильна архітектура для цієї ситуації. В оригінальному запитанні насправді не згадується контекст, в якому використовується додаток, тому я розповім про дві ситуації, яких я можу подумати. Перший - це випадок, коли особа, яка використовує програму, вже знає (і уповноважена знати) облікові дані бази даних. Другий - випадок, коли ви, розробник, намагаєтесь зберегти таємницю облікових даних бази даних від особи, яка використовує програму.
Перший випадок: користувач має право знати облікові дані для входу в базу даних
У цьому випадку згадане вище рішення буде працювати. Клас Java Preferenceзберігатиме ім’я користувача та пароль у звичайному тексті, але файл налаштувань читатиме лише авторизований користувач. Користувач може просто відкрити файл XML налаштувань і прочитати облікові дані для входу, але це не є ризиком для безпеки, оскільки користувач знав ці дані для початку.
Другий випадок: спроба приховати облікові дані для входу від користувача
Це більш складний випадок: користувач не повинен знати облікові дані для входу, але все одно потребує доступу до бази даних. У цьому випадку користувач, який запускає додаток, має прямий доступ до бази даних, що означає, що програма повинна знати облікові дані для входу заздалегідь. Рішення, про яке я згадав вище, не підходить для цього випадку. Ви можете зберігати облікові дані бази даних у файлі налаштувань, але користувач зможе прочитати цей файл, оскільки вони будуть власником. Насправді дійсно не існує хорошого способу безпечного використання цієї справи.
Правильний випадок: Використання багаторівневої архітектури
Правильний спосіб зробити це - мати середній рівень, між сервером бази даних і вашим клієнтським додатком, який автентифікує окремих користувачів і дозволяє виконувати обмежений набір операцій. Кожен користувач мав би власні облікові дані для входу, але не для сервера баз даних. Повноваження дозволяли б доступ до середнього рівня (рівень бізнес-логіки) і були б різними для кожного користувача.
Кожен користувач мав би своє власне ім'я користувача та пароль, які можна було б зберігати локально у файлі налаштувань без будь-якого ризику безпеки. Це називається трирівневою архітектурою (ярусами є ваш сервер баз даних, сервер бізнес-логіки та клієнтська програма). Це складніше, але насправді це найбезпечніший спосіб зробити подібні речі.
Основний порядок операцій:
- Клієнт виконує автентифікацію за рівнем бізнес-логіки, використовуючи особисте ім’я користувача / пароль користувача. Ім'я користувача та пароль відомі користувачеві і жодним чином не пов'язані з обліковими даними для входу в базу даних.
- Якщо автентифікація успішна, клієнт робить запит до рівня бізнес-логіки з проханням отримати інформацію з бази даних. Наприклад, інвентаризація продукції. Зверніть увагу, що запит клієнта не є запитом SQL; це віддалений виклик процедури, такий як
getInventoryList.
- Рівень бізнес-логіки підключається до бази даних і отримує запитувану інформацію. Рівень бізнес-логіки відповідає за формування безпечного запиту SQL на основі запиту користувача. Будь-які параметри запиту SQL слід дезінфікувати, щоб запобігти атакам ін'єкції SQL.
- Рівень бізнес-логіки надсилає список запасів назад до клієнтської програми.
- Клієнт відображає користувачеві інвентарний список.
Зверніть увагу, що протягом усього процесу клієнтська програма ніколи не підключається безпосередньо до бази даних . Рівень бізнес-логіки отримує запит від автентифікованого користувача, обробляє запит клієнта на список інвентаризації і лише потім виконує запит SQL.