Perché i siti principali (Facebook, Google, ecc.) inviano ancora password non trattate? [duplicare]

Question

Perché i siti principali (Facebook, Google, ecc.) inviano ancora password non trattate? [duplicare]

#1 da (3 voti)

5

SOMMARIO RAPIDO:

Sembra che i siti Web moderni, per motivi di sicurezza, debbano tutti avere il client con le proprie password prima di inviarli al server, che li ridistribuisce, per evitare la perdita della password originale (probabilmente riutilizzata su diversi siti), e anche per rendere necessaria la decrittografia su base individuale, piuttosto che semplicemente decifrare una singola chiave SSL.

QUESTIONE ORIGINALE:

Ho appena fatto un rapido controllo per essere sicuro, e sono rimasto stupito nel vedere che i principali siti Web sembrano ancora inviare le password nel loro formato originale per gli accessi, anche se su SSL / TLS. Capisco che sono hashing e salting / peppering prima di metterli nel database. Tuttavia, vedo ancora un problema con questo.

Sembra che l'hashing di tutte le password con un sale unico sul sito prima di inviarle, e poi l'hashing hash sarebbe sostanzialmente più sicuro per i client, specialmente alla luce di notizie recenti :

The NSA and its allies routinely intercept such connections -- by the millions. According to an NSA document, the agency intended to crack 10 million intercepted https connections a day by late 2012. The intelligence services are particularly interested in the moment when a user types his or her password. By the end of 2012, the system was supposed to be able to "detect the presence of at least 100 password based encryption applications" in each instance some 20,000 times a month. (Emphasis added)

Pur capendo che dal punto di vista dell'efficienza, avere la password del client hash non è necessaria, sono più interessato al fatto che l'hashing della password originale significherebbe che anche se i dati sono stati intercettati, sul server, -se durante la connessione o durante la decodifica del protocollo SSL, sarebbe utile solo per accedere al sito Web per cui è stato intercettato.

Suppongo che dovrebbe essere una preoccupazione importante considerando molte persone che riutilizzano le password , tuttavia questi enormi siti inviano ancora il password originale e hashing sulla loro fine. C'è una ragione tecnica dietro questa, o è solo una vecchia pratica che dovrebbe idealmente essere cambiata?

MODIFICA PER CHIARIMENTO: Non sto suggerendo che questi siti inizino a fare tutto ciò che è di hashing sul lato client e lo buttino nel loro DB così com'è, dovrebbero sicuramente hash / salt l'hash. Il mio suggerimento è che il client esegua l'hashing della password in modo che il server non abbia idea di quali fossero i dati originali e quindi la stessa password può essere riutilizzata e un compromesso su un sito Web non significherebbe compromettere la password su altri siti. Come bonus, limiterebbe anche l'accesso scoperto dai proxy malintenzionati ai siti registrati, piuttosto che passargli la password.

encryption passwords hash tls

posta Ecksters 04.03.2015 - 14:44

fonte

1 risposta

Leggi altre domande sui tag encryption passwords hash tls

Come funziona il monitoraggio degli utenti X-UIDH e come posso rilevarlo? Quali metodi vengono utilizzati dai siti Web per impedire l'accesso diretto ai media?

score 3 · Answer 1

Dobbiamo distinguere tra i seguenti due scenari:

1) Un hacker determinato cerca di ottenere le password

In questa situazione, l'SSL di solito fornisce una protezione sufficiente, il protocollo SSL ben implementato è molto difficile da violare. Non appena l'autore dell'attacco può avviare con successo un attacco ManInTheMiddle, l'hash del lato client non otterrebbe comunque più protezione, poiché l'autore dell'attacco potrebbe rimuovere facilmente lo script (JS), che sta calcolando l'hash.

2) Viene avviato un attacco automatico

Se ci fosse un'organizzazione in grado di leggere il traffico SSL, il calcolo dell'hash del client aumenterebbe i costi, perché in un attacco automatico vedrebbero solo l'hash della password. Non appena il loro interesse per un sito è abbastanza grande, potrebbero scrivere codice per rimuovere automaticamente lo script di questo sito.

Se hanno solo l'hash, potrebbero comunque provare a forzare questo hash. Dal momento che probabilmente utilizzerai un hash client veloce (SHA *), la forzatura bruta dovrebbe essere relativamente semplice. L'uso di un hash lento (PBKDF2 o BCrypt) è difficile da implementare, con un linguaggio lato client lento come JS. Anche se dovessi calcolare un client hash lento, dovevi ridurre il tempo sul lato server, perché non vuoi lasciare che l'utente attenda troppo a lungo. L'hashing commerciale lato server con hashing sul lato client ridurrebbe la sicurezza, perché l'hashing lato server può essere eseguito più velocemente (più round) rispetto all'hash sul lato client.

➽ Questo significa che potresti rendere la loro vita più difficile, ma non potresti fermarli se il loro interesse è abbastanza grande. Se l'utente è consapevole della sicurezza e sceglie una password molto strong, un hash del client potrebbe essere d'aiuto, ma questo utente non potrebbe riutilizzare la password.