Passwortmythen oder „Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest“
Gastartikel von Oliver Sperke.
Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängisten Internetsprachen: PHP, HTML, Javascript und CSS.
Was Du vor dem Lesen wissen solltest
Die Sicherheit eines Passwortes ergibt sich aus dem verwendetem Zeichensatz und der Länge des Passwortes. Besteht ein Passwort nur aus den Ziffern 0 bis 9, hat der Zeichensatz eine Länge von 10. Besteht ein Passwort aus maximal 8 Ziffern, ergibt sich eine Anzahl möglicher Passwörter von 10^8+10^7+10^6+10^5+10^4+10^3+10^2+10^1 oder ~ 111,11 Mio. Möglichkeiten. In den meisten Erklärungen steht übrigens nur 10^8, allerdings gilt das nur, wenn ein Angreifer die Länge des Passwortes kennt. Ansonsten muss er nämlich alle Möglichkeiten ausprobieren, d. h. 0, 1, 2…01, 02, usw bis 99999999. Werden zusätzlich Kleinbuchstaben (also 0-9, a-z, äöüß) verwendet, ergibt sich ein „Schlüsselraum“, d. h. die mögliche Anzahl Passwörter von 40^8+40^7+…+40^1, also 6.72 Billionen Möglichkeiten usw.
Mythos: Ein Passwort mit mindestens 8 Zeichen ist sicher
Diesen Satz lese ich seit 10 Jahren mindestens dreimal im Jahr, nur vor 10 Jahren arbeiteten die schnellsten Heimcomputer in etwa auf dem Niveau eines heutigen Smartphones. Innerhalb dieser 10 Jahre hat sich die Computerwelt rasend schnell verändert. Auch durch das „pöse Internetz“, in dem viele Menschen ihre Ideen und ihr Wissen verknüpfen können. Während damals die wenigen Hochleistungsrechner in den Geheimdienstzentralen und IBM Laboren standen, gibt es heute völlig andere Methoden, um ein hohes Maß an Computerleistung zu erreichen. Diese reichen von der Nutzung der kompletten Hardware inkl. Grafikkarte, über Botnetze bis hin zu mietbaren Cloudlösungen.
Moderne Systeme erreichen dadurch heute weit höhere Werte beim Erraten („Brute Force“) von Passwörtern als damals. Vergleichsweise neue Techniken wie „Rainbow Tables“, die es damals einfach noch nicht gab verschärfen die Situation. Der Schlüsselraum von 8 Zeichen mit einem Zeichensatz von 102 Zeichen kann auf einem handelsüblichem Supercomputer innerhalb weniger Stunden durchprobiert werden. Das ist kein Puffer, auf den man sich verlassen sollte. Im Jahr 2011 sollte man diesen Standard endlich auf 12 Zeichen anheben, zumindest bis zum Jahr 2020.
Mythos: Ein drei Monate altes Passwort ist unsicher
Diesen Mythos lese ich mindestens genau so oft. Sagen wir, ich habe ein Passwort wie „!´5´0+Jfl+A§R?ZfAIF`D“, dann benötigt man, um dieses Passwort zu erraten bis zu 1,53 Septillion (42 Nullen) Versuche, was bei aktueller Rechenleistungen etwa 48,54 Trilliarden (21 Nullen) Jahre dauert. Inwiefern wird es sicherer, wenn ich es alle drei Monate austausche? Dieses Passwort kann man sich nicht merken. Niemand würde es auf Zettel schreiben oder eintippen.
Ein klarer Fall für einen Passwortmanager. Wenn ich dem nicht vertraue bzw. meinem eigenem Rechner, dann brauche ich auch kein sicheres Passwort, denn dann sind alle Versuche für mehr Sicherheit zum Scheitern verurteilt. Sobald ich einen Keylogger auf meinem System habe, kann ich das Passwort auch drei Mal am Tag ändern. Der potentielle Angreifer wird darüber jedes Mal informiert. Ein sicheres Passwort wird nicht unsicherer mit der Dauer seiner Verwendung.
Der einzige Schutz auch schon vorhandene Keylogger zu überlisten ist die Verwendung von One-Time-Passwörtern, die aber einen zweiten Kanal voraussetzen. Bekannt sind ja die Tan Generatoren der Banken und Sparkassen und was immer beliebter werden wird: Einmalpasswörter per SMS, wie Google das neuerdings macht. Dies kann man übrigens auch problemlos in die eigene Seite integrieren, aber es kostet derzeit immer noch einige Cent pro SMS. Da die Handyinfastruktur mittlerweile abbezahlt ist, hoffe ich ja immer noch, dass man zeitnah Flatrates bekommen kann. Aber so ganz glaube ich leider noch nicht dran.
Mythos: Passwortmanager sind unsicher
Noch ein Mythos, der sich hartnäckig hält. Passwortmanager, Bookmarklets und andere Hilfsmittel sind per Definition unsicher, weil sie meistens mit einem Masterpasswort arbeiten. Ist dieses Passwort bekannt, sind alle anderen Passwörter kompromitiert. Grundsätzlich ja, aber ohne Hilfsmittel kann man die Verwendung von sicheren Passwörtern zu den Akten legen, denn ich behaupte, kein Mensch ohne Inselbegabung kann sich mindestens zwölf Zeichen lange unterschiedliche Passwörter für dutzende Webseiten merken, und wenn doch, dann steckt da ein System hinter, was die Sicherheit nicht verbessert, z. B. indem der Name der Seite eingebaut wird. Auch gegen die Verwendung von Bookmarklets spricht nur mangelndes Vertrauen gegenüber dem Webseitenbetreiber. Und wenn ich dem nicht vertraue, sollte ich mich nicht anmelden.
Besonders häufig höre ich, dass der Passwortmanager von Firefox total unsicher sein soll. Warum? Weil es vor fast 5 Jahren mal die Möglichkeit gab, dass Phishing durch die Verwendung des Passwortmanagers begünstigt wurde. Dieses Problem wurde aber innerhalb weniger Wochen gelöst. Wenn Ihr auch hunderten Entwicklern, die regelmässig über den Code schauen nicht vertraut, zieht dem Stecker von diesem Internetz und steigt auf eine Wii um (natürlich ohne Wlan).
Mythos: Ganze Wörter in Passwörtern sind unsicher
Die Idee hinter diesem Mythos ist, dass ein Angreifer mit einer Wörterbuchattacke das Passwort erraten kann. Das ist bei einzelnen Wörtern sicher richtig, aber es wird auch gern vergessen zu erwähnen, dass man Wörter kombinieren kann. Bei Wikipedia steht wörtlich „Ein Passwort, welches nur aus ein oder zwei Wörtern besteht, ist daher bei der Verschlüsselung von Texten sehr unsicher“. Sagen wir mal, kommt drauf an.
Die deutsche Sprache ist sehr umfangreich und umfasst ca. 75.000 Grundwörter plus hunderttausender „Spezialwörter“. Gehen wir vom schlimmsten Fall aus – jedes Wort entspricht einem Zeichen und daher entspricht der Zeichensatz dem Wörterbuchumfang von 75.000. Nehmen wir jetzt weiter an, ich hätte das Passwort „HimmelundHölle“. Dieses Passwort besteht aus drei Wörtern, die garantiert in jedem Wörterbuch stehen. Trotzdem ist eine Wörterbuchattacke sinnlos, denn bei 189,22 Billiarden Möglichkeiten dauert die Berechnung des Schlüsselraums mit modernen Mitteln noch 6 Jahre. Eine Brute Force Attacke mit 6.3 Quadrillionen (24 Nullen) Möglichkeiten ist zwar noch aufwendiger, aber für eine Wörterbuchattacke muss man sicher sein, dass nur Wörter darin vorkommen und vor allem, dass die Wörter auch in diesem Wörterbuch stehen.
Was wäre, wenn ich Fachwörter wie jQuery oder MariaDB dazu nehme? Oder Eigennamen? Die Anzahl möglicher Wörter würde problemlos die 500.000 Marke übersteigen und wer sagt, dass ich nicht „HimmelUNDHölle“ schreibe oder weitere Zeichen dazu nehme wie „Himmel&Hölle!“. Wenn Ihr also das nächste Mal lest, dass man Passwörter immer aus den Anfangsbuchstaben der Wörter eines Satzes zusammen bauen soll, fragt den Schreiberling doch mal, warum man denn nicht den ganzen Satz nehmen kann. Übrigens, „geheim0815“ sollte man wirklich nicht verwenden, aber was spricht gegen „Geheim-NullAchtFünfzehn“?
Mythos: MD5 ist unsicher
Hashfunktionen wie MD5 sind dazu da, eine beliebige Zeichenkette oder eine Datei auf eine in der Länge und in den Zeichen festgelegte Zeichenkette „umzuschreiben“, um u. a. zu prüfen, ob eine Eingabe mit dem Original übereinstimmt ohne die gesamte ursprüngliche Zeichenkette vergleichen zu müssen. Im Web werden Hashes genutzt, um zu verhindern, dass ein Angreifer, der sich schon Zugriff auf eine Datenbank verschafft hat, auch noch die Passwörter der Benutzer ausliest. Der MD5 Wert einer Zeichenkette ist immer gleich. Sobald ich ein Zeichen verändere, verändert sich auch die gesamte Zeichenkette. Ein Rückwandlung zum Original ist im Gegensatz zu Verschlüsselungsverfahren wie AES nicht vorgesehen, allein schon weil Hashfunktionen grundsätzlich verlustbehaftet sind. Von 100.000 Zeichen bleiben nur 32 übrig bleiben und daraus kann man die 100.000 Zeichen unmöglich wiederherstellen.
Bereits vor 15 Jahren wurden in MD5 Schwachstellen gefunden, mit denen man Ursprungswerte so manipulieren kann, dass zwei gleiche Hashes heraus kommen. Das ist problematisch, weil man damit z. B. SSL Zertifikate fälschen konnte. Diese Verwundbarkeit wurde aber erst über 10 Jahre später wirklich demonstriert. Die Verwendung von MD5 bei SSL Zertifikaten gilt seitdem als unsicher. Aber was hat das mit dem Einsatz in unserer Datenbank zu tun? Richtig, nichts!
Die Verwendung von MD5 als Schutz für gespeicherte Passwörter ist sicher. Sagen wir ein Angreifer kennt unseren MD5 Hash und es wäre ihm möglich, eine Zeichenkette zu erzeugen, die genau diesen MD5 Wert hat. Hat er damit das Originalpasswort? Vermutlich nicht. Er kann sich evtl. bei genau dieser Anwendung mit der erzeugten Zeichenkette anmelden, aber sonst? Wenn er sowieso schon die Daten aus der Datenbank gezogen hat, warum sollte er das überhaupt wollen, wenn er seine Informationen nicht auf andere Webseiten wie E-Mail Anbieter oder Onlinebanking übertragen kann? Ausserdem muss man wissen, dass „möglich“ nicht „einfach“ bedeutet. Es wird viel Rechenleistung benötigt. Um tausende Onlinebankingkunden mit einem falschen SSL Zertifikat „abzuphishen“ lohnt der Aufwand, aber zum Erzeugen eines Passwortes, mit dem man sich vielleicht in Eurem Lieblingsforum für Waffelrezepte oder Häkelanleitungen anmelden kann? Eher nicht.
Mythos: MD5 ist sicher
Wer immer so einen Mist behauptet, hat keine Ahnung. 🙂 MD5 ist nämlich unbrauchbar zum Schutz von gespeicherten Passwörtern und sollte niemals verwendet werden. Genau wie sha1, sha256 und sha512. Falls jetzt wer irritiert ist, die Erklärung ist ganz einfach.
$hash = md5 ( "test123" );
Diese Funktion ergibt immer den hash cc03e747a6afbbcbf8be7668acfebee5. Wenn das so ist, dann ist der Hash cc03e747a6afbbcbf8be7668acfebee5 ein sicheres Zeichen dafür, dass das Passwort test123 genommen wurde. Erstelle ich jetzt eine Datenbank, in der ich Millionen von Einträgen als Original und dem dazugehörigem MD5 Hash hinterlegt habe, dann kann ich mit sehr hoher Geschwindigkeit genau das erreichen, was nicht gehen sollte: Beliebige Hashes zurück rechnen. Diese sog. „Rainbow Tables“ sind es, die alle Hashverfahren zum Schutz von Passwörtern wertlos machen, denn es ist völlig unerheblich, ob ich für dieses Verfahren md5 oder sha512 benutze. Im Ergebnis ändert sich nur der Rechenaufwand, den ich betreiben muss.
MD5 ist, genau wie die SHA Funktionen darauf optimiert, auch große Zeichenketten möglichst effizient zu hashen, da man Sie auch für große Dateien einsetzt. Das ist z. B. dann wichtig, wenn man die Integrität einer Datei prüfen will. Beim Hashen von Passwörtern ist diese Eigenschaft eher kontraproduktiv, denn es optimiert unfreiweillig eine Brute-Force Attacke. Ob ein Verfahren sicher ist oder nicht entscheidet sich nicht in der Verwendung einer bestimmten Funktion, sondern (was auch sonst) in der Implementierung.
$hash = md5 ( "BeliebigeZeichenkette" . $passwort );
Verwende ich dieses Variante dann zwinge ich einen Angreifer den gesamten möglichen Schlüsselraum neu zu berechnen. Bereits vorhandene Rainbow Tables für MD5 sind wertlos. Ausserdem muss er den „Salt“ kennen und daher nicht nur Zugriff auf die Datenbank, sondern auch auf den Quelltext der darunter liegende Anwendung haben. Will man jetzt noch mehr Sicherheit, kann man diese Variante verwenden.
$hash = md5 ( "BeliebigeZeichenkette" . $passwort . $emaildesbenutzers );
Damit zwingt man einen Angreifer nicht nur den gesamten Schlüsselraum einmal neu zu berechnen, sondern für jeden Benutzer eine eigene Tabelle zu erzeugen. Ein Aufwand, der im richtigen Leben an der benötigten Rechenleistung scheitern wird und dieses Angriffsszenario weitgehend unbrauchbar macht. Dieses oder ähnliche Verfahren sind meiner Meinung nach das absolute Minimum, dass eine moderne Webanwendung im Bereich Passwortspeicherung können sollte.
Positiver Nebeneffekt: Sobald ein Benutzer seine E-Mail ändern will, muss er auch sein Passwort neu eingeben, das erhöht die Sicherheit vor XSS Attacken enorm. Wem das immer noch nicht reicht, der kann die benötigte Rechenleistung noch erhöhen, indem er diesen Wert mehrfach hasht.
$hash = md5 ( „BeliebigeZeichenkette“ . $passwort . $emaildesbenutzers );
for($i = 0; $i < 1000000; $i++ ) $hash = md5 ( $hash );[/php] Das Berechnen des Schlüsselraums für ein Passwort, z. B. von einem Administrator benötigt damit das 1.000.000-fache der ursprünglich nötigen Rechenleistung, was bei der Berechnung von Millionen möglicher Passwörter „hinderlich“ ist. Bei einem einzelnem Login führt es aber nur zu minimalen Verzögerungen. Um die Effizienz dieses Verfahrens in Zahlen auszudrücken. Eine Brute-Force Attacke auf das Passwort „geheim0815“ dauert auf oben erwähntem Supercomputer ca. 31 Minuten. Mit dem Faktor 1 Millionen erhöht man diese Zeit auf über 59 Jahre. In einem nicht repräsentativen Test auf meinem betagtem Laptop dauert die einmalige Berechnung etwa 500 ms.
Was lernen wir aus diesem Text?
Phishing ist lukrativer als Häkelforen! Und viel wichtiger, glaubt nicht jedem Pseudoexperten, der sich im Netz rumtreibt, schon gar nicht mir. Der größte Feind der eigenen Sicherheit ist in 99% aller Fälle nicht Unwissenheit, sondern pure Faulheit, denn ein gutes Sicherheitskonzept heißt, dass man sich zuerst einmal 30 Minuten Gedanken über das Thema macht. Es bedeutet nicht, sich ein Passwort auszudenken, für dass man Word starten muss und es bedeutet genau so wenig, dass man dieses sichere Passwort vier mal im Jahr ändern muss.
Ein sicheres Konzept fängt viel viel früher an. Verschlüsselte Daten, wo es nötig ist. Geeignete Hilfsmittel, wo man sie braucht und natürlich regelmässige Systempflege wie Updates und Virenprüfung. Das Wichtigste ist aber: Es muss benutzbar und komfortabel sein. Ein Passwortmanager, der nervt wird abgeschaltet – das ist einfach so. Überlegt Euch eine einfache Möglichkeit, um Eure Passwörter zu erzeugen. Das kann heißen, unmotiviert auf der Tastatur rumzuklimpern oder ein einfaches Javascript zu nutzen. Alternativ dazu funktionieren auch Programme wie pwgen. Dieses gibt es u. a. für Windows, Linux und als Firefoxplugin. Der beste Schutz vor geleakten Datenbanken ist aber immer noch, niemals ein Passwort zweimal zu benutzen.
Ich kenne kein einziges meiner Passwörter, ausser meinem Masterpasswort und dem Passwort meiner Festplattenverschlüsselung. Damit bin ich meiner Meinung nach auch schon völlig ausgelastet. Den Rest kann sich Firefox merken. Wenn Ihr Euch irgendwo aus welchem Grund auch immer nicht mehr anmelden könnt, lasst Euch ein neues Passwort schicken, dafür hat der Webmaster die Funktion ja eingebaut. Mit diesen einfachen Grundregeln im Hinterkopf seid Ihr schon besser geschützt als 90% aller anderen Internetnutzer.
@Oliver:
In den Kommentaren hier wird die Eingangstür mit hohen Mauern und Stacheldraht verrammelt, das Gartentor steht jedoch sperrangelweit offen. Es ist nämlich nun einmal so das kaum noch ein Angreifer ernsthaft versucht die Datenbanken auszulesen um Passwörter zu knacken. Denn mit der Vielzahl der Möglichkeiten Passwörter zu verschlüsseln, steht der Angreifer bereits vor seinem ersten und größtem Problem. Was nützt dem Angreifer ein Hash-Wert (oder tausende) wenn er nicht weiß mit welcher Methode diese erzeugt wurden?
Der primäre Angriff wird also nicht auf die Datenbank gehen um verschlüsselte Passworte zu bekommen, sondern gegen die Software um Lücken zu finden um an die Verschlüsselungsmethode, oder noch einfacher, an die unverschlüsselten Passworte zu gelangen.
Meine Aussage war ja nicht das JavaScript die ultimative Lösung sei, sondern die/eine der _einfachste(n)_ Möglichkeiten. Besser als nichts zu tun ist es ein bisschen was zu machen. Und JavaScript greift ja nicht in die Passwortspeicherung ein. Du kannst durchaus ein Passwort für den Transport einfach mit MD5 verschlüsseln und auf dem Server noch einmal mit einem Salt neu hashen. Der Unterschied zu den gängigen Lösungen ist schlichtweg der, dass auf dem Server niemals „einfache“ Passworte ankommen, sondern immer z.B. 32 Zeichen lange (je nach Verschlüsselungsmethode).
Wieso schaffen Browser es Inhalte bei https zu verschlüsseln, sollen aber bei Passwörtern versagen? Ansonsten könnte man sich auch PGP bedienen. Das Browser-Plugin könnte bei der Webseite anfragen ob und wenn ja welchen Krypto-Algorithmus diese unterstützt und dementsprechend das Passwort verschlüsseln. Einfaches Handshake-Verfahren.
Du bist auch so ein Abergläubiger der meint man müsse Informationen lediglich auf zwei Kanäle verteilen um sie vor dem Abhören abzusichern?
Weder WLAN noch GSM sind abhörsicher. Da SMS-TAN vor allem auf Reisen ganz praktisch wäre (wer will schon seinen TAN-Generator mitschleppen?), dürfte die Ausbeute z.B. am Flughafen oder Bahnhof recht gut sein. Im Internetcafe dürfte man sich dementsprechend auch in trügerischer Sicherheit wiegen.
Ganz schlimm sind hier Systeme bei denen man sich per SMS ins WLAN einbucht (z.B. MC Donalds). Hat man das WLAN geknackt, reicht ein IMSI-Catcher um sich auch noch die Daten des Handys zu verschaffen. Da die Anmeldung im WLAN über das Handy erfolgt, bekommt der Angreifen die Telefonnummer gleich frei Haus geliefert. Wenn du dann z.B. bei McD sitzt und mal eben eine Online-Überweisung machst, solltest du anschließend nachschauen ob nicht wenige Sekunden später eine weitere Überweisung raus gegangen ist. Denn solche Systeme kann man automatisieren und niemand muss sie bedienen. Das bisschen Hardware kann man leicht irgendwo im Baum/Gebüsch verstecken.
Ein System ist nur so stark wie sein schwächstes Glied. Wenn dieses schwächste Glied ausgerechnet die Datenübertragung ist, braucht man sich auch keine großen Gedanken machen wie man die Daten, z.B. Passwörter, am Zielort aufwendig verschlüsselt.
Ralf
12 Jul 11 at 00:05
„so das kaum noch ein Angreifer ernsthaft versucht die Datenbanken auszulesen um Passwörter zu knacken“
Es ist so: Man nimmt, was man kriegen kann. Der Hashalgorithmus ergibt sich aus der Länge und dem Zeichensatz. Ein MD5 sieht anders aus als sha1, sha256 oder bcrypt.
„Du kannst durchaus ein Passwort für den Transport einfach mit MD5 verschlüsseln und auf dem Server noch einmal mit einem Salt neu hashen.“
Du kannst den hash aber nicht zurück rechnen, also musst Du verschlüsseln und den Schlüssel mitsenden oder den hash speichern. In beiden Fällen hast Du nichts gewonnen. Speicherst Du den hash wertest Du evtl. Dein Passwort ab.
„Wieso schaffen Browser es Inhalte bei https zu verschlüsseln, sollen aber bei Passwörtern versagen?“
Du verwechselst etwas. Das eine ist ein Protokoll und das andere sind Daten innerhalb des Protokolls.
„Ansonsten könnte man sich auch PGP bedienen.“
Ja, aber wie tauschst Du die Schlüssel sicher aus? Über SSL? Dann brauchst Du den Javascript Foo nicht.
„Das Browser-Plugin könnte bei der Webseite anfragen ob und wenn ja welchen Krypto-Algorithmus diese unterstützt und dementsprechend das Passwort verschlüsseln. Einfaches Handshake-Verfahren.“
Ja, nennt sich SSL und geht auch ohne Plugin. 🙂
„Du bist auch so ein Abergläubiger der meint man müsse Informationen lediglich auf zwei Kanäle verteilen um sie vor dem Abhören abzusichern?“
Es erhöht die Sicherheit, mehr hab ich nicht gesagt. Ein Angreifer muss nicht nur Deine Internetleitung, sondern auch noch Dein Telefon abhören bzw. Deine SMS mitlesen. Die Barriere wird damit wesentlich höher.
„Hat man das WLAN geknackt, reicht ein IMSI-Catcher um sich auch noch die Daten des Handys zu verschaffen.“
IMSI Catcher? Jetzt wird es etwas albern, oder? Eher wird Dir jemand was über die Rübe hauen, da sind die Grundkosten billiger.
„Wenn du dann z.B. bei McD sitzt und mal eben eine Online-Überweisung machst, solltest du anschließend nachschauen ob nicht wenige Sekunden später eine weitere Überweisung raus gegangen ist“
Erstens mach ich das beim Mackes nicht, zweitens hab ich einen TAN Generator (total offline), drittens benutzt jede Bank der Welt SSL und letztens kann keiner mit einer gephishten TAN etwas anfangen, weil jede Überweisung erzeugt eine andere TAN.
„Wenn dieses schwächste Glied ausgerechnet die Datenübertragung ist, braucht man sich auch keine großen Gedanken machen wie man die Daten, z.B. Passwörter, am Zielort aufwendig verschlüsselt.“
Schnallst Du Dich auch nur in Autos mit Seitenairbag an?
Oliver
12 Jul 11 at 00:45
Der Artikel räumt in der Tat mit einigen Vorurteilen / Mythen auf. Eine zentrale Botschaft lautet: „Entspannt Euch“. Es ist gut, dass Dinge wie
– Ein drei Monate altes Passwort ist unsicher
– Ganze Wörter in Passwörtern sind unsicher
– MD5 ist unsicher
angesprochen werden; ich lese diese Vorurteile seit Jahren immer wieder. Und jedes Mal, wenn Einer darüber schreibt, was er bei Anderen gelesen (und häufig nicht richtig interpretiert) hat, treten Erleuchtete wie Daniel S auf den Plan und wissen’s nochmal besser.
Ralf trifft m.E. den Nagel auf den Kopf, wenn er sagt, dass die Angriffsvektoren in der Praxis woanders liegen. Die Sicherheit einer (Web-)Anwendung ist als Konzept zu verstehen; akademische Diskussionen um eine Inselproblematik wie das Speichern der Passphrase lenken von wichtigeren Fragen ab.
Dazu auch dieser schöne Artikel: http://meingottundmeinewelt.de/2011/06/18/eingeloggt-ohne-login/
In diesem Sinne,
cx
cortex
12 Jul 11 at 09:58
@cortex:
Nicht zuletzt die bei Sony geklauten Daten haben gezeigt, dass auch das Speichern bzw. Nicht-Speichern der Passphrasen sehr wohl relevant ist und nicht bloß akademisch.
Und sorry, der verlinkte Artikel… wer immer für den unfassbaren Schmonz verantwortlich ist, die diese Web-Anwendung darstellt, wird sowieso nicht durch Artikel über Websicherheit erreicht. Das ist so dämlich, man könnte fast von Vorsatz ausgehen. Fängt schon bei der SQL-Injection an. Nicht einmal meine erste Webanwendung war dafür anfällig, da reichen wenige Minuten, um sich zu informieren und dann das Thema für immer als abgehakt betrachten zu können!
GodsBoss
12 Jul 11 at 10:12
Ich denke was wir als Entwickler nicht vergessen sollten, ist es eben auch vor der eigenen Haustüre zu kehren. Nur weil es Trojaner, einfache Kennwörter oder unverschlüsselten Datentransport* gibt, ist das noch lange kein Grund Kennwörter »ungehasht« bzw. »ungesalted« in der Datenbank zu speichern. Denn das ist doch der Teil der in unserem direkten Einflussbereich liegt. Niemand von uns ist 100%ig davor sicher, dass die Datenbank nicht (aufgrund welcher Gründe auch immer**) in falsche Hände gelangt. Wenn dann wenigstens die Kennwörter schon mal sei es durch Salt+Runden oder (besser) bcrypt gegen Brute-Force-Angriffe geschützt werden. Dabei hilft es dann dem Angreifer doch auch nicht, wenn er die Methode kennt – wenn diese viel CPU-/GPU-Leistung erfordert. Das Ziel muss es halt sein, die benötigte Rechenleistung hinreichend hoch zu schrauben.
Nicht vergessen werden sollte, ein Trojaner greift evtl. ein einzelnes Benutzerkonto an. Bei Verlust der Datenbank sind potenziell erst einmal alle Konten in Gefahr. Allein das rechtfertigt IMHO schon die Überlegungen, wie Kennwörter in der DB sicher gespeichert werden können.
Die Benutzer unserer System können wir nicht (wirklich) vor Trojanern schützen***, das ist halt so. Aber natürlich können wir auf der DB und der Applikation aufbauend, dann je nach Sicherheitsbedarf weitere Schutzfunktionenn hinzufügen (z. B. eine 2-Wege-Authentifizierung z.B. per Yubikey, Google-Authentificator, …).
—
* bei den heutigen günsstigen Preisen von SSL-Zertifikaten ist doch die unverschlüsselte Übertragung von Kennwörtern schon fast als fahrlässig anzusehen.
** @GodsBoss: ich empfehle immer SQL-Injections nicht als so trivial abzustempeln (s. z.B. http://dearjunior.blogspot.com/2009/09/sql-injection-is-not-trivial-problem_30.html)
*** außer alles dafür zu tun, dass sie nicht über unsere Applikationen verteilt werden
Dominik Pesch
12 Jul 11 at 11:46
Sorry, ich sollte nicht in kleinen Comment-Boxen schreiben. Es hätte lauten sollen:
»Wenn dann wenigstens die Kennwörter schon mal besser gegen Brute-Force-Angriffe geschützt werden, sei es durch Salt+Runden oder (besser) bcrypt, ist schon mal einiges gewonnen.«
Dominik Pesch
12 Jul 11 at 11:48
@Dominik Pesch
Ich dachte, dass Google-Authentificator nur für Google-Apps funktionieren? Gibt es Wege, es auch für die eingende Webseite zu benutzen?
Kettil
12 Jul 11 at 14:26
@Kettil der kann auch für das normale Google-Konto aktiviert werden:
https://www.google.com/accounts/ManageAccount?hl=en
(Spracheinstellungen dafür auf Englisch setzen)
Damit sollte es dann klappen.
Dominik Pesch
12 Jul 11 at 15:18
@Dominik Pesch:
„Denn das ist doch der Teil der in unserem direkten Einflussbereich liegt.“
Die Praxis sieht aber doch leider oft so aus, dass jemand mit viel Mühe und Aufwand Passwörter verschlüsselt und sie dann in der Datenbank speichert. Aber auf der anderen Seite die Software so anfällig für Angriffe ist das ein Angreifer die Passwörter gleich im Klartext abgreifen kann.
Der erste Aufschrei in den Kommentaren galt MD5 das es nicht das optimalste sei und bcrypt doch tausendmal besser. Das beste Kryptoverfahren nützt jedoch wenig wenn die Software/Webseite selber extrem anfällig ist. Und da wäre es für Programmierer auch mal eine Überlegung wert wie man es schafft die Passwörter halbwegs sicher zu übertragen.
Deswegen fehlt mir im Beitrag eigentlich ein ganz wichtiger Hinweis an die Benutzer: Denke an den Übertragungsweg, achte darauf WO (also z.B. im öffentlichen WLAN, im Internetcafe, usw) du deine Passwörter verwendest.
Die meisten Mythen bestehen doch nicht aufgrund von Tatsachen, sondern deswegen weil man ganz andere Aspekte außer Acht gelassen hat. Was nützt es einem ein 32 Zeichen langes Passwort zu haben wenn man es im Internetcafe bei der Eingabe laut vor sich her sagt?
Der Account ist „geknackt“, der Mythos lange Passwörter seien auch nicht sicher im Umlauf.
Hier sind sicherlich ein paar Ansätze gefragt die über eine Hand voll PHP-Code hinaus geht. Aber sicherlich auch ein Thema das man als Programmierer nicht gänzlich unbeachtet lassen sollte.
Ralf
12 Jul 11 at 16:17
Sorry, Ralf, keine Ahnung, wo Du hier hinargumentierst:
Treibt nicht so viel Aufwand, weil woanders viel weniger betrieben wird?
In diesem Thread geht es um das einzeln betrachte Thema „Sicherheit von Passwörtern/Passwortspeicherverfahren“. Nur weil hier der Übertragungsweg nicht beleuchtet wird, ist jetzt das Thema nichts mehr wert? Da kann ich ja genauso argumentieren: „Vergesst SQL-Injection, viele pinnen ihr Passwort eh mit dem Postit an den Bildschirm“, „vergiss Mülltrennung, solange es Atommüll gibt, bringt das sowieso nichts“ … usw.
nk
12 Jul 11 at 17:05
@Ralf: dann ist das immer noch 1 kompromittierter Account im Vergleich zu vielen (Hundert-)Tausenden. Das ist schon ein erheblicher Unterschied.
Abgesehen davon, das Übertragungsproblem sollte doch sehr einfach, per SSL-Zertifikat zu lösen sein. Die Zertifikate kosten kaum noch etwas und bei einem nennenswerten Projekt sollte man einfach nicht mehr ohne HTTPS.
Der Hinweis auf unsichere Orte, wie »Internetcafés« ist natürlich auch wichtig. Keiner weiß, was da auf den Rechnern installiert ist. Bei sicherheitsrelevanten Seiten wäre da ein Hinweis an die Benutzer natürlich angebracht. Die berühmte Online-Überweisung möchte ich da nicht ausführen.
Das Problem bei allen Hinweisen ist leider, dass uns den Mund »franselig« hinweisen können, solange viele User eh keine Hinweise lesen sondern »weg klicken« hilft es nicht. Da sind wir schon fast wieder bei der so oft beschworenen »Medienkompetenz«. Besonders wichtig wären diese Hinweise und Schulung bei allen Administratoren von Web-Anwendungen.
Nur weil es das Problem gibt, und du hast völlig Recht, wir es nicht unbeachtet lassen dürfen; finde ich müssen wir dennoch erst einmal unsere Hausaufgaben machen. Und dazu gehört u.a. eben das sichere Speichern der uns überlassenen Geheimnisse, ganz sicher auch die sichere Übertragung (=HTTPS) und eben auch generell die Vermeidung von Angriffspunkten in unserer Programmierung (= irgendetwas zwischen trivial und sehr komplex).
Dominik Pesch
12 Jul 11 at 17:12
@nk ich denke, dass Ralfs Anmerkungen dahin gehen, dass Sicherheit im Ganzen immer am schwächsten Glied scheitert. Das ist grundsätzlich ja auch richtig.
In meinen Augen allerdings keine Rechtfertigung für unsichere bzw. nichte mehr sichere Verfahren (von Klartext bis ungesalzenen Hash-Werten).
Und für mich kommt eben zusätzlich der Unterschied zwischen einem einzelnen geknackten Benutzerkonto und allen/vielen Konten. (Immer davon ausgehend, dass Admins sich besser verhalten als User und alleine das Thema wäre wohl bereits abendfüllend.)
Dominik Pesch
12 Jul 11 at 17:15
Wo ist jetzt genau der Unterschied von „manuellem“ Mehrfachhashen und bcrypt? Das bei bcrypt alles fix und fertig ist?
Erhöht ein (zu) starkes Mehrfachhashen nicht die DOS-Anfälligkeit des Anwendung?
Markus
12 Jul 11 at 20:51
@Markus
Ja, im Prinzip schon. bcrypt den Vorteil, dass der Aufwand zur Berechnung einstellbar ist und dass man dem Hash einen Salt mitgeben kann, der dann auch mit im Hash steht. Ausserdem ist der Algorithmus auch optimiert noch sehr lahm-ja, das ist ein Vorteil.
Mehrfachhashes erhöhen die Laufzeiten, aber ich sag mal so, wenn man was kaputt kriegen will, dann schafft man das auch. So oder so,
Oliver
12 Jul 11 at 21:13
@Tom „Wenn jemand MD5 mit Salt verwendet haben wir bereits viel erreicht.“: Aber wir sollten nicht immer den gleichen Salt für alle Passwörter verwenden, sondern für jedes Passwort einen Salt zufällig generieren. Und damit wir dann das beim Login eingegebene Passwort mit dem Hash vergleichen können, speichern wir den generierten Salt natürlich in der Datenbank ab 😉
lg.
hummerlabber
13 Jul 11 at 10:15
[…] Artikel unter der Überschrift Passwortmythen oder "Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest&#… gibt es einen lesenswerten und umfangreichen Artikel zum Thema Sicherheit und […]
Sicherheit: die Passwörter-Mythen | WordPress & Webwork
13 Jul 11 at 19:02
[…] Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest | PHP Gangsta – Der P… […]
Linkliste 28 at Random People
13 Jul 11 at 21:02
@Oliver Sperke: Bei der Verwendung von Salts sollte UNBEDINGT die Funktion hash_hmac() verwendet werden. Warum genau hat Stefan Esser in einem Vortrag erklärt, von dem ich nicht wirklich viel verstanden habe 🙂 Aber hängen geblieben ist, dass man diese Funktion verwenden sollte, da Salts als Prefix oder Suffix (oder beides) auch nicht wirklich „sicher“ sind.
marcel
14 Jul 11 at 12:31
@marcel
Aber nur für md5? hmac ist ansonsten eigentlich nur dann interessant, wenn der Schlüssel wirklich geheim ist oder bleiben soll.
Oliver
14 Jul 11 at 12:54
Wer es so machen will, kein Problem.
Allerdings nochmal, es erhöht hier (in meinen Augen) nicht die Sicherheit, denn entweder der Angreifer kennt das Verfahren, nachdem wir vorgegangen sind, dann hat er auch den Schlüssel oder er kennt das Verfahren nicht und kann sich das Suchen nach dem Salt sparen, denn das wäre nur dann sinnvoll, wenn der Salt für alle gilt.
Oliver
14 Jul 11 at 13:15
@Oliver:
Ich habe es so verstanden, dass man eine Rainbow Table zu Nutze machen kann, wenn man den Salt nur als Suffix/Prefix verwendet. Wie genau es funktioniert kann Herr Esser erklären.
Somit ist der Salt nutzlos, wenn der Angreifer die Datenbank auslesen kann. Nutzt man hingegen hash_hmac() ist es wohl nicht so leicht oder schier unmöglich.
Stefan Esser hat es übrigens an SHA1 verdeutlich, so viel ich weiß.
Vielleicht findet noch jemand die Slides vom IPC10 (Mainz) von ihm.
marcel
14 Jul 11 at 13:57
[…] hat auf den Artikel Passwortmythen oder „Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest“ verwiesen und dabei RoboForm erwähnt, eine Verwaltung für Passwörter, die sich in die gängigen […]
Ratatatam – Netzleben, Webdesign, Ruhrgebiet … » Blog Archiv » Bewusstsein für Passwörter
14 Jul 11 at 14:05
Ich tippe mal, er meinte, wenn ein fester Salt vorgegeben ist und der geheim bleiben soll, dann wäre das richtig. Da sich hier der Salt in jeder Reihe ändert, macht es aber keinen Unterschied.
Oliver
14 Jul 11 at 14:33
[…] meinem vorherigem Gastbeitrag wurde ich direkt im ersten Kommentar aus meiner heilen Welt geworfen. Dort stand nämlich folgender […]
Schöner hashen mit bcrypt | Performance Test Blog
18 Jul 11 at 04:16
[…] suboptimal, wenn man damit Passwörter speichern will. Wie schon im letzten Artikel erklärt und ausgiebig diskutiert, ist die gestiegene Rechenleistung auch ein Problem für die klassischen Hashfunktionen in […]
Schöner hashen mit bcrypt | PHP Gangsta - Der PHP Blog
18 Jul 11 at 08:56
[…] Artikel zur Sicherheit von Passwörtern und zum richtigen Umgang mit md5(), sowie den Artikel zum neuen Verfahren mit bcrypt könnt ihr auf seinem Blog lesen und ausgiebig […]
PHP5 und Passwortsicherheit mit md5() und crypt() at voodoo4u/NET
23 Jul 11 at 20:11
[…] Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest | PHP Gangsta – Der P…. Tweet Schlagwörter: hash, passwörter, php, security Keine Kommentare LEAVE A COMMENT Post a comment […]
Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest » Dennis Wisnia
9 Aug 11 at 11:24
Oh Gott, so viel falsches über Sicherheit habe ich noch nie gelesen. Ich hoffe hier lesen nicht zu viele Leute mit und lernen falsche Dinge:
Wörter in Passwörtern sind unsicher, weil:
1. Die meistbenutzten Wörter zuerst verwendet werden, d.h. dein Passwort ist nur sicher, wenn es aus Wörtern besteht, die kein Mensch verwendet.
2. „GeheimNullAchtFünfzehn“ besteht aus den wohl meistbenutzten Top 100 Wörtern in Passwörtern, d.h. 100^4 = 100.000.000, das ist nichts! Schau‘ dir mal die Tabelle in dem Text an, dann bekommst du ein einigermaßen realistisches Bild: http://www.daemonology.net/blog/2011-06-03-insecurity-in-the-jungle.html#disqus_thread
3. Du wirklich zufällig aus den 75.000 wählen müsstest, was niemand tut
Außerdem will niemand so viel tippen bei der Eingabe.
„40^8+40^7+…+40^1“ ist korrekt, aber keiner verwendet 1 Zeichen-Passwörter. 40^7 ist 40 mal kleiner als 40^8, fällt also nicht mehr ins Gewicht und kann daher vernachlässigt werden.
„Ein drei Monate altes Passwort ist unsicher“, vielleicht nicht 3 Monate, vielleicht mehr, vielleicht weniger, du vergisst aber, dass 99,99 % der Passwörter nicht durch Brüte-Force geknackt werden, sondern, weil du nen Bot auf dem Rechner hat, dir jemand über die Schulter guckt, der Server es nicht sicher speichert usw., d.h. man sollte es immer mal ändern. BESONDERS DANN, wenn man einen Passwort-Manager benutzt!
Es wäre schon gut, wenn alle Passwort + Salt gehasht verwenden? Ja, aber deshalb rät man doch niemandem eine schlechtere Methode zu verwenden, wenn man eine bessere kennt. Du rätst doch auch niemandem DES zu verwenden anstelle AES nur weil DES besser ist als gar keine Verschlüsselung??? Und nochwas, benutze sichere Bibliotheken, programmiere so etwas nie selbst. Du verstehst nicht (ich auch nicht), auf was man alles achten muss, aber es gibt Leute, die können es zumindest besser als wir.
Der Firefox-Passwort-Manager ist deshalb unsicherer, weil der Browser das erste Angriffsziel aus dem Netz ist und dahinter erst der Rest des Systems steht.
Durch solches Halbwissen wird die Sicherheit im Netz nicht besser, rate den Leuten lieber mit Links zu professionellen Artikeln, dass sie dort nachlesen sollen.
@Daniel, Mehrfach hashen verringert ganz sicher nicht die Sicherheit. Wenn du es genau wissen willst, lese nach oder frage in einem Forum, dass sich mit Kryptographie beschäftigt.
Leute, ich, ihr und 99,9 % der Menschheit kennt sich mit Sicherheit nicht richtig aus, es gibt etablierte Standards, verwendet sie. Versucht niemals eigene Mechanismen zu entwickeln (wie diese Passwort hashing hier), ihr schafft es nicht, wenn ihr es schaffen wollt, studiert und promoviert und werdet Professor für Kryptographie und wenn ihr dann noch sehr bekannt seid, dann könnt ihr es mal versuchen, ansonsten Finger weg, wenn man die Algorithmen nicht versteht, dann sollte man auch keine Schlussfolgerungen daraus ziehen!
Max
24 Sep 11 at 06:25
Na, dann mal los. 🙂
Hab ich doch geschrieben. 🙂
So ein blödes Passwort würde ich auch nie vorschlagen. 😀
Die Tabelle hab ich schon verstanden, ABER diese Szenarien sind unrealistisch. In der Kombination mit Leerzeichen / Bindestrichen / Groß- / Kleinschreibung und mit/ohne Sonderzeichen ist das kein realistisches Angriffszenario, weil um diese Möglichkeiten auszuschliessen, brauchst Du Vorwissen, dass Du als Angreifer unmöglich haben kannst. Es einfach zu probieren macht keinen Sinn, denn die Energie kann man auch in was Sinnvolleres investieren. Theoretisch ist sicher vieles möglich, aber mit der Realität hat das herzlich wenig zu tun.
Genau wie Dein Beispiel. Du kannst ja auch geheimnullachtfünfzehn schreiben oder GeheimnullAchtFünfzehn. In jedem Fall kommst Du weit höher als 100 Mio. Möglichkeiten. In Kombination mit Zahlen (Geheim0AchtfünfZehn) oder Sonderzeichen (Geheim-NullAchtFünfzehn) ist die Anzahl der Möglichkeiten bedeutend höher. Ausserdem ist nur ein Zeichen oder auch nur ein Wort nicht in Deiner Liste, ist der Angriff nicht erfolgreich. Sowas kann man mal ein paar Stunden probieren, aber selbst das macht wenig Sinn.
Als Angreifer kannst Du nicht wissen, wie lang das Passwort ist. Bei einer Brute-Force Attacke musst Du erstmal alle 7-stelligen Passwörter probieren, bevor Du zu den 8-stelligen gehst. Daher ist mir nicht so ganz klar, warum man das vernachlässigen kann!? Ausser natürlich Du weißt systembedingt, dass es mindestens 8 Zeichen sein müssen. Ich denke, der Faktor 40 ist schon relevant, denn es ist ein Unterschied, ob eine Berechnung 1 Jahr oder 40 Jahre dauert.
Wie lange braucht denn so ein Trojaner auf einem Rechner, um das Passwort zu übertragen? Oder anders, Dein Computersystem ist kompromitiert. Wie oft müsste man das Passwort im Jahr ändern, damit es trotzdem sicher ist?
Dann tippt man nicht.
Und davon wird es sicherer? Warum? Ich persönlich bin da überhaupt kein Fan von, denn es verleitet dazu, ein System zu nutzen und sobald jemand das System versteht, sind die andere Passwörter auch gefährdet.
Öhm, was hab ich denn für eine „schlechte Methode“ geraten?
Also bisher sind mir keine erfolgreichen Angriffsszenarien aus dem Netz bekannt, die auf den Passwortmanager vom Web aus erfolgreich gewesen wären. Fast alle Angriffe auf den Browser benötigen lokalen Zugriff oder führen Programme auf Systemebene aus. In beiden Fällen ist es dann unerheblich, ob ich den PW Manager von Firefox oder einen anderen verwende.
Oliver
24 Sep 11 at 16:32
– Hab ich doch geschrieben.
Ich sehe nicht wo?
– So ein blödes Passwort würde ich auch nie vorschlagen.
Hast du aber, zumindest wird es nicht klar aus deinem Text
– Als Angreifer kannst Du nicht wissen, wie lang das Passwort ist.
Es kann vernachlässigt werden, da, wenn man ein 8 Zeichen Passwort knackt, für ein 7 Zeichen Passwort nur 1/100 der Zeit braucht wie für das 8 Zeichen Passwort, d.h. wer die Zeit hat ein 8 Zeichen Passwort zu knacken, wird sich auch noch ein paar hundertstel mehr Zeit nehmen können, um die 7, 6, 5 usw. langen Passwörter zu knacken. Natürlich dauert es ein wenig länger, aber es fällt nicht ins Gewicht und wird daher vernachlässigt. Wenn du es genauer wissen willst, ließ das:
http://en.wikipedia.org/wiki/Big_O_notation
In der Informatik wird ein Problem in eine Klasse eingeteilt, ob es jetzt bei 1 Stunde eine Minute länger oder kürzer dauert ist vollkommen Wurscht,
– „Wie lange braucht denn so ein Trojaner auf einem Rechner, um das Passwort zu übertragen? Oder anders, Dein Computersystem ist kompromitiert. Wie oft müsste man das Passwort im Jahr ändern, damit es trotzdem sicher ist?“
Am Besten so häufig wie möglich, denn wenn du es änderst, besteht die Chance, dass er und alle anderen, denen er es weitergereicht haben, keinen Zugriff mehr haben, wenn du es nicht änderst, besteht diese Chance auch nicht.
– Dann tippt man nicht.
Gratuliere zu deinem Home-Office Job, aber ist gibt Leute, die arbeiten in Teams oder in großen Büros und haben keine Augen am Hinterkopf und da kann sowas passieren.
– „Und davon wird es sicherer? Warum? Ich persönlich bin da überhaupt kein Fan von, denn es verleitet dazu, ein System zu nutzen und sobald jemand das System versteht, sind die andere Passwörter auch gefährdet.“
Ein System ist schlecht, aber immer noch 100 Mal besser als das Passwort gar nicht zu ändern, das wäre nämlich das am einfachsten zu knackende System und ja, es wird sicherer, denn ein Eindringling, der den Server geknackt hat, kann das Passwort für immer verwenden, selbst wenn der Server nach dem Angriff seine Sicherheitsmaßnahmen erhöht. Wenn man es ändert, ist der Schaden eventuell zu minimieren.
– Öhm, was hab ich denn für eine „schlechte Methode“ geraten?
Na zu der, die du in deinem Artikel beschreibst, md5 Passwort, Email-Adresse, mehrfach hashing, alles selbst erfundene oder abgeschriebene Methoden, die keinerlei Sicherheitsstandards entsprechen
Max
25 Sep 11 at 02:17
Nö, was kann ich dafür, was Du da rein interpretierst?
Ja, dann mach das mal für 96^14. Natürlich spielen da ein paar Mio. Jahre keine Geige, aber ich muss doch erklären, wie ich auf die Zahlen komme. Aber wenn es Dich beruhigt, sonst sag ich immer nur machbar oder nicht.
Nö, macht keinen Sinn. Ob jetzt 1 oder 10 Leute auf Deine Daten zugreifen können, spielt im Resultat keine Rolle. Ausserdem denken Angreifer selten langfristig, deshalb wird sofort maximales Kapital geschlagen.
Ist jemand im Zimmer und nicht in meinem Sichtfeld, gebe ich keine privaten Daten ein. Ist eigentlich ganz einfach.
Ja, aber warum sollte er das tun, wenn er Deine Daten doch schon hat? Ich seh da keinen echten Sicherheitsgewinn, sorry.
Nur mal so interessehalber: Wie ist denn der Sicherheitsstandard für die sichere Speicherung von Passwörtern in Webanwendungen und wer legt den fest?
Oliver
25 Sep 11 at 03:16
„Nur mal so interessehalber: Wie ist denn der Sicherheitsstandard für die sichere Speicherung von Passwörtern in Webanwendungen und wer legt den fest?“
Gute Frage, in deinem Fall zum Beispiel die „RSA Laboratories“ im PKCS5 v2 und im RFC 2898. Dafür gibt es auch schöne php Bibliotheken. Google einfach mal nach: PBKDF2 (Password-Based Key Derivation Funktion). Die „RSA Laboratorien“ haben eine ganze Reihe von PKCS Standards definiert an die man sich halten soll, denn sie werden von Spezialisten weltweit über Jahre hinweg analysiert und immer wieder an heutige Zeiten angepasst. Das gleiche gilt zum Beispiel für das NIST. So ziemlich alle kryptographischen Algorithmen und Protokolle werden erst jahrelang getestet bis sie sich etablieren und dann eingesetzt. Eigene Methoden sind mit 99,9%tiger Sicherheit nicht geeignet, selbst viele Professoren in dem Gebiet veröffentlichen Methoden, die oft nicht standhalten und die sich dann nie etablieren.
Scrypt scheint mittlerweile auch sehr sicher:
http://www.tarsnap.com/scrypt.html
Hat sicher aber wohl auch noch nicht richtig etabliert. Es ist von so einem Chef von BSD entwickelt worden und wenn du dir jetzt mal sein Paper anschaust:
http://www.tarsnap.com/scrypt/scrypt.pdf
Schau einfach mal kurz rein, dann weißt du, warum du niemals eine eigene sichere Methode entwickeln wirst!
Für dich auch sehr zu empfehlen, falls du dich wirklich mehr für IT-Sicherheit interessierst, ist sein Beginners Guide:
http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
Da gibt es auch einen sehr kurzen Bereich: „Password handling“
– „Übrigens, „geheim0815“ sollte man wirklich nicht verwenden, aber was spricht gegen „Geheim-NullAchtFünfzehn“?“
Ich weiß nicht, was man da falsch interpretieren kann.
– „Ja, dann mach das mal für 96^14. Natürlich spielen da ein paar Mio. Jahre keine Geige, aber ich muss doch erklären, wie ich auf die Zahlen komme. Aber wenn es Dich beruhigt, sonst sag ich immer nur machbar oder nicht.“
Auch da kann es vernachlässigt werden, denn es fällt in die gleiche Komplexitätsklasse. Schau dir dazu meinen Link an. Du musst es nicht vernachlässigen, ich will dir nur erklären, warum man es so macht, denn du schreibst:
„In den meisten Erklärungen steht übrigens nur 10^8,“
Ja, denn die Komplexitätsklasse ist nun mal 10^8, so wird es in der Informatik nun mal gemacht und da kannst du dich jetzt auf den Kopf stellen, die Klassen sind nun mal so definiert auch wenn deine Berechnung natürlich genauer ist.
„Nö, macht keinen Sinn. Ob jetzt 1 oder 10 Leute auf Deine Daten zugreifen können, spielt im Resultat keine Rolle. Ausserdem denken Angreifer selten langfristig, deshalb wird sofort maximales Kapital geschlagen.“
Wenn jemand dein E-Mail-Passwort kennt, kann er mitlesen und wenn du es geändert hast nicht mehr, du kannst nie wissen, ob jemand dein Passwort abgegriffen hat. Wenn dir das egal ist, ist das schön, aber darum geht es in der IT-Sicherheit nicht. Man will ein Maximum an Sicherheit erreichen.
Außerdem können 10 Leute nun mal mehr schaden anrichten, als nur einer. Und ganz sicher: Angreifer denken sehr wohl langfristig. Deine Bank blockt deine geklauten Kreditkarteninformationen sofort und wartet nicht erstmal ein Jahr, denn der Schaden wird größer je länger man wartet. Für Passwörter gilt das gleiche. Jemand hat das Passwort für deine Blog-Datenbank, gelangt über eine Sicherheitslücke auf den Webserver und solange du dein Passwort nicht änderst, hat nun der Angreifer auch Zugriff auf andere Benutzer, die dafür nichts können und nein, das ist nicht nur Aufgabe des Providers, er tut sein bestes (hoffen wir), aber du kannst ihm behilflich sein. Es geht nicht darum, ob das dann 100% sicher ist, sondern darum es so sicher wie möglich zu machen.
„Ist jemand im Zimmer und nicht in meinem Sichtfeld, gebe ich keine privaten Daten ein. Ist eigentlich ganz einfach.“
Und deshalb sage ich ja Gratulation zum Home-Office Job, ich kann in meinem Job, nicht alle aus dem Raum schicken, wenn ich etwas checken muss, außerdem schon mal etwas von Audio-Attacken gehört? Mit einem Mikrofon kann man heute durch den Klang der Tastatur sehr gut dein Passwort abschätzen, Mikrofone sind in jedem Handy enthalten. Und wenn nur 4 Zeichen deines Passworts gehört werden, ist es schonmal 4 Zeichen kürzer.
– „Ja, aber warum sollte er das tun, wenn er Deine Daten doch schon hat? Ich seh da keinen echten Sicherheitsgewinn, sorry.“
Er kommt auch noch an die Daten, die du in Zukunft eingibst, für immer, solange du nichts änderst.
Max
25 Sep 11 at 13:27
[…] lass Dir von niemandem sagen das ein gutes Passwort veraltern kann. Das ist Blödsinn. Ein toller Artikel dazu wurde auch von Oliver Sperke veröffentlicht. Ich kann nur jedem raten diesen Artikel zu […]
Wordpress sicher machen | Wordpress Experte Tom Meurer
1 Feb 12 at 01:10
[…] Artikel zur Sicherheit von Passwörtern und zum richtigen Umgang mit md5(), sowie den Artikel zum neuen Verfahren mit bcrypt könnt ihr auf seinem Blog lesen und ausgiebig […]
PHP5 und Passwortsicherheit mit md5() und crypt() at PHP, SEO, Software, Programmierung
23 Feb 12 at 16:56
“Was lernen wir aus diesem Text?”
Das du Salting und Mehrfachhashing predigst, während der Rest der Welt schon einen Schritt weiter zu bcrypt geht… Traurig.
Was lernen wir aus dieser Aussage? Erstens nicht traurig sein, wer wird denn gleich weinen. Zweitens geb ich nicht soviel drauf was die Welt sagt. Drittens die Länge des Passworts ist entscheidend. Aufgabe: Wie groß muss eine Rainbotalbe sein die alle mögliche Zeichen für ein Passwort mit 15 Zeichen enthält und wer kennt jemand der sowas hat?
lg. noctua
noctua
27 Feb 13 at 11:31
Bin leider erst gerade auf diesen Artikel gestoßen. Eine Anmerkung zu dem HMAC-Thema: Den HMAC zuverwenden, hat einen entscheidenden Grund, damit sollen die internen States des Hash-Algorithmus abgesichert werden.
Bei einem Salted Hash geht man ja normalerweise so vor:
$hash = $salt . hashFunction($salt . $password);
Der Salt wird mitgespeichert, da man die Passworterzeugung zum Testen ja rekonstruieren können muss. So ein Hash arbeitet nun blockweise. Das heißt, dass der Input erst Schritt für Schritt in einzelnen Runden miteinander gemixt und verrechnet wird.
HIer nun der Knackpunkt: Da der Salt bekannt ist, kann man den Hashvorgang teilweise durcharbeiten. Das heißt: Man generiert den Hash hashFunction($salt) und muss von hier aus „nur noch“ die Passwörter durchprobieren – die gesamte Hashing-Arbeit für den Salt muss nur ein einziges Mal vorgenommen werden.
Bei HMAC hingegen muss immer komplett gehasht werden, inklusive Salt. Dort kann man nicht einfach irgendwo mittendrin anfangen. Obsolet wird das natürlich, wenn man mehrfach hasht (was HMAC ja auch macht).
Kenny
5 Apr 13 at 10:17
[…] Der Gastartikel von Oliver Sperke auf PHP Gansta klärt einige Mythen von Passwörtern. Oliver schreibt z.B. dass man vor einer Wörterbuchattacke keine Angst haben muss und dass selbst hochkomplizierte Passwörter schneller geknackt werden können, als einem lieb ist. Kein Wunder, du kommst ja auch meistens beim ersten Vesuch ins System. Passwortmythen oder “Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest&… […]
Der Schlüssel für sichere Passwörter – Für jedermann - Sicherheit mit Linux
4 Mrz 15 at 13:53
[…] paar Tagen hatte Oliver Sperke einen viel diskutierten Gastartikel auf PHP Gangsta veröffentlicht: Passwortmyhten, oder “Was Du schon immer über Passwörter wusstest, aber nie zu sagen wagtest…. Der Vorwurf: bcrypt wurde im Post nicht einmal erwähnt. Diesen durchaus berechtigten Einwand […]
Mehr Sicherheit mit bcrypt - entwickler.de
28 Apr 15 at 16:12
[…] den vorhergehenden Beiträgen habe ich ja schon locker über Passwörter und wie man mit Ihnen umgehen sollte […]
TLS/SSL für Heimwerker | PHP Gangsta - Der PHP Blog mit Praxisbezug
6 Feb 17 at 12:44