Pin + guid in URL sicuro per un'app Web?

L'utilizzo del GUID come identificativo univoco per l'utente anziché l'indirizzo e-mail ha vantaggi contro gli aggressori a bassa potenza . L'URL-con-GUID è stato inviato tramite e-mail, quindi non può essere considerato veramente segreto. Gli aggressori motivati sputeranno le linee di rete e vedranno quell'e-mail. Tuttavia, i dilettanti oi robot di attacco automatici, pur non essendo in grado di leggere le email di altre persone, possono "indovinare" gli indirizzi email, ma non il GUID casuale.

Il GUID ha quindi qualche relazione con la sicurezza solo nella misura in cui è imprevedibile, e quindi porterebbe qualcosa di buono solo contro gli attaccanti che non sono molto potenti. L'uso del GUID non danneggia , ma non credo che in realtà aggiunga molta protezione. Potresti voler assicurarti che il GUID sia generato con l'algoritmo versione 4 , cioè 122 bit da un PRNG strong: sebbene il GUID miri a unicità , tu vuoi imprevedibilità , che è un'altra bestia; la versione 4 GUID garantisce entrambi.

Tenendo presente che il GUID non è (davvero) segreto, il sistema può essere descritto come tale: esiste una password di registrazione una tantum, che è un PIN di quattro cifre. Dopo la registrazione, viene utilizzata una normale password scelta dall'utente.

Il problema principale è che il PIN a quattro cifre è troppo facile da indovinare: un utente malintenzionato ha in media solo 5.000 tentativi prima di colpire quello giusto. È possibile attenuare questo problema disattivando il codice PIN dopo, ad esempio, tre tentativi errati per un determinato GUID; questo è il modello delle smart card , con il tuo server come la carta. Tuttavia, questo ostacolerà solo gli attaccanti che fanno una forza bruta online .

Sfortunatamente, occasionalmente, alcuni utenti malintenzionati possono dare un'occhiata ad alcune parti del database del server. Questo è un risultato frequente degli attacchi di SQL injection, ad esempio. I vecchi hard disk scartati sono anche una classica fonte di tali perdite. Questo è il motivo per cui prevedi di non memorizzare password di codici PIN, ma solo versioni con hash di questi.

Ma hashing delle password, anche se eseguito correttamente , solo rallenta gli attaccanti. Se il conteggio dell'iterazione è impostato in modo tale da richiedere un intero dieci secondi di calcolo per il server per verificare un codice PIN (e dieci secondi sono un tempo molto lungo per un cliente in attesa), e l'utente malintenzionato "solo" bisogno di 50000 secondi di calcolo, con lo stesso hardware, per "provare" 5000 possibili codici PIN. Dato che l'hacker introdurrà un paio di PC multi-core, probabilmente si spegnerà entro un'ora o due. Non è molto.

Suggerisco di utilizzare un codice PIN più lungo, ad esempio 8 cifre.

Per riassumere: il tuo GUID non è "abbastanza segreto" da tollerare un PIN di quattro cifre, anche per una pagina di registrazione una tantum. Usare un GUID invece dell'indirizzo email è interessante e vuoi che sia il più discreto possibile (quindi usa GUID "v4"), ma anche così, quattro cifre non sono sufficienti per un PIN quando il il sistema di verifica non è una smart card resistente alla manomissione. Utilizzare otto cifre (o più). Poiché l'utente digiterà il codice PIN una sola volta, può tollerare una sequenza piuttosto lunga (Microsoft potrebbe far digitare agli utenti le chiavi di attivazione di 25 lettere, quindi non penso che 8 cifre per la registrazione siano troppo chiedere).

Il PIN è molto debole contro la forza bruta se una e-mail è compromessa, tuttavia, questo potrebbe essere parzialmente neutralizzato semplicemente mettendo un blocco dopo, per esempio, 3 tentativi. Questo dà ad un attaccante un 1 su 3,333 possibilità di entrare. Non è ancora molto buono, ma potrebbe essere sufficiente a seconda del livello di sicurezza di cui hai bisogno. Verificherei anche la frequenza con cui vengono bloccati e se inizi a vederlo bloccato molto, lo cambierei perché mostrerebbe che qualcuno ti sta attaccando.

Se è comunque necessario utilizzare una password temporanea più lunga, sarebbe sicuramente preferibile, ma il blocco è un passaggio minimo che potrebbe essere utilizzato per rendere il sistema molto più sicuro di quello che è attualmente. (Ciò presuppone che i GUID siano generati anche in modo imprevedibile. Se i GUID sono prevedibili, il blocco non è sufficiente in quanto è possibile attuare attacchi contro un numero elevato di GUID e attaccare 3000 o giù di lì per ottenere un successo valido a meno che non siano GUID non può essere indovinato.)

1. Trovo che un numero di 4 pin sia un po 'corto quando potresti anche usare una stringa generata a caso che sarebbe più difficile da indovinare. Anche se un 40 char guid dovrebbe essere ok (assicurati che sia generato correttamente e non prevedibile)
2. 40 caratteri GUID sembrano abbastanza lunghi
3. L'hashing e la salatura di qualcosa che può essere solo un numero compreso tra 0000 e 9999 è un po 'eccessivo considerando che sarebbero necessari alcuni minuti per generare tutte le possibilità, anche con un'adeguata salatura.
4. Sembra buono, assicurati di utilizzare PBKDF2, bcrypt o scrypt su sale e memorizzare le password
5. Sembra buono

L'unica cosa che puoi ancora fare per renderla più strong è aggiungere l'autenticazione a due fattori. L'autenticazione a due fattori può quindi essere utilizzata anche in combinazione con la configurazione della password iniziale.

Devi fare un passo indietro e pensare al contesto.

"È abbastanza sicuro?" è una domanda inutile.

"È abbastanza sicuro per una banca che i clienti sono in pericolo di risparmiare sulla vita?" è una buona domanda.

Che cosa stai proteggendo con questo sistema? Che tipo di equilibrio vuoi raggiungere tra usabilità e sicurezza? Se questo è un sistema ad alta sicurezza, è necessario che gli utenti tengano traccia di un PIN a dieci cifre. Se stai proteggendo gli account di basso valore, allora 4 cifre probabilmente vanno bene.

Descrivi il perno a 4 cifre come non univoco. Non dovresti davvero preoccuparti dell'unicità, dovresti preoccuparti della prevedibilità e della forza bruta. L'utilizzo di un potente generatore di numeri casuali ti aiuterà con la prevedibilità, l'uso di un PIN più lungo e il blocco dei blocchi ti aiuterà con attacchi di forza bruta.