Permettere agli utenti di riprendere da dove erano rimasti ... senza effettuare il login (questa è una cattiva forma?)

Question

Permettere agli utenti di riprendere da dove erano rimasti ... senza effettuare il login (questa è una cattiva forma?)

#1 da (5 voti)
#2 da (3 voti)
#3 da (0 voti)

3

Ho un'app Grails su cui sto lavorando che consente agli utenti di compilare un modulo di domanda abbastanza lungo. Uno dei requisiti che ho ricevuto è NON richiedere agli utenti di accedere o creare alcun tipo di account. Quando iniziano a compilare l'app, memorizzo il loro ID app nella sessione in modo che possa essere ricordato da una pagina all'altra. Dopo un'ora, la sessione scade. Se non hanno terminato l'app, invio loro una e-mail ringraziandoli per averci pensato.

Quello che devo fare è dare agli utenti la possibilità di riprendere da dove erano rimasti, in modo che possano finire l'applicazione ... di nuovo, senza un account, senza una combinazione nome utente / login.

Un modo in cui ho pensato di fare questo è stato quello di creare un ID univoco (come adbce-13428-etace-etc ...) che è memorizzato nel DB e mappato al loro ID applicazione. Vorrei quindi inviare loro un link nell'email che dice "Se desideri continuare a compilare il tuo candidato, fai clic sul seguente link: myapp.com/continue/{their_unique_id}". Quando fanno clic su questo, cerca l'ID univoco nel database, ottiene l'ID dell'applicazione e reinserisce le informazioni nella sessione in modo che possano completare l'applicazione.

La mia domanda è : questa è una brutta forma? E 'un cattivo design? Fa male alla sicurezza? Perché?

cookies defense session-management

posta grantmcconnaughey 23.04.2014 - 22:06

fonte

3 risposte

Leggi altre domande sui tag cookies defense session-management

Una seconda carta bancaria è arrivata con lo stesso PIN Devo usare più di 2048 bit nella mia chiave RSA SSH-2?

score 5 · Answer 1

Potresti sfruttare lo spazio di archiviazione locale, ma puoi anche esporlo a un computer multiutente o pubblico, oppure l'usabilità fallire se l'utente utilizza più computer.

Nella tua soluzione email, potresti aggiungere un codice / token / password speciale oltre al tuo identificatore. Quindi hai l'identificatore (UUID) e poi un segreto. Hai ancora un'esposizione se l'email è compromessa, ma se l'UUID è compromesso dai log, l'acquisizione di pacchetti, ecc. Senza l'accesso segreto non può essere garantita attraverso il canale progettato. Puoi inserire il segreto come un altro parametro nell'URL, ma questo è un po 'meno sicuro poiché verrà esposto ovunque l'URL sia registrato dal suo GET

ad es.

Hey, come on back to http://somesite.com?your_app=12345...... on the page enter the following code to continue XXXX

I dati dell'applicazione e il segreto dovrebbero scadere e essere rimossi o non visibili dal punto di vista dell'utente dopo un periodo di tempo (i segreti tendono a diventare meno segreti nel tempo).

score 3 · Answer 2

La cattiva sicurezza dipende dal fatto che le informazioni che stanno inserendo possano essere considerate "sensibili".

Sarebbe importante per il richiedente se qualcun altro potesse indovinare (per quanto improbabile) il loro id di sessione e avere accesso ai dati che hanno già inserito? (La riservatezza dei dati è importante?)

Sarebbe importante per l'organizzazione che sta ricevendo i dati del richiedente che la parte 1 avrebbe potuto essere compilata da una persona e la parte 2, o la parte 3, ecc. avrebbe potuto essere compilata da un'altra persona o persone? (L'integrità dei dati è importante?)

Se un utente malintenzionato riusciva a capire il processo utilizzato per ottenere la funzionalità "salva e riprendi dopo" ed era in grado di raccogliere tutti i dati inviati, sarebbe dannoso per la reputazione dell'organizzazione? La loro reputazione ne risentirebbe?

Se la risposta a una di queste domande è sì, allora potrebbe non essere una buona idea. Come per la maggior parte delle cose in sicurezza, si tratta di dati.

score 0 · Answer 3

Sono d'accordo con la risposta e l'asserzione di monkeymagic che "è tutta una questione di dati" e implementerebbe sicuramente un token segreto come suggerito da Eric G.

Hai menzionato in un commento che le informazioni SSN sono state inserite in qualche punto, quindi un ulteriore passaggio che puoi implementare è quello di oscurare le informazioni particolarmente sensibili inserite in precedenza quando un utente riprende la propria applicazione. Forse dopo aver ripreso un'applicazione in corso, il loro SSN verrà visualizzato solo come: XXX-XX-1234

Sappiamo che oscurare SSN mostrando solo le ultime 4 cifre NON è una soluzione perfetta, ma anche se qualcuno è riuscito a capire il tuo schema di generazione UUID e indovina un gruppo di URL validi la probabilità che essi vogliano divulgare informazioni sensibili come Gli SSN sono MOLTO più alti della probabilità che saranno motivati a continuare alcune applicazioni in corso e completarle in modo fraudolento.

Un'altra preoccupazione è se questa è un'applicazione per un processo che verrà rilevato dagli esseri umani per il passaggio successivo che ha l'opportunità di eseguire alcune conferme / verifiche che è un problema diverso rispetto a quando l'ultimo passo è "Inserisci il conto bancario numero che vorresti depositare denaro in "