Soluzione accettabile per gli utenti che possono accedere solo con un breve codice univoco (nessun nome utente)

Ho un approccio simile per alcuni servizi Web su cui ho lavorato, questa è effettivamente un'autorizzazione basata su token.

Per mantenerlo più sicuro manterrei comunque tutti i token di autenticazione allo stesso modo delle password.

Potrebbe anche essere necessario ricordare che se un utente può modificare il proprio token, potrebbe essere possibile per loro creare una collisione con un altro token utente.

In definitiva, sei tu a dover decidere quale sistema è abbastanza sicuro per il contesto, perché sarà basato sul tuo modello di minaccia, ma possiamo certamente fornire alcune informazioni per aiutarti a prendere quella decisione .

Quindi, alcuni punti:

1. Il metodo di generazione dovrebbe essere un dato. Dal set di input a tua disposizione, (siano essi caratteri alfanumerici, un elenco di parole o qualsiasi altro insieme di componenti un sottoinsieme casuale di cui alla fine sarà il codice) ogni elemento dovrebbe essere selezionato utilizzando un psuedo crittograficamente sicuro generatore di numeri casuali. Quindi, questo risolve il problema di come generare i codici e lascia solo il problema di cosa dovrebbero consistere i codici.

2. Per gli elementi selezionati casualmente, l'entropia, che determina il livello relativo di sicurezza, si basa sul numero di elementi potenziali da cui si sceglie e su quanti di questi output si mettono insieme. Quindi, per un codice di 6 caratteri, l'utilizzo di tutte le 26 lettere maiuscole e 10 cifre ti darà poco più di 2 miliardi di possibili codici (36 ^ 6 o 36 * 36 * 36 * 36 * 36 * 36) per ~ 31 bit di entropia . (36 ^ 6 equivale approssimativamente a 2 ^ 31) Ora, se dovessimo proteggere gli hash delle password contro gli attacchi brute force offline, questo non sarebbe sufficiente per essere sicuro. Nel tuo caso però, se è come sembra, non proteggono realmente nulla, ma servono di più per identificare gli utenti al primo accesso, poi accoppiato con misure di sicurezza aggiuntive ragionevoli come la limitazione della velocità dei tentativi di accesso e la protezione dell'accesso al database e al database correttamente, potrebbe essere perfettamente adeguato.

3. Se invece dovessi utilizzare l'elenco di diceware di 7.776 parole e scegliere tre parole casuali dall'elenco, il numero di potenziali codici salirà a oltre 480 miliardi (7776 ^ 3 o 7776 * 7776 * 7776) che fornisce oltre 38 bit di entropia. (7776 ^ 3 è compreso tra 2 ^ 38 e 2 ^ 39) Ancora non eccezionale per la password di un utente, ma abbastanza probabilmente abbastanza per un codice predefinito. Inoltre, AOL utilizzava questo sistema per le password predefinite per anni e sembrava funzionare abbastanza bene per loro. (E hanno usato solo due parole!)

4. Se vuoi usare la costruzione [aggettivo] [sostantivo], dovrai calcolare quanto sicuro sarà basato sulla lista di parole che usi. Per due parole, moltiplichi il numero di parole nella lista di aggettivi per il numero di parole nella lista di nomi per ottenere il numero di potenziali codici casuali. Un numero maggiore significa più sicurezza. Quindi, se hai 2000 aggettivi e 4000 nomi, il tuo livello di sicurezza sarà 2000 * 4000. Se hai aggiunto un secondo aggettivo, 2000 * 2000 * 4000.

Quindi, ora che sai come misurare la forza relativa dei codici generati utilizzando diversi tipi di componenti di input, puoi prendere una decisione più informata su quale ti darà il margine di sicurezza di cui hai bisogno, e poi ci sono poche altre cose a cui pensare per il sistema nel suo complesso.

1. Come accennato in precedenza, i tentativi di utilizzo del codice limite di velocità. Per un sistema di nicchia con una piccola base di utenti, non c'è motivo per cui sia necessario consentire al sistema di elaborare centinaia o migliaia di tentativi di accesso al codice al secondo. L'unica cosa che causerebbe quei volumi di traffico sarebbe un attacco di forza bruta online.

2. Proteggi il tuo database. Se hai vulnerabilità di SQL injection nel tuo sito web, non importa quanto siano validi i tuoi codici ... L'hacker li scarterà dal database e li userà a suo piacimento.

3. Elimina i codici usati. Dal momento che vengono utilizzati solo per l'accesso iniziale al sistema, presumibilmente gli utenti possono scegliere una propria password in quel punto e il codice diventa ridondante. Non dovrebbero essere lasciati nel sistema in uno stato in cui possono essere riutilizzati dopo quel punto per accedere all'account dell'utente.

Da quello che hai detto, sembra che il livello di rischio qui sia relativamente basso, quindi non so che sarei troppo preoccupato, qualunque cosa tu scelga. Speriamo che le indicazioni sopra riportate ti aiutino ad essere più a tuo agio con la tua decisione, e meglio in grado di giustificare che la decisione che hai preso sia effettivamente sufficientemente sicura per il sistema in questione.

Hai diverse opzioni per codici come questo. Presumo che la tua idea sia di usare il codice come login principale dell'utente e non ci sarebbe una password separata. Hai diverse parti della domanda, inizierò con "è sicuro?"

Risposta breve, probabilmente non abbastanza. E non è solo per il contesto di invito solo e nessun motivo. C'è sempre un motivo, anche se è solo "per il lulz". Solo perché il sito non è indicizzato ed è solo ad invito, non significa che alcuni blackhat non lo trovino e vogliano giocare. Potrebbero non sapere di non avere informazioni potenzialmente preziose oltre all'accesso. Quanto di un problema sarà se qualcuno ottiene una copia del tuo database? Quanto di un problema se il codice di qualcuno viene rubato?

5 caratteri potrebbero essere sufficienti per un codice di invito, ma come accesso è irragionevolmente breve, anche se c'è un numero molto basso di utenti. Con la dimensione del tuo codice, hai tra 30 e 60 milioni di combinazioni a seconda dell'algoritmo di generazione e se stai limitando i caratteri per evitare confusione "O vs 0". Il codice può sempre essere suddiviso in sezioni per semplificare la digitazione, ad esempio A1C-B2X-YP3. 9 caratteri saranno almeno trilioni di combinazioni.

In termini di generazione dei codici, uno è più corto ma casuale, l'altro è più lungo e naturale. Scegliere un codice di lingua naturale significa che l'utente deve digitare più informazioni, e può anche limitare la quantità di combinazioni se viene ordinato di apparire naturali come una frase. Come gestisci un refuso? Cosa succede se un errore di battitura genera un accesso valido? Chiamando l'opzione della lingua naturale una "passphrase" può migliorare le cose per l'utente, in quanto la percezione di ciò che è può influenzare la capacità di richiamarlo e di non lasciarsi intimidire da esso. L'altro problema con un codice di linguaggio naturale è che a un utente potrebbero non piacere alcune delle parole, o la loro combinazione, potrebbero trovarle offensive, di cattivo gusto o avere qualche brutta memoria. Ad alcune persone, ad esempio, non piace la parola "umido".

Come utente preferirei un codice più "codey". Potrebbe esserci una verifica della cifra di controllo sul lato client prima del codice utilizzato per l'accesso. Limitare la quantità di tentativi di accesso funziona molto meglio se qualcuno non può inserire un codice ovviamente non valido. Io uso un algoritmo per generare codici come quello usando una permutazione pseudocasuale chiamata Molibdeno, fondamentalmente un codice a blocchi personalizzato simile a ALTA . Internamente è 5 valori a 8 bit, esternamente è 8 valori a 5 bit, codificati in 32 caratteri alfanumerici, con "OIZS" omesso da non confondere con "0125". Aggiungi una singola cifra di controllo alla fine, ed è composta da 9 cifre, che sembra carina suddivisa in 3 gruppi di 3. Rivedo regolarmente codici molto più lunghi nelle mailing. I nuovi codici vengono generati crittografando un contatore incrementale, quindi è garantito che non vengano ripetuti. Generare codici in modo casuale richiede un controllo contro tutti i codici in uso per assicurarsi che non ci sia una collisione. Usare una permutazione per generare codici significa che l'accesso ad esso deve essere limitato.

Potresti anche forzare un tipo specifico di sequenza come un codice postale canadese, che sta alternando lettere e numeri. NLN-LNL-NL (N) come 5A9-F4E-0L0 ti limitarebbero a 4,6 miliardi di codici, ma potrebbero essere più facili da ricordare e più facili da capire quando qualcuno sta riscontrando un problema. Supporrei che gli utenti non provassero a ricordare, ma piuttosto a tenerlo scritto da qualche parte.

Se un codice viene utilizzato come invito, i codici brevi sono ok, purché siano limitati nel tempo e utilizzati una sola volta. Suppongo che gli utenti non abbiano password e solo il loro ID utente. In tal caso, potresti considerare un codice di invito come aggiunta all'ID utente, utilizzato solo quando qualcuno deve chiamare il supporto come autenticatore aggiuntivo. In questo modo useranno il codice di invito per ottenere il loro codice utente al momento della registrazione, quindi il codice di invito viene disattivato, ma memorizzato con l'account. Solo il codice di invito verrebbe mai inviato per posta.

Se non sei vittima di un attacco mirato contro il tuo sistema e segui le migliori pratiche per proteggere il sito e il database, probabilmente starai bene. Esistono molti modi per archiviare ed elaborare i dati di accesso, che è probabilmente al di fuori della portata della domanda, che possono influire sulla sicurezza del sistema. Controllare la generazione e la ricerca di codici da parte del personale di supporto è una buona idea. Ho fatto alcune assunzioni qui a causa delle informazioni limitate riguardanti la base di utenti e il sito, speriamo che questa risposta sia ancora pertinente.