Progettazione di un sistema di autenticazione / reg password

Question

Progettazione di un sistema di autenticazione / reg password

#1 da (1 voti)

1

Sto progettando un sistema utente reg / auth per un sito web e ho creato questo design per l'autenticazione basata su password.

Mi piacerebbe sapere se questo è ragionevole. (ignorando i cookie per le credenziali di memorizzazione nella cache, oauth, ecc.)

Alcune cose che ho incorporato nel design, ma non sono sicuro di quanto "aiutino" la sicurezza:

nel caso in cui il server db sia compromesso, hashedPw viene inviato dal client in modo che saltedSecret possa essere riverificato. (hashedPw non è memorizzato sul server)
challenge (chalSecret) per impedire l'attacco di riproduzione
il costo di scrypt è regolabile nel tempo, ma poiché mi aspetto di usare un'implementazione javascript di scrypt nei browser forse non è una funzionalità così grande.

Un'altra domanda è se posso facilmente proteggere l'invio iniziale di saltedSecret durante la registrazione dell'utente, ma suppongo che l'utilizzo di HTTPS sia sufficiente per farlo.

Se ci sono modi in cui posso semplificarlo, faccelo sapere.

NOTA: leggi la sezione di modifica sottostante per le modifiche che semplificano questo design.

ModificaAlcunecosechemisonovenutedopoaverpostatoquesto:

TLS protegge dagli attacchi di replay , quindi posso rimuovere l'intera sezione della sfida.
sul lato server, dovrei (almeno) memorizzare un hash del saltedSecret. la cosa migliore è conservarne uno scrypt. Questo ha un buon effetto collaterale nel rimuovere il requisito dell'utente di inviare hashedPw durante il login.
Nuovo diagramma con queste modifiche:

authentication password-management scrypt

posta JasonS 02.04.2015 - 01:25

fonte

1 risposta

Leggi altre domande sui tag authentication password-management scrypt

Scelta di un codice e MAC per una connessione SSH Il port forwarding remoto VPN compromette l'anonimato dell'utente VPN?

score 1 · Answer 1

Il problema che vedo è che mentre ci si sforza molto per evitare di trasmettere la password degli utenti, saltedSecret è diventata essenzialmente una password.

La minaccia principale di una password trasmessa è che un MITM (man-in-the-middle) sarà in grado di osservarlo (in assenza di altre forme di crittografia) e accedere al sistema.

Se guardiamo a come un MITM potrebbe sfruttare il tuo sistema:

Osservano saltedSecret da una registrazione o da un login (flusso 1 o 7)
Fanno una richiesta di accesso e vengono informati di challengeSalt e chalCost prima di essersi autenticati. (flusso 2)
Usano il saltedSecret che sanno per generare chalSecret e login (flusso 7)

Tuttavia potresti parzialmente attenuarlo conservando saltedSecret e non inviando hashedPw o saltedSecret di nuovo nel flusso 7. Sarai comunque vulnerabile dall'iniziale saltedSecret nel flusso 5.

Questo è ancora problematico, anche perché hai bisogno di uno schema di salatura e di hashing anche sul lato server se memorizzi saltedSecret . Altrimenti se il tuo database è compromesso, in qualche modo possono usare questi valori per accedere al tuo sistema. Tuttavia, eliminando il saltedSecret non sarai in grado di ricostruire chalSecret sul lato server ed evitare di trasmettere saltedSecret generato dal lato client.

Generalmente la crittografia dei livelli di trasporto come TLS è considerata un controllo sufficiente contro gli attacchi MITM, quindi forse è necessario valutare se implementare l'hashing lato client attenui effettivamente qualsiasi minaccia significativa meglio di fare affidamento su TLS. Ad esempio, se TLS è compromesso, un MITM potrebbe probabilmente iniettare JavaScript per acquisire la password in qualsiasi modo.