Esistono alternative sicure ai link di reimpostazione password monouso?

Come sempre, devi valutare il valore della risorsa che stai tentando di proteggere per valutare correttamente se una procedura di sicurezza è adeguata o meno. In genere, sarai disposto ad accettare una minore usabilità quando il valore del tuo asset è elevato.

Ciò significa che è impossibile per chiunque stimare se una determinata soluzione è abbastanza .

Detto questo, un modo semplice per risolvere il tuo problema non è quello di far scadere immediatamente i tuoi collegamenti ma farli scadere dopo un periodo di tempo OPPURE quando la password è stata ripristinata (a seconda di quale evento si verifichi prima).

Per decidere se questo è abbastanza sicuro per te e supponendo che tu sia soddisfatto della configurazione corrente, dovrai considerare le seguenti modifiche:

Lo stesso link può ora essere riutilizzato più volte. Ciò potenzialmente indebolisce la sicurezza del sistema.

Tuttavia, al momento stai lavorando su un'ipotesi errata: la prima persona a visitare un link è l'utente legittimo. Chiaramente non è il caso (come hai notato). La conseguenza è che non aumenti realmente la sicurezza generale facendo scadere il link immediatamente dopo il primo accesso.

Quindi secondo me , cambiando il modo in cui il token di accesso scade sembra una soluzione migliore: aumenti l'usabilità senza influire sulla sicurezza complessiva del sistema.

Tuttavia, potresti prendere in considerazione l'inclusione di alcune convalide di secondo livello nella pagina in cui ti trovi quando utilizzi il link di ripristino. Qualcosa che in qualche modo migliorerà la tua sicurezza sull'identità dell'utente (in genere, viene utilizzata una "domanda di sicurezza" sebbene tale modello non sia molto buono).

Non vedo la sicurezza di un singolo link di reset della password come lo descrivi. La maggior parte dei collegamenti monouso non sono validi se la password viene modificata, non se la pagina viene caricata per la prima volta. Una stampa accidentale su ricarica o F5 renderà la richiesta non valida? Questa è una specie di pessima esperienza utente.

Quindi pensiamo a questo: un utente ordina un collegamento password, possono succedere due cose:

1. Un 'hacker' riceve prima la posta. Usando il tuo sistema l'utente reale non ha alcuna possibilità di aprire questo link, questo è molto brutto per te e per te. Ma in questo caso non vi è ulteriore sicurezza lasciando scadere il collegamento con il primo utilizzo.
2. L'utente ottiene la posta desiderata. Qui va tutto bene, ma se viene effettuato un aggiornamento accidentale, l'utente deve iniziare ordinando un nuovo collegamento.

Per rendere il sistema più sicuro, è possibile creare un sistema in cui viene inviata una posta aggiuntiva all'utente con un collegamento per "recuperare" la vecchia password, se non è stata lui a cambiarla. Io non voglio che tu invii la vecchia password in testo semplice all'utente (non dovresti nemmeno riuscire a farlo). Quello che intendo è di storicizzare il vecchio hash della password e il sale e se l'utente fa clic su "ripristina", si usa di nuovo il vecchio hash e la password. Sicuramente, questo non aiuterà se il mailaccount è compromesso, ma per il tuo esempio con un computer pubblico in cui è memorizzato il link di reset sarebbe di aiuto.

Inoltre, è possibile proibire di cambiare la posta degli account i primi X giorni dopo la modifica della password. In questo modo un hacker non può bloccare completamente l'utente (a patto che l'account di posta non sia compromesso, ma in questo caso c'è ben poco che puoi fare).

Un'altra opzione è quella di fornire all'utente un codice dopo la registrazione (secondo la vecchia lettera per la massima sicurezza, se questo è troppo costoso mostralo sulla pagina stessa quando l'utente effettua il login per la prima volta con la richiesta esplicita di stampare fuori - ancora meglio di inviarlo al possibile account di posta elettronica compromessa) che agisce come un recupero di emergenza per l'account specificato. Ad esempio quando viene inserito questo codice, l'utente può inserire una nuova mail e una nuova password per accedere all'account, indipendentemente da ciò che accade. Ma questo codice deve essere molto sicuro e non dovrebbe in alcun modo essere salvato su nessun computer.

Verrà aggiunta una maggiore sicurezza utilizzando l'autenticazione a due fattori, come è possibile utilizzare con Google, GitHub e molti altri. Puoi persino utilizzare il sistema da Google , in modo da non dover costruire tutto da solo. In questo modo un utente malintenzionato deve rubare il cellulare dell'utente, rendendo impossibile l'attacco casuale.

E infine, un punto molto grande e importante: non inviare MAI la password via mail. Ho visto molti grandi siti Web che fanno questo e non c'è modo in cui questa potrebbe essere una buona idea!

La vera minaccia è che un account possa essere dirottato . Attualmente la tua sicurezza è basata sul mantenimento segreto dei link per la reimpostazione della password , perché con esso chiunque può impostare una nuova password a piacere. L'uso di un link monouso non aiuta perché non sai se il primo visitatore è l'utente o un impostore.

Per migliorare la tua situazione, ci sono tre opzioni

• Mantieni segreto il link per la reimpostazione della password utilizzando un mezzo sicuro anziché email non crittografate . Ad esempio e-mail crittografata con PGP, SMS (non crittografato ma più difficile da intercettare), messaggio TextSecure, lettera cartacea, ...
• Non fare affidamento sul fatto che il link sia segreto . Quindi è necessario un altro modo per autenticare l'utente. Tutti gli esempi che posso immaginare sono costosi: una password più complessa che è stata inviata dai servizi postali (come un PUK), l'invio di un fax con informazioni personali (potrebbe anche essere simulato, ma è più difficile), ulteriori domande a cui solo l'utente potrebbe rispondere ...
• Mantieni la tua soluzione attuale, consenti più visite alla pagina di reimpostazione della password, rifiuta i tentativi dopo un periodo di tempo definito (ad esempio 2 ore) e sperare che la tua rete sia sicura. (Aneddoto: fino al 2013 la maggior parte dei provider di posta elettronica in Germania scambiava e-mail non crittografate.)

Un approccio a questo problema, che sto considerando di implementare, potrebbe funzionare come segue:

1. L'utente apre la pagina di reimpostazione della password, che ha un modulo con un campo di indirizzo email.
2. L'utente POST il modulo con il suo indirizzo email
3. Server invia una password monouso all'indirizzo email inserito dall'utente.
4. Il server risponde alla richiesta POST con un nuovo modulo contenente:
   • Campo nascosto con un valore segreto
   • Campo di testo per l'inserimento della password monouso
   • Due campi password per l'inserimento della nuova password
5. Alla sottomissione del secondo modulo il server verifica che il valore segreto nel modulo e la password monouso immessa corrispondano effettivamente l'uno all'altro. Inoltre verifica che i valori non siano più vecchi di x ore (per alcuni x tra 1 e 24).
6. Se tutto è stato inserito correttamente, la password viene ripristinata.

È simile all'utilizzo di un cookie di sessione, ma è probabile che il valore segreto in un campo modulo sia meno persistente di un cookie di sessione. È possibile combinare in modo tale che la prima richiesta POST crei tre valori uno nell'e-mail e due nel campo cookie e modulo nella risposta POST e la seconda richiesta POST deve contenere tutti e tre i valori per reimpostare la password.

Una variazione di questo approccio, che sto anche considerando è la seguente:

1. L'utente apre la pagina di reimpostazione della password, che li informa su un unico indirizzo e-mail nello stesso dominio della pagina Web (o di un sottodominio). Inoltre, la pagina contiene un modulo con un campo nascosto con un valore segreto e un campo password monouso.
2. L'utente invia un'email all'indirizzo di cui è stato informato.
3. Alla fine di DATA , il server di posta ricevente inizia immediatamente a inviare una risposta all'indirizzo email dell'utente. Questa risposta conterrà una password unica.
4. La password monouso inviata all'utente viene ora copiata dall'email nel modulo.
5. Il server verifica che il campo nascosto e la password monouso corrispondano tra loro (connessi tramite l'indirizzo email una tantum).
6. In caso di successo, all'utente viene presentato un account utente registrato all'indirizzo email verificato.

Il secondo approccio potrebbe non essere ancora completamente pensato, ma immagino che abbia i seguenti vantaggi rispetto all'invio di una semplice e-mail all'utente:

• Hai ancora una possibilità di verificare che l'utente controlli effettivamente l'indirizzo email, dato che puoi validare i record SPF a questo punto.
• È meno probabile che disturbi gli utenti con email di reimpostazione della password illegittime, poiché un utente malintenzionato dovrebbe superare il controllo SPF prima che venga inviata la mail di ripristino.
• La reimpostazione della posta è meno probabile che venga bloccata da un filtro antispam, perché è una risposta effettiva a una e-mail inviata dall'utente.

Il sistema di posta con cui hai a che fare ha un'enorme violazione della sicurezza da solo. Un robot che legge le e-mail sicure non è un problema, ma un robot che invia parti di messaggi apparentemente sicuri (link) a Internet è semplicemente inaccettabile. Triste com'è, esclude i collegamenti come mezzi sicuri per trasportare i dati dagli utenti al server. È necessario considerare altre opzioni, senza collegamenti personalizzati:

1) Sostituisci i collegamenti che trasportano i dati in URL con un link generico a un modulo + codice di sicurezza per l'inserimento della copia. È sicuramente un'esperienza utente peggiore, tuttavia se si limita la posta e il modulo al minimo e si forniscono istruzioni brevi e chiare, dovrebbe essere gestibile per tutti.

2) Utilizzare invece password monouso. La posta conterrà password monouso e le istruzioni per accedere con esso, il che reindirizza l'utente alla pagina "Definisci nuova password".

Raccomando il secondo approccio, poiché è meno minaccioso per gli utenti (hanno già familiarità con la procedura di accesso e puoi mascherare l'intero processo per sembrare simile all'accesso), non è necessario mantenere un'altra pagina (il " reset codice "pagina), e il messaggio è breve e compatto (" la tua nuova password: ") in modo da poter utilizzare altri mezzi di consegna, come i messaggi di testo.

Dovresti prendere in considerazione l'utilizzo simultaneo di due metodi:

1. Scade il collegamento dopo N minuti / ore

2. Scade il collegamento solo dopo che il modulo è stato inviato.

Questo dovrebbe essere un buon compromesso tra sicurezza e usabilità.