Link di conferma registrazione email hashing non

uniqid() non crea un hash crittograficamente sicuro, e l'invio di dati sensibili su canali in chiaro come email o http significa che chiunque li può leggere in un mezzo intermedio.

Questo è un problema? No, non proprio (con l'eccezione indicata nell'ultimo paragrafo).

Le informazioni che invii sono costituite dall'indirizzo email dell'utente e da una chiave di conferma. Questo è anche ciò che è memorizzato nel database. Non c'è modo di inviare un'e-mail senza rivelare l'indirizzo e-mail del destinatario, quindi trasmettere questo indirizzo in testo semplice come parte di un URL non è un problema. Se sta accadendo qualche Grande Male, allora è già successo.

Ora che dire del tasto di conferma?

Si potrebbero distribuire numeri interi consecutivi come chiavi di conferma (in realtà uniqid() non è molto lontano da quello!), e non avrebbe importanza. Una persona malintenzionata potrebbe intercettare la chiave di un'altra persona o potrebbe banalmente generare la propria, ma nessuno dei due permetterà loro di registrare un account falso, poiché la query del database cerca la coppia < username, confirm_key & gt ;. Una chiave di conferma rubata o casuale / falsa / calcolata quindi non funziona con un altro nome utente (casuale), non ha valore per un utente malintenzionato.

L'unico attacco che è ragionevolmente plausibile è che qualcuno possa intercettare la tua e-mail e confermare il tuo account legittimo con l'indirizzo email e la chiave di conferma corretti prima di poterlo fare.
Questo è davvero un problema se il tuo sistema è progettato in modo tale che la conferma di un account utente ti registri automaticamente anche nella tua prima sessione (alcuni siti fanno proprio questo!).

L'unico problema è che stai perdendo informazioni, in questo caso, l'indirizzo email dell'utente. Dal momento che è in chiaro nella querystring, verrà memorizzato da qualsiasi registrazione che si verifica ovunque tra il client e il server, potenzialmente nei segnalibri se l'utente aggiunge la pagina, se l'URL è copiato e memorizzato o inviato a chiunque, ecc.

Aggiungerò inoltre che qualsiasi cosa tu faccia sarà vulnerabile allo sniffing, dal momento che stai usando HTTP piuttosto che HTTPS.

uniqid() non deve essere utilizzato per scopi correlati alla sicurezza:

This function does not create random nor unpredictable strings. This function must not be used for security purposes. Use a cryptographically secure random function/generator and cryptographically secure hash functions to create unpredictable secure IDs.

Inoltre, dovresti rendere il tuo link un HTTPS anziché un semplice HTTP per proteggerti da MITM attacca e impedisce la memorizzazione nella cache da parte dei server proxy.

Potrebbe essere meglio inviare confirm_key solo come link inviato via email, quindi chiedere all'utente di accedere per associare l'indirizzo email all'account. Ciò confermerà che solo l'utente registrato sta effettuando l'accesso per confermare l'account piuttosto che chiunque altro possa accedere al link di registrazione.