Autenticazione della password di autenticazione HTTP di base più sicura dell'autent Digest

14

Se si sta già utilizzando SSL, sembra che l'autenticazione di base sia la strada da percorrere poiché è possibile eseguire bcrypt con la password quando la si archivia nel database, dove Autent digest consente solo md5 . Come sappiamo, in caso di furto del database, md5 può essere "incrinato" più velocemente di bcrypt .

La mia domanda ora è, dato che SSL è presente, e il fatto che non puoi bcrypt Digest password di autenticazione, perché dovrei continuare a usarlo su Basic auth? Oppure è l'autenticazione di base come fa se c'è SSL.

BTW questo è per un server API REST

    
posta IMB 13.08.2012 - 17:44
fonte

4 risposte

8

La tua ipotesi è corretta. L'autenticazione di base è la strada da percorrere, purché tu stia utilizzando correttamente HTTPS. Ti consente di implementare tutte le tue policy crittografiche e di accesso nella webapp, invece di essere legato al modello di sicurezza del tuo HTTPD.

    
risposta data 13.08.2012 - 17:46
fonte
12

La scelta non è solo tra auth di base e auth di digest se stai usando SSL. L'autenticazione del digest è preferibile all'autenticazione di base se non si dispone di SSL, anche se rimane comunque un po 'vulnerabile agli attacchi man in the middle; sebbene li renda più complicati dell'autenticazione di base.

Tuttavia, eviterei l'autenticazione di base per diversi motivi:

  • una brutta interfaccia per accedere (un avviso pop-up a malapena configurabile quando si accede per la prima volta a una pagina protetta) rispetto a un modulo di accesso opzionale da qualche parte sulla pagina.
  • su un tentativo di accesso errato, 401 - I messaggi non autorizzati sono peggiori di una schermata di password errata personalizzabile; dove magari aggiungi un CAPTCHA, o hai collegamenti che potrebbero ricordare nome utente in base all'indirizzo email, o reimpostare una password persa, o creare un nuovo account.
  • In genere non puoi disconnettersi dell'accesso di base per l'autenticazione senza chiudere il browser.

Per questo motivo, consiglio di utilizzare sessioni basate su cookie (su SSL) per tali motivi, dove ancora una volta si utilizza un hash strong (ad esempio, bcrypt) per memorizzare la password.

    
risposta data 13.08.2012 - 18:30
fonte
6

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.

    
risposta data 27.10.2012 - 22:26
fonte
1

La memorizzazione della password per l'autenticazione digest è in realtà peggiore di quanto suggerisci. Se un utente malintenzionato cattura l'hash della password, può utilizzarlo per eseguire autonomamente un'autenticazione digest. Non è necessario alcun cracking Come altri hanno già menzionato, l'autenticazione digest ha avuto il suo posto prima che il protocollo SSL fosse diffuso.

L'autenticazione di base su SSL è fondamentalmente valida. Tuttavia, potresti prendere in considerazione una soluzione basata sulla sessione. Anziché inviare la password ad ogni richiesta, inviarla una volta per configurare una sessione, quindi inviare l'id di sessione ad ogni richiesta. Dato che la password è la cosa più segreta, questo minimizza quanto viene inviato intorno.

Un altro poster menziona SRP e, sebbene SRP abbia vari vantaggi in termini di sicurezza, non è ampiamente implementato, quindi è un antipasto per la maggior parte delle app Web.

    
risposta data 06.10.2013 - 16:17
fonte

Leggi altre domande sui tag