Fornire agli utenti inesistenti con sali falsi impedisce l'enumerazione degli utenti?

Naviga le tue risposte
4

Sfondo

Attualmente sto impostando un nome utente e un ampli di base; processo di accesso basato su hash per un'applicazione web. Il processo consiste dei seguenti passaggi:

  1. L'utente invia il suo nome utente.
  2. Il server risponde con salt.
  3. L'utente hash la password e la invia e il nome utente al server.
  4. Il server autentica l'utente.

Ovviamente questo è un po 'semplificato e più passaggi durante il processo di hashing vero e proprio.

Quello che vedo qui è un potenziale di enumerazione dei nomi utente esistenti. Se un utente malintenzionato invia un nome utente non esistente, non verrà fornito alcun valore, suggerendo all'utente malintenzionato se il nome utente è in uso o meno.

Domanda

Quando viene fornito un nome utente non esistente, se dovessi fornire un valore salt saltuario, impedisce all'hacker di enumerare gli utenti esistenti?

Tale precompressione sarebbe così piccola da poter essere saltata?

Le preoccupazioni

  • Un utente malintenzionato potrebbe vedere che il server emette solo valori casuali.
posta Alex 27.10.2015 - 11:10
fonte

1 risposta

3

Il problema principale con il sistema proposto è che un utente malintenzionato probabilmente non si preoccuperebbe di ottenere la fase salt. Non è necessario: la password salata è una password equivalente, quindi è più semplice saltare al punto 3 e inviare hash pregenerati al server.

In termini di enumerazione del nome utente, sì, sarebbe possibile determinare se un utente esiste data la risposta di sale o meno. A seconda del sistema, potrebbe anche essere possibile determinare se un utente esiste richiedendo lo stesso nome utente due volte. Se si ottiene la stessa quantità di sale (che è necessario utilizzare, per mantenere l'archiviazione sul lato server della password sicura) per due chiamate, è possibile essere certi che l'utente sia reale. Puoi attenuarlo memorizzando i sali che hai inviato (il risultato è che il tuo DB utente è pieno di spazzatura dopo un paio di tentativi di attacco) o generandoli algoritmicamente dal nome utente (che dovrebbe essere applicato a tutti gli utenti per impedire enumerazione cercando quelli che non sono generati in questo modo).

Il sistema proposto in realtà non offre alcun miglioramento della sicurezza rispetto a un accesso standard nome utente / password, servito su HTTPS, ma aumenta l'area di attacco e le informazioni che gli utenti malintenzionati hanno sul tuo sistema. In particolare, sanno che le vere password sono hash, con un sale noto - sono una lunghezza specifica, contengono caratteri specifici (probabilmente cifre esadecimali) e sono output validi per stringhe contenenti il sale.

Suggerirei di attenersi al metodo collaudato di username / password su HTTPS!

    
risposta data 27.10.2015 - 11:36
fonte

Leggi altre domande sui tag

Come personalizzare i permessi / proc? Firma del codice Java contro sandboxing