Ricordo che l'unica funzione del salt e' di evitare che sia possibile "decifrare" gli hash confrontandoli con un elenco precalcolato (ranibow table).
Ricordo che l'unica funzione del salt e' di evitare che sia possibile "decifrare" gli hash confrontandoli con un elenco precalcolato (ranibow table).
Per questo io parlavo di connessione cifrata, in quel caso non si becca neanche l'hash della password.Originariamente inviata da k.b
Si ma fioj, senza htts, ci sarà un sistema, o no? E se si, quello indicato da Santino è ok? Penso di si...
Se ci fosse non avrebbero inventato HTTPS.
Non parlo di Fort Knox, anche se Goldfinger c'era quasi riuscito, parlo di una sicurezza base...
Che vuol dire "sicurezza base"? Cosa vuoi proteggere?
Se vuoi evitare che qualcuno faccia il login a nome di un altro, la soluzione di salvare la password criptata nel db non ha alcun valore, perché come ti ho già detto ad uno che vuole fare ciò non gliene importa niente di come hai salvato la password nel db, a lui interessa come sia quella in chiaro, è quella che deve scrivere nel modulo di login.
Salvare la password criptata e lasciare la connessione dati in chiaro ha il solo scopo di non far leggere a chi gestisce il sito le password degli utenti, un modo per dar loro fiducia, per dirgli "registratevi pure, le vostre password io non le verrò a sapere", questo perché molti usano la stessa password per tutti o quasi i propri account e se tu potessi leggere le loro password sul tuo sito, potresti provare ad accedere ai loro account anche su altri servizi usando tali password.
Se vuoi essere abbastanza sicuro che nessuno possa accedere agli account dei tuoi utenti non avendone diritto, devi usare una connessione cifrata.
Beh in realta' nella maggior parte dei casi dei siti "normali" e' piu' che sufficiente quanto segue:
- il server registra la password come hash (magari usando bcrypt invece degli altri algoritmi) con un salt
- l'utente invia user e pass in chiaro al server, il server calcola l'hash con salt e lo controlla con quello registrato nel db
in questo modo risolvi il problema per cui qualcuno in possesso dei dati contenuti nel db possa ricavare le password da una rainbow table (grazie all'hash) e rendi virtualmente impossibile il brute force (grazie a bcrypt con un workfactor che rallenti l'algoritmo). Se poi ci puoi/vuoi mettere SSL tanto meglio, ma gia' cosi' sei abbastanza a posto.
Alla fine dipende tutto da cosa si ha in mente di voler proteggere, se vuoi solo non far conoscere la password a uno che dovesse accedere al db ok, ma se vuoi che un malintenzionato non faccia il login con l'account di un altro, senza usare SSL la vedo dura stare sicuri.
Beh non e' che sniffare il traffico rete per intercettare le password sia una cosa cosi' immediata
Grazie k.b, era questa la sicurezza di base che intendevo, perché presumo che il sistema da te descritto metta al riparo legalmente da tentativi di violazione.
Permessi di invio
Rispondi quotando