La mia strategia di autenticazione è protetta?

0

Voglio implementare un sistema di autenticazione seguendo le buone pratiche, lo voglio il più semplice possibile e sicuro (non sto per implementare qualche funzione di hashing magica o qualcosa per sentire un eroe ..) volendo solo usare l'hash già noto ma non sono sicuro del modo giusto di usarlo. Ho letto alcuni articoli su come Lastpass (una società di gestione delle password) mange per gestire la loro autenticazione e mi è piaciuta molto la loro idea. Quindi volevo implementare la mia autenticazione basata su di essa.

Fondamentalmente sto creando una chiave di autenticazione dalla password sul lato client (quindi la password non viene mai inviata come un testo del piano al server). quella chiave di autenticazione che invia al server piuttosto che alcune operazioni di hashing anche sul lato server e confronta il risultato con quello all'interno del database.

Sul mio lato client:

auth_key = PBKDF2(SHA256, password+username, last_login_fe_salt, fe_rounds)

spiegazione - hashing password + nome utente + last_login_fe_salt testo fe_rounds volte

last_login_fe_salt - > un salt casuale inviato all'utente una volta inserito il proprio nome utente nel campo di testo - Per essere onesti, non sono sicuro di come questo last_login_fe_salt sia efficace per la crittografia contro gli attacchi di dizionario, ma almeno due persone che hanno la stessa password invieranno hash diversi sulla loro rete. qualsiasi hacker può ottenere questi dati chiedendo dal server, posso aggiungere limitazioni lato server (req / s se fa qualche differenza ecc. fammi sapere cosa ne pensi) anche l'aggiunta di captcha potrebbe essere una buona idea. Quando un utente ha effettuato correttamente l'accesso, il server genera una nuova stringa casuale e salva nel database.

* Non ho visto alcuna spiegazione quale sale che Lastpass utilizza sull'hash del lato client, stanno usando l'algoritmo PBKDF2 che ha bisogno di un parametro salt.

fe_rounds - > numero di round dati dal server durante la digitazione del nome utente -  è fisso per tutti e configurabile dal server, anche negli articoli che ho letto su Lastpass non spiegano da dove ricevono il numero lato client di round ...

così ora inviamo auth_key come è per il server ...

Sul mio server

ora stiamo creando un nuovo hash per confrontare quello all'interno del db. Perché un altro hash? se capisco correttamente leghiamo l'hash per i dati lato server, come una combinazione di una password (che solo l'utente conosce) e dati del server.

db_auth=PBKDF2(SHA256, auth_key, user_be_salt, 100,000+user_configurable_rounds)

user_be_salt - > un numero casuale salvato in db noto solo al server e quelli che ottengono il database, questo cambia ad ogni accesso riuscito.

user_configurable_rounds - > numero di iterazioni, ogni utente può scegliere la quantità di iterazioni (come in Lastpass), quindi l'attaccante deve anche indovinare il numero o le iterazioni?

Sarei felice di sentire cosa ne pensi di questo sistema di autenticazione, se è sbagliato, ma spiegami perché e dimmi cosa fa Lastpass perché non ho capito tutto il loro flusso di autenticazione.

    
posta Lihai 26.07.2017 - 14:42
fonte

1 risposta

1

Nel complesso non è male, con alcuni difetti nei dettagli.

  • Se last_login_fe_salt è casuale e cambia ogni accesso, il risultato PBKDF2 inviato al server non riesce. Questo deve essere memorizzato nel record del server per quel nome utente e mantenuto lo stesso.

    • Anche i turni devono essere mantenuti uguali e memorizzati per nome utente, quindi puoi cambiare i valori predefiniti.
    • Se vuoi la possibilità di cambiarli, devi essere in grado di inviare al client due conteggi di sale e due di iterazione; vecchio e nuovo; poi torni entrambi i risultati; eseguire sia tramite l'algoritmo sul lato server, quindi convalidare il vecchio risultato e, se valido, memorizzare il nuovo risultato.
  • Perché non usi SHA-512? Le operazioni a 64 bit richieste riducono il margine di vantaggio che gli attaccanti basati su GPU hanno sui sistemi basati sulla CPU.

  • Non inserire hardcode sul lato server di 100.000; se lo vuoi davvero, allora
    • memorizza i round del server richiesti dal sistema e i round del server richiesti dall'utente in campi separati
    • considerare di spostare l'arrotondamento utente aggiuntivo di sicurezza sul lato client; altrimenti colpirete attacchi denial of service con pazzeschi conteggi ricorrenti usando tutta la vostra CPU!

Congratulazioni per aver scelto una funzione di hashing della password chiave iterata ben nota con un numero di tondi ragionevole!

    
risposta data 10.01.2018 - 05:01
fonte

Leggi altre domande sui tag