Cosa c'è che non va nel mio schema di autenticazione?

Sì, questo non è sicuro come specificato.

Il tuo design sembra vulnerabile agli attacchi di falsa richiesta tra siti (CSRF noti anche come XSRF) (è necessario aggiungere un Token CSRF con tutte le azioni POST visualizzate con il modulo e memorizzate in un cookie di sessione). Fondamentalmente, se un utente accede ad un altro sito Web (email, forum, blog) mentre è collegato al tuo sito web, il browser potrebbe essere forzato (tramite javascript, da un modulo segreto) a fare una richiesta POST non desiderata al tuo sito web facendo qualche azione che Non voglio.

Anche il tuo schema non è particolarmente specifico.

• Come vengono gestite le password (bcrypt o PBKDF)? O almeno un hash salato? Sono controllati con un confronto costante di stringhe temporali?
• Come vengono protetti i dati sulla rete durante il transito (HTTPS?),
• Come vengono inseriti / estratti i dati dal database? Dichiarazioni preparate (note anche come query parametrizzate) ovunque? (Ottimo!) O esegui una stringa con un comando SQL che contiene l'input dell'utente (vulnerabile!)?
• In che modo vengono memorizzati i token nel browser (cookie protetti solo HTTP?)

Molto probabilmente potrebbero anche essere altri difetti nell'implementazione.

Quello che presenti non è un protocollo di autenticazione; è semplicemente un concetto , ovvero il concetto di un token di sessione .

In parole semplici:

• Il server autentica il client e restituisce una chiave segreta a quel client (il token di sessione).
• Quando il client torna, mostra il token sul server per dimostrare che si tratta dello stesso client di prima.
• Il client può richiedere al server di dimenticare il token (ovviamente, e contrariamente a quello che mostri, anche la richiesta di "logout" dovrebbe includere il token, altrimenti chiunque potrebbe disconnettersi da tutti gli altri).

Non c'è nulla di sbagliato in questo concetto, purché tu ne comprenda i limiti. Ad esempio, si basa intrinsecamente sulle comunicazioni client / server per essere sia confidenziali (in modo che nessun attaccante passivo origlia sul token) e resiliente alla manomissione (in modo che nessun attaccante attivo possa dirottare la connessione subito dopo l'autenticazione). In poche parole, SSL (ad esempio HTTPS) è obbligatorio.

Sono d'accordo con te: questo schema sembra facile da costruire. Ma attenzione: è un'illusione. In realtà, non è affatto semplice costruire un sistema di sessione autenticato sicuro, anche se il concetto è chiaro e semplice. Costruire un sistema che funziona è facile e può essere testato; la sicurezza, tuttavia, non può essere testata e richiede molto più lavoro del solito.

C'è un numero incredibilmente alto di modi in cui la realizzazione può far deragliare. @jimbob ne fornisce alcuni (e l'elenco non è esaustivo). L'arte della sicurezza informatica non significa che il sistema funzioni correttamente in condizioni normali; si tratta di fare in modo che i sistemi non funzionino troppo impropriamente in condizioni anormali.

La cosa divertente nel fornire un generico 'succo' di un flusso di autenticazione è che, a meno che tu veramente rovini il flusso, probabilmente non troverai problemi seri perché non c'è abbastanza dettaglio dire in un modo o nell'altro Più spesso che no, è l'implementazione che è difettosa.

Questo è ulteriormente complicato dal fatto che non si specifica cosa si sta proteggendo contro. Passare solo un nome utente e l'accesso è perfettamente sicuro * - nelle giuste condizioni. La domanda che devi porci è chi o cosa stai cercando di proteggere contro e se il tuo flusso di autenticazione ha fornito misure protettive contro ciò che quei cattivi ti daranno.

Hai menzionato le password ... come stai verificando le password?

Token di sessione ... come li stai generando, come li stai memorizzando sul server, come li stai memorizzando sul lato client, come stai convalidando il token su "any-action"?

Altre domande, ecc ...

Questo è il motivo per cui ti consigliamo di non costruirti. Le probabilità sono buone, non hai pensato ad ogni angolazione, mentre gli sviluppatori di un noto componente potrebbero avere. Ad esempio, dire che generare un token di sessione è "solo un dettaglio di implementazione" non è del tutto scorretto, ma è un dettaglio serio che ti rovinerà timidamente se lo rovini.

Quindi la mia risposta alla tua domanda è: sì, è insicuro perché non ci sono abbastanza dettagli da dire in un modo o nell'altro.

* Beh forse no, ma hai capito il punto.