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) .