Analizza il mio schema di autenticazione web personalizzato, basato su un token derivato da username e password

Question

Analizza il mio schema di autenticazione web personalizzato, basato su un token derivato da username e password

#1 da (8 voti)
#2 da (4 voti)
#3 da (4 voti)
#4 da (2 voti)

2

Per evitare che l'utente possa accedere ogni volta che scade la sua sessione, voglio implementare un sistema di autenticazione basato su token.

Il mio schema funziona così:

Invia l'accesso utente (invia nome + password) tramite $.ajax() a un https URI
Crea un token tramite $token = bin2hex(openssl_random_pseudo_bytes(16));
Salva $token , userid e data in un database (accessibile solo da SSL)
Fa eco a $token e userid al client
Salva $token e userid in html localStorage sul client
Quando si esegue un $.ajax() dal client, invia sempre userid e $token come POST
Server, abbina il $token fornito e verifica se è ancora valido (data non scaduta).
Se è tutto a posto, continua a consegnare il materiale richiesto

Puoi analizzare il mio schema?

Molte persone sconsigliano l'implementazione di processi di autenticazione personalizzati, in quanto sono spesso vulnerabili agli attacchi. Questo mi fa sospettare che il mio approccio potrebbe avere anche dei difetti. Puoi rivelare questi difetti a me?

authentication ajax web-application

posta Clawish 05.01.2015 - 15:47

fonte

4 risposte

Leggi altre domande sui tag authentication ajax web-application

Il seguente generatore di password è sicuro? Fingerprinting OS: posso contare sui risultati?

score 8 · Answer 1

Quindi ci sono alcuni motivi per cui non vuoi farlo, anche se non capisco il codice che hai presentato in quanto non lo affronterò. È necessario utilizzare una libreria di terze parti per gestire le sessioni. Ci sono diversi motivi ...

Il codice viene verificato, testato e migliorato su un pubblico molto più ampio quando si utilizza uno schema di autenticazione integrato o ben noto.
Quando e se te ne vai, qualcuno non è bloccato a gestire un meccanismo di autenticazione personalizzato
Probabilmente ci sono vulnerabilità nel codice, potrebbe essere o non essere direttamente nel tuo codice ma in un servizio che chiami, aggiornando quel singolo servizio potrebbe causare problemi attraverso il resto del codice, come argomenti e variabili deprecati. Questo potrebbe non rendere il tuo programma meno sicuro ma potrebbe romperlo.
L'autoassistenza è dura, soprattutto quando fai un buon lavoro e funziona senza problemi per un anno o due, poi bam !! nel bel mezzo di un altro progetto qualcosa si rompe e devi prenderti del tempo per risolverlo dal basso verso l'alto.
CYA, se commetti un errore e succede qualcosa di brutto, sei la persona alla quale torni e chiedi, perché non hai usato questo o quello schema che non è vulnerabile ad alcuni attacchi e dovrai spiegare che.

Comunque, spero che aiuti

score 4 · Answer 2

Non male come inizio. Alcune cose da guardare:

Se l'accesso fallisce, non rivelare se l'utente esiste
Implementa una qualche forma di protezione da forza bruta
Fornire una funzione di modifica della password; richiede la password precedente
Esegui il controllo della forza della password
Le sessioni di solito hanno sia inattività che timeout assoluti
Conserva le password in modo sicuro, ad es. bcrypt
Utilizza un token anti-CSRF
Consenti agli utenti di gestire autonomamente le sessioni

E questa è solo l'autenticazione e la gestione delle sessioni. C'è tutta una serie di altre considerazioni sulla sicurezza: SQL injection, cross-site scripting, uso di SSL / TLS, ecc.

La maggior parte delle librerie di autenticazione NON risolve tutti questi problemi nella configurazione predefinita.

score 4 · Answer 3

A prima vista, con un MITM posso solo accedere alla tua webapp fintanto che uno dei tuoi utenti sta usando il mio "wifi"

Inoltre, perché usare qualcosa di non provato quando puoi usare una tecnologia comprovata (OAuth2 sarebbe sufficiente per i tuoi scopi e che è stato testato per la sicurezza)

E non hai alcun controllo per forzare il tuo "token", il che significa che posso forzare la forza bruta non appena ottengo un "userid" (probabilmente un numero così facilmente ipotizzabile).

Inoltre, questo esempio manca di protezione contro le iniezioni SQL, il che significa che potrei semplicemente fornire a mysql un token valido e accedere all'account di chiunque.

Risolviarli tutti (senza creare backdoor nascoste / etc) è quasi impossibile per un uomo. Basta usare una delle librerie disponibili dalla comunità open source, una che è stata testata e verificata!

score 2 · Answer 4

Se si utilizza il modello di ID sessione standard e lo si implementa utilizzando un cookie persistente anziché il tipico cookie di sessione, si ottiene esattamente ciò che viene descritto, solo che si ottiene un'implementazione professionale del browser.

Ricorda: non solo il tuo algoritmo ha dei difetti, ma anche la tua implementazione può presentare dei difetti. Più devi implementare, maggiore è il tuo rischio. Lawri ha sottolineato che ora sei responsabile di assicurarti che non ci siano attacchi SQL injection nel tuo sistema.

Se veramente vuoi fare da te, il modo corretto per controllare l'algoritmo è identificare come qualcuno può usare le informazioni. Come hai scritto, l'unica differenza tra il tuo token e una password è che il token termina tecnicamente (lato server). Di conseguenza, dovresti scrivere il tuo codice trattando i token con la stessa cura e attenzione che daresti per l'archiviazione e la trasmissione di una password.

A un minimo assoluto, devi implementare SSL per proteggere dagli attacchi di sniffing in stile Firesheep come menzionato da Lawri. Se non lo fai, probabilmente non dovresti implementare i tuoi sistemi ID sessione quando questo è generalmente riconosciuto come un "problema risolto".