Perché le password non sono localmente hash localmente? [duplicare]

1

Le persone stanno sempre riutilizzando le password e, con molti siti che accettano indirizzi e-mail come login, una password rubata può potenzialmente sbloccare molti account. Quindi, perché non basta cancellare la password localmente tramite javascript e inviare la password hash al server (tramite SSL ovviamente) che poi lo blocca di nuovo, prima di salvarlo nel suo database. Questo sarebbe:

1

Mostra sicurezza agli utenti interessati, che le loro password sono almeno una volta hash (guardando il codice JS), il che significa che le loro password sono alquanto sicure in ogni caso.

2

Nel caso di una chiave privata rubata, le comunicazioni acquisite decodificate tra client e server rivelerebbero solo una password con hash. Ciò fornirebbe l'accesso al servizio danneggiato, ma poiché la password è già sottoposta a hash (e seminata con il nome del sito o altro) non può essere utilizzata per inserire altri siti web con email + password a meno che l'hash non sia rotto.

3

Nel caso di furto del database delle password, l'hash del lato server E l'hash del lato client dovrebbero essere "invertiti" per rivelare la vera password.

Ora sono consapevole che questi 3 casi sono alquanto rari, tuttavia non sono improbabili, dal momento che i database delle password vengono rubati , le chiavi private sono trapelate e gli algoritmi di hash diventano obsoleti (vedi SHAttered). Ora so che l'argomento 3 non è particolarmente strong, dal momento che le password vengono triturate più volte, ma comunque la mia domanda:

Perché questa best practice non è questa? Sto controllando eventuali inconvenienti? Questo è già implementato da qualche parte?

    
posta jaaq 24.04.2017 - 19:28
fonte

2 risposte

0

Come diceva korockinout13, in molti casi, solo l'hash è necessario e non la password in chiaro.

Questa è una vecchia domanda di cui è stata discussa parecchio. Per maggiori informazioni vedi Dovrei hash la password prima di inviarla al lato server? .

    
risposta data 24.04.2017 - 21:53
fonte
2

L'hashing delle password sul client non dovrebbe fare al caso nulla e, nel peggiore dei casi, far dubitare la sicurezza delle tue applicazioni da parte degli utenti. Per quanto riguarda il server, le password hash del client sono effettivamente le password in chiaro. Vedi le mie risposte alle tue domande individuali.

  1. No, non è così. Mostra solo che è stato sottoposto a hashing nel browser. Per l'utente, ciò non significa che la password sia stata ancora sottoposta a hashing sul server. Se l'ho visto, suppongo che l'hashing venga eseguito solo nel browser e presupporre che l'applicazione non sia sicura.

  2. Suppongo che tu intenda la chiave privata del certificato SSL. Se questo è stato rubato, ci sono problemi molto più importanti. Con le informazioni sul certificato trapelate, qualcuno può impersonare con successo il tuo server web, il che significa che nessuno dei contenuti scaricati può essere considerato attendibile. Gli script sul lato client possono semplicemente strappare le password prima che vengano crittografate.

  3. No, avrebbero solo bisogno di decifrare gli hash ottenuti dal server. Ancora una volta, per quanto riguarda il server, la password con hash del client è il testo in chiaro.

risposta data 24.04.2017 - 22:05
fonte