Perché le password vengono inviate non trattate dalla maggior parte dei siti Web moderni? [duplicare]

3

Ho indagato su vari protocolli utilizzati per inviare nomi utente e password ai server Web per l'autenticazione, e mentre ovviamente tutti questi giorni usano SSL / TLS, sono stato un po 'sorpreso nel vedere che anche con il mio banking online siti le password sono letteralmente incluse "così come sono" nel corpo del modulo senza alcun tentativo di hash o in altro modo proteggerle. Ciò significa che se a) qualcuno ha compromesso la mia macchina, l'installazione di nuovi certificati dell'autorità radice TLS e l'invio di richieste alla mia banca online a un altro server o b) è riuscita a indirizzarmi verso un sito in modo così convincente come il mio sito di banking online che non mi accorgo che non lo è (ad es. attacco omografo IDN), possono facilmente catturare la mia password di banking online. Potrei anche includere c) un operatore malintenzionato con accesso ai server di back-end sarebbe anche in grado di ottenere la mia password.

L'ormai popolare protocollo OAuth 2.0 include anche la password non protetta o non protetta come un campo modulo o parametro di query (il parametro query è forse anche peggiore in quanto non è insolito che le stringhe di query vengano registrate per intero dai server web). Dato che ci sono protocolli ben noti e stabiliti per l'hashing e la protezione delle password (ad esempio l'autenticazione del digest) che sembrano fornire alcuni ovvi benefici nel mantenere le password protette, perché sembra che nessuno le stia utilizzando?

Anche eseguire un SHA256 di base sulla password + sale predeterminato (sul lato client) sarebbe meglio di niente - ovviamente se l'hash è compromesso, un utente malintenzionato potrebbe comunque usarlo per accedere ai servizi protetti, ma almeno loro non ho alcuna informazione sulla mia password che potrebbe essere utile per determinare le mie altre password, compresa la password che sostituisco quella attuale con quando sono obbligata a cambiarla (sappiamo tutti qual è la routine più comune!)

L'unica spiegazione logica che posso vedere per il passaggio di password non protette (oltre che su TLS) è che consente ai backend di eseguire la convalida della complessità su di essi. Ma anche in questo caso, la password deve essere passata una volta una volta stabilita, non per ogni volta che si effettua l'accesso (inoltre, il backend potrebbe eseguire solo verifiche contro l'hash, ad es. - noti hash, in precedenza usati ecc., e lasciano il resto al lato client, accettando che le convalide sul lato client possano essere ignorate, e mi preoccupa che anche la validazione della lunghezza non è qualcosa che puoi fare solo con l'hash) .

    
posta Dylan Nicholson 08.11.2017 - 20:48
fonte

2 risposte

5

La tua domanda si riduce a

why do passwords get sent in clear text over an encrypted channel and are not hashed on the client before submission?

La risposta è: se il client è compromesso per compromettere la sessione TLS, non importa: la password è stata digitata e può essere salvata dalla tastiera.

Inoltre, l'hashing sul lato client rende il valore hash efficacemente la nuova password da inviare - di nuovo - in testo chiaro tramite la connessione crittografata.

    
risposta data 08.11.2017 - 20:52
fonte
3

Crackstation lo spiega abbastanza bene. L'invio dell'hash sul filo significa che il server sta convalidando l'hash con l'hash che ha memorizzato - l'hash effettivamente diventa la password dell'utente.

Se il server viene compromesso e gli hash vengono ottenuti, non è necessario che vengano violati per poter accedere come altri utenti.

Il modo corretto per farlo è hash la password sul server e convalidarlo da lì.

    
risposta data 08.11.2017 - 20:59
fonte

Leggi altre domande sui tag