Aggiungo alla chiarissima spiegazione un'osservazione tecnica per amor di discussione (è una divagazione tecnica OT rispetto all'argomento principale) su una questione tecnicamente molto interessante: la probabilità delle "collisioni" c'è, ma è bassissima e solitamente non incide sulla sicurezza (moltissimi sistemi registrano le password usando codifiche hash e basta): volendo creare una codifica univoca si può benissimo usare hash+id_unico, ma se si vuole incrementare di un ordine (tradotto non dal gergo: sensibilmente) la sicurezza questo risultato andrebbe criptato.

Supponiamo che un attacco voglia "forzare" un codice legato all'account "esempio@example.com":
- se il sistema si basa su una codifica hash in funzione dell'account la sicurezza è legata alla codifica hash stessa
- se aggiungiamo un id univoco l'ordine di grandezza è analaogo al precedente: basta "attaccare" il sistema ciclando sugli id (*: la sicurezza è maggiore, ma non sensibilmente, ossia tale da giustificare - in generale, poi ci sono i casi specifici - una procedura dedicata)


Criptando la chiave hash+id otteniamo invece un'ottima soluzione che incrementa effettivamente il grado di sicurezza.



(*) attenzione: "ordine di grandezza" nella sicurezza significa che se ci vuole T1 tempo per forza il primo sistema e N*T1=T2 per il secondo, l'ordine è lo stesso (un fattore lineare). Inoltre per conoscere l'id è sufficiente fare un'ordine vero oggi e domani (ottenendo i valori n1 ed n2) e possiamo limitare N a pochi valori (avendo idea di quanti ordini si fanno in un giorno e degli ultimi valori raggiunti).