rss feed articles activities all_comments

indeedgeek.de

Florian Eitel

Passwörter

Mit ein bisschen Verspätung heute meine Meinung zu Passwörtern. Das Thema ist nicht ganz so trivial wie es erscheint da man oftmals etwas vorschnell Annahmen macht. Ich hoffe meine Argumentation stimmt soweit da ich leider keine Quellen dafür habe. Ich kenne mich nicht so super mit Kryptographie aus aber ich hoffe dafür reicht es.

Passwort Speicherung auf dem Server

Greifen wir erst einmal Aarons Post auf und gehen auf die Serverseite ein. Beim Einloggen wird das Passwort üblicherweise im Klartext an den Server gesendet (daher ist SSL immer zu empfehlen – auch wenn das nur ein bisschen Schutz bietet. Dazu evtl. wann anders mehr). Dieser prüft ob das Passwort mit dem gespeicherten übereinstimmt. Wenn das passt ist man eingelogged. Nun muss selbstverständlich der Client das Passwort kennen um es zu senden. In der Regel weiß er es indem der User das Passwort eintippt. Gleichzeitig muss aber natürlich auch der Server das Passwort wissen um es mit dem gesendeten zu vergleichen.

Plaintext Passwords

Wird das Passwort einfach auf dem Server im Klartext gespeichert kann es von jedem der Zugriff hat, oder sich Zugriff beschafft, gelesen werden. Das bringt mich zum ersten extrem wichtigen Punkt, der oftmals unterschätzt wird. Ein Passwort niemals an zwei Stellen verwenden! Der böse Administrator könnte sonst einfach das Passwort auch bei anderen Diensten ausprobieren. Wenn bei jedem Dienst ein anderes Passwort verwendet wird kann so kein Schaden an anderer Stelle entstehen. Der Admin könnte sich nur bei seinem eigenen Dienst einloggen zu dem er sowieso Zugriff hat. Externe, die sich Zugriff auf das Passwort verschafft haben können so maximal den einen Dienst angreifen. Aber mal ehrlich, wenn jemand es geschafft hat mein Passwort aus der Datenbank zu lesen dann kann er an dem Dienst soviel Schaden anrichten, dafür braucht er gar nicht mein Passwort erst. Und andere Dienste brauchen wieder andere Passwörter, so dass diese sicher sind.

Hash Funktion

Nun sieht das so unsicher aus, wenn alle Passwörter im Klartext auf dem Server rumliegen. Daher bilden einige eine Hashfunktion über das Klartext-Passwort und speichern nur diesen Hash ab. Man kann nicht von dem Hash auf das ursprüngliche Passwort zurück schließen. Somit kann jemand der Zugriff zur Datenbank hat keine Passwörter lesen, da diese alle gehashed sind. Der Nachteil daran ist: Die Hashfunktionen sind aufgrund der heutigen Rechenpower “relativ schnell” durchgerechnet. Es gibt fertige Listen die beispielsweise alle Passwörter mit Buchstaben und Zahlen bis zu acht Zeichen und den dazugehörigen Hashes enthalten. Diese so genannten Rainbowtables kann man sich herunterladen (oder wenn einem kalt ist auch selbst generieren) und darin den Hash suchen. Mit etwas Glück findet sich daneben das Passwort welches den Hash ergibt. Somit ist ein alleiniges Hashen relativ nutzlos.

Salted Passwords

Um salted Passwords etwas besser zu erklären verwende ich mal ein echtes Beispiel. Die Hashfunktion die ich oben erwähnt habe nenne ich mal SHA1 und ich verwende das Passwort yaeT6Ief. Hashed man das Passwort mit der Hashfunktion kommt c115564dc874a2f4ece06b85781a5770ed042a5c heraus. Somit lässt sich sagen SHA1(yaeT6Ief) = c115564dc874a2f4ece06b85781a5770ed042a5c. Dies ist aber wie bereits gesagt relativ einfach wieder auflösbar da man sich die Liste generieren kann. Man muss also das Passwort so lang machen, dass die Liste zu aufwändig und zu groß wird. Dann lohnt es sich nicht die Liste zu erstellen. Aber keiner möchte ein Passwort mit 50 Zeichen haben. Daher verwendet man folgenden Trick: Man nimmt einen beliebigen String. Oftmals der Username – allerdings wenn man mit dem selben Usernamen und dem selben Passwort bei mehreren Diensten angemeldet ist, kann man diese Gleichheit anhand des Hashes sehen. Wenn man nun das Passwort des einen Dientes kennt ist es offensichtlich, dass bei dem anderen Dienst die selbe Kombination verwendet wurde. Daher nimmt man an dieser Stelle lieber einen zufälligen Wert der allerdings zusammen mit dem Usernamen mit im Klartext in der Datenbank abgespeichert wird. Dieser zufällige Wert sollte möglichst lang sein und wird Salt genant. Nun wird aus unserem Passwort Hash und dem Salt erneut ein Hash erzeugt. Dazu wird oftmals ein Separator wie “.” verwendet, der aber nur zur Übersichtlichkeit dient.

HASH = SHA1(salt.SHA1(password))

In unserem konkreten Beispiel mit dem Salt “Aer4e”:

HASH = SHA1(Aer4e.c115564dc874a2f4ece06b85781a5770ed042a5c) = ea9b188922cecff3ca7cba0f33aa6c283308a5c9

Somit sind zum entschlüsseln zwei Schritte notwendig. Erst muss ea9b188922cecff3ca7cba0f33aa6c283308a5c9 in der Datenbank nachgeschlagen werden. Da das Resultat sehr lang ist wird dies sehr wahrscheinlich nicht zum Erfolg führen. Wenn doch bekommt man Aer4e.c115564dc874a2f4ece06b85781a5770ed042a5c als Resultat. Davon muss man nun den Salt und den Separator wegstreichen und erhält unseren ursprünglichen Hash c115564dc874a2f4ece06b85781a5770ed042a5c. Dieser ist dann wieder “trivial” aufzulösen.

Fazit

Wird wie im oberen Beispiel einfach das Passwort im Klartext gesendet sollte man auf die Salted Passwords zugreifen. Sie bieten am meisten “Sicherheit” und haben keine Nachteile für diese Übertragung. Einzig wenn man doch mal das Passwort benötigt kann es zu Problemen führen. Ein Beispiel wäre der berühmte “Passwort vergessen”-Link. Hier kann nicht mehr das originale Passwort hergestellt, sondern nur ein neues generiert werden. Oder auch bei der Migration auf ein neues System müssen manchmal die Passwörter umgestellt werden. Aber dafür sollten sich in der Regel passende Lösungen finden.

Es gibt aber im Gegenzug zu dem Senden von Klartext Passwörtern auch andere Verfahren bei denen das Passwort nicht übertragen wird. Dabei fragt der Client einen zufälligen Wert vom Server ab und erzeugt mit diesem und dem Passwort einen Hash und sendet diesen zum Server. Dieser nimmt das gespeicherte Passwort und durchläuft den selben Vorgang. Beides kann verglichen werden und bei Übereinstimmung ist der User berechtigt. Dabei ist es nötig das Passwort auf Serverseite im Klartext zu speichern. Ein Angriff auf den Übertragungsweg halte ich fast für wahrscheinlicher als auf die Datenbank des Servers. Daher lohnt es sich das Passwort nicht im Klartext zu übertragen. Wenn man nun die Möglichkeit hat ein solchen Login zu implementieren (API etc) lohnt es sich sicherlich das Passwort im Klartext zu speichern und dafür die Übertragung etwas sicherer zu machen.

Bevor man so etwas startet sollte man sich allerdings etwas informieren, da es durchaus Verfahren gibt, die dieses Challenge-Response anwenden und dennoch das Passwort als Hash abspeichern. Dabei ist auf Clientseite meistens noch ein zusätzliches Hashen notwendig.

Sichere Passwörter

Kurz ein paar Worte zu einem sichen Passwort. Ich weiß ihr könnte es vermutlich schon fast nicht mehr hören, dass euch ständig jemand erzählen will wie ihr sichere Passwörter macht aber eventuell habe ich ja noch ein paar neue Informationen.

Passwortlänge

Ich begebe mich nun auf etwas Glatteis da ich mich auf dem Thema eigentlich nicht so super auskenne und ich mich gerade auch nur eingelesen habe. Korrekturen bitte unbedingt in den Kommentaren!

Die sinnvolle Passwortlänge ergibt sich aus der Verschlüsselungsmethode. Wird meine Verschlüsselung zum Beispiel mit einem 128 Bit Schlüssel durchgeführt wird jedes Zeichen welches aus acht Bit besteht mit einem Zeichen aus dem Schlüssel verschlüsselt. Sind alle 128 Bit des Schlüssels verbraucht wird wieder vorne begonnen. Demnach ist ein längerer Schlüssel besser da sich seltener Teile wiederholen. Die Schlüssellänge ist meistens von dem Algorithmus vorgegeben. Wird nun ein 128 Bit Schlüssel benötigt mein Passwort hat aber Entropie von 32 Bit dann ist mein Passwort unsicherer als der Algorithmus. Somit macht es mehr Sinn den Schlüssel anzugreifen als die Verschlüsselung selbst.

Man ermittelt die Entropie eines zufälligen Passworts anhand der möglichen Zeichen und der Länge des Passworts. Hat man 42 völlig zufällige Bits dann ist das Passwort 42 Bits stark. Aber normalerweise nutzt man Buchstaben und Zahlen für ein Passwort. Da hab ich bei Wikipedia einen guten Absatz drüber gefunden.

Dort wird die Entropie, also die Bitzahl eines Passworts mit folgender Formel berechnet:

Formel für Entropie eines Zufälligen Passworts (Quelle: WikipediaCC-BY-SA)

Dabei ist L die Länge des Passworts und N die Anzahl der möglichen Zeichen. Verwendet man nun nur Ziffern ist N=10 da es nur zehn Ziffern gibt. Bei Kleinbuchstaben sind es 26. Bei Ziffern und Buchstaben 36 und mit Groß- und Kleinschreibung sogar 62. Verwenden wir nun in unserem Passwort komplett Ziffern, Klein- und Großbuchstaben und unser Passwort ist 4 Ziffern lang ergibt sich ein Wert für die Entropie von 23.8 Bit. Nahezu lächerlich zu knacken.

Diese nette Seite bietet nicht nur an die Entropie eines Passworts auszurechnen, sondern empfiehlt auch in der Skala darunter mindestens 36 Bit Entropie. Die Seite dürfte aber mal mindestens ein Jahr alt sein daher könnte der Wert heute vermutlich etwas höher liegen. Für 128 Bit benötigen wir 22 Stellen mit unseren 62 Zeichen. Das sollte denke ich ein akzeptabler Wert sein. Mindestens hingegen 10 Stellen sollten drinnen sein. Bei Wikipedia gibt es eine schöne Tabelle mit welchen Zeichen und welcher Länge welche Entropie erreicht wird.

Wichtig: Die ganze Rechnung zählt nur bei wirklich vollständig zufälligen Passwörtern. Man muss sich diese schon generieren lassen und kann nicht einfach irgendwelche Wortanfänge von Sätzen verwenden!

Fazit ist nun wohl 10 Stellen Minimum. Mindestens Ziffern und Groß-/Kleinbuchstaben. Und auf jeden Fall zufällig erzeugte Passwörter. Bei Sonderzeichen bin ich immer etwas skeptisch da ich mir nicht sicher bin ob alle Programme damit umgehen können und ob ich immer vor einer Deutschen Tastatur sitze.

Passwörter wechseln

Viele empfehlen häufig die Passwörter zu wechseln. Man beachte den Aufwand diese neu zu generieren, überall zu ändern und auch noch sich zu merken(!). Wenn mein Passwort wirklich lang genug ist und somit entsprechend sicher, warum soll ich es dann ändern? Wenn wirklich jemand Passwörter durchprobiert ist es genauso wahrscheinlich, dass er mein neues Passwort als nächstes probiert als wie mein altes. Nur weil ich ein neues Passwort habe ist es nicht schwerer zu erraten. Die Wahrscheinlichkeit ist genauso hoch. Daher frage ich mich was ein Wechsel bringen soll. Wichtig ist natürlich bei jedem Dienst ein anderes Passwort zu verwenden. Ansonsten müsste ich ständig wechseln um die Dienste nur bis zum nächsten Wechseln angreifbar zu machen wenn das Passwort doch mal offen liegt.

Daher denke ich man kann sich das Wechseln sparen. Aber nur wenn das Passwort gut(!) und einmalig(!) ist!

Sonstiges

Noch ein paar allgemeine Dinge. Zum einen sollte, wie bereits erwähnt, ein Passwort immer zufällig sein. Nichts selbst ausdenken sondern immer generieren lassen. Aber vor allem, auf keinen Fall irgendwelche Silben, Wörter, Namen, etc verwenden. Auch nicht als Teil des Passwortes. Jeder Passwortcracker wird dies zuerst anhand eines Wörterbuches durchprobieren. Auch Wörter die nicht in dem Wörterbuch stehen werden durch Variationen probiert. Ist der Nutzername x88z dann wird der Passwortcracker auch so was wie Hallox88zDu probieren! Auf keinen Fall denken solche Konstrukte wären sicher. Auch andere Schreibweisen wie ae statt ä oder neue zusammengesetzte Wörter sind lächerlich einfach zu erraten. Generieren(!) aus fertig. Ohne wenn und aber!

Dabei ist es wichtig darauf zu achten was generiert wird. Es gibt einige Algorithmen die zufällige aber lesbare Passwörter erzeugen. Dabei kommt so etwas wie faiS4cai raus. Das lässt sich durch die Struktur einfach sprechen und somit einfacher merken. Ich finde das recht gut aber man muss bedenken, dass dadurch einiges an Entropie eingebüßt wird. Deshalb lieber bei so etwas ein paar Zeichen länger machen. Leider weiß ich nicht genau in wie weit sich die Lesbarkeit auf die Entropie auswirkt.

Zudem sollte man natürlich niemanden das Passwort geben und nirgends notieren (auch nicht in einem Script hart codieren). Jaja, ihr lacht – wie viele Leute wissen denn euer Login Passwort für euren Rechner? In wie vielen Scripten habt ihr euer Mail Passwort verwendet? – Klar, niemand, niemals – Schon klar.

Passwörter speichern

Ok, fassen wir zusammen. Wir nutzen zehn Dienste und haben somit zehn unterschiedliche Passwörter mit jeweils zwanzig Zeichen, die aus Klein-/Großbuchstaben, Ziffern und Sonderzeichen bestehen. Und wir dürfen diese nirgends aufschreiben. Und jetzt merkt euch das mal alles.

Kann natürlich niemand. Dafür gibt es ja Passwortmanager. Diese sollte man auch auf jeden Fall verwenden. Jeder blöde Browser bietet diese Funktionalität an. Dabei muss man aber eines grundlegend beachten. Wenn man kein Passwort (oder andere Authentisierungsmethode) eingeben muss, kann man sich das ganze auch sparen. Dann wird IMMER irgendwo auf der Festplatte das Klartext-Passwort liegen. Vielleicht ein bisschen maskiert, so dass man es nicht gleich erkennt, aber es bleibt ohne Probleme zurückrechenbar. Um es verschlüsselt abzulegen benötigt der Manager immer ein Passwort. Sonst kann jeder einfach die Datei entschlüsseln da es das Programm ja auch ohne mein Zutun (in Form eines Geheimnisses) erledigen kann. Wer mir nicht glaubt kann zum Beispiel mal die Datei ~/.purple/accounts.xml von Pidgin anschauen.

Welchen Passwortmanager man verwendet ist eigentlich egal. Manche integrieren sich gut, andere sind gut auf verschiedene Geräte wie Handy übertragbar. Es ist nicht ganz so wichtig. Man sollte aber darauf achten, dass der Manager locked memory verwendet um die Passwörter zu speichern. Ansonsten kann es sein, dass die RAM-Bereiche, die das Passwort enthalten auf Swap-Partition geschrieben werden. Damit steht das Passwort im Klartext auf der Festplatte und kann auch nach den neu booten noch ausgelesen werden. Zudem ist es wichtig, dass der root User trotz locked memory den Ram auslesen kann und so an das Passwort kommen könnte. Aber ich denke trotzdem immer noch sicherer als der Zettel unter der Tastatur.

Mein System beziehungsweise Manager kann ich euch irgendwann anders mal vorstellen. Ich glaube der Post ist sowieso schon viel zu lange geworden. Das abschließende Fazit sollte wohl sein “Passwörter sind scheiße” aber leider müssen wir (noch) mit leben. Anregungen, Kritik und vor allem Berichtigungen bitte einfach in die Kommentare.

Comments:

(howto comment?)

Deine Argumentation bezüglich dem Wechseln von Passwörtern finde ich gelungen. Das habe ich von der Seite noch gar nicht betrachtet :)

Postet on by kb.

Bekommst jetzt meinen unqulifizierte Meinung zu Passwörtern. Passwörter immer generieren zu lassen, finde ich doch etwas übertrieben.

Die Frage ist doch was will ich denn mit dem Passwort schützen und wie soll ich mir all die generierten Passwörter merken. Dabei bin ich jetzt natürlich nicht dafür Passwörter ala Sunshine oder ähnliche zu verwenden. Aber die Satz und erste Buchstaben Methode finde ich, in den meisten Fällen, Verhältnismässig angebracht. Wenn man dann noch darauf achtet, dass nicht alle Wörter mit a, e, o, r anfangen und man auch mal was anderes als 1 als Ziffer benutzt würde ich mal behaupten, dass müsste in den meisten Fällen reichen.

Postet on by Karin.

Sehr interessanter und ausfühlicher Beitrag. Schön mal wieder was von dir zu lesen!

Du hast Recht, das Thema Passwörter ist ein leidiges Thema und die meisten sehen das nicht mal als ein Problem an. Passwörter sind dazu da um die Privatsphäre zu schützen und sich auszuweisen. Ersteres ist vielen Menschen scheißegal. Sie lassen ihr Notebook offen stehen, das E-Mail-Programm noch offen und in Facebook eingelogged. Oder den Kontostand an einem offenen Surf-Terminal gecheckt und ohne sich abzumelden weggelaufen. Alles schon gesehen. Da muss man ja schon froh sein, wenn sie ein Passwort für alles haben, sich das gemerkt haben und den Logout-Knopf finden.

Was ich noch zum Passwort ändern sagen wollte: Grade heute stand auf Golem “Kundendaten/Zugangsdaten von Die ZEIT wurden auf einer P2P-Plattform verteilt”. Diese Schwachstelle ignoriert man sehr gerne und ist bei einem “Ein-Passwort-Für-Alles”-User natürlich fatal. Deshalb sind die von dir beschriebenen generierten “Wegwerf-Passwörter” natürlich das beste. Verwendet man eine Passwortverwaltung die sich gut ins System integriert, kann das Passwort auch 50 Stellen lang sein, wenn man es nie zu Gesicht bekommt.