Esiste un modo (a parte l'autenticazione HTTP, che ritengo intrinsecamente insicuro su Internet?) Per un sito Web di "vita reale" per gestire accessi e autenticazione piuttosto che in modo tradizionale, utilizzando i cookie di sessione?Esistono alternative valide all'autenticazione di cookie "classica"?
HTTP digest authentication (che è una bestia piuttosto diversa dall'autenticazione di base HTTP) è abbastanza sicuro su HTTP diretto e non è affatto difficile da implementare sul server. Nulla viene inviato sul filo che potrebbe rivelare quale sia la password, solo le informazioni che consentono al client di dimostrare al server di avere la password corretta.
Se si desidera una spiegazione decente su come implementare l'autenticazione del digest HTTP nell'applicazione, Paul James has an excellent article on it.
L'unico vero problema con l'autenticazione HTTP è nei browser stessi: l'interfaccia utente è terribile, ma può essere overcome with some Javascript.
L'autenticazione HTTP non è insicura quando si utilizzano HTTP.
L'autenticazione di base HTTP è perfettamente sicura se utilizzata con un sito Web SSL (https: //) poiché tutto il traffico HTTP, incluse le credenziali, verrà crittografato. Un inconveniente soggettivo è che quando si utilizza questo metodo gli utenti dovranno interagire con il popup di autenticazione del proprio browser per accedere al proprio sito.
Quindi presumibilmente i siti Web principali non utilizzano l'autenticazione HTTP perché SSL è piuttosto ad alto consumo di risorse a entrambe le estremità? Perché l'utente è in grado di interagire con il popup di autenticazione come un problema? Se avessero una disabilità non avrebbero già avuto meccanismi per superare questo problema? –
Senza SSL, qualsiasi forma di autenticazione web è meno sicura, quindi la decisione ha più a che fare con il livello di sicurezza necessario all'accesso e meno con quale tipo di autenticazione è in uso. La preoccupazione del browser popup riguarda principalmente la progettazione del sito in quanto può sembrare fuori luogo e sconvolgente per gli utenti. –
Quando si utilizza https, è anche possibile installare un certificato nel browser del client e verificarlo. myopenid offre questo per i loro account OpenID. Ne ho uno e funziona davvero bene (dal punto di vista del cliente).
Per essere chiari, l'unico modo reale per farlo è tramite HTTPS.
Ma, dal momento che presuppongo che questo non è un'opzione, e ho anche presumo siete alla ricerca di un sistema "completamente gestito login", continuo:
Altro che HTTPS è possibile utilizzare JavaScript fare hashing sicuro di password sul lato client, per evitare di rivelare le password in testo semplice over-the-wire, ma questa è solo una mezza soluzione.
I problemi con questo approccio sono:
Un altro approccio è un più complesso meccanismo di challenge/response:
E i problemi con questo:
Ora, ad essere onesti, problema # 2 non è così grande di un pericolo come sembra. Infatti, quando invece si utilizza l'autenticazione HASH, l'hash stesso viene elevato al livello di "chiave".
A questo punto è abbastanza sicuro di usare un cookie per memorizzare un ReferrenceID login generato in modo casuale, simile al loro ID di sessione, ma il server può essere utile per crittografare utilizzando l'IP si riferisce come parte del IV o per impedire ad altri utenti di dirottare il ReferrenceID.
In ogni caso, spero che fornisca un po 'di direzione nel design.
Utilizzo di SSL per la crittografia in combinazione con HttpOnly Cookies per impedire che XSS sia la soluzione migliore per l'utilizzo dei cookie. Non ho intenzione di dire che è a prova di proiettile, però.
Non proteggerà contro XSS, lo renderà più difficile da sfruttare. –
ma è ancora sfruttabile con un canale XSS interattivo. Dai un'occhiata a BeeF, BrowserRaider, XSS Shell e XSS Tunneling –
Grazie per il commento. Ho aggiornato la mia risposta. –
In primo luogo, HTTP Auth è protetto su SSL diverso dal fatto che non è possibile implementare una vera funzionalità di "Logout". L'utente deve chiudere il browser, il che è piuttosto brutto.
In secondo luogo, è necessario utilizzare HTTPS in tutti i casi per renderlo sicuro, dopo di che è stato eseguito l'accesso di base a cose simili come "Digest" e "NTLM Auth".
Correzione: l'autenticazione HTTP quando si utilizza HTTPS è sicura quanto la sessione SSL. – Randolpho
Non è possibile implementare la funzionalità di logout in Basic Auth, è piuttosto spazzatura :) –
Per firefox, vedere questi bug: https://bugzilla.mozilla.org/show_bug.cgi?id=55181 e https: //bugzilla.mozilla .org/show_bug.cgi? id = 287957. Ma sì, sono d'accordo. –