[Java + MySQL] Errore nella memorizzazione di una password criptata con MD5

[luxorl]

Ho un piccolo problema.
In pratica quando il sistema aggiunge un nuovo utente prima di inserire la password nel DB MySql la cripta con MD5.

	private String cryptPassword(final String password) {
		        MessageDigest md=null;
		        try {
		            //we use MD5 Algorithm
		            md = MessageDigest.getInstance("MD5");
		        } catch (NoSuchAlgorithmException ex) {
		            ex.printStackTrace();
		        }
		        md.update(password.getBytes());
		        return new String(md.digest());
     }

Quando un utente fa il login il sistema prende la password inserita dall'utente la cripta e la confronta con quella già criptata conservata nel DB.

Sembrava andare tutto ok, fin quando per caso non ho usato la password: "direttore".

In pratica usando nel prompt-msdos l'algoritmo MD5 con input "direttore" mi restituisce questa cosa

àLa☺ ×fá`¾e¦☼â♫&

Mente nel DB se accedo tramite MySql Administrator trovo solo questo:


Non succede con le altre password provate fin'ora.
Come mai? E' lo spazio che crea problemi? Sono quei caratteri speciali? Uso male l'algoritmo MD5? come risolvo?

Aiutatemi per favore

NB: nel DB la password viene memorizzata come VARCHAR

[banryu79]

Ciao,

premetto che non me ne intendo per nulla, nel senso che non so come funziona l'agoritmo MD5 percui potrei suggerirti un'amena cazzata.

Però leggendo qua:

...
md.update(password.getBytes());
...

si nota che ti stai facendo restituire la codifica della tua String con il metodo getBytes() che usa il charset di default della piattaforma e se la stringa, per qualche ragione, non è codificabile con quel charset [non esiste una mappatura per il dato carattere, cosa che non credo sia nel tuo caso, oppure la stringa è "malformata"] il comportamento è indefinito.

Prova ad usare il metodo .getBytes(Charset charset) : specificando un Charset esplicitamente in caso di problemi con la stringa la sequenza di caratteri malformata viene rimpiazzata con un array di byte di default per il dato Charset (Vedi le API Javadoc a riguardo)

In ogni caso credo che sarebbe meglio usare la versione che prende il Charset esplicitamente definito dal programmatore, perchè il Charset di default (quello utilizzato dal sistema, ci pensa la Jvm a pescarlo) può essere diverso tra diversi sistemi operativi.

[luxorl]

Originariamente inviato da banryu79

Ciao,

premetto che non me ne intendo per nulla, nel senso che non so come funziona l'agoritmo MD5 percui potrei suggerirti un'amena cazzata.

Però leggendo qua:

...
md.update(password.getBytes());
...

si nota che ti stai facendo restituire la codifica della tua String con il metodo getBytes() che usa il charset di default della piattaforma e se la stringa, per qualche ragione, non è codificabile con quel charset [non esiste una mappatura per il dato carattere, cosa che non credo sia nel tuo caso, oppure la stringa è "malformata"] il comportamento è indefinito.

Prova ad usare il metodo .getBytes(Charset charset) : specificando un Charset esplicitamente in caso di problemi con la stringa la sequenza di caratteri malformata viene rimpiazzata con un array di byte di default per il dato Charset (Vedi le API Javadoc a riguardo)

In ogni caso credo che sarebbe meglio usare la versione che prende il Charset esplicitamente definito dal programmatore, perchè il Charset di default (quello utilizzato dal sistema, ci pensa la Jvm a pescarlo) può essere diverso tra diversi sistemi operativi.

E se evitassi di usare stringhe?
Nel senso posso farmi restituire e quindi memorizzare direttamente byte[]?

	private byte[] cryptPassword(final String password) {
		        MessageDigest md=null;
		        try {
		            //we use MD5 Algorithm
		            md = MessageDigest.getInstance("MD5");
		        } catch (NoSuchAlgorithmException ex) {
		            ex.printStackTrace();
		        }
		        md.update(password.getBytes());
		        return md.digest();
     }

Ecco alcuni risultati di criptaggio di varie password:

[B@19821f
[B@addbf1
[B@42e816
[B@9304b1
[B@190d11
[B@a90653
[B@de6ced
Premere un tasto per continuare . . .

Secondo voi così va bene?

[^TiGeRShArK^]

Originariamente inviato da luxorl

E se evitassi di usare stringhe?
Nel senso posso farmi restituire e quindi memorizzare direttamente byte[]?

	private byte[] cryptPassword(final String password) {
		        MessageDigest md=null;
		        try {
		            //we use MD5 Algorithm
		            md = MessageDigest.getInstance("MD5");
		        } catch (NoSuchAlgorithmException ex) {
		            ex.printStackTrace();
		        }
		        md.update(password.getBytes());
		        return md.digest();
     }

Ecco alcuni risultati di criptaggio di varie password:



Secondo voi così va bene?

no, perchè applicando il toString al byte array ti viene restituito il reference dell'oggetto.
Ti conviene fare come suggerito da Banryu utilizzando una charset comune (direi che UTF-8 dovrebbe andar bene così ad occhio).

[luxorl]

Però così ho problemi a livello di Entity Bean.
Perché l'attributo password nell'EntityBean, essendo il campo password del DB MySql un VARCHAR, è una Stringa.

[luxorl]

Originariamente inviato da ^TiGeRShArK^

no, perchè applicando il toString al byte array ti viene restituito il reference dell'oggetto.
Ti conviene fare come suggerito da Banryu utilizzando una charset comune (direi che UTF-8 dovrebbe andar bene così ad occhio).

Ok, testo subito

[banryu79]

Originariamente inviato da ^TiGeRShArK^

Ti conviene fare come suggerito da Banryu utilizzando una charset comune (direi che UTF-8 dovrebbe andar bene così ad occhio).

Incredibile, non ho sparato una cazzata! [w i Javadoc]

[shinya]

Nota a margine: per l'amor di dio non usare MD5. E' rotto. L'algoritmo intendo.

Non va più bene per le password, usa bcrypt o sha-256 (o maggiore). Esistono implementazioni già fatte in java di entrambi gli algoritmi.

E se proprio devi usare MD5 (che è un colabrodo) almeno fai il salt delle password. Fare il 'salt' vuol dire aggiungere un pezzo arbitrario (tipo il nome dell'utente, o una stringa random che poi ti tieni sul db) alla password e criptare quello e non solo la password.

Esempio: invece di fare md5('direttore'), fai md5('utente.' + 'direttore'), oppure md5('$OMG!1PWNAGE!11' + 'direttore') dove la prima stringa è generata casualmente.

[^TiGeRShArK^]

Originariamente inviato da shinya

Nota a margine: per l'amor di dio non usare MD5. E' rotto. L'algoritmo intendo.

Non va più bene per le password, usa bcrypt o sha-256 (o maggiore). Esistono implementazioni già fatte in java di entrambi gli algoritmi.

E se proprio devi usare MD5 (che è un colabrodo) almeno fai il salt delle password. Fare il 'salt' vuol dire aggiungere un pezzo arbitrario (tipo il nome dell'utente, o una stringa random che poi ti tieni sul db) alla password e criptare quello e non solo la password.

Esempio: invece di fare md5('direttore'), fai md5('utente.' + 'direttore'), oppure md5('$OMG!1PWNAGE!11' + 'direttore') dove la prima stringa è generata casualmente.

fico non lo sapevo
io se non ricordo male usavo MD5 + il salt, ma non credevo che MD5 fosse combinato così male

[luxorl]

Ok posso usare un altro algoritmo ma prima vorrei risolvere questo problemino

Niente!
Utilizzando UTF-8 ho lo stesso identico risultato, forse il charset di default è proprio UTF-8? ....comunque il metodo modificato è questo:

  	 private String cryptPassword(final String password) throws UnsupportedEncodingException {
	        MessageDigest md=null;
	        try {
	            //we use MD5 Algorithm
	            md = MessageDigest.getInstance("MD5");
	        } catch (NoSuchAlgorithmException ex) {
	            ex.printStackTrace();
	        }
	        md.update(password.getBytes("UTF-8"));
	        return new String(md.digest());
     }

Giusto no?
Provo ad usare un altro charset? quale?

[luxorl]

Il problema sembra risolto usando UTF-16.
Forse gli 8bit di UTF-8 non erano abbastanza per quei caratteri speciali?
Posso stare sicuro secondo voi che adesso va bene con tutte le password?

[banryu79]

Originariamente inviato da luxorl

Posso stare sicuro secondo voi che adesso va bene con tutte le password?

E chi lo sa? (io no).
Però seguirei i consigli di shynia: abbandona MD5 e fai il "salt" della password.
In questo modo credo tu possa raggiungere una ragionevole sicurezza.

[luxorl]

Originariamente inviato da banryu79

E chi lo sa? (io no).
Però seguirei i consigli di shynia: abbandona MD5 e fai il "salt" della password.
In questo modo credo tu possa raggiungere una ragionevole sicurezza.

Si ok, uso SHA e faccio il salt
Speriamo che non mi rifà lo scherzetto del Charset, qualcuno può darmi maggiore sicurezza da questo punto di vista?

[shinya]

Originariamente inviato da ^TiGeRShArK^

fico non lo sapevo
io se non ricordo male usavo MD5 + il salt, ma non credevo che MD5 fosse combinato così male

C'era un paper di due ricercatori cinesi che facevano vedere (con un metodo che solo un crittografo può capire) come generare dei plaintext con lo stesso md5-sum.

Qui trovi qualche link: http://www.schneier.com/blog/archive...d5_collis.html

Anche sha-1 credo non stia benissimo. Se mi ricordo bene, credo sia stato dimostrato che si possano produrre collisioni ogni 2^69 invece dei soliti 2^80... però non ti fidare, cerca qualche paper che avvalori questa cosa.

[luxorl]

Originariamente inviato da shinya

C'era un paper di due ricercatori cinesi che facevano vedere (con un metodo che solo un crittografo può capire) come generare dei plaintext con lo stesso md5-sum.

Qui trovi qualche link: http://www.schneier.com/blog/archive...d5_collis.html

Anche sha-1 credo non stia benissimo. Se mi ricordo bene, credo sia stato dimostrato che si possano produrre collisioni ogni 2^69 invece dei soliti 2^80... però non ti fidare, cerca qualche paper che avvalori questa cosa.

Vabè è un sistema che dovrà girare intranet nella rete locale del dipartimento di ingegneria informatica.
Non sarà accessibile dall'esterno della LAN e gli utenti registrati non supereranno la dozzina...
Credo che con SHA posso stare sicuro, no?

[shinya]

Originariamente inviato da luxorl

Vabè è un sistema che dovrà girare intranet nella rete locale del dipartimento di ingegneria informatica.
Non sarà accessibile dall'esterno della LAN e gli utenti registrati non supereranno la dozzina...
Credo che con SHA posso stare sicuro, no?

Beh se fai il salt, anche con md5 sei al sicuro se i requisiti dell'applicazione sono quelli. Basta aggiungere il salt, cosi da scoraggiare qualche studentello curioso che ha googlato 'rainbow tables'

Cmq se vuoi stare dalla parte dei bottoni, come si dice da me, dai un'occhiata a questa libreria http://www.softabar.com/home/content/view/46/68/

Ho dato un'occhiata veloce ai javadoc e nella classe ShaUtil c'è un metodo per convertire l'array di byte in esadecimale (sotto forma di stringa). Cosi stai a posto e usi ascii.

[luxorl]

Originariamente inviato da shinya

Beh se fai il salt, anche con md5 sei al sicuro se i requisiti dell'applicazione sono quelli. Basta aggiungere il salt, cosi da scoraggiare qualche studentello curioso che ha googlato 'rainbow tables'

Cmq se vuoi stare dalla parte dei bottoni, come si dice da me, dai un'occhiata a questa libreria http://www.softabar.com/home/content/view/46/68/

Ho dato un'occhiata veloce ai javadoc e nella classe ShaUtil c'è un metodo per convertire l'array di byte in esadecimale (sotto forma di stringa). Cosi stai a posto e usi ascii.

Ti ringrazio. Ho visto il metodo nel javadoc...
Appena posso lo testo e vi faccio sapere.

[luxorl]

sul forum di html.it ho trovato questo

Originariamente inviato da andbin
Volendo formattare l'array di byte secondo il formato tipico di un MD5 e volendo usare le nuove funzionalità di Java 5:

public static String bytesToHexString (byte[] ar)
{
    StringBuilder sb = new StringBuilder (ar.length*2);
    for (byte b : ar)
        sb.append (String.format ("%02X", b));
    return sb.toString ();
}

Ma si possono studiare soluzioni ancora più performanti.

Dovrebbe essere la stessa soluzione che si ottiene usando quella libreria no?

[Angus]

Prova anche a documentarti sulla codifica Base64