Casuale password vs null password?

Importa gli hash delle password esistenti insieme al resto dei dati, aggiungi un flag 'dirty bit' al nuovo database e impostalo su true per questi utenti importati.

Quando l'utente accede al login, convalida utilizzando il meccanismo hash utilizzato nell'app / codice legacy, quindi obbliga l'utente ad aggiornare la propria password usando qualunque sia il metodo corrente, memorizza il nuovo hash e spegne bandiera.

Un po 'di lavoro in più sul back-end, ma se si impiega il tempo necessario per impostarlo correttamente, rende più agevoli gli eventuali futuri switch e rende la transizione più facile all'utente finale.

Modifica: Inoltre, si evita il pasticcio potenziale (letto come sicuro) che imposta la password di un utente su NULL o vuota. Come si suppone che qualcuno verifichi che l'utente finale sia l'utente 'effettivo'?

La domanda qui è, come la logica di login interpreta un valore non definito al posto di un hash della password. Immagino tu intenda NULL nel senso SQL, come un valore indefinito.

Se il sistema confronta l'hash della password inserita dall'utente con l'hash memorizzato, come dovrebbe, allora un valore non definito (o anche una stringa vuota) non corrisponderebbe mai. Allo stesso modo, l'hash memorizzato potrebbe essere impostato su un'altra stringa che non corrisponderà mai come un hash di password valido. Sui sistemi Linux, puoi vedere gli account di sistema in /etc/shadow con * al posto dell'hash della password, e il blocco di un utente con usermod -L imposta l'hash su ! . Nessuno di questi è mai un hash della password valido, quindi l'accesso con una password non avrà esito positivo.

Tuttavia, se esiste il rischio che il sistema di login interpreti un valore non definito (o vuoto) come corrispondente a una password vuota, si vorrebbe seriamente evitare di utilizzarli. Un valore non definito potrebbe anche portare a un errore, che potrebbe non sembrare piacevole.

È necessario verificare che il sistema sia conosciuto e testato per funzionare con password non definite o se esiste un altro modo per contrassegnare un account come inutilizzabile o bloccato. Generare un hash valido che corrisponda a una password lunga generata a caso che non è memorizzata in un punto qualsiasi sarebbe sicuro in quanto è probabile che il sistema sia in grado di gestirlo in ogni caso.

Perché non limitarsi a migrare anche gli hash delle password se si vuole generare comunque una password casuale? È quindi possibile forzare le persone a modificare la password al primo accesso se si mantiene il vecchio algoritmo di hash o si fa ciò che anche si prevede di fare con password casuali / nulle ora se non si mantiene lo stesso algoritmo di hash.

A meno che le tue password non fossero semplici testi / hash estremamente scadenti, non vedo perché la terza opzione di migrare gli hash sarebbe un problema.

Personalmente tenderei a favorire l'approccio della "password casuale per utente", poiché altrimenti esiste un account casuale che potrebbe essere "rubato" per semplice virtù di essere la prima persona a provare ad accedere con un determinato nome utente.

Ciò richiederebbe che gli utenti venissero messi al corrente della migrazione, in modo che l'e-mail con la nuova password e il nuovo URL (o qualunque sia il caso) non venga fuori dal nulla.

Tuttavia, quando dici che la tua password corrente è crittografata, cosa intendi esattamente?

Se sono hash e non criptati, allora tenderei a pensare che valga la pena di capire come vengono sottoposti a hash, e semplicemente li estraiamo con gli altri dati.

Quando un utente effettua l'accesso per la prima volta, puoi:

• imponi una modifica della password e cancella la nuova password con quello che desideri utilizzare nella tua nuova app
• o autentica gli utenti con le loro password "regolari" e, se la verifica della password passa, re-hash la loro password e la memorizza.

A meno che entrambe le app usassero lo stesso algoritmo di digest del messaggio, un semplice controllo della lunghezza della password hash memorizzata potrebbe indicare quali password non utilizzano l'algoritmo di hashing desiderato.

Se le password sono realmente crittografate, potrebbe anche avere senso vedere se è possibile scoprire come sono crittografate e scegliere uno dei due approcci menzionati sopra per aggiornare il proprio DB.