Avrebbe usato una password già con hash + salted essere sicuro?

Question

Avrebbe usato una password già con hash + salted essere sicuro?

#1 da (2 voti)
#2 da (0 voti)

3

Alcuni principi di base della sicurezza della password:

Hash e usa salt
Le persone che memorizzano la password non dovrebbero mai essere in grado di vedere quale sia la password, solo l'hash
Questo hash dovrebbe essere difficile da decifrare

Supponendo che ci stiamo registrando per un sito che implementa una buona sicurezza della password. E se dovessimo prendere una password facile da memorizzare (non necessariamente deve essere una password debole) ed eseguire i passaggi che un sito Web farebbe con la password e utilizzare il risultato come nostra password effettiva? I vantaggi (e, per favore, correggimi se sbaglio) sono:

Se il cracker non sta bersagliando questo specifico individuo, ma piuttosto bruteforcing di un modulo di accesso, la password non dovrebbe essere più facile da decifrare
Ottieni automaticamente una password sicura. L'utente deve solo ricordare la password "debole" (si pensi alle frasi di passaggio per le chiavi SSH). Se l'utente decide di utilizzare una password "strong" come seme e scriverlo, fai finta di tenere il documento in una cassastrong chiusa protetta da una protezione armata o qualcosa del genere.
Se il cracker determina che questo è il metodo utilizzato, ci vorrebbe molto più tempo perché l'hashing stesso richiede tempo alla CPU, e dovrebbero determinare il metodo di hashing utilizzato. Oltre a questo, dovrebbero applicare la forza bruta al seme corretto ...

So che questo è insicuro e imperfetto in qualche modo, ma vorrei una spiegazione.

passwords

posta user90076 24.10.2015 - 03:54

fonte

2 risposte

Leggi altre domande sui tag passwords

Automatizza la firma del certificato in Linux Servizio di auth centrale che reindirizza al sottodominio, utilizzando la firma digitale come token di autenticazione

score 2 · Answer 1

performed the steps a website would do on the password and use the result as our actual password

Questo quasi risolve il problema del riutilizzo della password. Se l'utente ha scelto una password principale e ha utilizzato un hash della password per ricavare una password diversa per ogni servizio (ad esempio salendo con il nome host del sito Web), ciascun sito non sarebbe teoricamente in grado di accedere agli account dell'utente su altri servizi. p>

Tuttavia, dico "quasi" perché, in pratica, la maggior parte degli utenti sceglie password con entropia insufficiente per essere protette con l'hashing della password. Ciò significa che qualsiasi servizio che l'utente accede (o chiunque interrompa qualcuno di questi servizi) potrebbe violare la password derivata dell'utente per determinare la password principale, lasciando l'utente completamente compromesso. Per questo motivo, le password generate casualmente + un gestore di password sono ancora le migliori pratiche, poiché le password risultanti non hanno alcuna relazione reciproca (o alla password principale).

Detto questo, con una password sufficientemente strong, questo schema è effettivamente sicuro. Una password di 8 parole generata utilizzando Diceware avrebbe circa 103 bit di entropia. Se questo schema fosse usato con un buon hash per le password, sarebbe praticamente impossibile decifrare la password principale (assumendo un'implementazione corretta, nessuna anticipazione della crittografia, ecc.)

Come menzionato nei commenti, è ancora piuttosto importante che il server abbia la "password" che riceve. Immagina se un utente malintenzionato è in grado di scaricare una tabella utente, ma non è in grado di compromettere completamente il server / servizio. Ottenere l'accesso alle password derivate consentirebbe all'utente malintenzionato l'account di qualsiasi utente su qualsiasi parte di quel servizio, che potrebbe potenzialmente ampliare l'impatto della violazione.

Nel caso in cui qualcuno fraintenda questo, lasciatemi includere un rapido promemoria: implementarlo in JavaScript insieme a un modulo di accesso non fornirebbe alcuna protezione da un server malevolo, poiché un server dannoso può sostituire quel JavaScript con qualcos'altro.

score 0 · Answer 2

Penso che il tuo difetto sia in questa affermazione:

If the cracker determines this is the method that is used, it would take significantly longer because the hashing itself takes CPU time, and they would have to determine the hashing method used. On top of that, they would have to bruteforce the correct seed...

Dato che nel tuo sistema, l'hashing avviene sul lato client, il cracker ha accesso al codice che esegue l'hashing - probabilmente Javascript, il che significa che è il codice sorgente.

Allo stesso modo, il sale dovrebbe essere contenuto nello stesso Javascript.

Quindi il cracker ha già tutto ciò di cui ha bisogno in termini di algoritmo. Quale potrebbe non essere effettivamente un problema, perché se la tua sicurezza si basa sul mantenere l'algoritmo segreto, hai altri problemi da risolvere. In ogni caso, l'algoritmo sarebbe facile da indovinare, perché ci sono solo alcuni possibili candidati (o potresti lanciare il tuo e sperare che possa essere effettivamente sicuro. Buona fortuna!)

Nel complesso, se capisco correttamente il tuo schema, questo sembra molto simile allo schema di autorizzazione della risposta alla sfida NTLM in Windows. Ecco una buona scrittura sui vari vulnerabilità di NTLM e molti potrebbero tradursi nella tua situazione. L'articolo è troppo lungo per essere citato, ma i problemi principali sembrano essere:

In NTLMv1, c'erano dettagli di implementazione che lasciavano buchi vuoti. In effetti, ha convertito la password solo in una chiave a 56 bit.
NTLMv2 è ancora vulnerabile a attacchi man-in-the-middle e altri.