Domanda:
Qualcuno può fornire riferimenti per implementare correttamente i meccanismi di reimpostazione della password automatica dell'applicazione Web?
bdg
2011-01-28 04:39:03 UTC
view on stackexchange narkive permalink

Stiamo implementando la reimpostazione della password automatica su un'applicazione web e so come voglio farlo (URL di reimpostazione della password limitato nel tempo dell'email per gli indirizzi email pre-registrati degli utenti).

Il mio problema è che non riesco a trovare alcun riferimento per indirizzare gli sviluppatori sull'uso di quella tecnica. Qualcuno può indicarmi alcuni buoni riferimenti su questa tecnica?

Che linguaggio di programmazione stai usando?
Vedi anche una [domanda simile] (http://stackoverflow.com/q/664673/10080) su SO.
Vedi: [Password dimenticata · Serie OWASP Cheat Sheet] (https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)
Otto risposte:
#1
+93
D.W.
2011-01-30 12:05:38 UTC
view on stackexchange narkive permalink

Alcuni suggerimenti:

Non reimpostare la password dell'utente fino a quando non viene confermata. Non reimpostare immediatamente la password dell'utente. Reimpostalo solo quando l'utente fa clic su un link di conferma inviato al suo indirizzo email preregistrato.

Richiedi un CAPTCHA. Quando un utente richiede che la sua password venga reimpostata, forzalo per risolvere un CAPTCHA prima di procedere oltre. Questo per evitare che strumenti automatici provino a provocare dolore a molti utenti e costringere l'utente a dimostrare di essere un essere umano (non un robot).

Casualità. Il tempo limitato L'URL di reimpostazione della password dovrebbe includere un componente casuale e indovinabile. Assicurati di utilizzare casualità di qualità crittografica. L'output di / dev / urandom o System.Security.Cryptography.RNGCryptoServiceProvider sarebbe una buona scelta. L'output di rand () o random () o System.Random non è abbastanza casuale e sarebbe una cattiva scelta. Un GUID o un timestamp non è abbastanza casuale e non sarebbe una buona scelta.

Includi un limite di tempo. Il link di conferma del ripristino dovrebbe scadere dopo un periodo di tempo ragionevole: ad esempio, 24 ore . Il link dovrebbe essere utilizzabile solo una volta e dovrebbe scadere immediatamente non appena viene utilizzato.

Includi testo esplicativo nell'email. Puoi aggiungere del testo esplicativo al email, per spiegare perché l'email è stata inviata, nel caso qualcuno richieda un ripristino per un account che non è il tuo. Potresti includere del testo come "Qualcuno ha richiesto la reimpostazione della password per il tuo account nome utente su site . Se hai effettuato questa richiesta, fai clic qui per modificare la password. Se non hai effettuato questa richiesta, fai clic qui per annullare la richiesta. "

Invia un'email dopo aver reimpostato la password. Una volta reimpostata correttamente la password, invia un'email all'utente a fagli sapere che la password è stata cambiata. Non includere la nuova password nell'email.

Monitoraggio degli annullamenti. Potresti considerare di includere una logica per monitorare la frequenza con cui gli utenti fanno clic sul link di annullamento che indica che non hanno richiesto un ripristino. Se questa supera una certa soglia, potrebbe essere utile inviare un avviso agli operatori di sistema. Inoltre, se un link di cancellazione per una richiesta viene visitato dopo che il link di conferma è stato visitato, questa è una potenziale indicazione di un attacco contro quell'utente: potresti voler agire a quel punto, ad esempio, invalidare la password dell'utente e chiedergli di reimpostare nuovamente la password. (Questa è una difesa contro il seguente attacco: l'attaccante ottiene l'accesso alla casella di posta dell'utente, quindi richiede che la sua password sul tuo sito venga reimpostata, quindi visita il link di conferma. Se l'aggressore non elimina queste email dalla casella di posta dell'utente, quindi, quando l'utente reale legge la sua email, può fare clic sul link di annullamento, dandoti un'indicazione di possibili problemi.)

Usa HTTPS. Il link deve utilizzare https (non http :), per proteggersi da vari attacchi (ad esempio, gli attacchi Firesheep agli utenti che navigano sul web da un Internet cafè).

Registra queste operazioni. Suggerisco di registrare tutte queste richieste. Oltre a registrare il nome utente dell'utente, è possibile che si desideri registrare l'indirizzo IP del client che ha richiesto che un collegamento di ripristino sia inviato all'utente tramite posta elettronica, nonché l'indirizzo IP del client che ha visitato il collegamento di ripristino.

Letture aggiuntive. Potresti anche leggere l'eccellente post del blog di Troy Hunt, Tutto ciò che avresti sempre voluto sapere sulla creazione di una funzione di reimpostazione della password sicura. Grazie a @coryT per un collegamento a questa risorsa.

Infine, considera l'autenticazione senza password. Le password hanno molti problemi come meccanismo di autenticazione e potresti prendere in considerazione altri metodi per autenticare gli utenti, come memorizzare un cookie persistente sicuro sul loro computer con un errore indovinabile segreto per autenticarli. In questo modo, non vi è alcuna password da dimenticare e nessun modo per l'utente di essere phishing, sebbene sia necessario fornire un modo per consentire a un utente di autorizzare l'accesso da una nuova macchina o da un nuovo browser (possibilmente via e-mail al pre- indirizzo email registrato). Questo documento del sondaggio contiene un'eccellente indagine su molti metodi di autenticazione di fallback e sui loro punti di forza e di debolezza.

+1, si noti anche che sebbene sia popolare (come evidenziato dalla maggior parte delle risposte sbagliate [su questa domanda SO] (http://stackoverflow.com/q/664673/10080)), un GUID * non * è abbastanza casuale . Inoltre, aggiungerei semplicemente un meccanismo di limitazione, ad es. Un utente non può richiedere di reimpostare la sua password, ad es. 3000 volte in un'ora.
Per riassumere la mia conversazione con @avid alla sua risposta a questa domanda, direi che un GUID della versione 4 è in effetti per lo più casuale e [immagino sia abbastanza lungo] (http://security.stackexchange.com/questions/ 1952 / quanto-tempo-dovrebbe-essere-un-non-essere-casuale). Ma probabilmente è sciocco e un po 'pericoloso da usare poiché non è stato originariamente progettato per l'attività. E chi sa dove verrà portato il tuo codice dopo?
Non sembra che "Se non hai fatto questa richiesta, fai clic qui per annullare la richiesta" sarebbe necessario per l'email.
@nealmcb Ecco un collegamento da un ragazzo del team del compilatore C # che parla di GUID e che menziona fortemente che i GUID non sono in alcun modo crittograficamente casuali: http://blogs.msdn.com/b/ericlippert/archive/2012/05 /07/guid-guide-part-three.aspx - c'è stato un altro studio che mostra che i GUID di Windows non sono crittograficamente casuali: http://www.gotdotnet.ru/blogs/denish/1965/ - Conclusione: no usa i GUID per scopi crittografici :) (Non so se qualche sistema operativo non Windows fornisce garanzie in questo aspetto, ma gli Unix di solito hanno sia / dev / random che / dev / urandom)
Quanti personaggi dovrebbe essere la parte casuale?
"Non includere la nuova password nell'email." Se hai la password dell'utente in chiaro, stai sbagliando.
AiliizxjlpCMT 64-80 bits should be plenty for the random part. (40 bits would actually probably be enough for this purpose, but why take any chances?)
@DavidMurdoch Vedi il link che ho postato sopra per maggiori informazioni sulla risposta di D.W. (cioè che un nonce di 64 bit va probabilmente bene per questo scopo): [Quanto dovrebbe essere lungo un nonce casuale? - Sicurezza IT] (http://security.stackexchange.com/questions/1952/how-long-should-a-random-nonce-be)
AilidzgldmCMT Thanks for the links, and as I said it is a bad choice. But in terms of assessing the actual risk, Google translate didn't help much with that russian post by Nikolay Denishchenko on something like "Device and cryptanalysis UUID-Generator for Windows". Can you summarize the results in terms of how many unpredictable bits of entropy he thinks Windows version 4 GUIDs have, and how hard it would be to guess them remotely?
#2
+15
coryT
2012-07-20 02:11:58 UTC
view on stackexchange narkive permalink

Troy Hunt ha scritto un articolo molto carino su questa esatta domanda. Tutto ciò che avresti sempre voluto sapere sulla creazione di una funzione di reimpostazione della password sicura

Il blog di troy è una grande risorsa per tutto ciò che riguarda la sicurezza web
#3
+9
Jesper Mortensen
2011-04-05 14:25:56 UTC
view on stackexchange narkive permalink

OK, quindi la tua domanda è: come dovresti strutturare il processo di recupero della password / dell'account? Ciò dipenderà da ciò per cui desideri ottimizzare: esperienza utente senza problemi o buona sicurezza.

Se desideri una buona sicurezza:

  • Durante la registrazione, l'utente deve inserire il proprio indirizzo e-mail.
  • Durante la registrazione, l'utente deve inserire un canale secondario per l'autenticazione: numero di cellulare o domanda di prova Risposta di & (ad esempio " qual è nome da nubile di tua madre "o migliore).

  • Durante il recupero, il tuo sistema ottiene prima una verifica approssimativa dell'identità per mezzo del canale secondario di cui sopra: la sfida domanda, o inviando un SMS con un codice al telefono cellulare o simile.

  • Quando il primo controllo di identità sopra è stato cancellato, il sistema invia un'email di reimpostazione della password solo all'indirizzo email inserito in precedenza . Questa è una misura aggiuntiva e importante per prevenire f.x. exploit di tipo Sarah Palin.

  • L'email non deve contenere una nuova password o simile. Dovrebbe avere un collegamento cliccabile a una pagina web crittografata HTTPS sul tuo sito che a) è collegata all'account tramite un valore segreto non indovinabile fornito nell'URL, b) è limitato nel tempo, quindi il ripristino dell'account funziona solo per x ore dopo che è stato richiesto, c) fornisce all'utente finale un modo per creare una nuova password.

  • Avere una buona registrazione di tutte le transazioni di ripristino dell'account e fare in modo che un essere umano le controlli effettivamente e agisca se appaiono sospette (guarda i log del server per gli indirizzi IP fx, fai molte richieste provengono dallo stesso indirizzo IP, ci sono casi in cui un utente sta tentando di reimpostare le password da un paese diverso da quello del proprietario dell'account registrato, ecc.

Puoi anche eludere del tutto questa complessità: è ancora all'inizio, ma OAuth / OpenID / accedi tramite Facebook, Google ecc. rimuove completamente questa complessità dai tuoi sistemi, ma con un forse usabilità meno consolidata.

Le domande di sfida sono l'opposto della sicurezza.
@DavidMurdoch: potete fornire un riferimento che discuta questo? Mi piacerebbe saperne di più.
@David Murdoch: Le domande di sfida sono equivalenti alla password, ma la domanda chiave è cosa. Nel mio schema sbloccano un meccanismo di reimpostazione della password che (presumibilmente) * non è sotto il controllo degli aggressori *; l'indirizzo email originale. Ma è vero, i meccanismi di reimpostazione della password generalmente scambiano una sicurezza ridotta con una maggiore usabilità, forse avrei dovuto renderlo più chiaro.
Nota che qui, nell'abbagliante mondo futuro del 2015, l'utilizzo di un numero di telefono come parte di uno schema MFA è andato in pezzi, poiché lo stesso piccolo dispositivo perdibile funge da gateway sia per la posta elettronica che per gli SMS.
#4
+9
Rich Homolka
2012-07-23 22:18:52 UTC
view on stackexchange narkive permalink

Qualsiasi posto che possa inviarti una password significa che non l'ha hash della password, ma la memorizza dove è in qualche modo decifrabile in "testo normale". Questo di per sé è un male.

Probabilmente non "più" sicuro, ma più sicuro sarebbe:

Su richiesta della password, inviare un link per reimpostare la password all'utente con GUID incorporato. La sessione nel GUID scade tra, hmm, ore o giù di lì.

Yeah no issues with it as I have session protected from SQL injection, so I send mail with well randomised password reset session code and allow hour to change it, that's OK.
@AndrewSmith - Dovresti consentire all'utente di selezionare la nuova password e non inviargliela, come già spiegato, se sei in grado di inviare la password all'utente c'è qualcosa di sbagliato nel tuo modello di sicurezza.
Questo sito attualmente genera una NUOVA password, invia tramite e-mail, l'ha hash e la memorizza in db, il che non va bene credo.
generare una password e non farla scadere alla connessione successiva è davvero una cattiva idea.
Se questo GUID è in testo normale, può essere ottenuto con sql injection e quindi stai annullando l'intero scopo dell'hashing della password. Questo post è un suggerimento pericoloso per mezzo di ambiguità.
So I should encrypt well randomized password reset session code and in window of 1h afterwards allow for change - no problem.
#5
+6
Rory Alsop
2011-01-31 01:58:25 UTC
view on stackexchange narkive permalink

Un altro che può o non può essere appropriato per la tua applicazione, ma viene utilizzato nelle applicazioni di online banking e cose simili è l'invio di metà del codice di ripristino tramite messaggi SMS a un telefono cellulare registrato. Dal punto di vista di un utente malintenzionato, questo è un PITA completo in quanto richiede la compromissione di un paio di canali per interrompere.

#6
+6
Polynomial
2012-07-24 01:31:29 UTC
view on stackexchange narkive permalink

Il modo più sicuro per eseguire una reimpostazione della password è generare un token di reimpostazione unico e casuale di grandi dimensioni, con una data di scadenza, legata all'ID utente. Il token dovrebbe essere sottoposto ad hashing nel database, poiché un utente malintenzionato con accesso SQL potrebbe utilizzarlo per reimpostare le password utente arbitrarie.

Un link di ripristino dovrebbe essere inviato all'indirizzo e-mail, contenente il token di ripristino. Quando l'utente fa clic sul collegamento, l'hash del token deve essere trovato nel database e la data di scadenza deve essere verificata nel futuro. Se queste condizioni sono soddisfatte, all'utente dovrebbe essere presentata una schermata che gli consenta di digitare una nuova password.

L'intero processo deve essere eseguito tramite SSL, altrimenti un utente malintenzionato potrebbe fiutare l'URL e reimpostare la password prima che lo faccia l'utente.

Alcuni altri suggerimenti:

  1. Domande segrete un fastidio minore per gli aggressori e un fastidio maggiore per gli utenti. Evitalo completamente.
  2. Presenta l'utente con una verifica umana (ad es. Un CAPTCHA) prima di inviare la reimpostazione della password. Ciò impedisce le richieste di ripristino automatiche.
  3. Controlla se l'indirizzo IP che esegue il ripristino è quello che ha effettuato l'accesso con successo all'account in precedenza. In caso contrario, chiedi ulteriori dettagli sull'account / utente, ad es. anno di creazione dell'account, data di nascita, prima riga dell'indirizzo.
  4. Aggiungi un link "Non ho chiesto questa email", in modo che gli utenti possano segnalare richieste errate di reimpostazione della password.
  5. ol >
Anche se viene generato tramite SSL: non hai la certezza che l'e-mail stessa venga trasferita tramite SSL e quindi questo metodo ha un enorme difetto durante il transito: il difetto di base dell'inoltro e del recupero della posta elettronica.
@EvanCarroll "_il difetto di base dell'inoltro e del ** recupero della posta elettronica ** ._" riguardante il ** recupero dell'email **: è responsabilità dell'utente utilizzare un indirizzo di recupero dell'email da un provider di posta elettronica con POPS, IMAPS o Supporto webmail HTTPS (e la maggior parte dei provider di posta elettronica offre tutti e tre al giorno d'oggi).
AilicdsxgfCMT Whilst it's not an ideal situation, security is *always* secondary to usability. If you implement the world's most secure browser login, but it requires JavaScript, Flash, Java, ActiveX, Silverlight, and a degree in Computer Science to use, your users will switch off. Email is the de-facto standard for this kind of functionality, primarily because it's usable by everyone. The burden of security on a user's email system and personal network is *not* with me, nor should it be.
AiliewquonCMT if plausible deniability is your goal, then yes. If security is your goal, then no.
Gli standard "de facto" di @polynomial non hanno nulla a che fare con la sicurezza. Questo è solo un argomento per mantenere lo status quo ignaro delle implicazioni sulla sicurezza.
AiliwjxdkvCMT The argument for the status quo is that there is no acceptable alternative.
Sono d'accordo con la tua risposta, ma perché dovresti includere l'ID utente nel link? Se per esempio questo user-id è un numero di 8 caratteri, questi 8 caratteri sono ugualmente facili da indovinare, come 8 caratteri casuali aggiuntivi nel tuo token. Con i caratteri casuali però non esporresti l'id utente.
AilixijzgbCMT True, but exposing the user ID isn't usually a big deal. You're likely to do it through the interface to your site anyway - look at StackExchange. Question 17542, answer 17547, your comment is 28508, you're user 8343, I'm user 5400, OP is user 10787. Trying to hide that info is difficult and would only introduce obscurity. In this case, though, the tokens should be unique, so the search should always return a single row regardless of whether the user ID is in the link.
#7
  0
frank
2011-04-06 10:36:01 UTC
view on stackexchange narkive permalink

Autenticazione a 2 fattori tramite SMS! 1 conosci il cliente e il suo numero di cellulare, inviagli un SMS con un codice univoco da aggiungere al sito web per confermare che è lui :)

Non è necessariamente una soluzione a 2 fattori, ma è fuori banda.
Fino a quando qualcuno non ruba il loro telefono.
#8
  0
Andrzej Bobak
2012-07-24 19:28:06 UTC
view on stackexchange narkive permalink

Fai una procedura in pochi passaggi. Ad esempio qualcosa del genere:

  1. L'utente ha dimenticato la password. Fa clic sul pulsante "Ho dimenticato la password inviami un'email cosa fare dopo" (l'etichetta del pulsante potrebbe essere diversa;))
  2. Il tuo server gli invia un link www.tuodominio.com/lostpassword?param_1 = x; param_2 = y
  3. Fa clic sul collegamento ed è in grado di crearsi una nuova password
  4. Fa clic su Invia. Tutto fatto. Tutti contenti

L'unico problema è il punto 3). I valori X e Y dovrebbero essere casuali, imprevedibili e collegati a questo particolare account. Dovrebbero essere utilizzati anche una sola volta e dovrebbero diventare stantii dopo un breve periodo di tempo (24 ore?). Memorizza entrambi i valori in una tabella dedicata con le colonne corrispondenti:

  | some_id | user_id | X | Y | expire_time  

Se un utente cerca di utilizzare il collegamento corretto, controlla se il tempo di scadenza non è rispettato e, in caso contrario, consentigli di cambiare la password.

In che modo questo è diverso dalle altre risposte? Non c'è alcun vantaggio nell'avere sia X che Y, usa solo un singolo valore casuale.
Va bene, ma come è sicuro contro SQL Injection? È a causa del tavolo dedicato?
AililqgzirCMT one value is easy to break via brute force attack.
AilicbyxheCMT you prevent yourself from an sql injection in a complete different way. It's how you filter user input and how you pass it to your queries.
@AndrzejBobak: Due valori sono ugualmente facili da sfondare con la forza bruta come un valore il doppio della lunghezza di entrambi.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...