Come dovrei distribuire un codice di accesso?

Question

Come dovrei distribuire un codice di accesso?

#1 da (7 voti)

1

Attualmente la nostra applicazione genera email di "invito" contenenti una persona crittografata nella stringa di query di un collegamento https. Quando il destinatario fa clic sul link, l'applicazione convalida il PersonId, restituisce la home page e imposta un cookie che non scade mai e che identificherà e autentificherà l'utente per tutte le visite future.

Possiamo rendere questo processo più sicuro senza sacrificare la facilità d'uso? Pensiamo che il punto debole sia l'uso della stringa di query. Il token sicuro, poiché è passato nella stringa di query, verrà archiviato nella cronologia del browser, nei log del server e, eventualmente, nei log del firewall se eseguono l'ispezione https man-in-the-middle. Potremmo inserire gli stessi dettagli in una forma con input nascosti, ma leggo che i moduli nelle e-mail causano la reazione di panico nei client di posta elettronica.

Le risorse che vengono protette non sono molto preziose. Ci sono ovvi miglioramenti che ho trascurato?

web-applications login

posta bbsimonbb 05.05.2015 - 10:38

fonte

1 risposta

Leggi altre domande sui tag web-applications login

Utilizzare la guida di stile aziendale o cercare di far corrispondere i file sorgente errati? [duplicare] Salvataggio automatico dell'input dell'utente: il modo più intelligente?

score 7 · Accepted Answer

emails containing an encrypted personId in the query string of an https link

In primo luogo, la crittografia non è proprio ciò che si vuole in questo scenario: si vuole davvero l'entropia. Il token di accesso deve essere interamente indipendente dalla personaId , invece dovrebbe essere una stringa casuale generata utilizzando un metodo crittograficamente sicuro.

Ovviamente dovrai memorizzare il token casuale nel tuo database e potresti scegliere di hash + salt quel valore, ma il valore inviato via email non dovrebbe essere il valore hash.

Can we make this process more secure without sacrificing the ease of use? We think the weak point is the use of the query string.

Non penso che il problema sia così tanto che il tuo token è nella stringa della query, ma piuttosto che i tuoi token non sono single use .

I token monouso risolvono la cronologia del browser e i log del server perché una volta che sono stati acceduti, i collegamenti nei log / nella cronologia non funzionavano più.

Riguardo a:

if they do man-in-the-middle https inspection

Se hanno installato una CA dannosa sulla macchina, possono ispezionare qualsiasi traffico, quindi indipendentemente da dove si inserisce il valore (nell'intestazione dell'URL di richiesta o nel corpo della richiesta) potrebbero accedervi.

Nel complesso, ritengo che questa sia una minaccia piuttosto bassa, non è facile installare una CA dannosa e se qualcuno malintenzionato è riuscito a farlo, probabilmente non ci si può fidare di nulla su quella macchina.

Ovviamente potresti anche digitare manualmente il codice anziché utilizzare un link, il che potrebbe mitigare alcune di queste minacce. Come minimo, potresti essere in grado di avere un codice separato e più facile da digitare (ad esempio un valore di 4 cifre) e un blocco tentativo fallito appropriato oltre al collegamento contenente il token principale.