it-swarm.com.de

Ist HTTPS und Standardauthentifizierung sicher genug für Banking-Webservices (RESTful)?

Ich habe in den letzten Tagen über SSL/TLS gelesen und es sieht so aus, als wäre es praktisch nie geknackt worden.

Wenn SSL/TLS für die gesamte Kommunikation zwischen der Clientanwendung und dem Server verwendet wird und der Kennwort-/API-Schlüssel zufällig und sicher und sicher auf der Serverseite gespeichert ist (bcryted, salted), denken Sie, dass Basic Auth sicher genug ist? auch für Bankdienstleistungen?

Ich sehe viele Leute, die die Idee nicht mögen, dass Benutzername/Passwort bei jeder Anfrage per E-Mail gesendet werden. Ist dies eine echte Schwachstelle von Basic Auth (auch wenn SSL/TLS verwendet wird) oder nur aus irrationaler Angst?

26
dnang

Die HTTP-Basisauthentifizierung wird in Browser-Server-Verbindungen nicht häufig verwendet, da sie auf der Browserseite ein browsergesteuertes Anmelde-Popup umfasst, das ausnahmslos hässlich ist. Dies gilt natürlich nicht für Server-Server-Verbindungen, bei denen kein menschlicher Benutzer Hässlichkeit beobachten kann, aber es trägt zu einem allgemeinen Klima des Misstrauens und der Nichtbenutzung für die Basisauthentifizierung bei.

In den 1990er Jahren, vor den Tagen von SSL, wurde das Senden von Klartext-Passwörtern über das Kabel als Schießerei angesehen, und in ihrer Torheit waren die Leute der Ansicht, dass Challenge-Response-Protokolle wie HTTP Digest ausreichten, um Sicherheit gewährleisten. Wir wissen jetzt, dass es nicht so ist; Unabhängig von der Authentifizierungsmethode muss der gesamte Datenverkehr mindestens kryptografisch mit der Authentifizierung verknüpft sein, um eine Entführung durch aktive Angreifer zu vermeiden. SSL ist also erforderlich . Wenn jedoch SSL aktiviert ist, ist das Senden des Kennworts "wie besehen" im SSL-Tunnel in Ordnung. Zusammenfassend lässt sich sagen, dass die Basisauthentifizierung in SSL für ernsthafte Zwecke stark genug ist, einschließlich nuklearer Startcodes und sogar geldbezogener Angelegenheiten.

Man sollte immer noch darauf hinweisen, dass die Sicherheit auf der Unmöglichkeit von Man-in-the-Middle-Angriffen beruht, die im Fall von SSL (wie allgemein verwendet) auf dem Zertifikat des Servers beruht. Der SSL-Client (in Ihrem Fall ein anderer Server) MUSS das Zertifikat des SSL-Servers mit größter Sorgfalt überprüfen, einschließlich der Überprüfung des Sperrstatus durch Herunterladen der entsprechenden CRL. Andernfalls, wenn der Client auf einen gefälschten Server umgeleitet wird, lernt der Eigentümer des gefälschten Servers das Kennwort ... In diesem Sinne fügt die Verwendung von HTTP Digest eine zusätzliche Schadensbegrenzungsebene hinzu, falls die Situation bereits ziemlich schlecht geworden ist, denn selbst mit HTTP Digest, ein gefälschter Server, der ein MitM ausführt, kann die Verbindung jederzeit entführen.


Wenn wir etwas weiter gehen, stellen wir möglicherweise fest, dass wir bei Verwendung der kennwortbasierten Authentifizierung tatsächlich eine kennwortbasierte gegenseitige Authentifizierung wünschen. Im Idealfall sollten sich der SSL-Client und der SSL-Server gegenseitig authentifizieren , basierend auf ihrer Kenntnis des gemeinsam genutzten Kennworts. Zertifikate sind eine unnötige Komplikation; Theoretisch sollten SSL-Client und -Server in dieser Situation TLS-PSK oder TLS-SRP verwenden und das gesamte Geschäft mit X.509-Zertifikaten insgesamt vermeiden.

Insbesondere in SRP speichert der Server nicht das Kennwort selbst, sondern eine Ableitung davon (ein Hash mit einer zusätzlichen mathematischen Struktur). Man muss einen wichtigen Punkt beachten: Im Fall einer Web-API sind sowohl der Client als auch der Server Maschinen, an denen kein Mensch beteiligt ist. Daher muss das "Passwort" nicht schwach genug sein, um von den Fleischsäcken gespeichert zu werden. Dieses Passwort könnte beispielsweise eine Folge von 25 zufälligen Zeichen sein, wobei eine Entropie durch das Dach geht. Dies macht die üblichen Passwort-Hashing-Methoden (langsames Hashing, Salze) nutzlos. Wir möchten weiterhin vermeiden, dass die Passwörter "wie sie sind" in der Datenbank des Servers gespeichert werden (also als Beute potenzieller SQL-Injektionen), aber In diesem Fall würde ein einfacher Hash ausreichen.

Dies weist auf Folgendes hin: Idealerweise verwendet die Kommunikation TLS mit SRP, damit eine RESTful-API von einem Server verwendet wird, um mit einem anderen Server zu kommunizieren, wobei die Authentifizierung auf einem gemeinsamen (fetten) Geheimnis basiert. Kein Zertifikat, nur auf dem Server gespeicherte Hashes. Keine Notwendigkeit für HTTP Basic Auth oder eine andere HTTP-basierte Authentifizierung, da die gesamte Arbeit bereits auf SSL/TLS-Ebene stattgefunden hätte.

Leider bedeutet der aktuelle Bereitstellungsstatus von SRP-fähigen SSL/TLS-Implementierungen normalerweise, dass Sie SRP noch nicht verwenden können. Stattdessen müssen Sie ein allgemeineres SSL/TLS mit einem X.509-Zertifikat auf der Serverseite verwenden, das der Client pflichtbewusst überprüft. Solange die Validierung ordnungsgemäß durchgeführt wird, gibt es kein Problem beim Senden des Passworts "wie es ist", z. als Teil der HTTP-Basisauthentifizierung.

35
Thomas Pornin

Ein Hauptproblem bei der HTTP-Authentifizierung besteht darin, dass Sie sich nur abmelden können, wenn Sie Ihren Browser schließen. Und da das Kennwort zu jeder Anforderung gehört, ist die Authentifizierung zustandslos. Sie können Benutzer beispielsweise nach 20 Minuten Inaktivität nicht abmelden.

Hochsicherheitsseiten wie Banken bieten in der Regel (immer?) Nicht nur die Möglichkeit für einen Benutzer, sich manuell abzumelden, sondern auch Benutzer nach einer Zeit der Inaktivität abzumelden. Dies hilft, eine Reihe opportunistischer Angriffe zu verhindern.

6
tylerl

Eigentlich habe ich gesehen, dass diese Anfragen von meiner Bank gesendet wurden. Sie verwenden jedoch weiterhin Sitzungskennungen, anstatt jedes Mal den Benutzernamen und das Kennwort zu senden (dies ist nicht wirklich erholsam, ich weiß). Der Grund, warum sie nicht nur Benutzername und Passwort, sondern eine Sitzung verwenden, liegt darin, dass sie einen zweiten Authentifizierungsfaktor benötigen. Dies bedeutet, dass Sie Ihre Challenge-Antwort bei jedem erneuten Laden der Seite erneut eingeben müssen.

Wenn Ihre Bank nur Benutzername und Passwort verwendet, würde es mich ehrlich gesagt nicht interessieren. Meiner Meinung nach sollte jede Bankanwendung mit Selbstachtung eine Form der Zwei-Faktor-Authentifizierung verwenden: entweder über SMS, Kartenleser, Token, ...

2
Lucas Kauffman