https URL con parametro token: quanto è sicuro?

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

Abbiamo pensato di inviare loro un’e-mail con un link, da cui potrebbero ottenere i loro risultati. Ma, naturalmente, dobbiamo proteggere questo URL, perché sono in gioco dati privati.

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

Alla fine, avrebbero ricevuto un’email come quella:

Ciao,
Ripristina i 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 dei parametri URL in una richiesta https?

SSL proteggerà i parametri della query in transito; tuttavia, l’e-mail non è sicura e l’e-mail potrebbe rimbalzare su qualsiasi numero 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 di quanto sensibili sono i dati, potresti non volere che i tuoi IT abbiano 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 di qualsiasi risorsa, anche di risorse di terze parti. Pertanto, se utilizzi Google Analytics, ad esempio, invierai a Google il token URL e tutto a loro.

Secondo me questa è una ctriggers idea.

Userei un cookie per questo. Il stream di lavoro dovrebbe essere così:

  1. L’utente arriva 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 memorizzata nel cookie.
  4. Quando l’utente esce, invii loro 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 vuole utilizzare un browser diverso su un altro computer. In questo caso, offrire un pulsante “trasferimento”. Quando l’utente fa clic su questo pulsante, otterrà un “token”. Lei può usare questo token su un altro computer per resettare il cookie. In questo modo, l’utente decide quanto è sicuro di voler trasferire il token.

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

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

Se l’e-mail dell’utente è compromise e un utente malintenzionato riceve il link per primo, beh, tu sei un hosed. Ma l’utente ha anche problemi più grandi.

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

Bene, il token è sicuro quando viene passato attraverso SSL. Il problema che si presenterà è che è disponibile per le persone (coloro a cui non è destinato) grazie alla possibilità di visualizzare l’URL.

Se si tratta di informazioni private come SSN, non penso di inviare un URL tramite email. 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 è comprimato, verrà in questione la colpa di chi è veramente. Più è sicuro, meglio sei da un punto di vista strettamente CYA.

Veramente non lo ritengo abbastanza sicuro per una situazione in cui ci sono seri problemi di privacy. Il fatto che tu stia 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 sui token, che (mancando della struttura di un vero meccanismo di autenticazione) sono probabilmente più vulnerabili di un nome utente ben costruito e una configurazione della password.

Non ci sono problemi con i parametri in una richiesta https, tra l’altro.

Così com’è, sarebbe una ctriggers 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 degli intermediari. Le email sono molto rischiose e insicure.

Il migliore sarebbe un nome utente e l’autenticazione della password per accedere alle informazioni.

Mi piace l’idea del biscotto più o meno. 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 tutte le 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 il cookie può essere rubato = (.

Meglio lasciare che il cliente digiti la frase chiave che ha fornito, che viene 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 non rileva il cookie. Quindi il cookie può essere trasferito o impostato.

Assicurarsi inoltre che i dati sensibili siano crittografati nel database. Non si sa mai 😉

Sei a conoscenza del fatto che se un hacker ottiene l’accesso al tuo database molte informazioni personali possono essere fornite liberamente?

Dopo di ciò, direi che non è male come idea. Non userei MD5 o SHA1 perché non sono molto sicuri per l’hashing. Possono essere “decodificati” (so che non è crittografia) abbastanza facilmente.

Altrimenti potrei usare una seconda informazione che non sarebbe stata inviata via e-mail come una password. Il motivo è abbastanza semplice, se qualcuno ha accesso all’e-mail dell’utente (abbastanza facile con hotmail se non si uccide la sessione), avrà accesso a tutte le informazioni che l’utente ha inviato.

Tieni presente che HTTPS protegge e crittografa i dati inviati dal tuo sito all’utente finale. Nient’altro, prendilo come un tunel sicuro. Niente di più non meno di meno.

Da quello che capisco della tua idea, in teoria qualcuno potrebbe digitare una stringa casuale di 40 caratteri o hash MD5 e ottenere dettagli di qualcun’altro. Anche se questo può essere altamente improbabile, deve succedere solo una volta.

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