Login: hash password contro decrittografia riuscita

Question

Login: hash password contro decrittografia riuscita

#1 da (4 voti)

2

L'utilizzo di una funzione a senso unico (ad esempio BCrypt) per la gestione delle password in accesso basato su password è un approccio comune.

Quando un'applicazione utilizza una chiave derivata dalla password dell'utente per crittografare una chiave privata, è sicuro affidarsi a una decifrazione corretta all'accesso?

Esempio:

Registrazione (tutti i passaggi eseguiti dal lato client):
1. Ricava una chiave (A) dalla password dell'utente (ad esempio utilizzando PBKDF2 con iterazioni di 100k).
2. Utilizza la chiave A per crittografare la chiave privata dell'utente (utilizzando la crittografia autenticata, ad esempio AES in modalità GCM).
3. Archivia le informazioni richieste nel record del database dell'utente (ad esempio ciphertext, salt, ...).
Login (tutti i passaggi eseguiti sul client):
1. Carica il record del database dell'utente per nome utente.
2. Ricava la chiave (B) dalla password dell'utente (utilizzando lo stesso metodo utilizzato per la registrazione).
3. Prova a decodificare la chiave privata degli utenti utilizzando la chiave B.

authentication encryption hash

posta Ratlos 12.01.2018 - 22:57

fonte

1 risposta

Leggi altre domande sui tag authentication encryption hash

Meltdown and Spect vs. tempistiche di dcache e problemi di perdita di dcache In che modo LBaaS / DBaaS o "auto-ridimensionamento" aiutano a proteggere da DoS?

score 4 · Accepted Answer

Sì, questo è un approccio praticabile, quando utilizzi la crittografia autenticata, come hai indicato. Il tag di autenticazione sui dati crittografati è analogo a un hash della password memorizzato e GCM è progettato specificamente per impedire la contraffazione dei messaggi (cioè un tag valido costruito senza accesso alla chiave privata).

In effetti, GMAC è una variante della modalità GCM progettata per non crittografare i dati, ma solo per fornire una firma con una chiave condivisa su alcuni dati.

È importante notare che questo non dovrebbe essere fatto con cifrari non autenticati, poiché anche con il padding usato per rilevare la decifrazione "corretta", ciò porterebbe a una probabilità (leggermente migliore) di 1/256 di qualsiasi password che funzioni correttamente avendo il padding corretto nonostante sia la chiave errata.

Tutto ciò detto, non penso che questa sia una buona idea, perché è molto più facile avere errori di implementazione in questo rispetto a uno schema di archiviazione delle password standard. Attaccare questo schema è ugualmente facile / difficile attaccare un hash PBKDF2 separato per la password dell'utente, che è un meccanismo di autenticazione ben studiato. Se sei preoccupato del tempo della CPU con il calcolo di due hash PBKDF2, puoi eseguire le seguenti operazioni:

Calcola key = PBKDF2(Password, Salt, N) per ricavare la chiave simmetrica.
Calcola pwhash = PBKDF2(Password, Salt, N+1) per derivare l'hash della password memorizzata. (Questo può essere fatto con un solo giro in più sull'hash originale sopra.)

Invertire PBKDF2(Password, Salt, N+1) in PBKDF2(Password, Salt, N) equivale a invertire HMAC su qualsiasi funzione di hash che usi.

Lo schema sopra riportato è lo schema utilizzato da Lastpass per l'autenticazione e la decrittografia del vault della password. (Solo pwhash viene inviato al loro server in modo che non possano recuperare la chiave per il vault della password da quello.)