URL https con parametro token: quanto è sicuro?

Question

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

Abbiamo pensato di inviare loro un'e-mail con un link, dal quale potevano recuperare i risultati. Ma, naturalmente, dobbiamo proteggere questo URL, poiché sono in gioco dati privati.

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

Alla fine, avrebbero ricevuto una email del genere:

  

Ciao,
  Ripristina i risultati    https://www.example.com/load_sXulation>

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

Answer 1

SSL proteggerà i parametri della query in transito; tuttavia, l'e-mail in sé non è sicura e l'e-mail potrebbe rimbalzare su qualsiasi numero di server prima di arrivare a destinazione.

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

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

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

Secondo me questa è una cattiva idea.

Answer 2

Userei un cookie per quello. 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 archiviati nel DB utilizzando una chiave memorizzata nel cookie.
4. Quando l'utente lascia, gli invii un'email con un link 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 "trasferimento" pulsante. Quando l'utente fa clic su questo pulsante, riceverà un "token". Può utilizzare questo token su un altro computer per ripristinare il cookie. In questo modo, l'utente decide quanto desidera trasferire il token.

Answer 3

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

Indipendentemente da ciò, un modo per mitigare un utente malintenzionato riutilizzando quel token URL è assicurarsi che ogni token possa essere utilizzato una sola volta. Puoi persino impostare un cookie in modo che l'utente legittimo possa continuare a utilizzare il link, ma dopo il primo accesso funzionerà solo per qualcuno con il cookie.

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

Answer 4

L'e-mail è intrinsecamente insicura. Se qualcuno può fare clic su quel link e accedere ai dati, non li stai davvero proteggendo.

Answer 5

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. Preferirei che creassero 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 conto di qualcuno è compreso, entrerà in discussione di chi è la colpa. Più sei sicuro, meglio sei dal punto di vista strettamente CYA.

Answer 6

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

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

Answer 7

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 email sono molto rischiose e insicure.

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

Mi piace più o meno l'idea dei cookie. 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 della verifica.

La frase chiave potrebbe essere memorizzata nel cookie per un facile utilizzo, ma tieni presente che anche i cookie possono essere rubati = (.

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

In alternativa, 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 manca il cookie. Quindi il cookie può essere trasferito o impostato.

Assicurarsi inoltre che i dati sensibili siano crittografati nel database. Non lo sai mai;)

Answer 8

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

Dopodiché direi che non è male come idea. Non userei MD5 o SHA1 in quanto non sono molto sicuri per l'hashing. Possono essere "decifrati" (So ??che non è crittografia) abbastanza facilmente.

Altrimenti potrei forse usare una seconda informazione che non verrebbe inviata via e-mail come una password. Il motivo è piuttosto semplice, se qualcuno ottiene l'accesso alla posta elettronica dell'utente (abbastanza facile con hotmail se non uccidi la sessione) avrà accesso a tutte le informazioni che l'utente ha inviato.

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

Answer 9

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 dettagli di qualcun altro. Sebbene ciò possa essere altamente improbabile, deve accadere solo una volta.

Una migliore assunzione potrebbe essere quella di inviare un token all'utente e quindi chiedere loro di inserire alcuni dettagli, come il loro nome, codice postale, ssn o una combinazione di questi.