So che esistono diversi tipi di meccanismi di autenticazione disponibili. Uno tra questi è l'autenticazione HTTP. Qual è il pericolo nell'uso di questo metodo rispetto ad altri metodi?
So che esistono diversi tipi di meccanismi di autenticazione disponibili. Uno tra questi è l'autenticazione HTTP. Qual è il pericolo nell'uso di questo metodo rispetto ad altri metodi?
L'autenticazione di base ha una serie di inconvenienti, uno dei quali è che il nome utente e la password vengono passati in chiaro ad ogni richiesta. Questo è chiaramente pericoloso sotto HTTP, ma è un po 'meno vulnerabile sotto HTTPS. Tuttavia, poiché le credenziali vengono inviate con ogni richiesta, è ancora peggio di qualsiasi altro metodo (incluso digest) che non presenta questa limitazione. La ragione principale è che ora ogni singola richiesta può essere un bersaglio per il furto di credenziali in chiaro, non solo una richiesta iniziale di accesso. Nella maggior parte dei sistemi, dopo l'accesso, il più che un utente malintenzionato può sperare di recuperare è un token di sessione o autenticazione. Con l'autenticazione di base, ogni richiesta è un'opportunità per rubare la password dell'utente. Questo non è l'ideale
L'autenticazione del digest è alquanto migliore in quanto invia un digest MD5 di alcuni bit diversi tra cui nome utente, password e un nonce (tra gli altri valori) e non le credenziali di testo non crittografato ... Non è possibile estrarre una password da un digest acquisito .
Con l'autenticazione HTTP (in qualsiasi forma) si dipende anche dal client per fornire l'esperienza dell'utente di autenticazione, che può avere i suoi problemi e quindi deve essere ben testato con i client che si prevede utilizzino la propria applicazione. In passato, ad esempio, ho visto che determinati browser non riescono ad autenticarsi a causa di determinati caratteri speciali in una password, ad esempio. Con l'autenticazione basata sull'applicazione UX, hai il controllo su questo. Con l'autenticazione HTTP, non lo fai.
Un altro attacco (ed è molto minore) è che se visualizzi contenuti ospitati esternamente generati dagli utenti sul tuo sito, ti apri a attacchi di phishing molto sottili. Poiché i tuoi utenti sono abituati al chrome del client per l'autenticazione HTTP, non noteranno necessariamente se ottengono una richiesta di autenticazione sul tuo sito per un dominio leggermente diverso. A seconda dell'applicazione, questa potrebbe non essere affatto una minaccia valida, ma è certamente una cosa da considerare se si scende lungo la route di autenticazione HTTP.
Oltre agli altri punti citati, un altro svantaggio significativo dell'autenticazione di base HTTP (vs, ad esempio, l'accesso basato su moduli) è che non ha il concetto di "disconnessione". Una volta che l'utente immette le proprie credenziali, il browser le archivia internamente per l'invio con ogni richiesta successiva. Ciò significa che non è possibile avere un timeout o un pulsante / logout "Disconnetti" per terminare la sessione. Se l'utente desidera evitare la possibilità che qualcun altro usi la propria sessione (ad esempio nel caso di un computer condiviso), deve ricordare di uscire dal browser.
Per ulteriori informazioni: link
L'autenticazione di accesso di base su HTTPS presenta chiari vantaggi rispetto all'autenticazione dell'accesso Digest su HTTP.
Anche con l'autenticazione dell'accesso digest, puoi effettivamente archiviare l'hash delle tue password con un unico salt (realm + username), ma prima questo sale è ipotizzabile (questo rende più facili gli attacchi contro singoli utenti e piccoli gruppi) e secondo puoi farlo ' t usa bcrypt , scrypt o PBKDF2 per rendere più difficile l'hash calcolo. Inoltre, se hai scelto di archiviare gli hash in un formato non recuperabile (cosa che dovresti fare!), Non puoi cambiare il dominio senza richiedere la password utente chiara.
In SASL , l'autenticazione dell'accesso digest anche è stato contrassegnato come storico da IETF. Per SASL, disponevano di un'alternativa ( SCRAM , ad esempio SASLPrep chiaramente per la normalizzazione dei caratteri, ad esempio) che potrebbero consigliare di utilizzare. SCRAM per HTTP ha sfortunatamente non ha mai superato lo stato di bozza (nota che con SCRAM, l'utente anche i sali non sono segreti. L'utente malintenzionato può abusare del meccanismo di accesso per ottenere i sali per ogni utente che desidera).
L'autenticazione dell'accesso al digest può dare un falso senso di sicurezza . Se l'attaccante può catturare un login riuscito, può montare un attacco a forza bruta contro la password. username , realm e nonce sono tutti valori noti per l'autore dell'attacco.
L'utilizzo di HTTP non crittografato, con o senza autenticazione dell'accesso Digest, non è immune da MITM. L'utente malintenzionato potrebbe non essere in grado di catturare la password, ma può acquisire cookie di sessione e modificare il contenuto o impersonare l'utente.
Con l'autenticazione dell'accesso digest è specificato solo per l'accesso ma non per l'impostazione dell'account. Devi configurare l'account come "normale". Anche se il tuo codice è intelligente e invia solo l'hash interno per impedire che la password venga trasportata in chiaro, può essere modificato dall'attaccante per inoltrarlo a loro. Tuttavia, questo grave problema esiste solo una volta, alla registrazione . Supponendo che l'utente acceda solo da una piccola quantità di macchine, è possibile ottenere una sicurezza simile usando TACK per HTTPS. Ciò consente al browser dell'utente di autorizzare solo il certificato ottenuto alla prima connessione al sito. Quindi, solo la prima connessione rimane esposta al possibile MITM, proprio come con l'autenticazione dell'accesso digest.
Leggi altre domande sui tag authentication http web-application