L'hashing sul lato client può migliorare la sicurezza dopo il fatto in risposta alle perdite di password?

Non ci sono vantaggi teorici dall'hashing lato client e lato server all'hashing due volte lato server; a meno che la connessione tra client e server non sia affidabile.

Tuttavia, in pratica, ho visto più istanze in cui le password in chiaro venivano archiviate nei registri (principalmente nei log degli errori). In questo particolare scenario ha un chiaro vantaggio.

Credo che l'hashing da H0 a H1 sia fattibile con un salt che è univoco per password.

Una volta che H1 è stato compromesso, poiché il server conosce questo particolare Salt, il client potrebbe autenticarsi inviando H0, e quindi il server può controllare che H0 + Salt = > H1. Quindi il server potrebbe cambiare il sale al sale e registrare H0 + Salt '= > H1 'come nuova password.

Penso che sia possibile, ma consiglierei di non farlo: La complessità è il nemico della sicurezza.

L'hashing della password prima della trasmissione avviene per alcuni protocolli di autenticazione, in particolare WAP / WPA2 Handshake a quattro vie PSK . In questo scenario, il protocollo WPA deve prevenire un attacco masquerade, in modo tale che un AP non autorizzato non possa ottenere la password in chiaro quando richiede ai client l'autenticazione.

In questo protocollo, un utente malintenzionato che ha ottenuto H1 = hash(H0) può utilizzare questo valore per l'autenticazione senza la necessità di conoscere la password in chiaro. Che è una violazione di CWE-294: bypass di autorizzazione per replay di cattura . Inoltre, vi è la preoccupazione di calcolare un hash della password utilizzando hash(hash'(H0)) , poiché non viene utilizzata una password-sale ( CWE -759 ), e quindi un attacco precomputazione pone il "percorso più breve per scendere a compromessi".

Se implementato correttamente, un sistema di autenticazione basato su prova della password senza conoscenza riduce significativamente l'impatto derivante dalla divulgazione della memoria attacchi come le vulnerabilità di heartbleed, log disclosure e alcuni aspetti del MITM. Tuttavia, il cracking delle password basato su dizionario è più o meno inalterato.

Penso che il difetto del tuo piano sia la tua affermazione

H0 is unknown to the hackers, yet still verifiable by the server.

Questo non è il caso. Ricorda che gli hash sono a senso unico. Tutto quello che il server ha ricevuto da te è H1, che hanno convertito in H2 (e che ora è compromesso). Il server non sa quale sia l'input che ha generato H1 (cioè H0). Inoltre, si presume che il server abbia mantenuto solo H2 e non mantenga H1. Se avessero mantenuto H1, allora sì, potevano avere H0 e confrontare con H1, ma hanno mantenuto H2.

Se ci pensate, mentre H1 è ciò che originariamente avete inviato al server, dal punto di vista del server, è solo una password - una password potenzialmente lunga, ma solo una password, nondimeno. Il server deve quindi inserire tale password per memorizzarla (creando H2). Speriamo anche che il server non abbia record di H1. Quando si effettua l'autenticazione, si invia H1 su cui il server esegue l'hash per ottenere H2. Affinché il tuo schema funzioni, il server dovrebbe anche mantenere H1, che sarebbe come mantenere una password in testo semplice. Una volta che un hacker ha ottenuto il database degli hash H1, può accedere al server come utente associato a quell'hash senza dover fare altro.

L'altra parte del tuo suggerimento, che ha un po 'di gloria, che probabilmente ha bisogno di più riflessioni è

Patch the client to now send (and the server to now require) the hash H0.

Questo è un potenziale problema o, per lo meno, è probabile che sia tanto lavoro quanto semplicemente la modifica della password. Se dovessi consentire questo tipo di path automaticamente e ridurre / evitare la necessità per l'utente di agire, l'apertura di un altro potenziale problema di sicurezza - come / chi avvierebbe tale patching e come si eviterebbero patching non autorizzati. Se si desidera che l'utente esegua il patching, probabilmente sarà necessario uno sforzo maggiore per ottenere il diritto piuttosto che farli modificare la propria password.

EDIT: come indicato nel commento, è possibile verificare l'hash H0 eseguendo il hashing per due volte H0 - > H1 - > H2 e confrontando con H2 il server ha. Quindi forse quella parte dell'equazione potrebbe funzionare.

Tuttavia, il patching o il coordinamento della mossa dall'uso di H1 all'utilizzo di H0 è ancora problematico IMO. Meccanismi di aggiornamento / patch "normali" non funzioneranno in quanto tali meccanismi si basano su un'unica "fonte di verità" di fiducia. Ad esempio, se su Windows ti fidi del servizio di aggiornamento di Windows e se su OSX ti fidi del servizio di aggiornamento OSX. Ma per quanto riguarda i siti web, ci occupiamo di infrastrutture decentralizzate.

Considera un ambiente in cui questo schema è stato adottato da tutti o da alcuni sottoinsiemi di tutti i server web disponibili. Se un server Web viene compromesso, in qualche modo è necessario che quel server informi il cliente che ora è necessario inviare H0 anziché H1. A questo punto, le cose cominciano a diventare molto complesse e la complessità è il naturale nemico della sicurezza.

Non puoi effettuare la modifica globalmente, ovvero ora richiedono che tutti i siti che utilizzano questo schema utilizzino H0 anziché H1 perché ciò causerebbe un problema di coordinamento: in qualche modo dovresti dire a tutti i server che usano lo schema di passare al H0 - > H1 - > metodo h2. Ora devi aggiornare server e client e coordinare tale modifica o alcuni siti smetteranno di funzionare.

Pertanto, dovresti farlo a livello di singolo sito. Ciò significa che è necessario disporre di un meccanismo integrato nello schema che consenta al server di comunicare al client quale hash desidera per l'autenticazione: H0 o H1. Ora hai un altro problema. Come proteggi contro un server canaglia che chiede H0?

Dato che uno dei maggiori problemi con qualsiasi schema di password è che le persone tendono a utilizzare la stessa password su più siti. Sappiamo che questa è una cattiva pratica, ma la gente lo fa comunque. Se dovessi visitare un server cattivo, potrebbe chiedere H0. Ora quel server ha H0 e può cancellarlo per ottenere H1 e usare quell'hash per accedere ad altri server che potresti usare, che fanno ancora affidamento sull'H1 originale come password. Questo potrebbe anche far parte di un altro vettore di attacco su host compromessi: una volta compromesso un host, è possibile iniziare a chiedere gli hash H0.

il vero problema qui è che stiamo aggiungendo ulteriore complessità, che aggiungerà 'buchi' imprevisti che aggiungono solo una minima sicurezza aggiuntiva e non riesce a risolvere l'approccio fondamentale (e probabilmente non risolvibile) dell'uso delle password per l'accesso sicuro - bottom line le password come controllo di accesso per conto proprio sono fondamentalmente infranti. Ciò che è veramente necessario è un modo conveniente per aggiungere ulteriori fattori al processo di autenticazione e allontanarsi dagli approcci che si basano su una semplice parola segreta