Ich benutze Devise eine Weile, um die Authentifizierung in meinen Rails-Apps zu handhaben, habe aber nie wirklich verstanden, wie es funktioniert. Da Devise auch die auf Rails festgelegte Sitzungsspeicherkonfiguration verwendet, gehe ich davon aus, dass dies eine Frage zur Sitzungsbehandlung mit Rails ist.
Grundsätzlich bin ich ein Auth-Neuling. Ich habe ein paar Artikel über Authentifizierung gelesen, aber die meisten beschäftigen sich mit abstrahierten Bibliotheken (sie sprechen über Engines, Middleware usw.), die für mich keinen Sinn ergeben. Ich suche wirklich nach Details auf niedrigerer Ebene.
Hier ist, was ich bis jetzt weiß ..
Ich weiß über Cookies und Sitzungen Bescheid. Cookies sind Zeichenketten, die auf der Client-Seite gespeichert werden und zur Aufrechterhaltung der Sitzung über mehrere HTTP-Anfragen hinweg verwendet werden.
Hier ist mein grundlegendes Verständnis der Authentifizierung (bitte korrigieren Sie mich, wenn ich falsch liege):
Wenn sich ein Benutzer anmeldet, senden wir die SSL-verschlüsselte Anfrage an den Server. Wenn die Anmeldeinformationen gültig sind, speichern wir eine zufällige Zeichenfolge mit der Bezeichnung Sitzungs-ID in der Datenbank (oder einem anderen Datenspeicher) als gültige Sitzungs-ID, die einer Benutzer-ID zugeordnet ist. Diese Sitzungs-ID ändert sich für jede Anmeldung / Abmeldung des Benutzers.
Nach dem Speichern dieser Sitzungs-ID in unserem Datenspeicher geben wir eine Antwort zurück, die den Browser auffordert, ein Cookie mit der Sitzungs-ID festzulegen. Diese Sitzungs-ID zusammen mit der Benutzer-ID wird dann für die sukzessive Anforderung an die Domäne gesendet, bis sie abläuft. Für jede Anfrage würde unser Server die Sitzungs-ID in den Kopfzeilen überprüfen und überprüfen, ob diese Sitzungs-ID für diese Benutzer-ID gültig ist. Wenn dies der Fall ist, bedenken Sie, dass der Benutzer authentifiziert wurde.
Hier sind meine Fragen:
Ich habe gelesen, dass standardmäßig ab Rails 2 CookieStore (anstelle von SessionStore) verwendet wird, der Session-Hashes mit SHA512 generiert (anstelle von Session-IDs), und all dies wird auf einem Cookie gespeichert, was bedeutet Mehrere Benutzer-IDs können buchstäblich den gleichen Sitzungshash haben und es würde einfach gut funktionieren. Es scheint mir, dass dies eine sehr gefährliche Sache ist, indem eine große Anzahl von Hashes mit einem einzigen geheimen Schlüssel auf dem Server gespeichert wird und Ihr gesamtes Authentifizierungssystem basierend auf diesem Schlüssel basiert. Gibt es eine reale Anwendung im großen Maßstab, die Hashing verwendet, anstatt serverseitige Sitzungs-IDs zu speichern?
Zum Thema des Speicherns aktiver Sitzungs-IDs auf Serverseite habe ich auch gelesen, dass Sie wechseln können, um verschiedene Arten von Sitzungsspeicher für Rails zu verwenden. Auf dieser Grundlage habe ich von Systemen gehört, die Authentifizierungssysteme als Dienste herausziehen und stattdessen Auth-Tokens verwenden. Was ist ein Authentifizierungs-Token und wie unterscheidet es sich von einer Session-ID?
Scheint, als könnte ich einfach eine zufällige Zeichenfolge (sowohl für Hashing- als auch für serverseitige Sitzungen) erraten, um eine bestehende Sitzung zu erfassen. Gibt es einen Weg, sich davor zu schützen? Ist es normal, mehr Werte auf einem Cookie zu verwenden? (wie den Benutzernamen, echten Namen oder sogar einen anderen Hash für die Authentifizierung)
Ich weiß, ich frage viel, aber ich glaube, dass dies für Leute wie mich nützlich sein wird, die die Authentifizierung nicht verstehen und sehr nützlich sein werden, um eine solide Grundlage für das Thema zu bekommen.
Ich habe gelesen, dass standardmäßig ab Rails 2, es jetzt verwendet wird CookieStore (anstelle von SessionStore), der Sitzungshashes generiert mit SHA512 (anstelle von Session-IDs), und all dies wird auf a gespeichert Cookie, was bedeutet, mehrere Benutzer-IDs können buchstäblich das gleiche haben Session Hash und es würde einfach gut funktionieren. Das scheint mir so zu sein eine sehr gefährliche Sache, eine große Anzahl von Hashes mit einem einzelner geheimer Schlüssel, der auf dem Server gespeichert ist Authentifizierungssystem basierend auf diesem Schlüssel.
Ja, es wirkt auf den ersten Blick gruselig, aber ich bin mir nicht sicher, was die Gefahr wirklich ist. In Rails 4 werden Sitzungsdaten mit PBKBF2 verschlüsselt und dann mit Ihrem Sitzungsgeheimnis signiert . Diese Signierung hilft zu erkennen, ob der Inhalt der verschlüsselten Sitzung manipuliert wurde und der Server wird die Sitzung ablehnen, wenn eine Manipulation festgestellt wird.
Wenn jemand Zugriff auf das Sitzungstoken erhält (das zum Signieren des Sitzungscookies verwendet wird), haben Sie wahrscheinlich wesentlich größere Probleme in den Händen als Endbenutzer, die versuchen, den falschen Benutzer anzunehmen.
Gibt es eine echte Großanwendung, die Hashing verwendet? anstatt serverseitige Sitzungs-IDs zu speichern?
Ich kenne ehrlich gesagt die Antwort auf diese Frage nicht, aber ich vermute, dass die Tatsache, dass dies der "Standard" für Rails ist, bedeutet, dass es mehr als eine Handvoll Sites gibt, die Cookies speichern.
Zu dem Thema, aktive Session-IDs auf Serverseite zu speichern, habe ich auch lesen Sie, dass Sie wechseln können, um verschiedene Arten von Sitzungsspeicher für zu verwenden Schienen. Auf dieser Grundlage habe ich von Systemen gehört, die die Authentifizierung verschieben Systeme als Dienste aus und verwenden stattdessen Autotoken. Was ist eine Auth Token und wie unterscheidet es sich von einer Session ID?
Ich mache das jetzt auf einem Server - im Grunde wird ein zufälliger Hash generiert, wenn sich ein Benutzer authentifiziert, und dieser Hash wird im Cookie gespeichert, verschlüsselt und signiert. Der Cookie-Hash ist ein Schlüssel in einen serverseitigen Datenspeicher (in meinem Fall Redis, aber er kann in einer relationalen Datenbank oder Memcache oder was auch immer Sie wollen), und die tatsächlichen Sitzungsdaten sind die gespeicherte Serverseite, die diesem Schlüssel zugeordnet ist. Dadurch bleiben weniger Sitzungsdaten in den Händen des Kunden, da die Benutzer diese möglicherweise entschlüsseln und analysieren könnten. Daher ist es im Allgemeinen ein wenig sicherer.
Scheint so, als könnte ich einfach eine zufällige Zeichenfolge erraten (für beide Hashes) und serverseitige Sitzungen), um eine vorhandene Sitzung zu übernehmen. Gibt es einen Weg davor schützen? Ist es normal, mehr Werte zu verwenden, die auf einem gespeichert sind? Plätzchen? (wie der Benutzername, der richtige Name oder sogar ein anderer Hash für Authentifizierung)
Ja, das könnte man machen, aber es würde sehr lange dauern. Sie müssen auch erraten, wie die neu manipulierten Cookie-Daten signiert werden, damit sie mit dem übereinstimmen, was der Server auf seiner Seite erwartet, und er ist mit einem ziemlich großen Schlüssel signiert.
Ich glaube wirklich nicht, dass es viel Alternative gibt, den Authentifizierungsstatus bei der Verwendung von Cookies beizubehalten (ich nehme an, HTML5 Local Storage würde funktionieren, wenn Sie sich exotisch fühlen und sich nicht viel um die Legacy-Browser-Unterstützung kümmern).
Tags und Links ruby-on-rails session authentication devise cookies