Non sei loggato | Register | Login

Memorizzare password in un db in modo sicuro Aggiungi

News / Codice

Benvenuto! Se sei un nuovo visitatore ti consiglio di iscriverti al mio Feed RSS in modo da essere sempre aggiornato riguardo l'uscita di nuovi articoli oppure sbirciare tra i tutorials ed i progetti.
Per avere un'idea del best-content presente in questo blog puoi leggere il post intitolato "Ed ora è il momento di rilanciare alcune iniziative! (1a parte e 2a parte)".
Buona navigazione e grazie per la visita!

Molto spesso si incontra la necessità di dover registrare le credenziali dell'utente in un qualsiasi database.
Il dato più delicato a cui prestare attenzione è la password: molto spesso viene memorizzata nel database in chiaro oppure per chi ci tiene alla sicurezza ne viene calcolato l'hash in md5 (e quindi criptato).
Molto spesso quest'ultima soluzione viene considerata la migliore: ed è vero, ma manca un piccolo particolare!
L'md5 essendo per definizione un algoritmo di crittografia univoco a senso unico rende "impossibile" (anzi per essere precisi, molto laborioso e poco conveniente visto che la matematica che si interessa di scomposizione in numeri primi di grandi numeri non ha trovato ancora alcun algoritmo adatto allo scopo) trasformare l'hash nella password originaria.
L'unico sistema per fare ciò è il matching degli hash, ossia ottenere la password tramite il semplice confronto tra hash (è il sistema che ci mette a disposizione rednoize) ma ciò richiede l'esistenza di un database corposo di hashes (rainbow tables).
L'hash della parola test è 098f6bcd4621d373cade4e832627b4f6 di cui è facile fare il lookup utilizzando il sito citato sopra, da ciò si capisce come la sicurezza è si legata all'algoritmo di crittografia ma anche alla qualità della password (lunghezza, ecc...).
Per risolvere questo problemino si utilizza solitamente la tecnica del salting che consiste nel concatenare alla password in chiaro una stringa random o "prestabilita" in modo da rendere impossibile il confronto tra hashes, ecco un piccolo esempio in PHP:

Visualizza il codice PHP
  1. <?php
  2.  
  3. /* Definiamo il SALT */
  4. define('SALT', 'yuppydoo');
  5.  
  6. /* Crittografia password */
  7. $password_criptata=md5(SALT.$_POST['password']);
  8.  
  9. ?>

Naturalmente nel momento in cui dobbiamo identificare l'utente dobbiamo tenere conto di questa soluzione e quindi fare una cosa simile a:

Visualizza il codice PHP
  1. <?php
  2.  
  3. if (md5(SALT.$_POST['password'])==$password_criptata) {
  4.     /* Loggato */
  5. } else {
  6.     /* Non Loggato  */
  7. }
  8.  
  9. ?>

Ora l'utilizzo di una rainbow table risulta essere inefficace :)

Daniele Simonin 29 September 2006 alle 11:04 Trackback URI

Scrivi un commento

Tags di formattazione:








Leggi i 6 commenti

bella snake
se leggi i miei post in materia su warp, sai che non conosco molto l'ambiente php/mysql e sono a zero in tema di sicurezza.

ma volevo porti sto quesito.
il sistema da te citato, previene che un malintenzionato che riesce ad accedere al db riesca a recuperare le password, perchè diciamo che parte della password sta direttamente nel php. giusto?

questo presume il fatto che sia più difficile recuperare le pagine php da cui recuperare il salt, rispetto a crackare il db. mi confermi che è così?

bella! :D

Commento di kitch 2 October 2006 alle 16:25

La maggiore sicurezza è dovuta al fatto che ad esempio mentre è facile trovare nelle rainbow tables l'hash della parola "test", risulta invece molto difficile trovare l'hash della parola composta da "yuppydootest" ossia del SALT+Password (è proprio l'esempio PHP che ho citato nel post).
Non necessariamente il malintenzionato, per recuperare una password criptata, deve accedere al db perchè è ormai abitudine salvare su un cookie l'accoppiata nickname+md5(Password) potendo riconoscere l'utente ad ogni visita successiva.

Poi naturalmente la sicurezza al 100% non esiste... ;)

Bella kitch!

Commento di Daniele Simonin 2 October 2006 alle 17:17

uè rieccomi
credo di aver capito il senso generale, anche se mi rimane il dubbio che se un malintenzionato si mette a fare un brute force attack, non ci mette molto a trovare il salt... o sbaglio?

riguardo il cookie, c'è poco da fa in quel caso, si sa!
bella!

Commento di kitch 12 October 2006 alle 15:18

il brute force richiede moltissimo tempo...dovrebbe calcolare l'hash di ogni parola possibile :) con il SALT poi si allunga la password quindi la percentuale di successo si riduce notevolmente (oltre a rendere inutilizzabili le rainbow tables).

Commento di Daniele Simonin 12 October 2006 alle 16:01

Domanda:

"Per risolvere questo problemino si utilizza solitamente la tecnica del salting che consiste nel concatenare alla password in chiaro una stringa random o prestabilita"

Se genero una stringa random devo anche salvarla nel db assieme alla psw criptata, giusto?

Molto interessante! Grazie della dritta.

Ciao

Commento di Max 7 November 2008 alle 23:46

Si, oppure in un file di configurazione dell'applicazione che stai creando.

Commento di Daniele Simonin 8 November 2008 alle 10:37

Feed

infoPillole (by Wikipedia)

Ultimi commenti

  • byman: Ho trovato molto utile questa raccolta di...
  • Flavio: bella questa!
  • Beta: Thank you.Beautiful CSS form“
  • Daniele Simonin: Per guadagnare molti usano questa...
  • Luca: Per guadagnare bisogna lavorare, io ho raccolto un...

Calendario

September 2010
M T W T F S S
« Aug    
 12345
6789101112
13141516171819
20212223242526
27282930  

Archivio

Categorie

News casuali

Ultimi tutorials

Progetti

Alcuni miei lettori