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

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ì:

  1. Invia l'accesso utente (invia nome + password) tramite $.ajax() a un https URI
  2. Crea un token tramite $token = bin2hex(openssl_random_pseudo_bytes(16));
  3. Salva $token , userid e data in un database (accessibile solo da SSL)
  4. Fa eco a $token e userid al client
  5. Salva $token e userid in html localStorage sul client
  6. Quando si esegue un $.ajax() dal client, invia sempre userid e $token come POST
  7. Server, abbina il $token fornito e verifica se è ancora valido (data non scaduta).
  8. 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?

    
posta Clawish 05.01.2015 - 16:47
fonte

4 risposte

8

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 ...

  1. Il codice viene verificato, testato e migliorato su un pubblico molto più ampio quando si utilizza uno schema di autenticazione integrato o ben noto.
  2. Quando e se te ne vai, qualcuno non è bloccato a gestire un meccanismo di autenticazione personalizzato
  3. 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.
  4. 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.
  5. 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

    
risposta data 05.01.2015 - 17:02
fonte
4

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.

    
risposta data 05.01.2015 - 17:03
fonte
4

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!

    
risposta data 05.01.2015 - 17:01
fonte
2

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".

    
risposta data 06.01.2015 - 04:14
fonte

Leggi altre domande sui tag