Oggetto: Criptare le password - md5 non basta
Postato il 20/01/2010 18.15.40. Letto 1685 volte.

Apro questo topic perché ci tengo ad informare i "colleghi" responsabili dei vari gdr online che la tanto pubblicizzata funzione md5 non è sufficiente, con la sua criptazione, a metterci al riparo da malintenzionati.
Md5 è un algoritmo, per dirla breve, che converte una qualunque stringa di testo (la password) in 32 caratteri esadecimali.
Teoricamente viene detto che è molto raro che si possa risalire alla password originale, rubando questo codice criptato, perchè il numero di tentativi necessari sarebbe troppo alto (nell´ordine dei milioni).
Quando un utente fa il login la pagina invia il codice criptato invece della password "così com´è" e la confronta con la password memorizzata nel database che appunto dev´essere registrata in forma criptata.

Ma se tramite uno sniffer un malintenzionato al momento del login di un tizio gli "intercetta" la password criptata può comunque utilizzare il dato per loggarsi al posto del malcapitato.
O, riuscendo ad ottenere una password criptata, tramite progetti e programmi facilmente reperibili sul web come raimbow project è probabile che il malintenzionato riesca addirittura a risalire dalla criptazione md5 alla parola originaria.

Come ci possiamo difendere ulteriormente allora?

Io ho avuto un´idea possibile. ALtri più titolati di me in fatto di programmazione sicuramente potranno illustrare metodi meno grezzi, ma ritengo che già la mia idea fornisca una relativa sicurezza.

Tramite javascript, al momento del login dell´utente, si può far generare dal server una parola casuale che fungerà da chiave di criptazione con cui verrà ulteriormente criptata la stringa già codificata con md5.
Ciò che verrà inviato dalla nostra pagina sarà quindi una password criptata con md5, ulteriormente criptata con una chiave casuale e temporanea, che il server confronterà con la password md5-coded registrata nel database ed ulteriormente criptata con la chiave casuale e temporanea.

Se un malintenzionato la "sniffa" e invia questa combinazione di password+coding md5+criptazione casuale essa non sarà più valida in quanto la chiave casuale ogni volta è diversa.
E se anche riuscisse a rubare dal nostro database una password criptata con md5, essa sarebbe molto spesso inutile in quanto è infruttuoso saltare fraduolentemente il consueto form di login, visto che è l´unico metodo perchè avvenga il doppio coding (md5 e chiave casuale).

Ed anche la velocità di login non ne risente, in quanto md5 è un hashing ultrarapido appositamente studiato per gli accessi via password. E la chiave casuale garantisce un´ottima sicurezza anche se scegliamo sia costituita da soli 4 caratteri alfanumerici.

Il Gioco di Ruolo Fantasy

[LINK ]

"Chi segue le orme altrui non giunge mai primo"

20/01/2010 18.38.20

L´MD5 si cracca in poco tempo con questo programmino [LINK ] (o altri programmi simili), ed una scheda video moderna (non serve nemmeno una tanto potente o costosa per farlo). SHA-1 ci mette più tempo, ma anche quello è facilmente bucabile.

Per proteggere i dati è molto meglio puntare a SHA-256, SHA-512 o altri algoritmi che sono almeno sopra i 256bit (meglio se sopra i 512bit) o che comunque risultano essere molto sicuri anche se con pochi bit. Implementazioni per Javascript oltre ai soliti MD5 e SHA-1 non ne conosco, ma probabilmente si trovano.

Se si vuole davvero proteggere il proprio sito fin dal login però è molto meglio puntare alla protezione SSL tramite certificati e crittografia RSA. E´ una soluzione che può essere più o meno costosa a seconda del certificato che si desidera, ma ne vale sicuramente la pena e protegge tutti i dati ricevuti ed inviati dal server (non solo la password al login).

20/01/2010 20.24.07

oorazoroo ha scritto:
Implementazioni per Javascript oltre ai soliti MD5 e SHA-1 non ne conosco, ma probabilmente si trovano.

JSsha [LINK ] prevede l´implementazione degli hash fino a 512 bit, per cui è possibile sfruttarla per secure login da sniffing anche con simili algoritmi.

Per quel che concerne i gdr-online direi che è la soluzione piu´ pratica e avvicinabile, sempre se non si ha un capitale da spendere in SSL e RSA

Messaggio modificato il 20/01/2010 20.25.14 da blancks

20/01/2010 21.39.49

Ah vincè!
[LINK ]

Tempo fa programmai questa cosa, mi sembra che la pensai alla tua stessa maniera :)
Buttaci un occhio, lì è fatto con sha256 (mi pare). Tutta un´altra cosa rispetto ad md5.

Se darkside non va alla montagna...
Darkside va al mare.

[LINK ]

21/01/2010 10.39.09

21/01/2010 12.38.22

I certificati SSL in se non hanno un costo così elevato, e possono anche essere creati gratuitamente se si hanno gli strumenti adatti (noi come azienda usiamo gli strumenti per certificati integrati in Windows Small Business Server 2003 per creare certificati di protezione per le connessioni aziendali, e code-signing per i programmi).

Se si vogliono certificati che funzionano immediatamente e sono rilasciati da delle CA (Certificate Authorities) conosciute e di cui ci si può fidare, ci si può rivolgere a VeriSign per esempio, ma anche GoDaddy offre certificati SSL a prezzi molto inferiori. Per esempio come si vede qui [LINK ] un certificato per il proprio dominio (non sottodominio), per un anno costa 20€ circa (praticamente come un servizio di hosting o anche meno). Alcuni servizi di hosting a seconda del piano offrono pure la creazione di certificati compresa nel prezzo!

Per quanto riguarda la creazione in proprio, i certificati possono essere resi estremamente sicuri esattamente come quelli commerciali. L´unica differenza è che l´utente (se non correttamente informato) potrebbe fidarsi degli avvisi del browser secondo cui la CA del certificato non è riconosciuta e potrebbe essere pericolosa. Ma superato questo ostacolo tutto il resto funziona alla perfezione, e si possono ottenere livelli di protezione superiori a quelli comunemente offerti a livello commerciale, oltre che poter decidere sulle scadenze o sulle revoche dei certificati.

In ogni caso, una volta che il certificato è stato installato nel computer locale (dopo aver accettato di scaricarlo ed installarlo dal prompt del browser, o automaticamente se è considerato attendibile), le comunicazioni con quel sito sono sicure sia con soluzioni commerciali che non, e non c´è bisogno di implementare altri sistemi di protezione o di criptare manualmente tutte le comunicazioni.

21/01/2010 20.54.32

27/01/2010 14.36.36

29/01/2010 23.18.40

kinley ha scritto: ma perchè i gdr online necessitano di tutta questa sicurezza ?

nessuna transazione finanziaria
nessun dato sensibile se non l´indirizzo email (che uno potrebbe creare solo poi per il gioco)

e allora perchè usare tutta questa sicurezza ?

solo per evitare che uno entrando "sputtani" la reputazione di un pg ?
forse per questo motivo è un pò troppa questa siscurezza di cui si parla.

oppure per evitare che qualcuno entri come admin o master e scombini cose o gioco?

dove per questo basta fare un generatore casuale di password che viene invata via email giornalmente ad admin e master e che dura quindi un dì.

Per esperienza personale, posso garantirti che c´è gente (ed è tanta) che usa la password per i GDR anche per il conto in banca, per facebook, per la posta, per xyzblabla..ciò comporta che, per venire incontro alla "pirlaggine" dell´utente, ci debba essere un´entità, il programmatore, che metta una pezza :).
Detto questo, sono assolutamente convinto che andare oltre lo SHA-256 sia assolutamente inutile e, per ovviare alle rainbow table, basta il salt casuale pseudogenerato (o il salt generato pseudocasualmente :))..

Il Regno di Nimenia
[LINK ]