È sicuro generare una password per un utente durante la registrazione in un'applicazione web?

Questo dipende totalmente dalla tua applicazione e dai suoi requisiti.

Se le tue applicazioni devono verificare gli indirizzi e-mail degli utenti, puoi inviare loro un token generato casualmente (utilizzo monouso e valido per un periodo di tempo limitato) per il primo accesso, sull'indirizzo email che hanno fornito durante l'iscrizione. E chiedi loro di impostare la propria password dopo aver usato quel token casuale per accedere. In questo modo stai verificando anche il loro indirizzo email.

Se non ti interessa la verifica dell'e-mail, puoi semplicemente chiedere loro di scegliere una password sicura durante la registrazione. In questo caso, non dimenticare di autenticare nuovamente gli utenti subito dopo la registrazione.

In ogni caso, assicurati che i tuoi utenti scelgano una password complessa, rispettando una politica di password complessa . Assicurati inoltre che tutte le funzionalità relative alle password nell'applicazione (password dimenticata, password di reimpostazione, ecc.) Siano conformi anche alla politica della password dell'applicazione.

Se il tuo metodo di generazione ha abbastanza lunghezza e un buon set di caratteri, sarà più sicuro di chiedere all'utente la password.

Il problema in questo modo che rende i siti Web non usarlo, è perché le password generate automaticamente sono difficili da ricordare e non offrono una buona esperienza utente.

Vorrei sconsigliarlo. La tua applicazione web dovrebbe avere una politica in base alla quale le password vengono sempre immesse, non emesse mai. Trovo che seguendo questo approccio, la tua applicazione sarà più sicura in generale.

C'è anche un ulteriore problema su come fornire la password all'utente. La visualizzazione della password sullo schermo (in una e-mail o quando si registra) comporta il rischio che un navigatore della spalla veda la password. Se visualizzati nella pagina vi sono anche dei rischi di memorizzazione della pagina nel browser o nella cache del proxy. Sì, le intestazioni di risposta dovrebbero essere impostate per impedire ciò, tuttavia è facile da dimenticare.

Un approccio migliore sarebbe quello di generare un collegamento casuale come parte del processo di registrazione , che viene inviato via email per l'utente. L'approccio protegge anche da enumerazione utente e convalida l'e-mail allo stesso tempo. Il link dovrebbe scadere, quindi se l'email viene lasciata nella posta in arrivo dell'utente e successivamente scoperta, non può essere utilizzata per accedere all'account. Al momento della registrazione, scadendo questo link è effettivamente la stessa di eliminazione dell'account. Ciò è utile nel caso in cui qualcuno abbia inserito l'indirizzo email sbagliato - questo account accidentale non impedisce quindi al proprietario del vero indirizzo email di registrarsi.

Se un utente malintenzionato desiderava ancora accedere all'account su un indirizzo di posta elettronica a cui era riuscito ad accedere, sì, potrebbe generare una nuova registrazione a quell'indirizzo email. Tuttavia, questo lascia una traccia di controllo dietro in modo da poter determinare in seguito cosa è successo. L'utilizzo del collegamento consente all'applicazione di comunicare più informazioni su ciò che è accaduto. per esempio. fare clic su un link scaduto potrebbe rendere un messaggio per l'effetto di Sorry, this registration has expired, please register again . Tuttavia, se un utente tenta di accedere con una password scaduta, non è possibile fornire ulteriori informazioni sull'account senza ridurre la sicurezza. Rivelare che l'account è scaduto sarebbe una vulnerabilità di enumerazione degli utenti, che rivela che la password è già stata cambiata e trapelerebbe anche informazioni sullo stato dell'account.