2015-07-07 9 views
5

Jak mówi tytuł, szukam sposobu na znalezienie tablicy char [] do nawiązania połączenia JDBC zamiast tworzenia nowego obiektu String z char [] array i używając tego do ustanowienia połączenia.Problem przy ustanawianiu połączenia z bazą danych z tablicą znaków zamiast z ciągiem znaków

Ponieważ tablice char [] to more secure than Strings in java, chciałem, aby wszystko było tak bezpieczne, jak to możliwe, gdy mam do czynienia z moimi pulami JPasswordFields.

W tym konkretnym przypadku biorę zawartość tablicy char [] z pola JPasswordField i próbuję ustanowić połączenie JDBC z bazą danych. Działa to doskonale, ale muszę utworzyć nowy obiekt String z tablicy char [], aby wywołać metodę getConnection.

Czy jest jakiś sposób, aby zapewnić co najmniej pewne bezpieczeństwo to zrobić, czy jestem po prostu zmuszony do utworzenia obiektu String i nadal go używać w metodzie?

To jest mój kod:

/** 
* Construct a new DataManager object with it's own 
* connection to the database. 
* 
* @param ipAddress The IP address to the server on which MySQL is running. 
* @param port The port to use when connecting to MySQL. 
* @param databaseName The database name of the database to connect to. 
* @param username The username for a MySQL account with access to the specified database. 
* @param password The password for the MySQL account specified by the specified username. 
*/ 
public DataManager(final String ipAddress, final String port, final String databaseName, final String username, final char[] password) throws ClassNotFoundException, IllegalAccessException, InstantiationException, SQLException { 
    Class.forName("com.mysql.jdbc.Driver").newInstance(); 
    String url = "jdbc:mysql://" + ipAddress + ":" + port + "/" + databaseName + "?noAccessToProcedureBodies=true"; //?noAccessToProcedureBodies=true is required for using the stored procedures. 
    dbConnection = DriverManager.getConnection(url, username, new String(password)); 
} 

Przepraszamy za formatowanie, ale linie są trochę długo i zawinąć.

Here's the Java docs for the DriverManager class, którego używam. Sprawdziłem i wydaje się, że nie ma metody, aby użyć char[] zamiast String i to właśnie podpowiadało ten post.

Dzięki za pomoc/wskazówki.

+1

Powiązane: [Łańcuch znaków lub tablica znaków dla hasła podczas korzystania z JDBC?] (Http://stackoverflow.com/questions/20342389/string-or-char-for-password-when-using-jdbc) – Pshemo

+1

Być może chcesz kodereview end-to-end, dzięki czemu można dowiedzieć się, gdzie istnieją luki w zabezpieczeniach – Drew

+0

@Pshemo Po szybkim zapoznaniu się z tym linkiem, wygląda na to, że głównie omawiają one, dlaczego nie należy przechowywać hasła jako ciągu znaków, a zamiast tego użyj tablicy char []. Istnieje jedna sugestia, aby użyć puli połączeń/menedżera, a następnie zezwolić tylko na dostęp do hasła, ale to nadal oznaczałoby, że hasło jest przechowywane, aby można je było ponownie wykorzystać, prawda? – Valkryst

Odpowiedz

2

Jako @DavidS powiedział w komentarzach, nie jestem pewien, używając char [] jest naprawdę bardziej bezpieczne w znaczący sposób, ale ja nie kopać w źródle DriverManager, aby zobaczyć, czy to możliwe, aby używać tak czy inaczej.

Jeśli spojrzysz na the getConnection() method you're using zobaczysz, że to (wraz z innymi odmianami parametrów) zbiera wszystkie dostarczone informacje o połączeniu w java.util.Properties, która jest w istocie tabelą skrótu String-> String. Obiekt Properties jest następnie passed to the needed driver w metodzie, która jest zdefiniowana jako część długo stojącej (a zatem bardzo nieprawdopodobnej do zmiany) java.sql.Driver interface, z dowolną implementacją, która oczywiście zależy od sterownika.

W tym momencie myślę, że musisz automatycznie założyć, że ktoś gdzieś zrobi kopię dostarczonego hasła String lub umieści go w składzie większego String, a więc nie będziesz mógł polegać na refleksji, aby wrócić i wyczyść ten bufor. Na przykład w sterowniku JDBC PostgreSQL, w zależności od ustawień uwierzytelniania, hasło może być po prostu sitting out as an encoded byte[], a nawet ustawienia, które go trawią prawdopodobnie (nie wyglądałem zbyt szeroko i nie próbuję zapukać tutaj PostgreSQL) to trawienie jest otwarte na wykopanie.

Nawet jeśli nikt nigdy nie zrobił kopii hasła String, a podsumowanie było całkowicie nietykalne, nadal musisz się martwić faktem, że istnieją wiszące odniesienia do niego (poprzez obiekt Properties) na całym stosie sterownika , a rzeczy mogą pękać w nieoczekiwany sposób.

Na dobre i na złe uważam, że bardzo zależy nam na przechowywaniu w tym miejscu haseł DB jako Strings, ale nie jestem przekonany, że to poważny problem. Nie sądzę, że doświadczenie historyczne było takie, że programistom łatwiej jest bezpiecznie zarządzać cyklem życia wrażliwych obiektów w przeciwieństwie do garbage collectora. Byłoby miło, gdyby Java dała nam sposób na opisanie obiektu jako celu bardziej agresywnego przycinania, ale prawdopodobnie również nie jest to konieczne.

Po napisaniu tego posta, musiałem przejść przez ~ 8 poziomów wywołań metod i tworzenia obiektów, więc zastanawiam się, czy ciąg hasła jest naprawdę krótkotrwały na tyle, że możliwość ręcznego wyczyszczenia go znacznie zmniejszyłby powierzchnię ataku . Myślę, że wygoda, jaką jest ergonomia obsługi Java w Javie, pozwala nam zapomnieć, jak wiele dzieje się za kulisami.

Powiązane problemy