Devo nascondere le password prima dell'hashing? Devo pre-cancellarli sul client? E i sali?

Q1: "offuscando" la password non ti compra nulla qui, in termini di sicurezza; rende solo il codice più complesso, che è una cattiva idea.

Q1a: l'hash della password è "equivalente alla password": presentarlo è sufficiente per essere autenticato. Quindi l'hashing non cambia nulla alla sicurezza: equivale a scambiare la password in chiaro. Per sicurezza, davvero vuoi usare SSL - non avrai molta sicurezza senza di esso. In realtà puoi dimenticare tutto su crypt() e Blowfish e il conteggio delle iterazioni "15" finché non hai abilitato SSL: la mancanza di SSL è un problema di sicurezza molto più ampio. crypt() con Blowfish è molto buono, ma usarlo senza un trasferimento protetto da password SSL è come mettere un lucchetto d'acciaio su un lembo della tenda.

Q2: il punto di sale deve essere univoco per istanza di password; un sale casuale abbastanza grande garantisce tale unicità "probabilisticamente". Così cambi il sale ogni volta che crei e modifichi una password (ad esempio quando aggiungi un nuovo account utente o quando un utente cambia la sua password). Non è necessario aggiornare nuovamente una password che non cambia.

Q1: Supponendo che lo stai facendo in modo "convenzionale":

• un utente finale compila un modulo HTML,
• che viene pubblicato su HTTPS,
• la risposta passa su HTTPS sul tuo server webapp,
• che è collegato al server del database su una rete affidabile (ad esempio, sia server webapp che server database sono sistemi sicuri su una LAN sicura)

allora no, non offuscare la password prima che arrivi al tuo codice webapp (PHP) nel modulo submit.

Ma - stai pensando di usare PHP crypt (), che ti offre diversi modi per metterti nei guai, f.x. usando MD5. Perché non utilizzare una libreria di livello superiore ottimizzata per l'archiviazione sicura delle password? Non sono un programmatore PHP, ma PHPass sembra una scelta comune, utilizzata da fx Wordpress. Altrimenti guarda Stack Overflow per "PHP bcrypt" o "PHP scrypt".

Q1a: non c'è sicurezza qui se non stai usando HTTPS. La tua analogia con la "tenda flap" è azzeccata, non fermerai nemmeno i bambini con i flintstones ... In pratica, non farlo. E se lo fai, lascia perdere le idee sull'hashing sul lato client "per sicurezza". Passa a un webhost che offre HTTPS.

Q2: crei un nuovo salt se / quando l'utente finale cambia la sua password. Non cambiare mai altrimenti, il sale è necessario ogni volta che verifichi una password utente (ad esempio ogni volta che un utente accede), quindi con un sale sbagliato, gli utenti non possono accedere.

Q1: In teoria non è necessario confondere ulteriormente la password, a parte l'aggiunta di un sale prima dell'hashing. Ciò aumenterà la complessità, non il valore di sicurezza.

Q1.a: L'hashing della password prima di inviarlo attraverso il filo impedirà solo a un intercettatore di leggere la password stessa. Non proteggerà dal replay dell'hash e dall'accesso come tale utente. La connessione dovrebbe davvero essere su SSL.

1) no. L'Obfiscation è più che gli amministratori non possono dire quale sia la password

1a) Lasciami stare chiaro: devi sempre, sempre, usare sempre SSL.

Una domanda migliore è; quello ha la stessa risposta è; Diciamo che hai una connessione SSL su un provider di terze parti a causa delle disposizioni del tuo contratto con loro, ma non vuoi correre il rischio che stiano annusando le informazioni degli utenti (password, qualsiasi cosa sia veramente). e fuori dall'onore degli esploratori, non ti fidi di loro. Oltre a questo, puoi usare un canarino nel campo di input per assicurarti che sia l'utente a cui hai inviato i dati.

Risposta: puoi fare crittografia a chiave pubblica sul lato JS prima di inviare i dati. Questa NON ha la stessa sicurezza di SSL, ma offre un altro livello di sicurezza che può essere utilizzato.

Sono stato in quella situazione, dove il partner aveva i certificati SSL, e potevo annusare i nostri dati, e abbiamo usato un sistema del genere.