Informazioni su password_hash () in PHP e memorizzazione (parte di) sale su DB

1

Quindi, ho imparato che il nuovo in PHP 5.5 è password-hash () che funziona molto come crypt (). Che è più sicuro (più lento) di md5 () o sha1 (). La stringa del risultato è algo + hash + salt, che può essere passata così com'è per password-verify () per verificare la password. Finora ho capito come funziona.

Alcune domande del giorno del giudizio che rimangono:

Q1) Qual è il nome del formato / protocollo / convenzione risultato?

Q2) Quello che non ottengo comunque è che tutto il sale è incluso nel database. Se un badguy® dove ottenere questi, ha tutti le parti del puzzle. In passato, ho imparato a mettere (in parte) il sale al di fuori del database: in origine, persino di basarlo su valori ram / system / hardware quindi non è nemmeno su disco. Perché questo non è facilitato, o come dovrei? Ovviamente potrei fare un doppio hash con un sale diverso, o c'è un modo migliore?

Q3) Inoltre, nella mentalità apocalittica che richiede la sicurezza, credo che il single-point of failure password_hash () sarà un target di alto valore e potrebbe facilitare gli attacchi MITM in modo più semplice rispetto alla più criptata self-contained ( ). Immagino che scrivere un algo "cattivo" e impostarlo come PASSWORD_DEFAULT sarebbe più semplice che alterare crypt (). Non ho ancora esaminato il codice / i moduli di back-end di PHP, solo speculando.

Considerazioni benvenute. La risposta accettata sarà quella che ottiene il massimo voto / censimento per le domande 2/3 entro una settimana al massimo, e ha la domanda 1 verificabile corretta.

    
posta Barry Staes 04.02.2014 - 09:12
fonte

1 risposta

6

What is the name of the result format/protocol/convention?

password_hash() utilizza l'algoritmo bcrypt .

PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).

Fonte: link

Q2) What i dont get however, is that all of the salt is included in the database. If a badguy® where to obtain these, he has all the puzzle parts. In the past, i learned to put (part of) the salt outside of the database: in source, of even base it on ram/system/hardware values so its not even on disk. Why is this not facilitated, or how should i? Ofcourse i could do a double hash with a different salt, or is there a better way?

L'unico requisito per un sale è che sia globalmente unico. Non deve essere tenuto segreto. password_hash() si prende cura di te per te. Non fare niente di stravagante e stupido. Vedi: Come conservare il sale?

Q3) Also -in the doomsday mindset that security requires- i believe the single-point of failure password_hash() is going to be a high value target, and might facilitate MITM attacks way easier than the more self-contained crypt(). I imagine writing a "bad" algo and setting it as the PASSWORD_DEFAULT algo would be easier than altering crypt(). I have not looked into the PHP backend code/modules however, just speculating.

Che cosa? MITM ha letteralmente NOTHING a che fare con questo. L'hashing dovrebbe essere fatto sul server. Se un utente malintenzionato può modificare i file sul tuo server, può già fare ciò che vuole.

    
risposta data 04.02.2014 - 09:19
fonte

Leggi altre domande sui tag