Diese Frage wurde hier in etwas anderer Form ausführlich behandelt:
RESTful Authentifizierung
Dies spricht es jedoch von der Serverseite an. Schauen wir uns das von der Client-Seite aus an. Bevor wir das tun, gibt es jedoch einen wichtigen Auftakt:
Javascript Crypto ist hoffnungslos
Matasanos Artikel dazu ist berühmt, aber die darin enthaltenen Lektionen sind ziemlich wichtig:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
Zusammenfassen:
- Ein Man-in-the-Middle-Angriff kann Ihren Kryptocode trivial durch ersetzen
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- Ein Man-in-the-Middle-Angriff ist für eine Seite, die eine Ressource über eine Nicht-SSL-Verbindung bereitstellt, trivial.
- Sobald Sie SSL haben, verwenden Sie sowieso echte Krypto.
Und um eine eigene Folgerung hinzuzufügen:
- Ein erfolgreicher XSS-Angriff kann dazu führen, dass ein Angreifer Code im Browser Ihres Clients ausführt, selbst wenn Sie SSL verwenden. Selbst wenn Sie jede Luke geschlossen haben, kann Ihre Browser-Krypto dennoch fehlschlagen, wenn Ihr Angreifer einen Weg zur Ausführung findet Javascript-Code im Browser eines anderen.
Dies macht viele RESTful-Authentifizierungsschemata unmöglich oder albern, wenn Sie beabsichtigen, einen JavaScript-Client zu verwenden. Lass uns nachsehen!
HTTP Basic Auth
In erster Linie HTTP Basic Auth. Das einfachste Schema: Geben Sie bei jeder Anfrage einfach einen Namen und ein Passwort ein.
Dies erfordert natürlich unbedingt SSL, da Sie bei jeder Anfrage einen Base64 (reversibel) -codierten Namen und ein Kennwort übergeben. Jeder, der in der Leitung zuhört, kann den Benutzernamen und das Passwort trivial extrahieren. Die meisten Argumente für "Basic Auth is unsicher" stammen von einem Ort mit "Basic Auth over HTTP", was eine schreckliche Idee ist.
Der Browser bietet integrierte HTTP Basic Auth-Unterstützung, ist aber hässlich und sollte wahrscheinlich nicht für Ihre App verwendet werden. Die Alternative besteht jedoch darin, Benutzername und Passwort in JavaScript zu speichern.
Dies ist die RESTful-Lösung. Der Server benötigt keinerlei Kenntnis des Status und authentifiziert jede einzelne Interaktion mit dem Benutzer. Einige REST-Enthusiasten (meistens Strohmänner) bestehen darauf, dass die Aufrechterhaltung eines Zustands Häresie ist und beim Aufschäumen des Mundes schäumt, wenn Sie an eine andere Authentifizierungsmethode denken. Diese Art der Einhaltung von Standards bietet theoretische Vorteile - sie wird von Apache sofort unterstützt - Sie können Ihre Objekte als Dateien in Ordnern speichern, die durch .htaccess-Dateien geschützt sind, wenn Ihr Herz dies wünscht!
Das Problem ? Sie speichern auf der Clientseite einen Benutzernamen und ein Kennwort zwischen. Dies gibt evil.ru einen besseren Überblick - selbst die grundlegendsten XSS-Schwachstellen können dazu führen, dass der Client seinen Benutzernamen und sein Kennwort auf einen bösen Server überträgt. Sie könnten versuchen, dieses Risiko durch Hashing und Salting des Passworts zu verringern, aber denken Sie daran: JavaScript Crypto ist hoffnungslos . Sie könnten dieses Risiko verringern, indem Sie es der Basisauthentifizierungsunterstützung des Browsers überlassen, aber wie bereits erwähnt hässlich wie Sünde.
HTTP Digest Auth
Ist eine Digest-Authentifizierung mit jQuery möglich?
Eine "sicherere" Authentifizierung, dies ist eine Anfrage / Antwort-Hash-Herausforderung. Außer JavaScript Crypto ist hoffnungslos , funktioniert also nur über SSL und Sie müssen den Benutzernamen und das Kennwort auf der Clientseite zwischenspeichern, was es komplizierter als HTTP Basic Auth macht, aber nicht sicherer .
Abfrageauthentifizierung mit zusätzlichen Signaturparametern.
Eine weitere "sicherere" Authentifizierung, bei der Sie Ihre Parameter mit Nonce- und Timing-Daten verschlüsseln (zum Schutz vor Wiederholungs- und Timing-Angriffen) und die senden. Eines der besten Beispiele hierfür ist das OAuth 1.0-Protokoll, das meines Wissens eine ziemlich einfache Möglichkeit darstellt, die Authentifizierung auf einem REST-Server zu implementieren.
http://tools.ietf.org/html/rfc5849
Oh, aber es gibt keine OAuth 1.0-Clients für JavaScript. Warum?
JavaScript Crypto ist hoffnungslos , denken Sie daran. JavaScript kann ohne SSL nicht an OAuth 1.0 teilnehmen, und Sie müssen den Benutzernamen und das Kennwort des Clients weiterhin lokal speichern. Dies entspricht der Kategorie Digest Auth. Es ist komplizierter als HTTP Basic Auth, aber nicht sicherer .
Zeichen
Der Benutzer sendet einen Benutzernamen und ein Kennwort und erhält im Gegenzug ein Token, mit dem Anforderungen authentifiziert werden können.
Dies ist geringfügig sicherer als HTTP Basic Auth, da Sie die vertraulichen Daten verwerfen können, sobald die Transaktion zwischen Benutzername und Kennwort abgeschlossen ist. Es ist auch weniger RESTful, da Token "Status" darstellen und die Serverimplementierung komplizierter machen.
SSL immer noch
Das Problem ist jedoch, dass Sie immer noch diesen anfänglichen Benutzernamen und das Passwort senden müssen, um ein Token zu erhalten. Vertrauliche Informationen berühren immer noch Ihr kompromittierbares JavaScript.
Um die Anmeldeinformationen Ihres Benutzers zu schützen, müssen Sie Angreifer weiterhin von Ihrem JavaScript fernhalten und weiterhin einen Benutzernamen und ein Kennwort über das Netzwerk senden. SSL erforderlich.
Token-Ablauf
Es ist üblich, Token-Richtlinien wie "Hey, wenn dieses Token zu lange existiert, verwerfen Sie es und lassen Sie den Benutzer erneut authentifizieren." Durchzusetzen. oder "Ich bin mir ziemlich sicher, dass die einzige IP-Adresse, die dieses Token verwenden darf, XXX.XXX.XXX.XXX" ist. Viele dieser Richtlinien sind ziemlich gute Ideen.
Feuersheeping
Die Verwendung eines Tokens ohne SSL ist jedoch weiterhin anfällig für einen Angriff namens "Sidejacking": http://codebutler.github.io/firesheep/
Der Angreifer erhält die Anmeldeinformationen Ihres Benutzers nicht, kann sich jedoch als Benutzer ausgeben, was ziemlich schlecht sein kann.
tl; dr: Das Senden unverschlüsselter Token über das Kabel bedeutet, dass Angreifer diese Token leicht schnappen und sich als Benutzer ausgeben können. FireSheep ist ein Programm, das dies sehr einfach macht.
Eine separate, sicherere Zone
Je größer die Anwendung ist, die Sie ausführen, desto schwieriger ist es sicherzustellen, dass sie keinen Code einfügen können, der die Verarbeitung vertraulicher Daten ändert. Vertrauen Sie Ihrem CDN absolut? Ihre Werbetreibenden? Ihre eigene Codebasis?
Häufig für Kreditkartendaten und seltener für Benutzername und Kennwort - Einige Implementierer speichern die Eingabe sensibler Daten auf einer vom Rest ihrer Anwendung getrennten Seite. Diese Seite kann streng kontrolliert und so gut wie möglich gesperrt werden, vorzugsweise auf einer ist schwierig, Benutzer mit Phishing.
Cookie (bedeutet nur Token)
Es ist möglich (und üblich), das Authentifizierungstoken in ein Cookie einzufügen. Dies ändert keine der Eigenschaften von auth mit dem Token, es ist eher eine bequeme Sache. Alle vorherigen Argumente gelten weiterhin.
Sitzung (bedeutet immer noch nur Token)
Session Auth ist nur eine Token-Authentifizierung, aber mit ein paar Unterschieden, die es etwas anders erscheinen lassen:
- Benutzer beginnen mit einem nicht authentifizierten Token.
- Das Backend verwaltet ein Statusobjekt, das an das Token eines Benutzers gebunden ist.
- Der Token wird in einem Cookie bereitgestellt.
- Die Anwendungsumgebung abstrahiert die Details von Ihnen.
Abgesehen davon unterscheidet es sich jedoch nicht wirklich von Token Auth.
Dies geht noch weiter von einer RESTful-Implementierung entfernt - mit Statusobjekten gehen Sie auf einem Stateful-Server immer weiter auf dem Weg des einfachen alten RPC.
OAuth 2.0
OAuth 2.0 befasst sich mit dem Problem: "Wie gewährt Software A Software B Zugriff auf die Daten von Benutzer X, ohne dass Software B Zugriff auf die Anmeldeinformationen von Benutzer X hat?"
Die Implementierung ist nur eine Standardmethode für einen Benutzer, um ein Token zu erhalten, und dann für einen Drittanbieter, der sagt: "Ja, dieser Benutzer und dieses Token stimmen überein, und Sie können jetzt einige ihrer Daten von uns erhalten."
Grundsätzlich ist OAuth 2.0 jedoch nur ein Token-Protokoll. Es weist die gleichen Eigenschaften wie andere Token-Protokolle auf - Sie benötigen immer noch SSL, um diese Token zu schützen - es ändert lediglich die Art und Weise, wie diese Token generiert werden.
OAuth 2.0 kann Ihnen auf zwei Arten helfen:
- Bereitstellung von Authentifizierung / Informationen für andere
- Authentifizierung / Informationen von anderen erhalten
Aber wenn es darauf ankommt, benutzt du nur ... Token.
Zurück zu Ihrer Frage
Die Frage, die Sie stellen, lautet also: "Soll ich mein Token in einem Cookie speichern und die automatische Sitzungsverwaltung meiner Umgebung für die Details sorgen, oder sollte ich mein Token in Javascript speichern und diese Details selbst verarbeiten?"
Und die Antwort lautet: Tu, was dich glücklich macht .
Die Sache mit der automatischen Sitzungsverwaltung ist jedoch, dass hinter den Kulissen für Sie viel Magie passiert. Oft ist es besser, die Kontrolle über diese Details selbst zu haben.
Ich bin 21, also ist SSL ja
Die andere Antwort lautet: Verwenden Sie https für alles, oder Räuber stehlen die Passwörter und Token Ihrer Benutzer.