Warum werden Passwörter nicht als private Schlüssel benutzt?



  • Gibt es einen technischen Grund dafür, dass das Passwort jemals den lokalen Rechner verlassen muss? Lokale Software könnte doch einen privaten Schlüssel aus dem Passwort berechnen. Bei einer Registrierung bei einem Online-Dienst übermittelt die Software nicht das Passwort, sondern den passenden öffentlichen Schlüssel. Bei der Anmeldung muss das Passwort auch nicht übermittelt werden, denn es dient nur als privater Schlüssel.

    Es gibt bestimmt auch Verfahren, um bei jedem Dienst einen anderen öffentlichen Schlüssel zu verwenden, obwohl das Passwort immer dasselbe ist. Der private Schlüssel könnte beispielsweise aus dem Passwort, einer eindeutigen ID des Dienstes und einem beliebigen Benutzernamen berechnet werden. Der Name erlaubt es mehrere Konten pro Dienst mit demselben Passwort zu haben, ohne dass der Dienst automatisch weiß welche Konten derselben Person gehören.

    Ich weiß, dass man Passwörter aus historischen Gründen verwendet. Ich weiß auch, dass Kryptographie oft als unrealistisch abgetan wird, weil man zu faul und zu dumm ist sie zu nutzen (mich eingeschlossen).

    Aber hat es irgendwelche Vorteile das Passwort durch die Gegend zu schicken, damit Idioten es im Klartext in ihre Datenbank schreiben?

    EDIT:
    Zusatzfrage: Braucht man überhaupt asymmetrische Verschlüsselung für die Authentisierung oder könnte Trickserei mit einem Hash den gleichen Effekt erzielen?

    Die Kommunikation würde natürlich immer über TLS oder etwas Äquivalentes ablaufen, sonst ist das witzlos.

    Bitte vor dem Antworten:
    (1) - wissen was asymmetrische Verschlüsselung ist
    (2) - nachdenken



  • TyRoXx schrieb:

    Gibt es einen technischen Grund dafür, dass das Passwort jemals den lokalen Rechner verlassen muss? Lokale Software könnte doch einen privaten Schlüssel aus dem Passwort berechnen. Bei einer Registrierung bei einem Online-Dienst übermittelt die Software nicht das Passwort, sondern den passenden öffentlichen Schlüssel. Bei der Anmeldung muss das Passwort auch nicht übermittelt werden, denn es dient nur als privater Schlüssel.

    Damit ist der "öffentliche Schlüssel" dein Passwort. Wer den "öffentlichen Schlüssel" abfangen kann (was genau gleich schwer ist, wie dein Passwort abzufangen) hat volle Kontrolle über deinen Account. Zudem enthält der "öffentliche Schlüssel" genau gleich viel Entropie wie dein ursprüngliches Passwort, aus dieser Sicht ist er keineswegs besser.

    TyRoXx schrieb:

    Es gibt bestimmt auch Verfahren, um bei jedem Dienst einen anderen öffentlichen Schlüssel zu verwenden, obwohl das Passwort immer dasselbe ist. Der private Schlüssel könnte beispielsweise aus dem Passwort, einer eindeutigen ID des Dienstes und einem beliebigen Benutzernamen berechnet werden. Der Name erlaubt es mehrere Konten pro Dienst mit demselben Passwort zu haben, ohne dass der Dienst automatisch weiß welche Konten derselben Person gehören.

    Das nennt sich Salt und sollte bereits jetzt überall verwendet.

    TyRoXx schrieb:

    Aber hat es irgendwelche Vorteile das Passwort durch die Gegend zu schicken, damit Idioten es im Klartext in ihre Datenbank schreiben?

    Der Sinn, das Passwort im Klartext rumzuschicken ist es, dass der Server es hashen kann um den Hash mit der Datenbank abzugleichen. Dadurch kannst du den Account nicht knacken, selbst wenn du den Hash in der Datenbank kennen würdest, weil du nicht vom Hash auf das Passwort schliessen kannst. Würde hingegen der Hash verschickt, würde diese Sicherheit fehlen.

    Was man genau rumschickt ist egal, ob Passwort oder Hash des Passworts (gespeichert würde dann der Hash des Hashes). Bedenke aber, dass bei mehrmaligem Hashen Sicherheit verloren geht.

    Und inwiefern würden es Idioten es dann unterlassen, Passwörter im Klartext in ihre Datenbank zu schreiben? Klar, dass Datenbanken sicher sind, wenn sie sichere Verfahren (deines zählt nicht dazu) verwenden.



  • Was das mit asymmetrischer Verschlüsselung zu tun haben soll ist mir etwas schleierhaft, aber gehen wir mal auf den Punkt mit dem Hashen ein: Wie salty schon geschrieben hat, ist es prinzipiell egal was du als Password schickst, wenn man erwartet dass ein Angreifer das Passwort abfangen kann*. In Verbindung mit dem zweiten Vorschlag allerdings, also hash(pw + servicename + username), hätte man zumindest ein einfaches System für jeden Account ein separates Passwort zu benutzen. Warum es das noch nicht gibt? Vermutlich immer noch zu umständlich für die meisten Leute.

    * Alles was darüber hinaus geht will im Prinzip MITM-safe sein und da darfst du dann eh alles verschlüsseln.



  • Ok, das ist anscheinend schwerer nachvollziehbar als ich angenommen habe. Ich erkläre den Ablauf noch einmal neu.

    In folgendem Beispiel ist Alice die Benutzerin eines Dienstes von Bob. Alice kennt sich nicht so gut mit Computern aus und das weiß Bob, also möchte er eine unkomplizierte Möglichkeit für Alice anbieten, ihre Identität beim Login zu beweisen. Alice legt Wert auf Sicherheit, also soll das von Bob angebotene Verfahren zumindest besser sein als das naive Übertragen eines Passwortes.

    Bob kennt das RSA-Kryptosystem. Dabei hat jeder Benutzer einen privaten und einen öffentlichen Schlüssel. Den private Schlüssel hält der Benutzer unbedingt geheim, denn damit beweist er seine Identität. Der private Schlüssel wird auf einem Rechner des Benutzers generiert und nie zu jemand anderem übertragen. Der öffentliche Schlüssel hingegen darf beliebig weitergegeben werden und fungiert als eine Art Benutzerkennung. Der öffentliche Schlüssel reicht natürlich nicht aus, um sich zu authentisieren, denn dafür ist der private notwendig. RSA wäre die sicherste Möglichkeit für Alice sich zu authentisieren. Alice müsste dann aber einen sehr langen, privaten Schlüssel speichern und geheim halten. Bob nimmt an, dass ihr das nicht zuzumuten ist.

    Bob möchte RSA noch nicht aufgeben und überlegt, ob man vielleicht doch irgendwie Alice den privaten Schlüssel anvertrauen kann. Vielleicht kann man den privaten Schlüssel aus etwas berechnen, das nur Alice weiß. Das erinnert Bob als die altbekannten Passwörter, die sich die Benutzer ohnehin schon immer merken müssen. Man könnte doch den privaten Schlüssel aus einem Passwort ableiten, das nur Alice kennt. Passwort wäre jedoch der falsche Name dafür, weil es Passwort etwas ist, das vor dem Eintreten genannt werden muss. Dies hier ist aber eher ein Geheimnis, also nennt Bob es fortan so. Bob entschließt sich, seine Idee auszuprobieren. Er lädt Alice ein seinen Prototyp zu testen.

    Alice ruft nun Bobs Webdienst auf und klickt auf Registrierung. Die Registrierungsseite bittet sie ein Add-on für Firefox zu installieren, um die sichere Registrierung zu ermöglichen. Alice installiert das Add-on, weil sie weiß, dass es von bekannten Kryptologen geprüft und für vertrauenswürdig gehalten wird. Nach der Installation fragt das Add-on Alice nach einem persönlichen Geheimnis. Es erklärt, dass das Geheimnis so ähnlich funktioniere wie ein Passwort und unbedingt für jede andere Person schwer zu erraten sein müsse. Alice selbst müsse sich das Geheimnis aber merken können oder dieses analog notieren. Sie gibt ein Geheimnis ein, das nur sie kennt und bestätigt es. Die Registrierungsseite ist immer noch offen und das Add-on fragt nun, ob Alice sich registrieren wolle. Sie antwortet mit Ja, muss zur Bestätigung einmal das Geheimnis eingeben und die Registrierung findet statt:

    (1) Das Add-on berechnet aus dem Geheimnis einen privaten Schlüssel, der für RSA genutzt werden kann.
    (2) Das Add-on berechnet aus dem privaten Schlüssel den öffentlichen Schlüssel und übermittelt diesen an Bobs Dienst zur Registrierung.
    (3) Bobs Dienst empfängt den öffentlichen Schlüssel und legt für ihn ein Benutzerkonto an, sofern noch keins vorhanden ist.
    (4) Bobs Dienst antwortet dem Add-on, dass die Registrierung erfolgreich war.
    (5) Die Webbrowser wechselt wieder auf die Hauptseite von Bobs Webdienst.

    Nun hat Alice ein Benutzerkonto bei Bobs Dienst angelegt, ohne, dass irgendeine geheime Information ihren PC verlassen hat. Der öffentliche Schlüssel, der gesendet wurde, ist für Angreifer nutzlos. Auch Bob kann damit nicht viel anfangen außer Alice in Zukunft wiederzuerkennen. Insbesondere kann er sich damit nicht bei Eves Webdienst anmelden, sollte Alice sich einmal mit dem gleichen Verfahren und demselben Geheimnis bei Eves Webdienst anmelden. Hätte das Geheimnis ihren PC verlassen wie ein Passwort, müsste Alice das befürchten.

    Alice klickt auf Bobs Webseite nun auf Anmelden. Das Add-on fragt sie wieder nach ihrem Geheimnis. Der Dialog, der sie das fragt, hat übrigens Merkmale, die es Webseiten unmöglich machen ihn überzeugend zu fälschen. Beim Anmelden passiert nun folgendes:

    (1) Das Add-on berechnet aus dem Geheimnis einen privaten Schlüssel für RSA.
    (2) Das Add-on berechnet aus dem privaten Schlüssel den öffentlichen Schlüssel.
    (3) Mit den beiden Schlüssel beginnt das Add-on sich bei Bobs Webdienst zu authentisieren.
    (4) Bobs Webdienst verwendet einen bekannten Algorithmus, um zu überprüfen, ob der Client wirklich im Besitz des privaten Schlüssels ist, der zu Alices öffentlichem Schlüssel passt.
    (5) Bobs Webdienst stellt fest, dass sich hinter dem Client tatsächlich Alice bzw ihr privater Schlüssel verbergen muss.
    (6) Alice wird informiert, dass die Anmeldung erfolgreich war und sie nun Bobs Dienst als angemeldete Benutzerin verwenden könne.

    Dieses Verfahren ist so sicher wie mit realistischem Aufwand möglich und gleichzeitig mindestens so komfortabel wie herkömmliche Passwörter. Es benutzt sich im Grunde genau gleich. Ein Vorteil ist, dass man bedenkenlos für beliebig viele Dienste das gleiche Geheimnis verwenden kann. Wenn gewünscht, kann die Client-Software weitere Merkmale des Benutzers in das Geheimnis einbeziehen, zum Beispiel biometrische.
    Kein Dienstanbieter muss das Rad neu erfinden oder sich absurde Einschränkungen für Passworter überlegen. Dienstanbieter wären ein weniger lohnendes Ziel für Angreifer, weil kein Passwort mehr zu holen wäre. Falls sich das durchsetzt, wäre das Add-on nicht mehr notwendig und Browser oder andere Programme würden das Verfahren direkt unterstützen.

    Ich schätze mal den meisten Benutzern sind nur etwa 200 Bit zuzumuten.
    Könnte das trotzdem funktionieren, obwohl RSA-Schlüssel eher so 2048 Bit lang sein sollten?
    Die Idee ist hier nicht den privaten Schlüssel für SSH zu benutzen. Das Geheimnis, das lokal bleibt, soll bloß die dämlichen Passwörter ersetzen. RSA ist nur das Hilfsmittel, um den Besitz des Geheimnisses zu beweisen ohne es preiszugeben. Vielleicht ist RSA dafür auch gar nicht geeignet. So genau weiß ich das nicht.
    Weiß da jemand anderes mehr und möchte mich aufklären?



  • Das Problem ist dass du auf Public-Keys die von Passwörtern derived wurden genau die gleichen Angriffe fahren kannst wie auf Hash-Tabellen. Einfach eine Liste mit häufigen Passwörtern durchgehen, für jedes ein Key-Pair generieren, wenn die Public-Keys übereinstimmen hat man den passenden Private-Key. Was die Sicherheit der Datenbanken angeht hat sich also nicht wirklich irgendetwas geändert, offline Angriffe sind genau so möglich.

    Was das reine Abhören angeht hat man gegenüber Passwörtern den Vorteil, dass keine replay-attacks möglich sind, weil man jedes mal eine random challenge vom Server bekommt. Aber wenn man das als möglichen Angriff sieht, nimmt man normalerweise auch gleich MITM ins Boot, und dagegen schützt das leider nicht. Will man davor auch "sicher" sein, ist man quasi wieder bei SSL/TLS. Und da das vorgeschlagene Verfahren ja keinen Einfluss auf die Sicherheit der Datenbank hat, kann man dann auch gleich wieder Hashes speichern.

    Einen großen Vorteil hat man allerdings noch: Man muss dem Service-Anbieter nicht vertrauen, auch wenn man das gleiche Passwort für mehrere Services benutzt. Denn man gibt ihm nie das erforderliche Wissen um sich bei einem anderen Service zu authentifizieren. Das funktioniert btw auch mit symmetrischer Krypto, man kann einfach einen key aus dem Passwort deriven, und dann 128 random Bit mit diesem Key verschlüsseln, und dann 128 verschlüsselte und 128 unverschlüsselte Bits zum Server schicken. Dieses pair wird dann vom Server abgefragt.

    Warum das niemand so macht? In Zeiten in denen große deutsche Banken ein 5-Stellen Limit für's online banking haben, wundert mich in dieser Hinsicht leider gar nichts mehr. 😉


  • Mod

    Das war jetzt extrem viel Text, aber wenn ich das richtig sehe, hast du gerade das altbekannte Verfahren beschrieben, wie man sich per public key Verfahren authentifiziert: Schlüsselpaar erzeugen, dann über sicheren Kanal einen der Schlüssel übertragen. Damit kann sich dann der eine Nutzer beim anderen authentifizieren. Du hast es bloß durch das Passwort unnötig unsicher gemacht, da das Passwort viel weniger Entropie als ein zufällig erzeugtes Schlüsselpaar hat.
    Der Clou an der Sache ist nämlich die Übertragung des Schlüssels. Ob du da nun den Schlüssel oder das von dir vorgeschlagene Schlüsselerzeugungsprogramm überträgst ist egal. Diese Übertragung muss vertrauenswürdig sein.

    (Eigentlich würde ja derjenige, der sich authentifizieren muss, das Schlüsselpaar bei sich erzeugen. Dann könnte man nämlich den öffentlichen Schlüssel auch öffentlich übertragen, so dass das ganze Verfahren nicht an der Sicherheit der Erstübertragung hängt. Aber dazu ist dein Alice ja nicht in der Lage 😞 )



  • Das gute an dem passwort system wäre ja, dass der Verlust des privaten Schlüssels nicht so schlimm ist, weil er aus dem passwort neu generiert werden kann und man sich so noch immer überall anmelden kann.

    Das Problem ist nur, das man nun keinen sicheren Weg kennt, deterministisch einen sicheren privaten Schlüssel aus einem Passwort zu berechnen. Ein Mapping passwort+salt->große Primzahl kennt man ja leider noch nicht.



  • cooky451 schrieb:

    Das Problem ist dass du auf Public-Keys die von Passwörtern derived wurden genau die gleichen Angriffe fahren kannst wie auf Hash-Tabellen. Einfach eine Liste mit häufigen Passwörtern durchgehen, für jedes ein Key-Pair generieren, wenn die Public-Keys übereinstimmen hat man den passenden Private-Key.

    Wenn Alice sich nur noch ein Geheimnis merken muss und nicht mehr 30 Passwörter, verwendet sie natürlich nicht mehr "123456".
    Ein Problem ist in der Tat, dass zwei Benutzer mit dem zufällig gleichen Geheimnis automatisch dieselbe Identität für Bob hätten. Das könnte man mit einem Benutzernamen lösen, der nur einmal vom Dienst pro Benutzer bei der Registrierung vergeben wird. Den Namen müsste Alice sich dann noch merken. Aber der kann ja einfach "Alice123" sein.

    cooky451 schrieb:

    Was die Sicherheit der Datenbanken angeht hat sich also nicht wirklich irgendetwas geändert, offline Angriffe sind genau so möglich.

    Das ist wahr. Mindestens Bob muss den öffentlichen Schlüssel kennen. Er kann dann in aller Ruhe den privaten Schlüssel daraus berechnen, weil der ja effektiv extrem kurz ist. Mein Verfahren ist wohl gescheitert.

    cooky451 schrieb:

    Will man davor auch "sicher" sein, ist man quasi wieder bei SSL/TLS.

    Das ganze würde natürlich immer über TLS laufen wie heutige Webseiten auch. Bob muss sich mit Hilfe einer CA ausweisen, bevor Alices Browser fortfährt.

    otze schrieb:

    Das gute an dem passwort system wäre ja, dass der Verlust des privaten Schlüssels nicht so schlimm ist, weil er aus dem passwort neu generiert werden kann und man sich so noch immer überall anmelden kann.

    Genau das ist die Idee. Ein privater Schlüssel, der nur im eigenen Gehirn dauerhaft gespeichert ist.

    otze schrieb:

    Das Problem ist nur, das man nun keinen sicheren Weg kennt, deterministisch einen sicheren privaten Schlüssel aus einem Passwort zu berechnen. Ein Mapping passwort+salt->große Primzahl kennt man ja leider noch nicht.

    Die Primzahlen werden doch irgendwie mit einem PRNG generiert oder nicht? Dessen Seed kann das Geheimnis sein.

    SeppJ schrieb:

    (Eigentlich würde ja derjenige, der sich authentifizieren muss, das Schlüsselpaar bei sich erzeugen. Dann könnte man nämlich den öffentlichen Schlüssel auch öffentlich übertragen, so dass das ganze Verfahren nicht an der Sicherheit der Erstübertragung hängt. Aber dazu ist dein Alice ja nicht in der Lage 😞 )

    Alice erzeugt das Schlüsselpaar bei sich, indem sie sich ein Geheimnis ausdenkt. Seine Identität muss Bob natürlich eine Ebene tiefer mit TLS und einer CA beweisen.


  • Mod

    TyRoXx schrieb:

    SeppJ schrieb:

    (Eigentlich würde ja derjenige, der sich authentifizieren muss, das Schlüsselpaar bei sich erzeugen. Dann könnte man nämlich den öffentlichen Schlüssel auch öffentlich übertragen, so dass das ganze Verfahren nicht an der Sicherheit der Erstübertragung hängt. Aber dazu ist dein Alice ja nicht in der Lage 😞 )

    Alice erzeugt das Schlüsselpaar bei sich, indem sie sich ein Geheimnis ausdenkt. Seine Identität muss Bob natürlich eine Ebene tiefer mit TLS und einer CA beweisen.

    Warum denkt sich Alice dann überhaupt ein Geheimnis "fürs Gehirn" aus, anstatt sich einen riesigen, zufälligen Schlüssel zu generieren und diesen auf dem Computer zu speichern?



  • SeppJ schrieb:

    Warum denkt sich Alice dann überhaupt ein Geheimnis "fürs Gehirn" aus, anstatt sich einen riesigen, zufälligen Schlüssel zu generieren und diesen auf dem Computer zu speichern?

    Weil man sich dann von überall aus, ohne einen USB-Stick o.Ä. dabei haben zu müssen, authentifizieren kann. Außerdem kann der Schlüssel nicht gestohlen werden. Man könnte natürlich irgendwie das gleiche erreichen indem man den Schlüssel verschlüsselt und dann zum öffentlichen Download bereitstellt, aber das dürfte mehr oder weniger die gleichen Sicherheitsprobleme haben. 🤡



  • TyRoXx schrieb:

    otze schrieb:

    Das Problem ist nur, das man nun keinen sicheren Weg kennt, deterministisch einen sicheren privaten Schlüssel aus einem Passwort zu berechnen. Ein Mapping passwort+salt->große Primzahl kennt man ja leider noch nicht.

    Die Primzahlen werden doch irgendwie mit einem PRNG generiert oder nicht? Dessen Seed kann das Geheimnis sein.

    Wie lange dauert es denn für einen PRNG, dir eine lange Primzahl zu ziehen?



  • Nicht sehr lange, das ist der übliche Weg Keys zu erzeugen. (Nur eben dass der Seed random ist.)



  • otze schrieb:

    Wie lange dauert es denn für einen PRNG, dir eine lange Primzahl zu ziehen?

    Der Primzahlsatz sagt, dass π(n)nlnn\pi(n) \approx \frac{n}{\ln n} gilt wobei π(n)\pi(n) die Anzahl Primzahlen kleiner gleich nn ist. Das heisst wenn du eine zufällige Zahl in der Grössenordnung nn ziehst hast du mit Wahrscheinlichkeit 1lnn\frac{1}{\ln n} eine Primzahl. Das ist auch für sehr grosse Zahlen (z.B. mit 2048 Bits) noch ziemlich wahrscheinlich.


Anmelden zum Antworten