Anche se l'entropia in un grande token casuale suggerisce che il token sarebbe un meccanismo di autenticazione sicuro, ci sono molti problemi ad esso associati:

• Il token è fisso per utente, quindi un utente non può cambiare il token se sospetta che sia stato compromesso.
• Il token potrebbe essere utilizzato un numero illimitato di volte, il che aumenta l'opportunità di scendere a compromessi.
• In base alla descrizione, il cliente può conoscere i token per i suoi dipendenti. Sebbene i dati possano essere uguali (o avere le stesse restrizioni di accesso) per ogni account gestito dal cliente, questo compromette il non ripudio . Il cliente potrebbe utilizzare un account dipendente e nessuno sarebbe più saggio.

Esiste un problema di processo

Come hai sottolineato, avere clienti che chiamano il servizio clienti per cambiare una password ha due problemi significativi:

• In primo luogo, è inefficiente per la tua attività e sta costando denaro ai tuoi affari e ai tuoi clienti.
• In secondo luogo, è pericoloso dal punto di vista della sicurezza.

Considera in che modo consentire al servizio clienti di reimpostare le password influisce sulla sicurezza dell'applicazione:

• Qualsiasi rappresentante del servizio clienti può reimpostare la password (e in base a come la descrivi, in realtà impostare la password) di qualsiasi account cliente e può quindi accedere alle informazioni riservate dell'account del cliente.
• A seconda delle procedure per la reimpostazione della password avviata dal telefono, il processo potrebbe essere suscettibile all'ingegneria sociale.

Utilizza il token casuale per avviare una reimpostazione della password

I clienti che devono modificare la propria password devono utilizzare l'applicazione Web esistente per richiedere la reimpostazione della password. Ciò potrebbe richiedere l'invio di una e-mail all'account e, facoltativamente, una serie di domande di sicurezza (in base alla propria valutazione dei rischi). Successivamente un link di reimpostazione della password con un token casuale viene inviato via email a tale indirizzo email. Questo link dovrebbe essere valido una sola volta e dovrebbe scadere dopo un breve periodo di tempo se non utilizzato. Quando l'utente fa clic sul collegamento, vengono autenticati. La maggior parte delle app web avrà l'utente di impostare una password a questo punto. Nel tuo caso, potresti voler consentire all'utente di saltare l'impostazione di una password, dato che lo dimenticheranno comunque.

I clienti che chiamano il servizio clienti per reimpostare la propria password dovrebbero essere istruiti a utilizzare la funzione di reimpostazione della password. Il rappresentante del servizio clienti può rimanere sulla linea e accompagnare il cliente attraverso la procedura, ma il punto chiave è che il cliente si resetta da solo. Una volta che un cliente reimposta una password, è meno probabile che effettui nuovamente la chiamata.

Questo è quasi equivalente al passaggio della password come parametro GET, che è male. È discusso qui: Esiste una differenza tra GET e POST per la sicurezza delle applicazioni Web?

Inoltre, nel tuo URL di esempio non stai utilizzando HTTPS. Anche l'invio della password in chiaro sulla rete è negativo per ovvi motivi.

Quindi, un utente può modificare il proprio token nel caso in cui sia compromesso? Sei sicuro che non perderanno questo token? Voglio dire, potrebbero anche solo scrivere la loro password.

In alternativa, puoi utilizzare l'autenticazione di base su HTTPS. Questa è una tecnica di autenticazione standard e può essere scritta sotto forma di un URL come link . Dubito che verrà salvato come segnalibro, ma la maggior parte dei browser dovrebbe offrire una funzione "ricorda queste credenziali".

Lo schema proposto corrisponde fondamentalmente a OWASP 2 e il più pericoloso problema di sicurezza delle applicazioni Web: autenticazione e sessione non funzionanti gestione . Il sito di OWAPS spiega abbastanza bene il problema:

Airline reservations application supports URL rewriting, putting session IDs in the URL: http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Considera inoltre che ogni URL digitato da un utente può essere inviato al suo creatore di browser e / o al motore di ricerca preferito (vedere Norme sulla privacy di Google Chrome ).

Questa è un'espansione sulla risposta di amccormack .

Permetti al cliente di avviare un accesso inserendo il suo indirizzo email. Quando hanno inserito l'indirizzo email, utilizzalo per convalidare che l'utente è autorizzato ad accedere, quindi invia un token singolo e di breve durata all'indirizzo e-mail dell'utente. Potrebbe essere nel forma di un collegamento web con opportuni nonce, o una chiave che l'utente deve copiare in un campo sul modulo successivo (login stile wizard). Convalida che il token inserito corrisponde a quello inviato per quell'indirizzo e che è ancora valido. Assicurati di consentire alcune ore di validità iniziale in caso di greylisting, ma anche solo monouso in modo che un token non possa essere riutilizzato.

In questo caso, l'utente non dovrà ricordare nulla di speciale per il proprio servizio (è necessario solo il proprio indirizzo email e l'accesso a tale account di posta elettronica) e lo schema non è probabilmente meno sicuro di qualsiasi altro reset puro - schema password per e-mail che puoi trovare.

Inoltre, in futuro, puoi estenderlo consentendo la consegna di token tramite SMS (o qualsiasi altro canale di consegna che puoi immaginare), con modifiche minime a tutto tranne il codice di consegna del token.