2009-09-08 12 views
13

Attualmente uso,
base64_encode() per codificare la password di un utente, questo funziona bene perché mi permette di usare semplicemente base64decode() per decodificare la password per una parola e inviare a lì e-mail se perdono lì la password.modo migliore di codificare le password in PHP

Ho letto la password e molte persone sembrano dire che è necessario utilizzare sha1() per codificare una password. Io sono tutto per migliorare la sicurezza del mio sistema, ma se mi converto per usare shal() allora non sarò in grado di inviare un utente lì perso la password.

Cosa usi? Puoi darmi qualche consiglio? E c'è un modo per decodificare una password leggibile per inviare un'email a un utente?

Mentre scrivevo questa domanda ho appena ricordato che alcuni forum non ti inviano una password quando richiesto ma invece inviano un link speciale per reimpostare la tua password, suppongo che questo sia dovuto al fatto che non sono in grado di decodificare la tua password può essere?

//what I use now 
$password_encoded = base64_encode($password); 

//what I am considering using 
$password_encoded = sha1($password); 
+4

Vedendo domande come queste mi fa davvero non voler mai creare un login utente su qualsiasi sito per paura della loro terribile sicurezza, come l'archiviazione reversibile delle password. – umassthrower

risposta

41

favore, per favore per il bene dei vostri utenti non conservare le proprie password in qualsiasi formato reversibili! Non importa se è codificato Base64 o triple-DES 168-bit encryption - se è reversibile, è esattamente sicuro come se non lo avessi codificato in tutti.

No il sito web che ha qualche interesse a proteggere se stesso o i suoi utenti (o ha una lusinga di senso) invierà a un utente la sua password via e-mail. L'unica cosa che possiamo fare è anche lontanamente vicino alla sicurezza è inviare agli utenti un'email con un unico link monouso che consente loro di impostare una nuova password.

  • Conservare un hash (o bcryptPBKDF2) della password che è stata salted
  • gettare via la password originale non appena hai hash esso. Asportalo dalla memoria.
  • richiedono sempre all'utente di creare il proprio nuova password su un canale SSL

Cercando di ottenere vicino con tutto il resto è onestamente negligenza. Usiamo uno scenario molto comune utilizzato nelle discussioni sulla sicurezza:

L'email di Frederic è compromessa. Questo potrebbe essere dal lasciare il suo computer sbloccato o utilizzando una password debole. Indipendentemente da ciò, una persona non autorizzata ha accesso ai suoi messaggi. Idealmente, ciò significherebbe nient'altro che alcune imbarazzanti lettere d'amore lette da uno sconosciuto. Sfortunatamente, la persona non autorizzata scopre che un forum invierà per e-mail la password di Frederic in testo semplice. Come la maggior parte degli utenti, Frederic usa la stessa password per tutto, incluso il suo banking online. Il suo nome utente è elencato in un'e-mail dalla sua banca. Ora la situazione è molto sfortunata.

Gli utenti si fidano di te quando creano una relazione basata sulle credenziali con te. Parte di questa fiducia è che manterrai quelle credenziali come un segreto sicuro tra te e loro.

correlati

Un sacco di questioni che circondano e le idee sono state esaudite molto bene su SO:

+0

@ anonimo - Perché il DV? –

+0

Falso: "esattamente sicuro come se non lo avessi codificato" –

+6

@ d03boy security by obscurity è lo stesso di nessuna sicurezza. In un sistema autonomo come un sito Web, devono necessariamente essere presenti tutte le parti necessarie per invertire i dati, non importa quanto offuscati. Quindi, se un utente malintenzionato ottiene l'accesso al sistema, l'utente malintenzionato ha accesso a tutte le parti. –

6

È necessario consentire a un utente di RESETTARE una password ma non RECETTUARE la password. Questo è il motivo per cui vorresti usare un hash unidirezionale (SHA2) invece di una forma di crittografia che ti consenta di decodificarlo.

Immagina se hai lasciato la tua email aperta. Potrei semplicemente chiedere di recuperare la tua password per qualche sito web, cancellare l'e-mail e non lo sapresti mai. D'altra parte, se mi richiedeste di reimpostare la password, la password dell'account cambierebbe e il proprietario si renderebbe conto che qualcosa non andava. (Questo è uno scenario stupido ma il concetto è l'importante)

Gli hash possono essere "invertiti" provando tutte le possibili combinazioni di parole (o utilizzando le tabelle arcobaleno) finché non viene prodotto un hash corrispondente. Un modo per evitare ciò è aggiungere/anteporre la password fornita a salt per renderla una stringa molto lunga e imprevedibile. Il sale dovrebbe essere una stringa univoca di dati univoci per l'account della persona.

In PHP non è presente la funzione SHA2. SHA-2 è una famiglia di algoritmi di hash, (SHA-256, SHA-384, SHA-512, ecc ...)

hash('sha256', 'The quick brown fox jumped over the lazy dog.'); 
+0

Sto cercando di trovare sha2, non sembra essere sul mio php – JasonDavis

+0

Aggiornato con sha-2 info –

10

In qualità di amministratore, non hai mai veramente bisogno di ricordare la password di un utente. Devi semplicemente sapere se una stringa che hanno inviato una volta, è identica a un'altra.

Se un utente dimentica la propria password, non è necessario che gli venga comunicata la propria vecchia password, è sufficiente farli fornire uno nuovo.

Dato che non è necessario conoscere le password effettive, l'uso di un crytographic hash delle parole sembrerebbe un modo sicuro per memorizzarle. Tuttavia, sono state create ampie tabelle di stringhe pre-calcolate per eseguire facilmente una ricerca inversa dell'hash indietro rispetto alla stringa originale. Questi sono chiamati rainbow tables.

Per evitare la ricerca semplice della stringa pre-calcolata, è necessario salt le password prima di eseguirne l'hashing. Salt può essere il loro nome utente anteposto, o il loro ID utente postfisso, qualsiasi informazione aggiuntiva che hai sull'utente che sia permanente che puoi facilmente aggiungere alla password durante l'autenticazione.

+0

Vedo così se dovessi prendere un utente inviato la password e aggiungere lì il numero utente che non cambia mai la password, quindi crittografare quella stringa, che sarebbe una password salata? – JasonDavis

+3

hash @jasondavis, non crittografare –

4

Base64Encode offerta no sicurezza, perché chiunque può invertire facilmente.

Se si assolutamente è necessario invertire la password, un buon metodo è utilizzare una domanda segreta e utilizzare la risposta come chiave di crittografia. Una volta che la password è stata crittografata, si butta via la risposta (non la si memorizza). Inoltre, si utilizza la crittografia standard sha1 per il momento in cui è necessario verificare che inserisca la password corretta. Se l'utente desidera la sua password, inserisce la risposta alla sua domanda segreta e la usa per ripristinare la password e inviarla a lui.

Non è sicuro come solo la crittografia basata su hash, ma se è necessario restituire la password è un buon compromesso.

Si consiglia di guardare in biblioteca mcrypt per PHP http://ca3.php.net/mcrypt

1

ho sempre cancellare il mio account solo altri siti che mi e-mail la password. Ho messo troppa fatica e tempo a memorizzare password lunghe e casuali per farmi mandare in chiaro.

Utilizzare l'hash non reversibile sha1() o superiore per identificare la password. Quando si autentica una password utente, recuperare l'hash e confrontarlo con l'hash della password fornita durante l'autenticazione. Se corrispondono, l'utente è autentico secondo standard ragionevoli.

$user = "joe"; 
$password = 'password'; 

$saved_hash = DB::Query("select hash from users where username = ".quote($user)." LIMIT 1"); 

if (sha256($password) == $saved_hash) User::authenticated(); 

Mai e poi mai inviare password in posta elettronica. Invia un non prevedibile, chiave univoca, generato, come ad esempio in PHP:

$key = sha256(time().rand().$secret_seed); 

Invia questa chiave al cliente, per un uso di volta, per impostare una nuova password.

+3

Ha dovuto DV per la scarsa dimostrazione di SQL –

+0

Che cosa è povero di SQL? – bucabay

5

Un must assoluto su questo argomento è lo You're Probably Storing Passwords Incorrectly di Jeff. Ecco il sommario esecutivo:

  1. Non inventare il proprio schema di archiviazione delle password "intelligente".
  2. Non memorizzare mai le password come testo normale.
  3. Aggiungi un salt casuale unico per ogni password memorizzata.
  4. Utilizzare un hash crittograficamente sicuro.
0

Si vuole utilizzare un hash (preferibilmente SHA1) con "sale"

+1

Penso che, ancor più preferibilmente, tu voglia SHA2 –

+1

Nonostante il fatto che SHA1 abbia un difetto matematico che può risultare in una più facile ricerca di collisioni, incluso un sale preverrà tale evenienza. Langauges come PHP non supportano SHA2 nella libreria standard, quindi SHA1 è un'alternativa molto adatta. –

0

Si può fare lo hashing sul server per l'autenticazione in una query rapida:

SELECT * FROM user WHERE password = MD5(CONCAT(?, salt)); 
+0

Questo è un terribile schema di hashing debole. Le password non dovrebbero essere sottoposte a hash con MD5, perché questo algoritmo è troppo veloce e la forzatura bruta è troppo semplice. – martinstoeckli

Problemi correlati