[JAVA]wachtwoord "veilig" naar database sturen

[mpegernie]

Ik ben voor mijn opleiding bezig met java en databases. Ik heb een MS Acces database gemaakt en die benader ik vanuit mijn programmaatje via JDBC:ODBC, gaat goed. Nu wil ik de mogelijkheid om via de GUI het wachtwoord voor de database in te typen. Het password haal ik uit het JPasswordfield met getPassword(), die het opslaat in een char-array. De methode getText() (slaat het op in een String) mag ik wel gebruiken icm met een Passwordfield (hoewel het deprecated is) maar dat zou onveilig zijn las ik...?

Het probleem is nu dat ik het wachtwoord mee moet sturen bij het maken van de connectie naar de database server. De methode getConnection accepteerd de char-array niet. Dus dit werkt niet:

code:

con = DriverManager.getConnection(sURL,
                        sUserID,
                        cPassword);

Ik moet blijkbaar een String mee sturen...?

Twee vraagjes dus: is een string echt onveilig? en kan ik het wachtwoord niet "veilig" naar de database server sturen?

Niet dat het mij echt uit maakt maar ik vind dat als je al geheimzinnig gaat zitten doen met PasswordFields dat het niet zo lek als een zeef moet zijn. Beetje educatief bedoel dus

PS, ik werk, zoals je denk ik al wel gezien had, met Swing voor de GUI

[mpegernie]

Ik zit net ff te lezen over een JDBC driver die SSL ondersteund. Dat zou al een begin zijn dan. Zit ik alleen nog met die String...

[wasigh]

Een string heeft een constructor die met een charArray werkt. Dus het omzetten zou geen probleem moeten zijn.

Of het wachtwoord veilig overgestuurd wordt ligt aan het protocol en daar ken ik de details niet van.

[Glimi]

Weet je eigenlijk wel waarom een passwordfield een char array returned? Het is tenslotte toch een string?

Het is eigenlijk heel simpel. In Java is er niet een primitieve string, maar een classe string. Dit betekend dat als een string object niet meer gebruikt wordt, deze door de garbage collector opgeruimt.

Echter van de garbage collector hebben we geen idee waarneer die het doet en of ie het wel gaat doen (heb je echt geen garantie voor). Het kan dus zijn dat de string nog gewoon in je geheugen staat, als de JVM afgesloten is.

Dat hebben we niet met primitieven. Daarom returned een passwordfield een chararray

Dus ja, als je een string van die chararray gaat maken, is het effect van zo'n JPasswordField alsnog naar z'n grootje

[mpegernie]

Op zondag 26 mei 2002 14:23 schreef Glimi het volgende:
Dus ja, als je een string van die chararray gaat maken, is het effect van zo'n JPasswordField alsnog naar z'n grootje

thnx, voor de uitleg. en ik moet idd de char[] naar een String omzetten. maar ik kan zelf toch wel voor garbagecollector spelen? ik heb het nu zo gedaan dat hij, na de opbouw van de connectie dit doet:

code:

sPassword = null;
cPassword = null;
jpfPassword.setText("");

[Glimi]

Op zondag 26 mei 2002 15:08 schreef mpegernie het volgende:

[..]

thnx, voor de uitleg. en ik moet idd de char[] naar een String omzetten. maar ik kan zelf toch wel voor garbagecollector spelen? ik heb het nu zo gedaan dat hij, na de opbouw van de connectie dit doet:

code:

sPassword = null;
cPassword = null;
jpfPassword.setText("");

Denk hierbij dat String immutable is. Wat je dus doet is cPassword naar niets laten verwijzen. De oude password string zit nog wel in het geheugen, maar is niet toegangelijk meer met je variabeles! Er is volgens mij ook geen manier om dit weg te krijgen

[Verwijderd]

misschien helpt in dat geval het aanroepen van System.rc() (of Runtime.getRuntime().gc()) iets ?

[Bobco]

Op zondag 26 mei 2002 23:20 schreef JavaRules het volgende:
misschien helpt in dat geval het aanroepen van System.rc() (of Runtime.getRuntime().gc()) iets ?

Op zich wel, maar garanties biedt dat niet. De JVM mag namelijk zelf bepalen wanneer hij aan GC doet. De mogelijke onveiligheid blijft dus bestaan. Ik vraag me trouwens af in hoeverre dit een groot risico is, want degene die geinteresseerd is in dit password moet wel in staat zijn om een geheugendump te maken van het JVM proces. Als een gebruiker dat kan is er volgens mij sprake van een veel groter beveiligingsprobleem.

Ik weet niet hoe kritisch deze toepassing is, maar voor gebruik op een intranet lijkt me dit veilig genoeg (famous last words.... )

[Xanthus]

Java kan je volgens mij zo simpel decompilen dat als het password hardcoded is het zo makkelijk is uit te lezen dat je geheugen leegmaken eigenlijk geen zin heeft.
Als het gaat over de verstuurde informatie over internet dan kan je hem misschien simpel encrypten, zodat als je afgetapt oid wordt, het niet duidelijk is wat het is.

[Glimi]

Op maandag 27 mei 2002 15:49 schreef Xanthus het volgende:
Java kan je volgens mij zo simpel decompilen dat als het password hardcoded is het zo makkelijk is uit te lezen dat je geheugen leegmaken eigenlijk geen zin heeft.
Als het gaat over de verstuurde informatie over internet dan kan je hem misschien simpel encrypten, zodat als je afgetapt oid wordt, het niet duidelijk is wat het is.

Het ging hier om een JPasswordField hoor. Die vraagt input van de user != hardcoded passwordstring

[Bobco]

Op maandag 27 mei 2002 15:49 schreef Xanthus het volgende:
Java kan je volgens mij zo simpel decompilen dat als het password hardcoded is het zo makkelijk is uit te lezen dat je geheugen leegmaken eigenlijk geen zin heeft.
Als het gaat over de verstuurde informatie over internet dan kan je hem misschien simpel encrypten, zodat als je afgetapt oid wordt, het niet duidelijk is wat het is.

Hmm, een database aanspreken via Internet lijkt me hoe dan ook niet het meest veilige om te doen. En zoals Glimi ook al opmerkt: het gaat om een password dat je alleen maar via een Java applicatie doorgeeft aan een database. Je bent natuurlijk niet echt slim bezig als je de applicatie laat controleren of userId/password wel kloppen, daar gebruik je het user management van de database voor.

En als we het toch over veiligheid gaan hebben: via welk protocol moet die applicatie met de database gaan praten?

[mpegernie]

Op maandag 27 mei 2002 16:48 schreef Bobco het volgende:

[..]

Hmm, een database aanspreken via Internet lijkt me hoe dan ook niet het meest veilige om te doen. En zoals Glimi ook al opmerkt: het gaat om een password dat je alleen maar via een Java applicatie doorgeeft aan een database. Je bent natuurlijk niet echt slim bezig als je de applicatie laat controleren of userId/password wel kloppen, daar gebruik je het user management van de database voor.

En als we het toch over veiligheid gaan hebben: via welk protocol moet die applicatie met de database gaan praten?

protocol? jdbc:odbc bedoel je denk ik?
Dat is idd denk ik, zoals ik in mijn post al zei, niet echt veilig maar er zijn drivers die SLL ondersteunen (dus als het echt moet...).
Verder is het idd geen kritische applicatie maar ik ben een beetje de mogelijkheden aan het verkennen. Het is de bedoeling dat ik uiteindelijk een enquete systeem ga maken die antwoorden over een intranet in een DB gooit (en daar ook de vragen vandaan haalt). Password en ID heeft daar verder niet zoveel mee te maken.

Ieg bedankt voor de uitleg, tis een stuk duidelijker geworden.

en idd, het password in de code zetten is ook niet mijn idee en eigenlijk vind ik dat ook een slechte gewoonte. Zet het dan ff in een properties file.