Wir arbeiten an einem neuen Projekt, wir sind zwei leitende Entwickler und haben uns überlegt, wie man mit einem Token die Kommunikation zwischen Server und Client sicherstellt.

Erster Vorschlag: (Das einmalige statische Token der Alias)

1. Der Client fordert ein primäres Token an, indem er den Benutzernamen und das Kennwort sowie die aktuelle Zeit (diese Variable wird in der Datenbank des Servers und auch auf der Clientseite gespeichert) an die API sendet. Der Server interpretiert die Eingabe und gibt ein gehashtes Token aus (z. B .: 58f52c075aca5d3e07869598c4d66648) speichert es in der Datenbank und gibt es an den Client zurück.

2. Der Client speichert nun das primäre Token und erstellt ein neues Hash-Token unter Verwendung des primären Tokens + der in der Authentifizierungsanforderung gesendeten Variable current_time. (Nennen wir dieses neue Token main_token.) Der Server macht dasselbe und erstellt dasselbe Token unter Verwendung desselben Algorithmus .

3. Jedes Mal, wenn der Client die Server-API abfragt, sendet er das main_token an den Server. Jetzt vergleicht der Server das darin generierte Token mit dem main_token, das vom Client gesendet wird. Wenn es übereinstimmt, bedeutet dies, dass der Benutzer real ist

Zweiter Vorschlag: (Dynamisches Token)

1. Der Client generiert zwei zufällige Schlüssel ($ key1 = rand (10000,90000); $ key2 = rand (10000,90000);) Bei jeder Anforderung in der API erstellt der Client einen Hash mit dem Abfragetyp und die beiden Schlüssel mit einen komplexen Algorithmus und sendet diese beiden Schlüssel + den Hash an den Server

2. Der Server erstellt unter Verwendung desselben im Client verwendeten Algorithmus einen Hash und vergleicht diesen mit dem vom Client gesendeten. Wenn er übereinstimmt, verarbeitet der Server die Abfrage

Nun stellt sich die Frage: Welches ist der logischste und sicherste Weg, um die API-Anforderungen zu sichern?

Ich mag den ersten Ansatz im Allgemeinen sehr.

• es ist einfach zu verstehen und umzusetzen
• es ist sicher (meines Wissens)
• Es ist ein nicht ungewöhnlicher Ansatz, den ich in der Vergangenheit verwendet habe

Eine Sache, die ich nicht über die erste erwähnt sehe, die Sie beachten sollten, ist, dass der Zeitstempel, der für das Hashing des Tokens verwendet wird, einen extrem kurzen TTL-Ablauf hat (z. B. 1 Sekunde), damit Sie sicherstellen können, dass die Nachricht nicht mit gesendet wurde gleicher Zeitstempel und Token einer Nachricht 12 Stunden zuvor; offensichtlich würde es als legitim errechnen, ist aber in diesem Fall nicht.

Wenn dies die einzigen beiden Optionen sind, die Sie in Betracht ziehen, möchte ich nur sicherstellen, dass Sie auch andere Ansätze in Betracht gezogen haben, da es viele gibt. Mehr als ich in der Tat auflisten werde. Dies sind einige gängige Auth-Ansätze, die es wert sind, untersucht zu werden, um festzustellen, ob sie besser zu Ihrem Zweck passen, und wenn Sie sie nicht anders verstehen, können Sie einige Ideen erhalten, die Ihnen dabei helfen, den Ansatz, den Sie verfolgen, zu verfeinern.

Beachten Sie, ich bin kein Sicherheitsexperte.

OAuth / Federated

Bei diesem Ansatz haben Sie einen Drittanbieter-Garantiegeber, bei dem der konsumierende Code das Token / Zertifikat / was haben Sie von ihnen anfordert und das an Sie weiterleitet. An diesem Punkt müssen Sie den Drittanbieter nur fragen, ob der Schlüssel, den Sie erhalten haben, ist legitim.

Profi:

• Standards basieren
• Probleme werden von anderen auf den Systemen anderer gefunden, sodass Sie feststellen können, ob Unsicherheit vorliegt
• Sie werden viel weniger Auth-Arbeit benötigen

Con:

• Sie müssen sich mit einem Drittanbieter-Servicer und dessen API befassen oder einen eigenen "Drittanbieter" erstellen und hosten, um die Authentifizierung von Ihrem Hauptdienst zu trennen.
• Für viele Dienste übertrieben, aber konzeptionell eine Überlegung wert

Asynchrone Zertifikate

Hier lassen Sie Ihre Kunden ihre Kommunikation mit einem öffentlichen Zertifikat verschlüsseln, das Sie bei der Erstellung eines Benutzers für sie freigegeben haben. Auf Ihrer Seite würden Sie mit dem privaten Schlüssel entschlüsseln, der dem Benutzer zugeordnet ist. Im Allgemeinen würden Sie die Kommunikation mit einer Challenge-Response initiieren, um zu zeigen, dass sie verschlüsselt / entschlüsselt werden können, wie Sie es erwarten, um sie als diejenigen zu identifizieren, die sie für sich beanspruchen. Obwohl "synchrone" Ansätze möglich sind, bei denen die Abfrage-Antwort nicht verwendet wird, weisen sie etwas weniger Sicherheit und einige Zeitsynchronisierungsprobleme auf, die sie schwieriger machen können.

von Novell (Ja, ich weiß, Novell ? Wirklich?)

Token verwenden eine Variable als Basis, um das Einmalpasswort zu generieren. Diese Variable wird als Herausforderung bezeichnet. Die beiden Hauptmethoden zum Bestimmen der Variablen, die zum Generieren des Kennworts verwendet wird, sind asynchron oder synchron.

Bei der asynchronen oder Challenge-Response-Methode sendet die Serversoftware dem Token eine externe Challenge - eine zufällig generierte Variable -, damit das Token-Gerät es verschlüsselt. Das Token verwendet diese Herausforderungsvariable, den Verschlüsselungsalgorithmus und das gemeinsam genutzte Geheimnis, um die Antwort zu generieren - das korrekt verschlüsselte Kennwort.

Bei der synchronen Methode wird die zur Generierung des Kennworts verwendete Abfragevariable intern vom Token und vom Server bestimmt. Als Basis für die Herausforderungsvariable wird ein Zeitzähler, ein Ereigniszähler oder eine Zeit- und Ereigniszählerkombination in jedem Gerät verwendet. Da das Token und der Server die Herausforderungsvariable jeweils separat und intern von ihren eigenen Zählern bestimmen, ist es sehr wichtig, dass ihre Zeitzähler und die Ereigniszähler synchron bleiben. Da es für den Server und das Token so einfach ist, nicht synchron zu sein, lassen die meisten Implementierungen eine gewisse Abweichung zwischen den Zählern zu. Normalerweise wird ein kleiner Bereich oder ein kleines Fenster dieser Zählerwerte verwendet, um das Kennwort zu berechnen. Wenn das Token und der Server jedoch außerhalb dieses Fensters nicht mehr synchron sind,

Profi:

• Zertifikate haben CA-Wurzeln, wodurch sie vertrauenswürdig und schwer zu fälschen sind
• In Betriebssystemen gibt es Standardfunktionen zum einfachen Verwalten und Verwalten von Zertifizierungsspeichern
• Gut durchdachter Ansatz, viele Informationen verfügbar
• Ablauf zusammen mit einer Vielzahl von anderen Dingen sind eingebaute Einrichtungen von Standard-Zertifikaten, sie sind in der Regel robust

Con:

• Es kann schwierig sein, mit Zertifikaten programmgesteuert zu arbeiten
• Je nachdem, ob Sie eine externe Zertifizierungsstelle benötigen, ist diese möglicherweise nicht kostenlos
• Möglicherweise müssen Sie die Zertifikatspeicher manuell verwalten, um sicherzustellen, dass die erwarteten Stammvertrauensstellungen konfiguriert sind

NTLM

Lachen Sie nicht, wenn dies ein kleinerer oder nur interner Dienst ist und Sie sich in einer Windows-Umgebung befinden, ist die Verwendung der Standard-NTLM-Authentifizierung zur Gewährleistung des Zugriffs nichts Falsches. Besonders wenn Sie mit IIS arbeiten, ist dies zweifellos der einfachste Ansatz. Einfach zu pflegen und auch in einer web.config zu konfigurieren.

Profi:

• Sehr einfach zu konfigurieren, zu implementieren und zu warten

Con:

• Minimale Interoperabilität
• Nicht ausreichend für die öffentliche Authentifizierung

Nonces

Wenn Sie in Ihrem Authentifizierungsansatz mit Nonces arbeiten, geben Sie eine Methode an, um eine Nonce für den Service abzurufen. Diese Methode gibt bei jeder Anforderung eine eindeutige beliebige Zeichenfolge oder ein Datenelement ("nonce") zurück. Für jede Anforderung an andere Methoden muss jetzt eine Nonce abgerufen und im Krypto-Algorithmus für die Anforderung verwendet werden. Der Wert hier ist, dass der Server die verwendeten Nonces verfolgt und die Wiederverwendung einer Nonce niemals zulässt. Dies verhindert Wiederholungsangriffe vollständig, da eine Anfrage mit dieser Nonce niemals mehr gestellt werden kann, sobald eine Anfrage mit einer Nonce gestellt wurde. Wenn Nonces angefordert werden, werden sie zu einer Liste verfügbarer Nonces hinzugefügt, sobald sie verwendet werden. Anschließend werden sie von der Liste der verfügbaren in die Liste der verwendeten Nonces verschoben.

Profi:

• Die Wiederholungsangriffe von Thwarts sind recht gut
• Alles in allem nicht schwer zu implementieren oder zu verstehen

Con:

• Erforderliche Clients stellen für jede Anforderung zwei Anforderungen (dies kann jedoch dadurch verringert werden, dass Nonces nur für bestimmte Anforderungen erforderlich sind Anforderungen ).
• Erfordert die Verwaltung von Nonces, die transaktional sein sollen
• Beeinträchtigt die Leistung negativ, da zusätzliche Anforderungen für Nonces erforderlich sind (die Transaktionalität erhöht die Ressourcenkosten für die Arbeit mit Nonces weiter).