Un server autenticato che vede la password in chiaro è un problema serio?

Come altri hanno sottolineato, l'hashing lato client in realtà non risolve il problema, dal momento che il server vede ancora qualcosa che può essere riutilizzato per l'autenticazione (tramite un attacco pass-the-hash). È ancora meglio che passare la password in chiaro, dal momento che le persone riutilizzano le password (ma non gli hash salati) tra siti / servizi e anche quando non usano spesso le password simili (/ sistemi di scelta password / ecc).

BTW, questo non è solo un problema di sicurezza del server. L'intercettazione TLS (da parte dei dispositivi di sicurezza di rete lato client) sta diventando fastidiosamente comune e qualsiasi dispositivo che ha intercettazioni ha anche accesso alle password o agli hash.

Fortunatamente, c'è una soluzione: lo scambio di chiavi (PAKE) con autenticazione tramite password asimmetrica consente l'autenticazione senza esporre o memorizzare nulla equivalente alla password sul server (o su un dispositivo di intercettazione). Secure Remote Password (SRP) è il protocollo PAKE più conosciuto e più popolare. C'è anche una nuova proposta di protocollo PAKE, chiamata OPAQUE che sembra ancora migliore (anche se voglio vedere il cripto della community battere su di esso per un po 'prima di usarlo). Matthew Green ha una buona sintesi di questo qui .

Purtroppo i PAKE non sono molto conosciuti o usati. IMO, questo dovrebbe essere il modo standard per fare l'autenticazione di rete.

Oh, c'è un grosso limite: se questo è implementato nel JavaScript fornito dal server, qualcuno con accesso sufficiente ad esso (o una casella di intercettazione TLS) può modificare il codice JavaScript che viene inviato al client per perdere la password. Ci sono modi per migliorare questo aspetto (ad es. Con l'integrità di subresource), ma anche senza questi PAKE si riduce la vulnerabilità.

L'esposizione della semplice password è sempre un problema, a volte più e talvolta meno. Se l'attaccante riesce a compromettere il server, potrebbe prendere le semplici password quando il server verifica se queste sono corrette. Registri di debug estesi simili sul server potrebbero inavvertitamente registrare anche le password immesse in modo che un utente malintenzionato possa prelevarle dal disco del server o da backup esterni.

Pertanto, potrebbe essere una buona idea proteggere la password anche dal server. Solo questo non è facile poiché il server richiede in definitiva la password o qualcosa di equivalente per autenticare l'utente.

Un modo non sarebbe quello di inviare la password originale dal client al server ma utilizzare qualche algoritmo per ricavare la password lato server dalla password inserita dall'utente - una funzione di derivazione della chiave (KDF). Questo è come suggerisci con h(p) . Ovviamente, questa chiave derivata dovrebbe avere la stessa protezione lato server di una password in testo normale poiché è essenzialmente una password in testo semplice, ma non è così facile da indovinare. Ciò significa che la chiave derivata deve essere memorizzata correttamente con password sul lato server. Se questa chiave derivata dipende dal dominio del server o da qualsiasi altra specifica del sito, potrebbe almeno proteggere un po 'dal riutilizzo della password poiché la stessa password genererà una chiave derivata diversa a seconda del sito. Ovviamente se la chiave della password viene ricavata dal codice fornito dal server, un utente malintenzionato potrebbe modificare questo codice per prendere anche la password originale, ma ciò richiede uno sforzo maggiore e quindi questo metodo riduce il rischio totale.

Ancora meglio sarebbe se la password fosse utilizzata solo localmente sul client per proteggere un certificato client all'interno del browser e quindi utilizzare l'autenticazione reciproca in https. In questo caso non sarebbe sufficiente per l'attaccante attaccare il server ma ogni client dovrebbe essere attaccato. D'altra parte i certificati lato client sono più una seccatura da utilizzare rispetto a una semplice password e quindi vengono usati raramente. In altre parole: meno rischi al costo di una minore usabilità.

A parte questo ci sono anche metodi di risposta alle sfide come Digest-MD5. Solo queste funzioni di digest hanno il problema che la password degli utenti o qualcosa di equivalente deve essere memorizzata sul lato server senza la protezione offerta dal solito hashing della password unidirezionale, aumentando così la superficie di attacco.

Altre risposte e commenti hanno già rivelato che la sicurezza del meccanismo di autenticazione non cambia in realtà applicando prima una funzione hash (potrebbe persino ridursi se le password di input lunghe sono comuni).

Vorrei sottolineare che nascondere la password originale può davvero proteggere gli utenti e le loro strategie di creazione di password.

Gli utenti che hanno la stessa password per molti siti possono trarre vantaggio dall'hashing se viene inclusa una chiave specifica del sito. Gli schemi di generazione password applicati da un utente (come "mypw4site1.com", "mypw4site2.com", ...) sono nascosti anche da qualsiasi utente nel mezzo.

Ovviamente anche le informazioni personali che potrebbero essere contenute nella password (come i nomi o le date di nascita dei parenti) vengono nascoste.

Inviando un hash della password, invece della password stessa, tutto ciò che stai proteggendo è il testo chiaro della password. Questo ha qualche merito, ma non fa nulla per proteggersi dagli attacchi di replay - questo è noto come pass-the -hash.

Combinando la password degli utenti con un sale monouso (challenge) fornito dal server, è possibile proteggersi da un tale attacco - ma per convalidare il token presentato (h (p + c)), il servizio ha bisogno per ricreare lo stesso valore di hash, ovvero è necessario memorizzare il testo in chiaro della password. Non va bene.

Convenzionalmente, un servizio di autenticazione memorizzerà un hash della password con un sale generato in modo casuale (h (s + p)), insieme al testo in chiaro del sale. Il testo chiaro del sale non è considerato particolarmente segreto - l'efficacia del meccanismo non è strongmente indebolita rivelando questo. Quindi, in linea di principio, il server poteva inviare sia una richiesta che il client avrebbe restituito:

 h(h(s+p)+c)

Purtroppo, questo non risolve il problema del pass-the-hash poiché una conoscenza dei dati (h (s + p)) memorizzata sul server è sufficiente per essere in grado di autenticarsi.

L'unico modo pratico per evitare il problema è utilizzare un servizio di autenticazione affidabile sia dal client che dal servizio dell'applicazione - ad es. usando kerberos o openid - questo sposta semplicemente il problema nel servizio di autenticazione, ma questo separa e disaccoppia le responsabilità.