Frage:
Sind Login-Zertifikate sicherer als die Standardauthentifizierung mit Benutzername und Passwort?
tobik
2014-06-24 22:40:41 UTC
view on stackexchange narkive permalink

Ich habe gerade ein neues Bankkonto eröffnet, das mit Internetbanking verbunden ist. Im Gegensatz zu den anderen, die ich bisher verwendet habe, erfordert dieses ein persönliches Zertifikat (eine auf meinem Computer gespeicherte P12-Datei) + Passwort zur Authentifizierung anstelle des Standardbenutzernamens + Passworts. Diese Methode ist ziemlich unpraktisch ... Ich muss das Zertifikat an einem sicheren Ort aufbewahren, ich muss es sichern, ich kann auf keinem Computer auf mein Konto zugreifen, es sei denn, ich habe das Zertifikat bei mir, das Zertifikat hat ein Ablaufdatum und ich kann nicht einfach eine neue generieren.

Also ... gibt es irgendwelche Vorteile? Ich würde annehmen, dass diese Methode sicherer ist, bin mir aber nicht sicher. Ich weiß nicht, wie der Authentifizierungsprozess tatsächlich funktioniert, aber es scheint mir, dass das Stehlen eines Zertifikats vom Computer des Kunden genauso einfach / schwierig ist wie das Stehlen seines Benutzernamens. Persönlich fühle ich mich besser mit meinem Benutzernamen, der nur in meinem Kopf gespeichert ist, als mit einer Datei, die irgendwo auf meiner Festplatte gespeichert ist.

https://security.stackexchange.com/questions/3605/certificate-based-authentication-vs-username-and-password-authentication
Fünf antworten:
David
2014-06-24 23:03:27 UTC
view on stackexchange narkive permalink

Das Zertifikat schützt Benutzer vor der häufigsten Sicherheitsbedrohung für die Authentifizierung: der Wiederverwendung von Kennwörtern. Die meisten Internetnutzer neigen dazu, dieselben oder ähnliche Passwörter auf verschiedenen Websites zu verwenden, auch auf Bankenseiten. In diesem Fall bedeutet der Kompromiss einer Kennwortdatenbank von einer anderen Site jetzt den Zugriff auf die Banking-Site.

Zertifikate schützen auch vor der zweithäufigsten Bedrohung: Phishing. Die Verwendung der gegenseitigen Authentifizierung in TLS für die Clientüberprüfung macht Phishing nahezu unmöglich. (Der Angreifer müsste auf beiden Seiten der Verbindung eine nicht autorisierte Zertifizierungsstelle einrichten. Wenn er dazu in der Lage ist, kann er viele schlimmere Dinge tun.)

Sie haben Recht, dass ein Zertifikat vorliegt Für einen Angreifer ist es nicht wesentlich schwieriger zu stehlen als Anmeldeinformationen. Daher bietet er einem Benutzer mit einem gefährdeten Endpunkt wenig Sicherheit. Das Zertifikat schützt jedoch vor zwei sehr realen Problemen und ist daher eine sicherere Option als ein einfacher Benutzername / Passwort. Wie Sie bereits betont haben, ist diese Sicherheit mit Usability-Kosten verbunden, was unglücklich ist.

Ich bin mir nicht sicher ob ich das verstehe. Erste Bedrohung: Wenn jemand mein Passwort von einer anderen Quelle stiehlt, benötigt er immer noch meinen Benutzernamen. Normalerweise ist der Benutzername eine E-Mail, also wäre das kein Problem, aber zum Beispiel authentifiziere ich mich in meinem anderen Konto mit einer ziemlich langen, eindeutigen Kundennummer. Der Angreifer würde diese Nummer genauso benötigen wie mein Zertifikat. Aber in diesem Fall ist die Nummer nur in meinem Kopf, nein auf meinem Computer, also wäre es tatsächlich schwieriger zu bekommen.
Zweite Bedrohung: Was ist der Unterschied für eine gefälschte Site zwischen Zertifikat + Passwort und Benutzername + Passwort? Die meisten Phishing-Sites richten sich an unerfahrene Benutzer, denen die https-Verschlüsselung sowieso egal ist. Ein solcher Benutzer würde einfach ohne zu zögern sein Zertifikat auf diese Site hochladen.
(Beachten Sie, dass ich das Zertifikat nirgendwo installieren musste. Es ist ein einfaches Webformular, in dem ich aufgefordert werde, die Zertifikatdatei von der Festplatte auszuwählen und mein Kennwort einzugeben.)
Benutzernamen sollten niemals als Authentifizierungsfaktoren betrachtet werden, sie sind häufig Supportmitarbeitern ausgesetzt usw. Wenn ein Benutzer bereit ist, sein Zertifikat hochzuladen, anstatt es zur Authentifizierung zu verwenden, können sie auf diese Weise gefälscht werden.
Das Verteilen des Zertifikats ist * keine * Bedrohung. Das ist der springende Punkt bei der Authentifizierung mit öffentlichem Schlüssel: Sie tauschen zu keinem Zeitpunkt vertrauliche Informationen mit dem Server aus. Der private Schlüssel bleibt auf Ihrem PC, und ohne den privaten Schlüssel ist das Zertifikat für einen Angreifer nicht von Nutzen.
@Fleche Ja, ich meinte, das Ganze (Zertifikat + Schlüssel) auf einen Gegner hochzuladen, wie im Fall einer .p12-Datei. Wenn Sie jemanden dazu bringen können, ist das Spiel vorbei.
Ich bin immer noch nicht von dem Phishing-Argument überzeugt (zumindest im Fall meiner Bank, mit der ich das Zertifikat über ihre Webseite auswählen kann), aber es besteht kein Zweifel daran, dass die Zertifikatauthentifizierung bei der erstgenannten Bedrohung erfolgt ein Unterschied. Wie bereits erwähnt, kann ich nachweisen, dass ich den Schlüssel besitze, ohne ihn tatsächlich zu senden, was natürlich nicht für einfache Benutzernamen gilt. Und wie bereits erwähnt, kann der Benutzername kaum als Authentifizierungsfaktor angesehen werden. Ich kann mir vorstellen, dass es in derselben Datenbanktabelle direkt neben dem Passwort gespeichert ist.
Ein privater Schlüssel * ist * erheblich schwerer anzugreifen und zu stehlen ***, sobald er auf einer Smartcard gespeichert ist und nicht direkt zugänglich ist ***. Smartcards können in vielen Browsern und E-Mail-Anwendungen über standardisierte Schnittstellen als Zertifikat- / Schlüsselspeicher verwendet werden. Bei einigen Bankstandards wie [FinTS] (http://en.wikipedia.org/wiki/FinTS) ist die Unterstützung von Smartcards in Anwendungen enthalten, die diese unterstützen.
@David Wenn der Schlüssel an einem Ort gespeichert wird, auf den der Benutzer nicht leicht zugreifen kann (ich weiß nicht, ob dies der Fall ist), müsste die Phishing-Website komplizierte Anweisungen zum Abrufen dieser Datei bereitstellen. Das sollte für die meisten Menschen eine rote Fahne auslösen.
Leider ist dies bei meinem Internetbanking nicht der Fall, bei dem das Zertifikat einfach über die Weboberfläche bereitgestellt wird. Es ist also anfällig für Phising wie jede andere Standard-Authentifizierungsseite für Benutzername und Passwort. Deshalb war ich in erster Linie so skeptisch gegenüber Zertifikaten.
Tom Leek
2014-06-25 01:56:50 UTC
view on stackexchange narkive permalink

Der wichtige Teil des Zertifikats ist eigentlich nicht das Zertifikat selbst, sondern das zugehörige Objekt namens privater Schlüssel . Die "p12" -Datei enthält beide. Während der Verbindung wird dem Server das Zertifikat (der öffentliche Teil) angezeigt, und der private Schlüssel wird verwendet, um den Server davon zu überzeugen, dass der private Schlüssel tatsächlich vorhanden ist (also vermutlich der Schlüsselbesitzer, d. H. Sie). Technisch handelt es sich um eine digitale Signatur. Dies wird innerhalb der Mechanik des SST / TLS-Protokolls behandelt (das für jede "https: //" - URL verwendet wird).

Das Hauptinteresse für eine Bank von Bei Verwendung der zertifikatbasierten Clientauthentifizierung kann Ihr privater Schlüssel nicht durch Phishing gestohlen werden. Wenn böse Menschen eine gefälschte Website einrichten, die wirklich wie eine echte Bank-Website aussieht, veranlassen sie Sie möglicherweise, Ihr Passwort einzugeben, und lernen dann Ihr Passwort. Sie können jedoch Ihren privaten Schlüssel nicht stehlen. Das ist die Magie kryptografischer Signaturen: Macht zu verifizieren bedeutet nicht Macht zu generieren. Selbst wenn Sie sich törichterweise mit einem gefälschten Server verbinden und dieser Server nach einem Nachweis des Besitzes Ihres privaten Schlüssels (gemäß SSL) fragt, kann der gefälschte Server Ihren privaten Schlüssel nicht lernen und sich als Sie ausgeben.

Das ist also Ihr Vorteil: Schutz vor Phishing. Gefälschte Websites scheinen die häufigste Sicherheitsbedrohung für Banken im Zusammenhang mit dem Internet zu sein. Daher ist es logisch, dass sie versuchen, etwas dagegen zu unternehmen.

Wir können auch argumentieren, dass Ihr privater Schlüssel entgegen Ihrem Passwort nicht von einem Schlüssellogger erfasst wird, aber das ist kein sehr gutes Argument, da Software-Schlüssellogger Schlüssel nur protokollieren können, weil sie welche haben privilegierter Zugriff auf Ihren Computer. Ab diesem Zeitpunkt können sie auch den privaten Schlüssel abrufen oder zumindest verwenden. (Das Argument funktioniert immer noch bei "Hardware" -Tastenloggern, z. B. einer Kamera, die in der Nähe der Decke verborgen ist und eine gute Sicht auf die Tastatur bietet.)


Es gibt noch ein weiteres potenzielles Plus, aber es ist nicht wirklich für Sie. es ist eher für die Bank. Das Verteilen von Zertifikaten an Kunden innerhalb eines bestimmten Verfahrens kann der erste Schritt für Signaturen bei Transaktionen mit Nicht-Zurückweisung sein. Dies erhalten Sie nicht mit SSL (wobei sich die Signatur in der Sitzung befindet, nicht in den übertragenen Daten). Es erfordert speziellen Code auf der Client-Seite. Unterschriften ohne Ablehnung sind eine legale Waffe gegen Sie , falls Sie die Website verwenden, um einen Finanztransaktionsauftrag zu senden, und dann versuchen, darauf zu verzichten. Die Unterschrift kann dann vor Gericht als Beweis dafür verwendet werden, dass Sie es wirklich getan haben.

Es ist unwahrscheinlich, dass Ihre Bank derzeit ein solches Unterschriftssystem verwendet. Das Bereitstellen clientseitiger Zertifikate beginnt jedoch.

Vielen Dank für Ihre Antwort. Ich habe bereits irgendwo in den Kommentaren hier erwähnt, dass mir das Phishing-Argument nicht gültig erscheint. Bei meiner Bank besteht das Authentifizierungsformular aus zwei Feldern, einem zur Auswahl des Zertifikats von der Festplatte und einem für das Kennwort. Ich nehme an, die Originalseite sendet das Zertifikat zwar nicht an den Server, aber es wäre wirklich einfach, eine gefälschte Seite mit ähnlicher Form zu erstellen, die die Datei an den Angreifer sendet.
@tobik Sie haben eine "Seite", auf der das Zertifikat ausgewählt wird? Klingt nach clientseitiger JS-Krypto. Können Sie auf die Seite verlinken? Wenn clientseitige Krypto in JS verwendet wird, gibt es viele Probleme bei der Implementierung.
https://www.mojebanka.cz/InternetBanking/?L=DE Dies scheint leicht zu fälschen.
Ja, Ihre Bank hat eine unglaublich schlechte Benutzeroberfläche erstellt, die den Eindruck erweckt, dass Sie Ihre PKCS # 12-Datei und die Passphrase verteilen sollten. Das ist nicht der Fall. Sie geben den privaten Schlüssel oder die Passphrase niemals an Dritte weiter. Und tatsächlich sieht es so aus, als würde die Website diese Daten nur clientseitig verarbeiten. Ich verstehe Ihre Verwirrung, aber Sie müssen zwischen der Methode selbst (die sehr sicher ist) und der schlechten Implementierung durch Ihre Bank unterscheiden (was es einem Phisher erleichtert, nach privaten Daten zu fragen).
Fleche
2014-06-24 23:24:07 UTC
view on stackexchange narkive permalink

Ihnen fehlen mehrere Dinge:

  • Ihr Konto ist jetzt durch zwei Faktoren geschützt: den privaten Schlüssel (der auf Ihrem Computer gespeichert ist) und die Passphrase (was du weißt). Ein Angreifer benötigt beides.
  • Es müssen keine vertraulichen Daten auf dem Server gespeichert oder an diesen gesendet werden. Der private Schlüssel verlässt niemals Ihren PC. Ein Angreifer kann also nicht einfach einige Passwort-Hashes vom Server abrufen und einen Brute-Force-Angriff starten. Sie müssen Sie gezielt angreifen.
  • Seien wir ehrlich: Die meisten Passwörter sind schrecklich. Dies kann akzeptabel sein, solange „nur“ unser Facebook-Konto auf dem Spiel steht, eine Bank jedoch etwas mehr Sicherheit benötigt.
Nun, aber beide Faktoren sind auf meinem Computer gespeichert. Wenn also ein Angreifer meinen Computer hackt, spielt das keine Rolle. Er kann einfach meine CD nach dem Zertifikat durchsuchen und dann mit dem Key Logger mein Passwort abrufen. Oder liege ich falsch? Und wofür genau wird der Schlüssel verwendet? Ich konnte nicht finden, wie es funktioniert.
Wenn Ihr gesamtes Betriebssystem kompromittiert ist, ist das für * jede * Authentifizierungstechnik so gut wie vorbei. Der Punkt ist, dass die Authentifizierung mit öffentlichem Schlüssel vor Massenangriffen schützt, bei denen jemand eine Sicherheitslücke auf dem Server findet, die Datenbank herunterlädt und dann die Kennwort-Hashes aller Kunden angreift. Mit Zertifikaten ist das nicht möglich. Jetzt müssen sie dich persönlich angreifen. Beachten Sie auch, dass Zertifikate * nicht * auf dem PC gespeichert werden müssen. Sie können für zusätzlichen Schutz auf einer Smartcard aufbewahrt werden.
Es ist nicht möglich, denn selbst wenn er es schaffen würde, das Passwort zu knacken, würde er immer noch das Zertifikat benötigen, um sich anzumelden? Könnten Sie bitte erklären, wie genau das Zertifikat verwendet wird, oder mich auf eine Quelle verweisen?
("Zertifikat" ist in diesem Fall möglicherweise kein korrekter Ausdruck. Die Bank verwendet "Zertifikat" zur Beschreibung der .p12-Datei.)
Eine `.p12`-Datei ist ein Zertifikat, das mit dem entsprechenden privaten Schlüssel gebündelt ist.
goodguys_activate
2014-06-24 22:51:59 UTC
view on stackexchange narkive permalink

Sie äußern berechtigte Bedenken:

  • Wenn sich auf Ihrem Computer Malware befindet, kann das vom Menschen einprägsame Kennwort zum Schutz der p12-Datei brutal offline gezwungen werden, wodurch Ihre Anmeldeinformationen und Ihr Kennwort offengelegt werden.
  • Die Verwendung eines Zertifikats auf vielen Geräten ist problematisch.

Der Hauptvorteil, den ich sehe, besteht darin, dass Client-Zertifikate TLS für gegenseitige Authentifizierung zulassen, was bedeutet, dass jede Seite sicher sein kann, dass es keine gibt HTTPS-Proxy (Corporate Spyware oder Wifi-Hacker), der den Datenverkehr zwischen Ihnen und der Bank überprüft.

Ich hoffe, Ihre Bank ermöglicht es Ihnen, eine Reihe von Zertifikaten auf vielen Geräten zu haben, von denen jedes unabhängig storniert werden kann / widerrufen, wenn Ihr Gerät verloren geht, gestohlen oder kompromittiert wird.

Omer Iqbal
2014-06-25 14:03:27 UTC
view on stackexchange narkive permalink

Zertifikate fügen einen zweiten Authentifizierungsfaktor hinzu, der Ihr Konto viel sicherer macht.

Erstens sind die drei Faktoren:

  • Was Sie wissen (dh Passwörter)
  • Was Sie haben (z. B. Telefon, Zertifikat usw.)
  • Was Sie sind (z. B. Fingerabdrücke, Netzhaut usw.)

Ihre Bank hat Es wurde sichergestellt, dass jeder, der sich bei dem Konto anmeldet, das Kennwort kennt und das Zertifikat hat.

Nehmen wir also an, ein Angreifer findet Ihr Kennwort heraus. Entweder durch Social Engineering oder durch Kompromittieren der Passwortdatenbank der Bank oder durch Abhören des Datenverkehrs von Ihrem Heimrouter oder durch Phishing usw. können sie immer noch nicht auf Ihr Konto zugreifen, da sie immer noch nicht über das Zertifikat verfügen.

Nehmen wir nun an, ein Angreifer zielt auf Sie und stiehlt Ihren Laptop oder Computer von zu Hause aus usw. Er kann immer noch nicht auf das Bankkonto zugreifen, da er nicht über das Kennwort verfügt.

Der Angreifer muss also irgendwie stehlen beides, was offensichtlich schwieriger ist und somit zu t beiträgt Die Sicherheit.

Fragen Sie Ihre Bank aus Sicht der Benutzerfreundlichkeit, ob sie stattdessen als zweiten Authentifizierungsfaktor eine SMS an Ihre Telefonnummer senden kann. Dazu muss der Angreifer Ihr Passwort kennen und Ihre Telefonnummer haben.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...