URL https con parametro token: quanto è sicuro?

Sul nostro sito, forniamo agli utenti una simulazione basata sulle loro informazioni private (fornite tramite un modulo). Vorremmo consentire loro di tornare sui risultati della simulazione in un secondo momento, ma senza costringerli a creare un account di accesso / password.

Abbiamo pensato di inviare loro una mail con un link, da cui poter recuperare i risultati. Ma, naturalmente, dobbiamo proteggere questo URL, perché sono in gioco i dati privati.

Quindi intendiamo passare un token (come una combinazione di 40 caratteri di lettere e cifre, o un hash MD5) nell'URL e di utilizzare SSL.

Infine, avrebbero ricevuto un'e-mail del genere:

Ciao,
recupera i tuoi risultati su https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Cosa ne pensi? È abbastanza sicuro? Cosa mi consiglieresti per la generazione di token? Che dire del passaggio di parametri URL in una richiesta https?

SSL proteggerà i parametri di query in transito; tuttavia, la posta elettronica in sé non è sicura e potrebbe rimbalzare su un numero qualsiasi di server prima di arrivare a destinazione.

Inoltre, a seconda del tuo server web, l'URL completo potrebbe essere registrato nei suoi file di registro. A seconda della sensibilità dei dati, potresti non volere che il tuo personale IT abbia accesso a tutti i token.

Inoltre, l'URL con la stringa di query verrà salvato nella cronologia dell'utente, consentendo ad altri utenti della stessa macchina di accedere all'URL.

Infine, e ciò che lo rende molto insicuro è che l'URL viene inviato nell'intestazione Referer di tutte le richieste per qualsiasi risorsa, anche risorse di terze parti. Quindi, se utilizzi Google Analytics, ad esempio, invierai a Google il token URL e tutto a loro.

Secondo me questa è una cattiva idea.

Per questo userei un cookie. Il flusso di lavoro dovrebbe essere così:

1. L'utente accede al tuo sito per la prima volta.
2. Il sito imposta un cookie
3. L'utente inserisce i dati. I dati vengono memorizzati nel DB utilizzando una chiave che viene memorizzata nel cookie.
4. Quando l'utente esce, gli si invia un'e-mail con un collegamento https :.
5. Quando l'utente torna, il sito scopre il cookie e può presentare all'utente i vecchi dati.

Ora, l'utente desidera utilizzare un browser diverso su una macchina diversa. In questo caso, offri un pulsante di "trasferimento". Quando l'utente fa clic su questo pulsante, riceverà un "token". Può utilizzare questo token su un altro computer per reimpostare il cookie. In questo modo, l'utente decide quanto sicuro desidera trasferire il token.

SSL protegge il contenuto dei dati in transito, ma non sono sicuro dell'URL.

Indipendentemente da ciò, un modo per evitare che un utente malintenzionato riutilizzi quel token URL è assicurarsi che ogni token possa essere utilizzato solo una volta. Potresti anche impostare un cookie in modo che l'utente legittimo possa continuare a utilizzare il collegamento, ma dopo il primo accesso funzionerà solo per qualcuno con il cookie.

Se l'e-mail dell'utente viene compromessa e un utente malintenzionato ottiene il collegamento per primo, beh, sei ingannato. Ma l'utente ha anche problemi maggiori.

La posta elettronica è intrinsecamente insicura. Se qualcuno può fare clic su quel collegamento e accedere ai dati, non lo stai davvero proteggendo.

Bene, il token è sicuro quando viene passato tramite SSL. Il problema che avrai è che è disponibile per le persone (coloro a cui non è destinato) essendo in grado di visualizzare l'URL.

Se si tratta di informazioni private come SSN, non credo che invierei un URL tramite e-mail. Preferisco che creino un nome utente e una password per il sito. È troppo facile compromettere un'e-mail con quel tipo di informazioni in gioco per te e per loro. Se il racconto di qualcuno è compromesso, si chiederà chi sia davvero la colpa. Più sei sicuro, meglio sei da un punto di vista strettamente CYA.

Non lo considererei davvero abbastanza sicuro per una situazione in cui ci sono seri problemi di privacy. Il fatto che stai inviando l'URL in un'e-mail (presumibilmente in chiaro) è di gran lunga il collegamento più debole. Dopodiché c'è il rischio di attacchi di forza bruta sui token, che (privi della struttura di un vero meccanismo di autenticazione) rischiano di essere più vulnerabili di una configurazione di nome utente e password ben costruita.

Non ci sono problemi con i parametri in una richiesta https, per inciso.

Così com'è, sarebbe una cattiva idea. Scarificherai la sicurezza con un facile utilizzo. Come detto prima, SSL proteggerà solo il trasferimento di informazioni tra il server e il browser client e impedirà solo l'attacco intermedio. Le e-mail sono molto rischiose e insicure.

La migliore sarebbe un'autenticazione con nome utente e password per accedere alle informazioni.

Mi piace più o meno l'idea dei biscotti. Dovresti crittografare anche le informazioni sui cookie. Dovresti anche generare il token con salt e la frase chiave più $ _SERVER ['HTTP_USER_AGENT'] per limitare la probabilità di un attacco. Memorizza quante più informazioni non sensibili sul client nel cookie per l'utilizzo di verifica.

La frase chiave potrebbe essere memorizzata nel cookie per un facile utilizzo, ma tieni presente che anche il cookie può essere rubato = (.

È meglio lasciare che il cliente digiti la frase chiave che ha fornito, che è anche memorizzata nel database insieme ai suoi dati.

Oppure, la chiave può essere utilizzata nel caso in cui la persona utilizzi una macchina diversa che differisce nei parametri $ _SERVER ['HTTP_USER_AGENT'] o semplicemente perde il cookie. Quindi il cookie può essere trasferito o impostato.

Assicurati inoltre che i dati sensibili siano crittografati nel database. Non si sa mai ;)

Sei consapevole che se un hacker ha accesso al tuo database, molte informazioni personali possono essere fornite liberamente?

Dopo di che direi che non è male come idea. Non userei MD5 o SHA1 in quanto non sono molto sicuri per l'hashing. Possono essere "decrittografati" (so che non è crittografato) abbastanza facilmente.

Altrimenti potrei forse utilizzare una seconda informazione che non verrebbe inviata via email come una password. Il motivo è abbastanza semplice, se qualcuno ottiene l'accesso alla posta elettronica dell'utente (abbastanza facile con Hotmail se non si interrompe la sessione) avrà accesso a tutte le informazioni inviate dall'utente.

Tieni presente che HTTPS proteggerà e crittograferà i dati inviati dal tuo sito all'utente finale. Nient'altro, prendilo come un tunnel sicuro. Niente di più, niente di meno.

Da quello che ho capito della tua idea, in teoria qualcuno potrebbe digitare una stringa casuale di 40 caratteri o un hash MD5 e ottenere i dettagli di qualcun altro. Sebbene ciò possa essere altamente improbabile, deve accadere solo una volta.

Una soluzione migliore potrebbe essere quella di inviare un token all'utente e poi chiedergli di inserire alcuni dettagli, come nome, codice postale, ssn o una combinazione di questi.