it-swarm-eu.dev

Token-basierte Authentifizierung - Sichern des Tokens

Ich habe eine Backend REST API für eine mobile App entwickelt und möchte nun eine tokenbasierte Authentifizierung implementieren, um zu vermeiden, dass der Benutzer aufgefordert werden muss, sich bei jedem Lauf der App anzumelden.

Was ich im Sinn hatte, war bei der ersten Anfrage, dass der Benutzer seine Anmeldeinformationen mithilfe der Standardauthentifizierung über SSL sendet. Sobald der Server die Anmeldeinformationen authentifiziert hat, erstellt er ein sicheres Token und sendet es an den Benutzer zurück, damit dieser es in nachfolgenden Anforderungen verwenden kann, bis das Token entweder abläuft oder widerrufen wird.

Ich suche nach Ratschlägen, wie ich ein Token generieren kann, das nicht anfällig für MoM/Replay-Angriffe ist, und um sicherzustellen, dass die im Token gespeicherten Daten nicht extrahiert werden können.

Ich werde das folgende Ansatz verwenden, um das Token zu generieren, von dem ich denke, dass es verhindern würde, dass Daten daraus extrahiert werden. Ich muss jedoch immer noch sicherstellen, dass es nicht von anderen Angriffen betroffen ist.

Auf die API kann nur über SSL zugegriffen werden, aber ich bin mir nicht sicher, ob ich mich aus Sicherheitsgründen ausschließlich darauf verlassen kann.

99
James

Das "Authentifizierungstoken" funktioniert so, wie sich der Server daran erinnert.

Ein generisches Token ist eine zufällige Zeichenfolge. Der Server speichert in seiner Datenbank eine Zuordnung von ausgegebenen Token zu authentifizierten Benutzernamen. Alte Token können automatisch entfernt werden, um zu verhindern, dass die Datenbank des Servers auf unbestimmte Zeit wächst. Ein solches Token ist für die Sicherheit gut genug, solange ein Angreifer kein gültiges Token mit nicht zu vernachlässigender Wahrscheinlichkeit erstellen kann. Ein "gültiges Token" ist "ein Token, das sich in der Datenbank der ausgegebenen Token befindet". Es ist ausreichend, dass Token-Werte eine Länge von mindestens 16 Bytes haben und mit einer kryptografisch starken Funktion PRNG (zB /dev/urandom, CryptGenRandom(), Java.security.SecureRandom ... abhängig von Ihrer Plattform).

Es ist möglich, die Speicheranforderungen auf den Clients selbst zu verlagern. Welchen "Speicher" sollte der Server im obigen Absatz für ein Token haben? Nämlich den Benutzernamen und das Herstellungsdatum des Tokens. Erstellen Sie Ihre Token also folgendermaßen:

  • Der Server hat einen geheimen Schlüssel [~ # ~] k [~ # ~] (eine Folge von beispielsweise 128 Bit, die von einem kryptografisch sicheren PRNG erzeugt wird).
  • Ein Token enthält den Benutzernamen ( [~ # ~] u [~ # ~]), den Ausstellungszeitpunkt ( [~ # ~] t [~ # ~]) und eine verschlüsselte Integritätsprüfung berechnet über [~ # ~] u [~ # ~] und [~ # ~] t [~ # ~] (zusammen), verschlüsselt mit [~ # ~] k [~ # ~] (standardmäßig [~ # ~ verwenden) ] hmac [~ # ~] mit SHA-256 oder SHA-1).

Dank seiner Kenntnis von [~ # ~] k [~ # ~] kann der Server überprüfen, ob ein vom Benutzer zurückgesendetes Token eines seiner eigenen ist oder nicht. Der Angreifer kann solche Token jedoch nicht fälschen.

Die Antwort, auf die Sie verlinken, sieht ungefähr so ​​aus, außer dass es sich um Verschlüsselung anstelle von MAC handelt, und das ist:

  1. verwirrt;
  2. verwirrend;
  3. möglicherweise unsicher;

weil Verschlüsselung nicht MAC ist.

82
Thomas Pornin

Kurz gesagt, Sie sollten ein einmaliges zufälliges Token mit kryptografischer Stärke verwenden und es in der Datenbank hashen.

Das Zeichen

  • darf nur einmal verwendet werden,
  • darf nur für den Benutzer verwendet werden, für den es erstellt wurde.
  • darf nur über HTTPS gesendet werden,
  • sollte ein Ablaufdatum haben (z. B. 7 Tage).

Sobald sich der Benutzer mit dem Token anmeldet, ist es ungültig und ein neues Token sollte erstellt und dem Benutzer übergeben werden. Im Falle eines abgelaufenen Tokens muss sich der Benutzer erneut mit seinen tatsächlichen Anmeldeinformationen anmelden.

Eine ausführlichere und ausführlichere Beschreibung dieser Regeln finden Sie in Teil 2 von Der endgültige Leitfaden zur formularbasierten Website-Authentifizierung :

Permanente Login-Cookies ("Remember Me" -Funktionalität) sind eine Gefahrenzone. Einerseits sind sie genauso sicher wie herkömmliche Anmeldungen, wenn Benutzer verstehen, wie sie damit umgehen sollen. Andererseits stellen sie ein enormes Sicherheitsrisiko für die meisten Benutzer dar, die sie auf öffentlichen Computern verwenden, vergessen, sich abzumelden, nicht wissen, was Cookies sind oder wie sie gelöscht werden usw.

[...]

Folgen Sie Charles Millers 'Best Practices'-Artikel . Versuchen Sie nicht, die am Ende seines Artikels verlinkten "Verbesserten" Best Practices zu befolgen. Leider können die "Verbesserungen" des Schemas leicht vereitelt werden (alles, was ein Angreifer tun muss, um das "verbesserte" Cookie zu stehlen, ist daran zu denken, das alte zu löschen. Dazu muss sich der legitime Benutzer erneut anmelden und eine neue Serienkennung erstellen und den gestohlenen gültig lassen).

Und SPEICHERN SIE DAS PERSISTENT LOGIN COOKIE (TOKEN) NICHT IN IHRER DATENBANK, NUR EIN HASH! Das Login-Token ist Passwort-äquivalent, wenn also ein Angreifer Er hat Ihre Datenbank in die Hände bekommen und kann sich mit den Token bei jedem Konto anmelden, als wären es Klartext-Login-Passwort-Kombinationen. Verwenden Sie daher beim Speichern dauerhafter Anmeldetoken stark gesalzenes Hashing (bcrypt/phpass).


Update: Entschuldigung, ich habe die Frage falsch verstanden. Die von Ihnen verknüpfte Methode sieht vernünftig aus, schützt Sie jedoch nicht vor Wiederholungsangriffen oder Man-in-the-Middle. Sie sollten SSL daneben verwenden.

38
Polynomial

Ein reiner RESTful API-Webdienst sollte die zugrunde liegenden Protokollstandardfunktionen verwenden:

  1. Für HTTP sollte die RESTful-API vorhandene HTTP-Standardheader, Statuscodes und Methoden berücksichtigen und diesen entsprechen. Das Hinzufügen eines neuen HTTP-Headers verstößt gegen die Prinzipien REST).

  2. RESTful Services müssen zustandslos sein. Alle Tricks, wie die tokenbasierte Authentifizierung, die versucht, sich den Status früherer REST - Anforderungen auf dem Server zu merken, verstoßen gegen die REST - Prinzipien.

Fazit: Für Authentifizierungs-/Autorisierungszwecke sollten Sie den HTTP-Autorisierungsheader verwenden. Außerdem sollten Sie bei jeder nachfolgenden Anforderung, die authentifiziert werden muss, den spezifischen HTTP-Autorisierungsschema-Header hinzufügen.

Ich habe einen RESTful-Webdienst für die Cisco Prime Performance Manager-Anwendung entwickelt. Durchsuchen Sie Google nach dem Cisco Prime Performance Manager REST API-Dokument, das ich für diese Anwendung geschrieben habe, um weitere Informationen zur RESTFul-API-Konformität zu erhalten - siehe unten. Für diese Anwendung haben wir uns für die Verwendung von HTTP "Basic" entschieden "Autorisierungsschema zur Authentifizierung und Autorisierung von Anforderungen. Und natürlich verwenden wir HTTPs, um alle Daten zu verschlüsseln, die beim Verwenden der HTTP-Autorisierung vom Client zum Server übertragen werden.

http://www.Cisco.com/c/en/us/support/cloud-systems-management/prime-performance-manager/products-programming-reference-guides-list.html

4
Rubens Gomes