Passwort Blacklist
Kunden, die eine Webseite mit Registrierung und Login benötigen kann man nicht immer davon überzeugen, strenge Passwortrichtlinien anzusetzen. Wenn ich vorschlage „10 Zeichen, davon mindestens eine Zahl, ein Großbuchstabe und ein Sonderzeichen“ wird das nicht selten abgelehnt, mit Hinweisen auf „Dann sinkt die Conversion-Rate“, „Dann vergessen die Kunden andauernd ihr Passwort und wir haben mehr Supportaufwand“ etc. Also kommt häufig die Richtlinie „mindestens 8 Zeichen“ zum Einsatz.
Damit ich mich darauf einlasse verlange ich aber mindestens eine Passwort Blacklist, sprich eine Liste der meistgenutzten Passwörter, die dann nicht erlaubt sind, beispielsweise „12345678“ oder „passwort“, um das ganze zumindestens etwas sicherer zu machen. Man muss den Benutzer vor sich selbst schützen, sonst werden sie „12345678“ oder „passwort“ als Passwort nutzen.
Gestern ist eine Liste mit E-Mail-Adressen und Klartext-Passwörtern von Rewe aufgetaucht, von denen ich die am meisten genutzten Passwörter extrahiert habe. Im Internet findet man auch hier und da „The Top 50 Passwords“, da sind aber häufig englischsprachige Begriffe dabei. Mich interessieren bei deutschen Benutzern natürlich deutsche meistgenutzte Begriffe, und da habe ich noch keine längere Liste gefunden mit mehr als 20 Einträgen. Die sortierte Rewe-Liste findet sich übrigens hier als Textdatei zum Download. Hier die Top 20:
123456 sticker 123456789 schmetterling michael vanessa sonnenschein giraffe moritz rewe2011 sabrina alexander maximilian pauline schule johanna elefant tauschen dennis andreas
Interessant an dieser Liste ist, dass „passwort“ erst weit unten erscheint, in englischen Listen ist „password“ eigentlich immer in den Top3.
Microsoft hat letzte Woche groß angekündigt dass Hotmail-Nutzer nun keine leichten Passwörter wie „123456“ mehr benutzen können, sprich sie haben auch eine Blacklist geschaltet. Dass man für solch eine Selbstverständlichkeit, die man hätte schon vor Jahren aktivieren müssen, eine große Pressemitteilung verbreiten kann ist mir ein Rätsel.
Nutzt ihr auch Passwort Blacklists? Wie sieht eure Sperrliste aus? Mich würden vor allem deutsche Passwörter interessieren die häufig genutzt werden und die man sperren sollte.
Was ich auch gerne nutze, ist, sofern vorhanden, den vom Nutzer angegeben Vor- und/oder Nachnamen als Teil im Passwort zu verbieten. Sonst meldet sich ein Markus mit dem Passwort „markus123“ an 😀
Markus
20 Jul 11 at 10:23
Man sollte bei diesen TopTen allerdings noch beachten, dass die Passwörter „Sticker“, „rewe2011“ und „tauschen“ in dieser Liste themenrelevant sind, da die Datenbank zu einer von Rewe in diesem Jahr angebotenen Tauschbörse für Tier-Aufkleber handelt.
Also auch „Schmetterling“, „Giraffe“ und „Elefant“ könnten auf Grund des Themas so häufig vorkommen.
Eventuell sollte man also noch ein paar andere Passwörter nachrücken lassen.
Der Tipp von Markus scheint mir bei der häufigen Anzahl von Vornamen allerdings tatsächlich eine gute Idee zu sein.
Norman
20 Jul 11 at 10:44
Viel interessanter finde ich, dass die Passwörter überhaupt gespeichert werden. Warum wird das noch immer gemacht? Um den Kunden die Passwörter im Falle des Falles nochmal im Klartext zumailen zu können? Ich kann da keinen vertretbaren Grund erkennen…
Daniel
20 Jul 11 at 10:47
Warum eigentlich Pass_wörter_ und nicht Pass_phrasen_? „xÜ_8fhq3M“ ist nur 8 Zeichen lang, aber kann sich wohl kaum jemand so einfach merken. „Ich bin der Timo, ja das bin ich!“ ist viel länger und sehr leicht zu merken, aber dürfte wohl in keiner Phrasenliste auftauchen (oder doch?).
Wenn ich also dürfte, wie ich wollte, würde ich einen Hinweis einbauen, dass man auch Sätze benutzen darf, und die Mindestlänge der Phrase auf 20 Zeichen hochsetzen. Der Hinweis ist übrigens wichtig – vor kurzem erhielt ich folgende erstaunte Nachfrage: „Wie, man darf Leerzeichen in Passwörtern verwenden?“…
Timo Reitz
20 Jul 11 at 11:24
@Norman: Das stimmt, jede solche geleakte Liste ist themenrelevant, deshalb braucht man mehrere Listen, um die Themenrelevanz zu eliminieren.
@Timo: Normalerweise sollten Leerzeichen erlaubt sein, das stimmt, aber es gibt Situationen in denen sie verboten sind, wenn beispielsweise das Passwort auch für einen FTP-Zugang genutzt wird, wenn da ein Leerzeichen im Passwort ist kommen einige FTP-Clients durcheinander und der Login klappt nicht. Aber für reine Weblogins spricht nichts gegen Leerzeichen in Passwörtern.
Michael Kliewe
20 Jul 11 at 11:31
Sieht ja mehr wie eine List der vor 10 bis 20 Jahren meitgewählten Vornamen aus 😉
@Timo: Leider passiert es noch immer mal wieder das Passwörter abgelehnt werden weil Sonderzeichen, Leerzeichen oder sogar Buchstaben (Banken!) abgelehnt werden.
Grund ist wohl öfters solche Problematiken wie von Michael mit FTP angesprochen. Bei den Banken ist wohl das Problem das HBCI in alten Versionen nur Zahlen kann!
Aber so wie bei Banken wo nur ein sehr kleiner Teil HBCI nutzt (bei FTP oft wohl oft das selbe) würde ich wohl in den meisten Fällen, wenn es geht, trotzdem die kritischen Zeichen erlauben. Die die dann HBCI nutzen möchte, müssen dann halt ihr Passwort ändern. Wobei man mit der Lösung natürlich mit erhöhtem Support-Aufwand rechnen muss.
Florian Heinze
20 Jul 11 at 12:20
Wie war das mit „Die Welt ist schon einen Schritt weiter“. *stöhn*
Man kann auf eine Blacklist verzichten, wenn man eine Mindestsicherheit vorgibt. So mach ich das gern. Also nicht starr nach Zahlen, Sonderzeichen, Buchstaben, sondern nach der Kombination – ist eine Brute Force Attacke in eine geologisch sinnvollem Rahmen erfolgreich oder nicht. Von denen da kommt keins durch.
Oliver
20 Jul 11 at 12:41
Ich nehme tatsächlich oft, wenn möglich, das Passwort ******** (sic!) da kann mir dann auch keiner über die Schulter gucken beim Eintippen in Klartext-Felder 🙂
ilja
20 Jul 11 at 13:38
Ich hätte da mal eine Frage zu der von dir verlinkten Liste: Das sind jetzt die Passwörter die am _häufigsten_ verwendet wurden? Kann ich mir nur schlecht vorstellen. Denn das „4pgdivubawlq“ mehr als einmal benutzt wird ist doch eher unwahrscheinlich. Genauso wie „s14fld“, „rrmx0674“ und „brauni1994lieb“.
Wenn die Hacker tatsächlich 52.000 Datensätze aus 7 Datenbanken gestohlen haben, dann würde die Liste wohl anders aussehen. Scheint eher so als wenn sie irgendwelche Backups gezogen haben und somit etliche Datensätze doppelt sind.
Bei der Mindestlänge für Passwörter muss man auch vorsichtig sein. Wenn man mindestens 10 Zeichen verlangt, werden 99% der Benutzer auch nur 10-11 Zeichen verwenden. Der Mensch ist halt faul. Im Grunde genommen also genauso effektiv als würde man ein PW mit exakt 10 Zeichen verlangen.
Zudem reduziert man die Anzahl an möglichen PWs um die Anzahl an PWs die nicht die Mindestlänge haben.
Da würde ich dem Benutzer eher einen Hinweis geben das ein zu kurzes PW extrem unsicher sei. Dann kann jeder Benutzer selber entscheiden ob ihm der Account bei einer Klebebildchentauschbörse so wahnsinnig wichtig ist das er ein längeres PW braucht.
Eine andere Möglichkeit den Benutzer zu zeigen ob sein Passwort sicher ist, wäre anzuzeigen wie oft sein Passwort bereits von anderen Benutzern verwendet wurde. Also bei Eingabe von „Passwort“ oder „schatzi“ halt eine Anzeige „Dieses Passwort wird bereits von x anderen Benutzern verwendet“ (Alternativ: Dieses Passwort wollten schon x Benutzer verwenden und wurde deshalb abgelehnt).
Das hätte z.B. bei einer Klebebildchentauschbörse zumindest schon mal einen erzieherischen Effekt, sofern der Auftraggeber keine höheren Sicherheitsstandards bezahlen will.
Blacklisten haben auch so ihre Nachteile. Wenn sie wirklich populär werden, würden auch entsprechende Listen auftauchen die von vielen verwendet werden. Was der Programmierer kann, kann der Hacker auch. Er würde dann also seine PW-Listen, Rainbowtables usw. um die Blackliste verringern was seinen Aufwand mindert. Auf alle Fälle könnte er anhand von öffentlich zugänglichen Blacklisten seine eigene Listen dementsprechend optimieren das die gelisteten PWs zu letzt versucht werden.
Programmierer sind genauso faul wie Benutzer. Die suchen auch erst einmal nach fertigen Blacklisten anstatt eigene zu erstellen.
@Markus:
Wenn es sich hauptsächlich um erwachsene Benutzer handelt, dann sind die Namen der Kinder eher die Favoriten. Das Scheint mir auch der Fall bei der von Michael verlinkten Liste der Fall zu sein. Da werden wohl nicht wenige Eltern den Namen ihres/ihrer Kinder verwendet haben.
Eine einfache Blacklist wäre dementsprechend die am häufigsten verwendeten Taufnamen der letzten 0-5 Jahre. Entsprechende Statistiken sollten recht einfach zu finden sein.
Ebenso kann man das PW auf Geburtsdaten hin abchecken. Geht ja recht einfach mit einem RegExp.
Ralf
20 Jul 11 at 14:21
@Michael / @Ralf
Kannst Du bei der Passwortliste die Häufigkeit dabei schreiben? Ich würde mal tippen, dass aus 7 Datenbanken sich ein paar mehrfach angemeldet haben und daher diese komischen Passwörter auftauchen. 52.000 Accounts müssen ja nicht 52.000 Benutzer sein.
@Ralf
Ja, aber das spielt ja keine Rolle. Sagen wir mal, die Passwörter wären als md5 da. Dann wären alle bis 11 Zeichen mindestens geleakt (Rainbow Table). Alles, was darüber hinaus geht wird schon schwieriger.
Moment, Du willst also nicht nur diesen Bockmist zulassen, sondern auch noch einem potentiellem Angreifer sagen, wie lohnenswert es ist, auf anderen Accounts dieses Passwörter zu probieren? Und wie willst Du das testen, wenn Deine Passwörter sich gespeichert sind?
Also hätte er sich mindestens mal … wieviel gespart? Über 1 Sekunde? Wir reden hier ja nicht über Mio. Passwörter, sondern vielleicht über 100 bis 500. Ausserdem bisher ist es nicht mal populär md5 zu benutzen.
Kommt drauf an. Der Name der Frau mit dem Geburtsdatum der Geliebten wäre schon recht sicher. 😀
Oliver
20 Jul 11 at 14:44
@Oliver: Die Liste war recht komisch. Es waren nur 5500 verschiedene E-Mail-Adressen, der Rest waren Duplikate wenn ich mich recht entsinne. Ich glaube 123456 war mit knapp über 100 Mal der erste Platz, also 2% der User. Der Rest war schon alles unter 20 Mal. Müßte ich nochmal nachgucken heute Nacht.
Michael Kliewe
20 Jul 11 at 15:02
Sicheres Hashing von Passwörtern ist eine Kunst, die nicht jeder beherscht.
Daher einfach mal hier ein Ansatz von mir, der mal zerrissen werden darf. Bei mir steht dem User eine umfangreiche Liste von Hash-Algorithmen zur Verfügung, kurz, alle Algorithmen, die mein System in Verbindung mit php-mhash unterstützt. Jeder User kann sich daraus seinen Lieblingsalgorithmus auswählen, vom CRC bis sha512, alles ist möglich. Danach wird das PW 2 Mal mit diesem Algorithmus gehasht, und der zweite Durchlauf wird mit 4 – 6 Zeichen des ersten Hashes gesalzen. Danach ist jeder Rainbow-Table am Arsch. Und da jeder User einen anderen Algorithmus nutzen kann, müsste sogar das PW für jeden Algorithmus neu berechnet werden.
Zusätzlich wird jedem User die Möglichkeit gegeben, sein verwendetes PW in bis zu 4 Sicherheitsstufen einzusortieren, unabhängig von der Länge, die bei mindestens 6 Zeichen liegt. Die 4 Stufen setzen sich aus Zahlen, Kleinbuchstaben, Großbuchstaben und Sonderzeichen zusammen, pro Kategorie einen Punkt und die Anzahl der Punkte ergibt die Sicherheitsstufe (naja also eher 0 – 3 statt 1 – 4). Somit hat der User die größtmögliche Kontrolle und einen Hinweis über die mögliche Sicherheit bei Brute-Force-Angriffen. Denn nichts anderes muss gemacht werden, wenn die DB mal geklaut worden sein sollte.
Damit ist ein Blacklist-Ansatz nicht mehr wirklich nötig.
Master_D
20 Jul 11 at 15:29
Moinsen,
– les ich das richtig, Du hast Dir den gehackten Datenbestand besorgt und daraus Deine Liste extrahiert? Tut mir leid, ich schätze Deine Artikel und Dein profundes Fachwissen sehr, aber ich bin damit nicht einverstanden. Da sind Leute in eine Datenbank eingebrochen, ob mit weißem Hut oder schwarzem, da kann man doch nicht einfach hergehen und sagen, besten Dank, ich hab auch schon ne Idee, wozu das gut ist? – Viele Grüße, Carsten.
Carsten Witt
20 Jul 11 at 15:40
@Carsten:
Diese Gedanken hatte ich für einen kurzen Moment auch gehegt, aber mal ehrlich: wenn er es nicht macht, macht es ein anderer. Ich meine, hier sind ja nun keinerlei weitere Daten bekannt gemacht worden. Wer jetzt will, kann bei Google „REWE Tauschbörse Hack Daten“ eingeben und wird in Windeseile die Informationen selbst bekommen.
Wir haben es hier nicht mit einer Bauanleitung ala „Wie extrahiere ich die gewünschten Daten aus einer Liste von Daten, die ich geklaut habe und das ging so:“ zu tun, von daher, Wayne kratzt es?
Du willst mir doch nicht ernsthaft sagen, dass Du, wenn es Dich nicht interessiert hätte, das gelassen hättest, nur weil es vielleicht schändlich ist? Schändlich ist m.E. nach nur, dass Leute diese Liste veröffentlichen! Wenn man jetzt von „Hackern mit weißen Hut“ ausginge, könnte man diesen Leak auch anders anzeigen, als einfach so Daten zu veröffentlichen.
Egal, ich komme vom Thema ab, daher beende ich das hier.
Sascha
20 Jul 11 at 16:50
@Master_D
Jetzt muss ich mal klugscheissern.
CRC ist kein kryptografischer Hash, sondern eine Prüfsummme. Das ist so als wenn Du mit nem Fleischhammer einen Nagel in die Wand haust. Es fuktioniert, ja. Ausserdem was soll ein Besucher mit der Information anfangen, wenn Du und die meisten Webmaster auch wenig bis gar nichts darüber wissen? Da nimmt jeder das, was angehakt ist und der Rest meldet sich gar nicht an. SHA512 ist für die Speicherung von Passwörter nicht sicherer als MD2, nur länger. Kollisionsattacken spielen bei der Speicherung von Passwörtern keine Rolle. Versteht das doch bitte endlich! *heul*
Und was soll das bringen? Ich mein ok, der Salt ist individuell, aber sonst? Bis 10 Zeichen hast Du das als Rainbow Table in 4 Wochen für die gesamte Datenbank, völlig egal, welcher Algorithmus. Und was heißt 4 bis 6 Zeichen? Machst Du ne Brute-Force auf die eigene DB?
Schlüsselraum ~ 1 Billionen ist in ca. 1 Sekunde fertig – mit vollem Zeichensatz. Bis 8 Zeichen übrigens in 3 Stunden.
Ja, aber wenn 6 Zeichen Minimum ist, was interessiert den User, ob Du das für unsicher hältst, wenn er es trotzdem abspeichern kann?
@Carsten Witt
Was wäre denn die Alternative gewesen? Wenn wir jetzt sagen, da ist mal wieder ne DB geleaked worden, die Passwörter waren unverschlüsselt, aber aus ethischen Gründen dürfen wir nichts daraus lernen?
Oliver
20 Jul 11 at 18:12
Nö. Man kann Leute nicht vor sich selbst schützen, bzw nur sehr begrenzt; und wenn man es versucht und es geht trotzdem schief – in dem Fall, der Account wird gehackt – dann wird man vielleicht noch (mit-)verantwortlich gemacht.
Von daher – gut gemeinte Ratschläge zur Wahl des Passworts sind prima, eine Anzeige wie „stark“ das Passwort ist auch, aber wer trotzdem „12345678“ als Passwort wählt hat halt Pech. IMvHO
danielj
20 Jul 11 at 18:38
es gibt eine ganz einfache loesung:
ein ’sicheres‘ passwort wird generiert und dem user per mail zugeschickt.
das kann er dann abschreiben, auf ein postit kleben und unter der tastatur aufbewahren 😀
blubberlutsch
21 Jul 11 at 00:24
@Oliver:
Ich beziehe ich mit meinem Kommentar in erster Linie auf den Beitrag. Aussagen wie „wird das nicht selten abgelehnt, mit Hinweisen auf “Dann sinkt die Conversion-Rate”, “Dann vergessen die Kunden andauernd ihr Passwort und wir haben mehr Supportaufwand”“ sind da eher noch harmlos. Aussagen wie „Was? Die Routine für das Passworthaschding kostet 30 Euro? Ist zu teuer!!!“ kommen auch nicht selten vor.
Ich kann aus dem sichern Speichern von Passwörtern eine Raketenwissenschaft machen und Passwörter ggf. so kryptisch verschlüsseln das kein Hacker da jemals dran kommt. Ich kann auch die Übertragung verschlüsseln usw. usf.
Nur was nützt das alles wenn es nicht bezahlt wird? Arbeitest du etwa umsonst? Investierst du 5 oder 6 Stunden in ein sicheres System und das dann als GiveAway für den Kunden?
Nein. Mit Sicherheit nicht. Und viele andere Programmierer und Agenturen werden es ebenfalls nicht machen. Es wird auch kein Verkäufer hingehen und 4 Stunden lang auf den Kunden einreden das er für eine Klebebildchentauschbörse (einself!!!) achtfach gesicherte Passwörter braucht. Es ist ein Verkäufer und nicht Jack Bauer, er wird alles dran setzen die Wünsche des Kunden mit minimalen Aufwand (sprich möglichst günstigen Angebot) umzusetzen.
Wir sind Programmierer und müssen meistens aus Schei*** Gold machen. Das bedeutet, man muss auch mal in den sauren Apfel beißen und Dinge machen die man nur schwer vertreten kann. Dazu zählen dann wohl oder übel so Sachen wie Passwörter mit 4 Zeichen Länge zuzulassen. Dann sollte man als guter Programmierer so viel Kreativität haben und ein oder zwei andere Lösungsansätze für halbwegs sichere Passwörter nennen können.
Klar kann man sich hier die allerschönsten Methoden und Algorithmen ausdenken um Passwörter sicher zu speichern. Wenn niemand bereit ist das zu bezahlen, weil es z.B. sich nur um eine Klebebildchentauschbörse (!!!) mit einem Budget unter 10tsd Euro handelt, dann bleibt das alles graue Theorie.
Und Hacker denken genauso ökonomisch. Da werden als erstes die einfachsten Methoden angewendet. Brute Force und Passwörter raten sind dabei wohl die einfachsten Methoden. Ich bin mir ziemlich sicher das mit ein paar öffentlich zugänglichen Infos und ein wenig Geschick sich auf den allermeisten Plattformen eine paar Accounts hacken lassen. Namen und Geburtsdaten der Familienangehörigen lassen sich oft mit ein paar Klicks recherchieren. Der Rest ist das Ausprobieren von ein paar Kombinationen. Erfolgschance: Hoch.
So einfach lassen sich Accounts hacken. Und glaub mir, genauso einfach wurden die allermeisten Hacks durchgeführt.
Ralf
21 Jul 11 at 03:32
Braindump: Google bietet doch eine „Trends“-Suchmaschine an, könnte man das nicht mit der Passwort-Blacklist koppeln?
Mir kommt da schon wieder so eine tolle Idee wie man das machen könnte, werd da mal was entwickeln übers Wochenende und mich nochmal rühren 😉
Michael H.
21 Jul 11 at 10:05
@Ralf
Die Conversion sinkt nicht, wenn man auf sichere Passwörter besteht, zumindest dann nicht, wenn man entsprechende Hilfsmittel anbietet. Wer sein Passwort vergisst, bestellt ein neues – die Funktion muss sowieso da sein. Da gibt es keinen Supportaufwand. Und wie lange braucht man denn für ein md5(‚blabla‘.$email.$passwort)? Das hätte zwar den „123456“ Leuten nicht geholfen, aber bei allen anderen, die von sich aus ein sicheres Passwort gewählt haben. Rocket science, hm?
Sicherheitslücken baut sich jeder mal. Das ist einfach so, aber das hier ist ja wirklich auf allen Ebenen verkackt worden (Inclusion, SQL, Passwörter, …). Wenn ich mit einem Budget nicht hin komme, kann und sollte man an allem sparen, aber niemals an der Sicherheit, denn im Falle eines Falles wird das richtig teuer. Und die Agentur schreibt ja auch nicht alles neu für jedes Projekt. Penny und Rewe war ja auch beides der gleiche Schrott.
Oliver
21 Jul 11 at 12:01
@Oliver:
Man muss schon im Auge behalten für wen die Webseite ist. Wenn es um einen Online-Shop geht bei dem Kreditkarten- oder Bankdaten hinterlegt werden, würde ich auch um jedes Bit kämpfen das zur Sicherheit beiträgt.
Wenn es aber um eine Webseite geht die vornehmlich für Kinder und Jugendliche gemacht ist, bei der man nicht mehr als Name, E-Mail und ein Passwort angeben muss, ist bei den Entscheidern schnell eine „So What?“ Einstellung vorhanden. Da lohnt es oft nicht auch nur ansatzweise eine Diskussion anzufangen.
Aus Sicht eines Programmierers gebe ich dir in allen Punkten Recht. Aber manchmal ist es halt so das die Ansprüche möglichst weit runter geschraubt werden damit auch noch der dümmste Kunde ja nicht die Webseite verlässt. Da sehe ich einen weiteren Nachteil von Blacklisten. Wenn ein Kunde dreimal die Meldung sieht das sein Passwort abgelehnt wurde, versucht er es kein viertes mal. Der Kunde ist weg, bedeutet Verlust. Und genau so und nicht anders denkt das Marketing. Dann kommt irgend ein Sepp (vom Marketing, Vertrieb, Lager, Pförtner, usw) der zu blöd ist um aus dem Bus zu winken und es nicht schafft 3 Zeichen als Passwort einzugeben, der aber zehnmal mehr zu sagen hat als du. Und schon gibt es keine Mindestlänge für Passwörter mehr.
Das ist leider nicht nur beim Programmieren so, dass kommt in fast allen Branchen vor. Aktuell wurden bei uns gerade mal rund 60tsd Euro vor die Wand gefahren weil Leute Entscheidungen getroffen haben die zwar keine Ahnung, dafür aber um so mehr zu sagen haben.
Meine letzte sehr leidvolle Erfahrung war die, dass HTTPS abgelehnt wurde. Erst zweifelte man an der Technik (Funktioniert das denn in jedem Browser? Wirklich? Braucht man da nicht zusätzliche Software??), dann war es plötzlich zu teuer. Was soll man da machen? Sein Ding durchziehen und ggf. das Zertifikat selber bezahlen? Den Kunden in die Wüste schicken? Diskutieren bis der Mund fusselig ist?
Die Entscheidung ist auf einer anderen Ebene gefallen und dann setzt ein psychologischer Prozess ein der verhindert das solche Fehlentscheidungen rückgängig gemacht werden.
Ralf
21 Jul 11 at 14:05
@Ralf
In so Fällen sagt man ok und lässt man sich schriftlich geben, dass man auf Problem X und Y mehrfach hingewiesen hat, aber Herr A die Sicherheit der Kundendaten nicht so wichtig findet und 30 Euro zu teuer waren oder Frau B es mit ihrem „Dreamweaver für Anfänger“ Volkhochschulkurs besser wusste und daher die ausdrücklichen Empfehlungen des Experten nicht umzusetzen waren. Für den Fall X oder Y möge man sich dann bitte auch an die wenden, weil man für dafür keine Verantwortung übernimmt. Das lässt man sich von der Geschäftsführung abzeichnen und alles ist gut. 🙂
Hier ist das allerdings in sofern was anderes, weil hier grundlegende handwerkliche Fehler gemacht wurden. Mit „Sparmaßnahmen“ kann man diesen Schmuh nämlich nicht erklären.
Oliver
21 Jul 11 at 14:31
Interessante Liste, aber durch die Duplikate wohl nicht ganz optimal.
Die Idee mit der Blackliste ist allerdings fragwürdig, ob man damit so viel Sicherheit erzeugen kann?
@Ralf
„Eine andere Möglichkeit den Benutzer zu zeigen ob sein Passwort sicher ist, wäre anzuzeigen wie oft sein Passwort bereits von anderen Benutzern verwendet wurde. Also bei Eingabe von “Passwort” oder “schatzi” halt eine Anzeige “Dieses Passwort wird bereits von x anderen Benutzern verwendet”“
*jirrrg* Am besten noch eine Benutzerliste irgendwo anzeigen, die „rentabelsten“ (also am meisten vorkommenden) Passwörter suchen und bei jedem Benutzer durchprobieren – ein paar muss es ja treffen?
Was mich allerdings bei einigen Registrierungen stört ist dieses starre Beharren auf „Kleinbuchstaben, Großbuchstaben, Sonderzeichen, zahl“.
Wenn ich da >20 Zeichen lange Sätze als Passwörter verwende (die deutlich leichter zu merken aber sicherlich sicherer sind) Passt da eine Zahl beispielsweise mal gar nicht rein…
Rasioc
21 Jul 11 at 17:26
@Rasioc:
Du und einige andere haben das Problem das ihr die Sache strikt aus der Sicht eines Programmierers seht. Schön wenn du PWs mit 20 Zeichen verwendest, 99% des Durchschnittkunden tut dies aber (noch) nicht. 90% der Durchschnittkunden pfeifen auch auf alles andere was man als Programmierer als Mindeststandard für ein PW betrachtet (siehe Liste).
Dein Auftraggeber muss nun einen Mittelweg finden zwischen dem was Programmierer als Mindeststandard ansehen und dem was die Kunden bereit sind mitzumachen. Lies doch noch mal was Michael bereits im Artikel geschrieben hat. Auftraggeber setzen die Prioritäten anders als Programmierer.
Um die Situation geht es doch, was kann man als Programmierer machen wenn der Auftraggeber z.B. sagt das dass PW keine Mindestlänge haben darf? Was machst du denn als Programmierer wenn dein Auftraggeber sagt der Kunde soll das PW im Klartext per Mail geschickt bekommen? Der Kunde ist König, der Auftraggeber jedoch Gott.
Auch auf die Gefahr hin hier jemanden auf die Füße zu treten. Aber in den Kommentaren hier sehe ich keine guten Programmierer. Denn alles was an Lösungen vorgeschlagen wurde kann mit Hilflosen Gestammel in Richtung „Das geht doch gar nicht! Viel zu gefährlich! So was macht man nicht!“ zusammenfassen.
In einem Einstellungsgespräch hätten wahrscheinlich die meisten versagt. Denn als Agenturchef/Arbeitgeber würde man Alternativen erwarten, z.B. PW vor dem Speichern in der DB mit PGP verschlüsseln so dass man sie bei Bedarf wieder entschlüsseln kann. Oder Alternativen zu dem üblichen „Passwortstärke schwach/gut/stark“.
Auch hat sich niemand mit dem Aspekt befasst wie ein Kunde darauf reagiert wenn sein PW dreimal abgelehnt wurde weil sie alle auf der Blacklist stehen. Ich halte das weiterhin für nicht so optimal (Konservationsrate).
Seid also doch mal kreativ und sagt mal was ihr machen würdet wenn ihr eben nicht machen könntet was man eigentlich machen müsste.
Ralf
22 Jul 11 at 01:43
Oliver
22 Jul 11 at 04:21
@Oliver:
Dir steht nicht zu darüber zu urteilen mit welchen Themen ich mich intensiv beschäftige.
Entweder liest du die Kommentare nicht, du willst es nicht verstehen was drin steht oder du kannst es einfach nicht. Du bist so auf sichere Passwortspeicherung fixiert das du in einen winzig kleinen Mikrokosmos diskutierst.
Einen guten Programmierer macht nicht aus wie viele Techniken er kennt um Passwörter zu verschlüsseln, sondern wie gut er über seinen Tellerrand hinaus schauen kann. Und dazu gehört halt die Dinge auch mal aus der Sicht eines anderen zu sehen. Das ist meine ganz persönliche Meinung. Und jeder Kommentar den ich abgebe kann nur meine ganz persönliche Meinung widerspiegeln.
Bisher kam von dir nicht ein einziges Wort zum Thema Usability und das obwohl das Stichwort Blacklist hierzu jede Menge Diskussionsstoff liefert.
Alleine schon das Beispiel mit Sonnenschein zeigt das du so ziemlich keine Erfahrung mit nicht so computererfahrenen Benutzern hast. Die Anzahl an Supportanfragen die eintrudelt wenn da plötzlich „S0nnenSche!n“ anstatt „sonnenschein“ steht, dürfte je nach Plattform exorbitant hoch sein.
Und das ist für mich der Unterschied ob man sich tatsächlich mal mit den Benutzer als Menschen auseinander setzt oder ob man in seinem eigenen kleinen Mikrokosmos lebt der ausschließlich aus Fachwissen besteht.
Bisher hast du auch noch nicht einmal auch nur ansatzweise mal eine Lösung vorgeschlagen wenn z.B. doch gefordert wird das dem Benutzer die Passwörter im Klartext gesendet werden sollen. Du verfällt immer wieder nur in dein „Das ist unsicher“ Mantra.
Wenn der Kunde das so will, dann hilft es nun einmal nichts sich in Embryonalhaltung auf den Boden zu werfen und ständig nur zu stammeln „Das ist unsicher! Das ist unsicher!“.
Programmierer die in der Situation keine Lösungsansätze finden sind in meinen Augen keine guten Programmierer.
Ralf
22 Jul 11 at 04:49
Das Beispiel mit dem Arzt und Automechaniker bringt es doch ganz gut auf den Punkt – warum hole ich mir Fachleute, wenn ich deren Fachwissen dann in Frage stelle?
Dafür gibt es keine Lösung. Ich kann nach der n-ten Diskussionsschleife letztlich entweder resignieren und es – gegen besseres Wissen – trotzdem machen, oder ich schmeiss den Kram hin. Das alles ändert aber nichts daran, daß die Klartextspeicherung von Passwörtern Schwachsinn ist; und das ist auch nicht verhandelbar.
danielj
22 Jul 11 at 07:46
Das von dir u.a. genannte Zuschicken der tatsächlich vom Benutzer gewählten Passwörter geht nur und ausschließlich, wenn diese gespeichert sind, egal ob verschlüsselt oder nicht. Das Speichern der Passwörter ist ein Sicherheitsrisiko und zwar schon konzeptionell. Ein Lösungsansatz für dieses Problem existiert nicht, es ist *unmöglich*. Was du also eigentlich behauptest, ist, dass überhaupt keine guten Programmierer existieren *können*.
GodsBoss
22 Jul 11 at 08:23
Du gibst „sonnenschein“ ein, die Validierung fragt ab, ob das sicher genug ist und wenn ja, wird es behalten, wenn nicht erscheint eine Sprechblase, dass sonnenschein nicht sicher ist, aber wenn man aus sonnenschein, z. B. $onnensch3iN machen würde, wäre das ausreichend. Möchten Sie diese Änderungen übernehmen? Ja / anderer Vorschlag.
Supportbedarf entsteht immer nur dann, wenn man etwas nicht ausreichend erklärt. Dann kann man aber immer noch nachbessern. Über dieses Verfahren kann man sicher auch reden oder ausprobieren oder andere Hilfsmittel (Stehen ja oben) anbieten. Über die Blacklist brauchen wir (für mein Empfinden) nicht zu reden, weil ich die Passwörter für so unsicher halte, dass ich sie niemals zulassen würde.
Das ist auch im Gegensatz zum anderen Problem nicht verhandelbar, denn es gibt nur einen richtigen und viele falsche Wege. Wir können uns den Himmel grün diskutieren, aber er ist davon nicht grün.
Oliver
22 Jul 11 at 12:41
I’m really loving the theme/design of your web site.
Do you ever run into any browser compatibility issues? A number of my blog readers have complained about my
site not operating correctly in Explorer but looks great in Firefox.
Do you have any advice to help fix this issue?
Stop by my homepage :: Google
Google
18 Aug 14 at 16:14
OK, das Thema ist etwas älter, aber trotzdem intressant. Bin eher aus Zufall drauf gestoßen, weil ich grad ne neues Portal entwerfe.
Bis her hatte ich auch mit MD5, Mehrfachhash und Salts gearbeitet, gehöre also sicher zu denen die wenigstens ein Mindestmaß an Aufwand betrieben habe.
Und ganu deswegen stell ich mir hier eine Frage, hier wird auf Kosten für die sicher Passwort speicherung rumgeritten, mal ehrlich, wer glaubt euch denn bitte, dass ich für jedes neue Projekt alles neu erfindet.
Sorry aber ich wette das über 50% der Entwickler die regelmäßig Kundenprojekte machen, eine Klasse haben die sie mit 2-3 Parametern für jeden Kunden wieder einsetzen.
Eine Funktion/Klasse ist schnell geschrieben (Oliver hatte ja in einem anderen Beitrag eine vorgestellt) diese mit ein par Parametern zu erweitern, so das ich sie mit einfachen Aufruf von z.B. meinecryptfunktion(‚password‘,’email‘,’Kunden-Salt‘,’mindestlänge’…) immer wieder verwenden kann, sollte jeder Hobbyprogger drauf haben, erst recht, wenn er mehr als ein Projekt umsetzt. Und damit verkauf ich meine Arbeit nicht nur einmal, sondern mehrfach, ohne dadurch wirklich mehr Aufwand zu haben. Ergo ist das Argument Kosten, eher fadenscheinig. Ganz im gegenteil, einmal anständig arbeiten, spart mir bei jedem weiteren Projekt Diskussionen und Arbeit. „Sie wollen ein Login? OK, 5€.“ „Achso, es soll sicher sein, 10€“ „sie heben gelesen das MD5 nicht sicher ist, kein Problem, 20€“ Im Hintergrund macht es bei mir nur Katsching, da ich immer die selbe Funktion benutze nur halt mit anderen Parametern. OK, der Kunde mit 5€ hätte ähnlich hohe Sicherheit wie der mit 20€, aber das muss ich ihm ja nicht verraten.
BTW: Was hier anscheinend oft übersehen wird, obwohl es oft genug gesagt wurde, „Benutzer sind faul“ und werden egal wie oft man es wiederholt, das selbe Passwörter auf mehreren Seiten verwenden, und damit schwächt jede schlampig gesicherte Webseite alle hoch gesicherten Seiten. Ihr sagt zurecht, für „Klebebildchentauschbörsen“ lohnt der Aufwand nicht, aber der Sicherheit der z.B. Paypal-Accounts schadet es trotzdem. Natürlich lohnt ein Angriff auf die Klebebildchentauschbörse nicht direkt, aber die Logins die dort funktionieren, einfach im nächsten Anlauf auf Paypal und co. angewendet und jede Wette 50% eben dieser „unwichtigen Klebebildchentauschbörsenkennwörter“ funktionieren auch auf anderen Seiten.
Klar kann man nun die Schuld an der Misäre dem User in die Schuhe schieben, aber man macht sich damit das Leben genauso leicht, wie eben jener User. Wie gesagt, eine Funktion kann man mehrfach benutzen und damit ohne hohe Kosten die Sicherheit auf allen Sites erhöhen. Und daran gemachte Arbeit doppelt zu verkaufen, sehe ich zumindest Vertriebstechnisch kein Hinderniss.
Wie so oft, ist Sicherheit eine Kette und ihr schwächstes Glied bestimmt die Stärke.
Micha
3 Dez 15 at 18:36
Was haltet Ihr davon einfach Benutzname und Passwort nicht zu speichern!? Dann müßt Ihr Euch keine Gedanken mehr machen 😉 dafür natürlich wie sich die User trotzdem einloggen können … wer solch ein System mal testen möchte antwortet einfach auf meinen Kommentar 🙂
davidSTERN
8 Nov 19 at 14:58