Cosa c'è di sbagliato in questo sistema di autenticazione?

Suppongo che l'ID utente sia attribuito in modo casuale e uniforme tra i 2 ³² possibili valori a 32 bit. In tal caso, la cosa migliore che un utente malintenzionato può fare è provare potenziali ID utente (valori a 32 bit) in qualsiasi ordine finché non ne viene trovato uno corretto. Se ci sono N ID utente valido, allora il numero medio di tentativi che l'attaccante dovrà eseguire sarà vicino 2 ³² / (N + 1) : se ci sono un migliaio di utenti, l'utente malintenzionato dovrà connettersi circa 4 milioni di volte al server prima di ottenere l'accesso. Una volta che l'attaccante ottiene l'accesso, può riutilizzare l'ID a proprio piacimento.

La tua unica difesa in quel caso è cercare di rilevare un tale forzamento bruto, ad es. vietando gli indirizzi IP dai quali provengono troppi tentativi falliti. Questo ha limitazioni; in particolare, quando molte persone sono dietro qualche tipo di proxy Web o NAT , possono, dal tuo punto di vista, condividere lo stesso indirizzo IP, quindi rischi di disabilitare una perdita di utenti con una strategia di blocco. Viceversa, gli attaccanti possono noleggiare botnet per eseguire la loro forza bruta unica da molti indirizzi IP distinti.

Un modo per guardarlo è in effetti considerare l'ID utente come una sorta di password; in tale vista, l'utente malintenzionato può attaccare le password simultaneamente per tutti gli utenti. Il livello di sicurezza viene quindi abbassato quando ci sono più utenti, come si può vedere nell'espressione matematica sopra: più utenti significano più bersagli per l'attaccante, senza aumentare il costo di ricerca.

Una strategia di login + password è ciò che fa la maggior parte delle persone. Questo è molto meglio: quando si tenta di forzare una password, l'utente malintenzionato deve selezionare un nome utente specifico e sarà in grado di interrompere solo quella specifica password. Il "nome utente" è un'informazione non segreta specifica per ciascun utente. Con i nomi utente, il compito dell'aggressore non è più mille volte più facile quando ci sono migliaia di utenti. Per quanto riguarda un "token di sessione", beh, ci sono diversi metodi che sono più o meno equivalenti (token nell'URL, token come parametro POST, token come intestazione HTTP - noto anche come "cookie" -, e presto); Lo stesso SSL ha la sua nozione di sessione e potresti riutilizzarlo.

Riepilogo: l'"ID utente segreto" senza la strategia del nome utente può essere sicuro, ma solo se lo spazio del possibile ID utente è abbastanza grande da sconfiggere la forza bruta , anche se ci sono molti ID utente validi. Ciò richiede un ID utente di grandi dimensioni che deve essere selezionato in modo casuale e uniforme. 128 bit sarebbero sufficienti. 64 bit mi renderebbero piuttosto nervoso. 32 bit sono troppo piccoli.

La semplice argomentazione è che 32 bit sono ben entro i limiti di forzatura bruta, a seconda di quanti attacchi al secondo è possibile, probabilmente ci vorrà qualcosa nell'intervallo da una settimana a un anno per cercare l'intero spazio. Dividi questo tempo per il numero di utenti e hai un intervallo di tempo approssimativo per l'attaccante per trovare un account.

Non conosco i dettagli dell'implementazione, una limitazione delle richieste di accesso per IP rende un attacco più difficile, ma probabilmente non abbastanza più difficile. È possibile dedurre lo spazio ID solo guardando il codice pubblico? Al momento la tua difesa più strong potrebbe essere che non molti sanno che tutti gli ID utente sono interi. Non è qualcosa su cui fare affidamento, ma un attacco di forza bruta del dizionario senza la conoscenza di interi sarebbe molto più difficile.

Inoltre, chiunque abbia scritto questo codice in primo luogo ovviamente non è molto attento alla sicurezza, sembra probabile che ci possano essere altri problemi. Falso richiesta cross-site, iniezioni SQL, o forse anche codice C "veloce" con buffer underrun vecchio-scuola.