La specifica del protocollo di digest risale al 1999, periodo in cui SSL era ancora visto come uno strumento troppo costoso per essere impiegato genericamente La RFC inizia con questo paragrafo, che fornisce il contesto:
"HTTP/1.0", includes the specification for a Basic Access
Authentication scheme. This scheme is not considered to be a secure
method of user authentication (unless used in conjunction with some
external secure system such as SSL 5), as the user name and
password are passed over the network as cleartext.
Questo è l'unico riferimento a SSL nell'intero documento. Ciò chiarisce le cose: Digest è stato progettato per cercare di affrontare il problema abbagliante dell'invio delle password in chiaro, dato che Basic quando non utilizzato con SSL . Sappiamo, comunque, che non usare SSL è comunque un grosso problema, perché gli hacker sono avanzati un po 'dal secolo scorso: non si accontentano più di intercettazioni passive, in realtà rubano connessioni e implementano attacchi man-in-the-middle . In questo caso nessuna somma di Digest ti salverà.
Si noti che un possibile vantaggio di Digest over Basic è che non si rivela la password nemmeno al server stesso, nel caso in cui quel server sia ostile - con ciò intendo dire che si sta parlando di un server falso, controllato dal attaccante. Il digest non protegge da un MitM, quindi in quella situazione sei già condannato, ma solo localmente condannato: l'utente malintenzionato può vedere i tuoi dati e modificare le tue richieste, ma non apprende la tua password non sarà in grado di tornare più tardi da solo. Diversi punti rendono questo vantaggio molto piccolo:
-
Anche se Digest con un server falso non rivela la password non corretta all'utente malintenzionato, dà comunque abbastanza per eseguire un attacco di dizionario e molto efficiente dato che sono solo un paio di hash MD5 (niente nemmeno lontanamente paragonabile a bcrypt).
-
L'attacco MitM intrinseco è abbastanza serio da richiedere adeguati controlli di integrità dei dati, il che significa SSL (con la convalida completa del certificato del server, per favore!). Se MitM viene sconfitto, allora il vantaggio di Digest over Basic evapora come rugiada nel sole del mattino.
D'altro canto, come hai notato, l'uso di Digest implica che il server deve memorizzare le password stesse (possibilmente crittografate, ma in modo reversibile), e che è un grosso svantaggio di Digest l'autenticazione.
Per il meglio di tutti i mondi, utilizza TLS con SRP che è SSL / TLS con una password kick-ass- scambio di chiavi basato, dove:
- il server non deve memorizzare la password, solo un token di verifica (una sorta di hash);
- non esiste alcun certificato;
- l'autenticazione è reciproca e relativa alla password;
- anche un utente malintenzionato che impersona il server, il client o entrambi non può apprendere dati sufficienti per eseguire un attacco di dizionario offline.
L'unico problema "minore" è che TLS + SRP non è ancora ampiamente supportato (ancora). GnuTLS può farlo. Possiamo sperare in un supporto più ampio in futuro. Nel frattempo, usa l'autenticazione di base all'interno di SSL, non dimenticare di convalidare a fondo il certificato del server e usa bcrypt per memorizzare un hash della password sul lato server.