Schockwellenreiter → Essays → Passwortverwaltung

Ideen zu einem (hoffentlich einigermaßen sicheren) Passwortgenerator und -verwalter

Die leider immer noch weit verbreitete Nutzung eines Passwortes für alle Dienste, die man im Internet in Anspruch nimmt, sorgt immer wieder für massive Sicherheitsprobleme – gerade auch in Betrieben und Institutionen. Auf der anderen Seite ist es für den Nutzer, der sich daran hält, für jeden Dienst ein eigenes, sicheres Passwort auszudenken, nahezu unmöglich, sich all diese Passwörter zu merken. Zwar gibt es kommerzielle Programme, die hinter einem master password alle vergebenen Passwörter verwalten, aber in meinen Augen sinkt die Sicherheit dadurch, daß diese Programme die Passwörter irgendwo – hoffentlich verschlüsselt – abspeichern.

Mir ist daher die Idee gekommen, ein Programm zu entwerfen, das nicht nur einigermaßen sichere Passwörter generiert, sondern diese auch rekonstruiert, ohne sie speichern zu müssen. Ausgangspunkt ist die Tatsache, daß nahezu jeder Zufallszahlengenerator in nahezu jeder Programmiersprache einen seed akzeptiert, der diese Zufallszahlen rekonstruierbar macht.

Voraussetzungen

Jeder Dienst, für den man ein Passwort benötigt, bekommt eine eindeutige, vierstellige, numerische PIN. Diese PIN muß man sich vermutlich irgendwo notieren (Sicherheitsrisiko!), doch dazu unten mehr.
Jeder Nutzer dieses Programms gibt sich ebenfalls eine vierstellige PIN.

Implementierung

Aus diesen beiden PINs konstruiert sich das Programm einen eindeutigen seed (z.B. durch DienstePIN*NutzerPIN, oder abs(DienstePIN minus NutzerPIN)^2, der Phantasie sind hier keine Grenzen gesetzt).

Mit dieser seed wird solange hintereinander ein Zufallszahlengenerator aufgerufen, wie die Länge des Passwortes gewünscht wird (ich empfehle 12 Zeichen). Der Zufallszahlengenerator erzeugt Zufallszahlen im Range der Länge des Arrays, das die zulässigen Zeichen für das Passwort enthält. Da ein Passwort aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen gemischt sein sollte, empfehle ich für dieses Array die Elemente

[a..b], [A..B], [0..9], [.,-;:!?]

Andere Sonderzeichen als die in den letzten eckigen Klammern genannte sind kritisch, da nicht alle Dienste UTF-8-fest sind. So akzeptiert nach meinen Erfahrungen z.B. Zope kein § im Passwort und viele Dienste reagieren verschnupft auf deutsche, skandinavische oder andere Umlaute im Passwort.

Um die Angelegenheit nicht allzu durchschaubar zu machen, sortiert man dieses Array zu Beginn einmal – aber fest – frei nach Schnauze um. Das kann man händisch auswürfeln und dann im Quellcode fest verdrahten. Danach sollte das Programm zu einer gegebenen Dienste- und Nutzer-Pin immer das gleiche Passwort ausgeben.

Sollte man also sein Passwort vergessen haben, gibt man einfach die Nutzer- und Dienste-Pin im Programm ein und man bekommt das Passwort ausgegeben – ohne daß dieses irgendwo abgespeichert wurde.

To PIN or not to PIN

Natürlich sind nun die PINs, die sich jeder Nutzer vermutlich irgendwo notieren wird, das Sicherheitsrisiko. Dazu habe ich eine Idee aus irgendeinem Tatort, den ich vor Jahren mal gesehen habe, geklaut:

Der Nutzer denkt sich ein zehnstelliges Wort aus, in dem jeder Buchstabe nur einmal vorkommt und das er sich gut merken kann, z.B. bezirksamt. Dieses Wort numeriert er nun durch. Ob er dabei die alte Telephon-Konvention (beginnend mit 1, endend mit 0) oder die neuere Informatiker-Konvention (beginnend mit 0, endend mit 9) einhält, ist völlig egal. Dann gibt es, wenn man die Telephon-Konvention verwendet, folgende Entsprechung:

|b|e|z|i|r|k|s|a|m|t|
---------------------
|1|2|3|4|5|6|7|8|9|0|

Hat der Nutzer nun für seine persönliche PIN 4711 gewählt, kann er sich irgendwo notieren isbb. Und wenn sein Facebook-Account die Nummer 0815 hat, steht in seinem Notizbuch (oder wo auch immer) zu Facebook tsbr.

Natürlich hält dieses einfache Verfahren keinem großangelegten Krypto-Angriff unserer Freunde von der NSA oder anderen Schlapphüten stand, aber solange man das Schlüsselwort (bezirksamt) nicht auch noch im gleichen Notizbuch aufgeschrieben hat, dürfte es schon einige Probleme bereiten. Denn alleine die deutsche Sprache hält Hunderte, wenn nicht gar Tausende von zehnstelligen Wörtern bereit, in denen jeder Buchstabe nur einmal vorkommt. Und wem dies nicht reicht, der kann sich ja ein Wort ausdenken, das nicht im Wörterbuch steht, z.B. wundergast.

Caveat

Dieses Verfahren setzt natürlich voraus, daß die zur Implementierung verwendete Programmier- oder Skriptsprache nicht irgendwann einmal den Algorithmus zur Erzeugung der Zufallszahlen ändert. Daher Vorsicht bei Updates!
Ich habe überlegt, auch noch den Nutzernamen (meist die Email-Adresse) in die Generierung des Seeds einfließen zu lassen. Aber ich glaube nicht, daß dadurch die Sicherheit wesentlich erhöht wird.
Daß dieses Verfahren nicht für hochsensible Daten geeignet ist, weiß ich auch. Aber ich denke hier eher an Erika Normalnutzer und Otto Mustermann.

Call for Comments

Ich plane, diese Idee in Programmcode zu gießen. Man könnte sie sogar durchaus auch als Webservice anbieten. Aber vorher würde ich gerne wissen, ob ich nicht irgendwo ein schwerwiegendes Sicherheitsloch übersehen habe. Daher wäre ich für kritische Kommentare dankbar.

Natürlich bin ich mir im Klaren, daß dies keine weltbewegende Idee ist. Daher erhebe ich auch keinerlei Urheber- oder Patentanspruch darauf. Wer sie also für gut findet und sie verwenden oder weiterentwickeln will: Nur zu! Hauptsache, das Web wird dadurch ein wenig sicherer.

6 (Email-) Kommentare

So etwas ähnliches scheint der Ansatz http://www.heise.de/ct/ausgabe/2014-18-Ein-neues-Konzept-fuer-den-Umgang-mit-Passwoertern-2284364.html zu sein. Statt Zufallszahlen mit festem seed werden dort Hash-Funktionen genutzt, um das Passwort zu berechnen, statt es zu speichern. Eine Umsetzung davon scheint http://www.supergenpass.com/ zu sein (Quellcode auf https://github.com/chriszarate/supergenpass).

– Tobias B. (Kommentieren) (#)

Die Idee gefällt mir gut. Ich würde dieses gerne nutzen. Der Hinweis von Tobias auf http://www.supergenpass.com/ funktioniert bei mir nur im Micro$chrott iExplorer. Firefox gibt nur gerade ‘true’ zurück. Ist wohl meine Unfähigkeit.
Wenn ich Deinen Programmcode auf einem eigenen Gerät oder wenigstens eigenem Server laufen lassen kann, ist mir dieses sympathischer als ein Script mit fremden URL.

– Ruedi K. (Kommentieren) (#)

Bei dem Beitrag mußte ich an das denken: https://www.sit.fraunhofer.de/de/news/aktuelles/presse/details/news-article/sicherer-passwortmanager-fuers-iphone/
Leider gibt es die Software wohl nur für iPhone, aber das Konzept ist schön.

– Jochen J. (Kommentieren) (#)

Auch bei meiner Idee würde das Programm – egal welche PINs eingegeben werden – ein Passwort ausgeben. Das richtige Password aber nur, wenn beide PINs korrekt eingegeben werden. Also wird auch hier ein potentieller Passwortdieb im Unklaren gelassen, ob die PINs, die er eingetippt hat, korrekt sind.

– Jörg Kantel (Kommentieren) (#)

Ich benutze dazu schon seit Jahren Passhash: ich merke mir ein master password und eine Browser Extension generiert aus dem Domain-Namen und meinem Masterpasswort ein unique password nur für diese eine Domain. Ich habe dazu vor langer Zeit mal gebloggt: http://www.splitbrain.org/blog/2007-09/11-better_password_security_with_firefox - die Extensions gibt’s für alle gängigen Browser und als Standalone JavaScript sowie als Android app.

– Andreas G. (Kommentieren) (#)

Mein Problem mit allen Passwort-Managern ist, dass man die Passwort-Datenbank und oder das Programm immer dabei haben muss. Mal schnell auf einem fremden Rechner zB auf der Arbeit die Mails checken wird dann schon aufwendig - besonders über verschiedene OS hinweg oder auf Mobilgeräten. Und einem Webservice vertraue ich meine Passwörter oder Hashes/PINs) ungern an.
Ich nutze eine Art "Kombi-Passwort" System, bestehend aus festen, zufälligen Teilen, die man sich nur einmal einprägen muss und einem variablen für jeden Webservice unterschiedlichen Teil. Dieser leitet sich direkt aus dem Namen der Website ab und kann im Kopf berechnet werden - Beispielsweise alle Vokale des Namens, um drei Zeichen im Alphabet verschoben ("Amazon" -> ddr). Für mich ein guter Kompromiss zwischen Sicherheit und Flexibilität/Merkbarkeit. Problematisch wird es nur, wenn der Angreifer mehrere Klartext-Passwörter kennt und merkt, dass jeweils nur ein kleiner Teil permutiert wird.
Wenn du allerdings wirklich deinen eigenen Service programmierst, dann kannst du auch deinen eigenen Zufallszahl-Erzeuger implementieren. In dieser Vorlesung werden ein paar erklärt: https://class.coursera.org/crypto-preview/lecture/5. Ansonsten sind auch die anderen Videos der Vorlesung hochinteressant :)

– Heinrich Sch. (Kommentieren) (#)

(Kommentieren)