hi ich ändere bei meinen Accounts auf verschiedenen Webseiten regelmäßig das Passwort. Ich war immer der Meinung, das Passwort wird auf den Servern nicht im Klartext gespeichert, sondern nur ein Hash davon. Darum hat es mich heute gewundert als ich wieder mal die PW ändern wollte (diesmal hab ich bei jedem einen einzelnen Buchstaben angehängt) und auf mehreren Seiten den Hinweis bekam, das neue PW darf nicht ähnlich wie ein zuvor verwendetes PW sein. Wie kann das sein? Ich denke nicht dass man vom hash eine Ähnlichkeit des PW heruaslesen könnte...
Musstest du zur Änderung des PW das alte eingeben? Dieser Abgleich kann bei dir lokal im Browser passieren. Dazu muss das PW nicht unverschlüsselt übertragen werden. Probier doch mal das PW über den Link Passwort vergessen zu ändern. Wenn du hier eine Meldung bekommst ist was faul. Sg
Beitrag #6879319 wurde vom Autor gelöscht.
> Ich war immer der Meinung, das Passwort wird auf den > Servern nicht im Klartext gespeichert, sondern nur ein Hash davon. Das macht jeder wie er Lust und Laune hat. Es gibt einige Protokolle (z.B. http-digest), wo der Browser bereits das Passwort hashed und der Server das Klartextpasswort nie sieht. Aber bei den ganzen Applikationsbasierenden Logins ...
Bei den Seiten, die ich schreibe, verschlüssle ich das Passwort nicht extra bereits im Browser. Ich überlasse das TLS und kümmere mich auf dem Server um alles weitere. Allerdings führt das häufige Ändern von Kennwörtern nicht zu besseren Kennwörtern, sondern eher zu schlechteren.
> Das macht jeder wie er Lust und Laune hat.
Sollte man nicht. Der Sicherheitsgewinn durch nur PW-Hashes in der
Datenbank ist gegenüber der eigenen Anwendung nicht besonders hoch
(jemand, der Zugriff auf die Datenbank hat und somit Kennwörter lesen
könnte, kann im Prinzip auch alles andere machen wie Daten verändern
oder wenn er den Account haben will einfach ein neues Kennwort setzen),
aber es gibt noch User, die für alle genutzten Internetseiten das
gleiche Kennwort verwenden. Also schützt man eher andere Zugänge wenn
man nur Hashes in seiner Datenbank hat. Außerdem kann dem Server auch
bei Scriptfehlern so schnell kein Kennwort im Klartext entfleuchen, mit
guten Hashes kann ein Angreifer nicht viel anfangen.
Ben B. schrieb: > kein Kennwort im Klartext entfleuchen, mit > guten Hashes kann ein Angreifer nicht viel anfangen. Genau darum geht es dabei. Es kommt ja immer wieder vor, dass Zugangs-DBs im Netz auftauchen. Gut gehasht können Leute, die nur diese Daten haben, nicht aber Admin-Zugang zum System, mit dem Password nichts anfangen. Auch nicht auf der betreffenden Site selbst.
Optimalerweise speichert man nicht nur den Hashwert eines Passwortes,
sondern nimmt das Passwort im Klartext (z.B. "P@ssw0rd"), fügt einen
Zufallswert (Salt, z.B. "S@1T") am Anfang oder Ende dazu und übergibt
erst diese Zeichenfolge ("P@ssw0rdS@1T") der Hashfunktion. Den Hash und
das Salt speichert man anschließend in der Datenbank.
Das hat den Vorteil: Selbst wenn mehr als ein Nutzer das Passwort
"P@ssw0rd" benutzt, bekommt man durch das Salt immer unterschiedliche
Hashwerte. Das erschwert u.a. Angriffe mit Hashtabellen.
Aber das ist nur ein Beispiel aus dem 1x1 der IT-Sicherheit.
Ich packe zusätzlich zu einem Salt (was die heute gängigen Passwort-Hashfunktionen sowieso von sich aus machen) den Benutzernamen in den Hashwert. Je mehr variable Daten desto besser, umso länger müsste ein Angreifer suchen und umso geringer ist die Wahrscheinlichkeit, daß der Hash in irgendwelchen Rainbow-Tables auftaucht.
> Wie kann das sein? Ich denke nicht dass man vom hash eine Ähnlichkeit > des PW heruaslesen könnte... Aber vielleicht wenn bei der Eingabe Zeichen für Zeichen jeder Hash als Historie behalten wird. Diese Hashes entsprechen dann zwar (hoffentlich) keinem vollständigen Passwort, aber eben deren Tippreihenfolge... Zu diesem Zweck muss der Hash-Algorithmus (oder der zugegebener Salz) nichtmal jenem der "scharfen" Passwörter entsprechen (also jenen Daten welche effektiv zur Zugangsautetifizierung ausgewertet werden) es darf ein anderer, weniger rechenkostenintensiver sein, der nur zum Zeitpunkt des Passwortwechsels zum Einsatz kommt. Das ist jetzt nur mein Vorstellungsvermögen, gesalzen mit meiner Phantasie. Ich selbst hatte noch nicht die Ehre an einer Implementation Hand anzulegen.
foobar schrieb: > Es gibt einige Protokolle (z.B. http-digest), wo der Browser bereits das > Passwort hashed und der Server das Klartextpasswort nie sieht. Was natürlich kaum einen Sicherheitsgewinn bringt. Dieses Hashing ist lediglich eine Transformation und das eigentliche Login-Klartext-Secret für den Login ist das gehashte Passwort. Wenn das im Klartext über die Leitung geht oder gespeichert wird, hat man exakt dieselben Probleme wie bei einer Klartextübertragung/Speicherung des eingegebenen Passwortes.
Ben B. schrieb: > Der Sicherheitsgewinn durch nur PW-Hashes in der > Datenbank ist gegenüber der eigenen Anwendung nicht besonders hoch > (jemand, der Zugriff auf die Datenbank hat und somit Kennwörter lesen > könnte, kann im Prinzip auch alles andere machen wie Daten verändern > oder wenn er den Account haben will einfach ein neues Kennwort setzen), Nein, das ist so nicht richtig. Passwort-Hashes (salted) sind weit mehr als nur Schutz fremder Systeme: Falls durch einen Softwarefehler unautorisiertes Lesen von Daten ermöglicht wird (leaks), einschließlich der Passwörter, kann bei Klartext-Passwörter damit ein Schreib-Lese-Zugriff auf die Daten erreicht werden. Wenn die Passwörter aber als (salted) Hashes vorliegen, kann der unautorisierte Lesezugriff nicht zu einem Schreibzugriff erweitert werden, da die Hashes wertlos sind. D.h. der Hash verhindert zuverlässig eine Rechte-Ausweitung. Klar, wenn Schreibzugriff vorhanden ist, hilft der Hash gegenüber dem kompromittiertem System nichts mehr.
MaWin schrieb: > foobar schrieb: > >> Es gibt einige Protokolle (z.B. http-digest), wo der Browser bereits das >> Passwort hashed und der Server das Klartextpasswort nie sieht. > > Was natürlich kaum einen Sicherheitsgewinn bringt. > Dieses Hashing ist lediglich eine Transformation und das eigentliche > Login-Klartext-Secret für den Login ist das gehashte Passwort. Wenn das > im Klartext über die Leitung geht oder gespeichert wird, hat man exakt > dieselben Probleme wie bei einer Klartextübertragung/Speicherung des > eingegebenen Passwortes. Nö. Es gibt eine nonce die genau sowas verhindert. Crypto halbwahrheiten sind gefährlich.
meckerziege schrieb: > Nö. Es gibt eine nonce die genau sowas verhindert. > > Crypto halbwahrheiten sind gefährlich. https://en.wikipedia.org/wiki/Digest_access_authentication > However, if the stored HA1 is leaked, an attacker can generate valid responses and access documents in the realm just as easily as if they had access to the password itself. The table of HA1 values must therefore be protected as securely as a file containing plaintext passwords. > Digest access authentication prevents the use of a strong password hash (such as bcrypt) when storing passwords
Christian schrieb: > Wie kann das sein? Ich denke nicht dass man vom hash eine Ähnlichkeit > des PW heruaslesen könnte... indem man beim Erstellen des Hashes gleich noch Hashes ähnlicher Passwörter generiert und die mit abspeichert.
>> [http-digest] > > Was natürlich kaum einen Sicherheitsgewinn bringt. > Dieses Hashing ist lediglich eine Transformation und das eigentliche > Login-Klartext-Secret für den Login ist das gehashte Passwort. Der Hash beinhaltet neben dem Passwort auch noch Username und Serverkennung (aka Realm). > Wenn das im Klartext über die Leitung geht ... Vor der Übertragung wird der Hash nochmals gehasht (diesmal u.A. mit salt von beiden Seiten), geht also nicht im Klartext über die Leitung. > ... oder gespeichert wird, hat man exakt dieselben Probleme wie bei > einer Klartextübertragung/Speicherung des eingegebenen Passwortes. Nicht ganz. Mit einem geklauten Hash (nicht mit einem mitgesnifften!) hätte man (mit spezieller Software) Zugriff auf diesen Account dieses Servers. Insbesondere hätte der Dieb aber kein Passwort, dass er auf anderen Servern/Accounts ausprobieren könnte. Versteh mich nicht falsch, Http-digest ist bestimmt nicht perfekt. Aber dass der Server das Klartextpasswort nie sehen muß, dass das auch über unverschlüsselte Verbindungen eingesetzt werden kann (was wohl der Hauptgrund für die Einführung von http-digest war) und dass die Implementation relativ simple ist, hat schon was ...
> Wenn die Passwörter aber als (salted) Hashes vorliegen, kann der > unautorisierte Lesezugriff nicht zu einem Schreibzugriff erweitert > werden, da die Hashes wertlos sind. Das Problem, dass ich mit diesen Verfahren habe, ist, dass dazu bei jeder einzelnen Authentisierung das Klartextpasswort zum Server übertragen werden muss. Der Server hantiert also ständig mit Klartextpasswörtern ... und TLS-Load-Balancer ... usw.
Ben B. schrieb: >> Das macht jeder wie er Lust und Laune hat. > Sollte man nicht. Der Sicherheitsgewinn durch nur PW-Hashes in der > Datenbank ist gegenüber der eigenen Anwendung nicht besonders hoch > (jemand, der Zugriff auf die Datenbank hat und somit Kennwörter lesen > könnte, kann im Prinzip auch alles andere machen wie Daten verändern > oder wenn er den Account haben will einfach ein neues Kennwort setzen), Alle mir bekannten Datenbanken unterstützen etwas das sich Rechteverwaltung nennt. Meine Webanwendungen können die Benutzerdatenbank deshalb nur lesen und lediglich für spezielle Funktionen wie die Änderung des Passworts auch beschreiben. Diese speziellen Funktionen laufen über eine zweite, dynamisch und nur im Bedarfsfall aufgebaute Verbindung mit entsprechenden Privilegien. Das macht die ganze Sache etwas komplizierter und garantiert natürlich auch keine "echte" Sicherheit. Denn die Webapplikation muß doch wissen wie sie privilegierte Verbindungen aufbauen kann. Aber diese Herangehensweise erhöht doch die Aufwände für einen Angreifer und obendrein dessen Entdeckungswahrscheinlichkeit. Aber daß ein Angreifer mit einer einfachen SQL-Injection auf meiner Datenbank herumrödelt und meinen Benutzern neue Paßworte setzt ist wirksam unterbunden.
Ben B. schrieb: > Ich packe zusätzlich zu einem Salt (was die heute gängigen > Passwort-Hashfunktionen sowieso von sich aus machen) den Benutzernamen > in den Hashwert. Vorhersagbare Daten in einen Hash zu packen ist eigentlich keine gute Idee. Es ist sinnvoller den Benutzernamen in der DB ungesalzen oder mit einem bekannten Salt zu hashen. Darauf muß man einen Lookup machen und braucht die konstante Zeichenkette. Das Passwort wird natürlich gesalzen um die Entropie verbessern. Königsdisziplin ist aber eine Authentifizierung mit Zertifikaten die ihrerseits paßwortgeschützt sind. Noch besser ist eine n-Factor-Authentifizierung.
:
Bearbeitet durch User
Den Benutzernamen hashe ich in der DB nicht, der steht im Klartext drin und wenn der User das möchte, kann er ihn auch per Cookie wiederhaben um ihn nicht bei jedem Login selber eingeben zu müssen. Ich verwende sowas nur um den Password-Hash-String künstlich zu verlängern, dadurch taucht der mit sehr hoher Wahrscheinlichkeit nicht in rainbow tables auf. Manchmal hab ich beides auch miteinander interleaved, oder 3fach interleave mit einem binary salt zusammen, der in der DB steht und den niemand jemals zu sehen bekommt ... da kommt dann nur noch Datengrütze raus, keine Ahnung wer sowas in seinen rainbow tables stehen haben sollte. Der binary salt bei dem Spaß ist 256 Bit lang, allein das als Hashwert müsste bei der Erzeugung schon sehr schlecht gelaufen sein, damit man den in rainbow tables findet. Ansonsten machts aus meiner Sicht nicht viel Sinn, sicherer arbeiten zu wollen als die Scripte sind. Also sowas wie Kennwörter zwischen Browser und Server nur als Hash zu übertragen. Dann wäre der Browser das nächste möglicherweise unsichere Element, bzw. der Rechner des Users ansich (z.B. Keylogger). Wenn jemand Zugriff auf die Scripte hat um dort z.B. Kennwörter abzufischen, dann kann der sowieso alles machen. Der findet auch jeden Zugang zur Datenbank, egal ob der httpd-user immer Schreibrechte hat oder nur manchmal eine zweite Verbindung aufgebaut wird. Ich weiß doch als Angreifer wo ich suchen muß, ich werde auch finden.
foobar schrieb: >> Ich war immer der Meinung, das Passwort wird auf den >> Servern nicht im Klartext gespeichert, sondern nur ein Hash davon. > > Das macht jeder wie er Lust und Laune hat. So war es bisher, aber die DSGVO setzt inzwischen hohe Maßstäbe vorraus, so dass man sich als Seitenbetreiber bzw. Entwickler der Webseite und Software an dem Stand der Technik orientieren sollte.
Christian schrieb: > Darum hat es mich heute gewundert als ich wieder mal die PW ändern > wollte (diesmal hab ich bei jedem einen einzelnen Buchstaben angehängt) > und auf mehreren Seiten den Hinweis bekam, das neue PW darf nicht > ähnlich wie ein zuvor verwendetes PW sein. > > Wie kann das sein? Ich denke nicht dass man vom hash eine Ähnlichkeit > des PW heruaslesen könnte... Es ist folgendermaßen. Das neuste und somit gültige PW wird als Hash gespeichert. In der Regel mit Salt und ein paar mal gehashed usw.. Bei der Änderung wirst du aber nach dem alten PW gefragt. Wenn die Änderung erfolgreich ist, also beide Eingaben für das neue PW identisch sind, dann wird das alte PW auf dem Server gespeichert und im Idealfall mit dem neuen verschlüsselt und somit in verschlüsselter Form auf dem Server abgelegt. Wenn dich der Server daran hindert, uralte Passwörter oder Strings daraus zu verwenden, dann gilt das für alle Passwörter, die du auf diesem Server bisher genutzt hast. D.h. änderst du ein paar mal dein Passwort, dann wird die Liste der alten Passwörter, die der Server im Klartext kennt, immer länger und anhand dieser Liste erkennt er dann, ob du dann bei einem neuen Passwort auch wirklich ein neues PW generierst, oder lediglich wieder das Alte oder Teile davon vom vorletzten mal verwenden möchtest. Ob das weiter als 1 PW zurückgeht, kann man ganz einfach testen, in dem man versucht, das vorletzte PW oder einen Teil daraus als String für das neue Passwort zu verwenden. Wenn der Server das bemängelt, dann weiß man, dass er auch mehrer PW Iterationen hinweg die alten PW im Klartext speichert. Lediglich das neuste sollte in Form eines Hash und mit Salt nach den gängigen aktuellen Verfahren gespeichert werden. Aus diesem Grund sollte man auch alte Passwörter nicht mehr verwenden. Auch nicht auf anderen Servern.
Ich sehe sowas kritisch, auch wenn man die alten Kennwörter verschlüsselt speichert. Erstens führt das wie bereits gesagt erwiesenermaßen nicht zu sichereren Kennwörtern, sondern eher zu unsichereren wenn man Benutzer zwingt, regelmäßig das Kennwort zu ändern. Zweitens birgt es die Gefahr, daß irgendwer die gespeicherten alten Kennwörter auslesen kann. Ein einziges geleaktes/unsicheres Kennwort reicht, um von dort an die ganze Kette entschlüsseln zu können, die dazu mit dem Benutzernamen assoziiert werden kann. Dann erhält man eine Menge guter Kandidaten zum Ausprobieren auf anderen Seiten. Denn auch wenn man alten Kennwörtern nicht mehr vertrauen sollte bzw. diese Kennwörter nicht mehr auf anderen Seiten verwenden soll - welcher User macht das und vergisst dabei auch nichts, vor allem irgendwelche Accounts, die seit etlichen Jahren nicht mehr genutzt werden...
Ben B. schrieb: > Ich sehe sowas kritisch, auch wenn man die alten Kennwörter > verschlüsselt speichert. Es soll halt verhindern, dass du ein altes PW oder Stringabschnitte davon, wieder benutzt. Dazu muss der Server die alten PW kennen. Anders kann man diese Funktion nicht realisieren. Das wird vor allem dann wichtig, wenn der regelmäßige Passwortwechsel erzwungen werden soll, also nicht freiwillig ist. Bei solchen Maßnahmen neigen Nutzer nämlich dazu, die PW einfach hin und herzu wechseln. Zuerst also PW A, dann B, dann wieder A, dann wieder B usw. Will man das verhindern, so dass es zu C kommt, muss der Server somit A im Klartext verschlüsselt durch B speichern. Ist dann das PW auf C geändert, wird A und B im Klartext bzw. verschlüsselt durch C gespeichert und das aktuellste liegt dann immer nur als Hash und Salt vor. > Erstens führt das wie bereits gesagt erwiesenermaßen nicht zu sichereren > Kennwörtern, sondern eher zu unsichereren wenn man Benutzer zwingt, > regelmäßig das Kennwort zu ändern. Ja, ich mag diesen Passwortändernzwang auch nicht, aber auf manchen Servern ist er eben vorhanden und dann wird das dort genau so gemacht, weil es dann nötig wird. Gegen unsichere PW sind dann andere Abfragen wie Prüfung auf Groß und Kleinbuchstaben, Ziffern und Sonderzeichen wichtig, sowie natürlich den Abgleich mit bekannten Passwortlisten. > Zweitens birgt es die Gefahr, daß irgendwer die gespeicherten alten > Kennwörter auslesen kann. Wenn die alten PW verschlüsselt gespeichert werden, dann müsste er dazu Rainbowtable für das aktuelle gehahste PW und dessen Salt haben und bei letzterem scheitert es dann meist. Das ist also kein Problem. > Ein einziges geleaktes/unsicheres Kennwort > reicht, um von dort an die ganze Kette entschlüsseln zu können, die dazu > mit dem Benutzernamen assoziiert werden kann. Selbst wenn die alten PW unverschlüsselt auf dem Server im Klartext gespeichert werden würden, wie willst du da auf das aktuelle PW schließen? > Dann erhält man eine Menge > guter Kandidaten zum Ausprobieren auf anderen Seiten. Das ist der einzige Gewinn. Die Passwortliste wird größer. Allerdings ist der Zugewinn eines zufällig generierten PW eher klein. Genauso gut könnte man sich solche Passwortlisten auch generieren lassen. > Denn auch wenn man > alten Kennwörtern nicht mehr vertrauen sollte bzw. diese Kennwörter > nicht mehr auf anderen Seiten verwenden soll - welcher User macht das > und vergisst dabei auch nichts, vor allem irgendwelche Accounts, die > seit etlichen Jahren nicht mehr genutzt werden... Ich mach das und andere Nutzer verwenden Passwortverwaltungsprogramme und merken sich nur ihr Masterpasswort.
> Selbst wenn die alten PW unverschlüsselt auf dem Server im > Klartext gespeichert werden würden, wie willst du da auf > das aktuelle PW schließen? Das aktuelle PW finde ich nicht. Aber ich finde gute Anhaltspunkte nach welchem Schema der User seine Kennwörter wählt und jede Menge gute Kandidaten, die man zusammen mit dem Benutzernamen mal auf anderen Seiten ausprobieren kann. Vielleicht werde ich fündig, vielleicht nicht... Aber die Chance, daß ich fündig werde, ist mit diesen Informationen extrem erhöht als wie sie ohne diese Infos wäre. Das kann ja auch ein nicht loyaler Administrator machen. Der kann zu einem beliebigen Zeitpunkt (im Rahmen der Neuvergabe-Zeitpunkte) sämtliche alten Kennwörter aller User im Klartext bekommen. Das würde ich glatt schon wieder als Sicherheitsrisiko einstufen. Nicht für die Anwendung selbst, sondern für die anvertrauten User. Es ist auch ein Gewinn wenn ich nur rein zufällig generierte Kennwörter finde. Dann weiß ich hier brauche ich erstmal keine Zeit zu verschwenden und suche mir ein anderes Ziel. > Ich mach das und andere Nutzer verwenden Passwortverwaltungsprogramme > und merken sich nur ihr Masterpasswort. Was sehr sinnvoll ist wenn dieses unsicher ist oder zusammen mit der Datenbank geleakt wird. Das veschiebt das Problem, verbessert es aber nicht. Oder wenn das Master-Passwort verlorengeht und man alles neu machen darf. Da kommt Freude auf.
Nano schrieb: > Wenn der Server das bemängelt, dann weiß man, dass er auch mehrer PW > Iterationen hinweg die alten PW im Klartext speichert. Nein. Diese Annahme ist falsch. > Lediglich das > neuste sollte in Form eines Hash und mit Salt nach den gängigen > aktuellen Verfahren gespeichert werden. Das dürfte kein fahrlässiger Murks sein, sondern fast schon vorsätzlich Murks. Die alten Passwörter bleiben natürlich als Hash und Salt gespeichert. Passwörter werden niemals in Klartext gespeichert. Wird ein neues Passwort gesetzt, wird es eben gegen jeden Salt+Hash in der Alte-Passwort-Liste getestet. Kostet nur etwas Rechenzeit. Sollen Variationen abgefangen werden, errechnest Du aus dem neuen Passwort die nicht erlaubten Variationen, und testest jede Variation gegen die Liste der alten Passwörter. Kostet etwas mehr Rechenzeit. In der Alte-Passwort-Liste können auch vereinfachte Versionen vom Passwort gespeichert werden (natürlich als Salt+Hash), z.B. nur in Kleinbuchstaben, oder als statistischer Stempel, vom dem ein Hash+Salt gespeichert wird. Das Prinzip dahinter ist, dass man weniger Variationen gegen die Liste der alten Passwörter testen will, was ja nicht umsonst ist, eben wegen dem Salt. D.h. im Idealfall produziert die statistische Auswertung der Variationen möglichst viele Kollisionen. So muss nur noch jede Kollisionsgruppe einmal gegen die Liste mit Salt-Hash getestet werden.
Einer schrieb: > Nano schrieb: >> Wenn der Server das bemängelt, dann weiß man, dass er auch mehrer PW >> Iterationen hinweg die alten PW im Klartext speichert. > > Nein. Diese Annahme ist falsch. Dann erkläre mir, wie er bspw. den String "Xrw7#" wiedererkennt und neue Passwörter mit diesem String ablehnt, wenn dieser String in einem PW vor 5 Generationen vorkam? Solltest du das "PW im Klartext speichern" meinen, dann sollte dir klar sein, dass damit im Kontext gemeint ist, dass sie mit dem aktuellen PW verschlüsselt werden, sie aber quasi im Klartext vorliegen, wenn der Nutzer sein PW aktualisieren will. Das hatte ich aber oben schon erwähnt. >> Lediglich das >> neuste sollte in Form eines Hash und mit Salt nach den gängigen >> aktuellen Verfahren gespeichert werden. > > Das dürfte kein fahrlässiger Murks sein, sondern fast schon vorsätzlich > Murks. Das PW als Hash mit Salt nach aktuellen Verfahren gespeichert ist ganz gewiss nicht fahrlässiger Murks und schon gar nicht vorsätzlich, sondern Stand der modernsten Sicherheitstechnik. > Die alten Passwörter bleiben natürlich als Hash und Salt gespeichert. > Passwörter werden niemals in Klartext gespeichert. Du redest hier Blödsinn, weil man dann einen alten String in einem neuen PW dann gar nicht erkennen könnte, genau dafür werden die alten PW aber gespeichert. Ein Hash nutzt hier nichts, weil du mit dem Hash nicht auf den String schließen kannst. > Wird ein neues Passwort gesetzt, wird es eben gegen jeden Salt+Hash in > der Alte-Passwort-Liste getestet. Das ist Quatsch, das funktioniert nämlich nicht. Siehe oben. > Kostet nur etwas Rechenzeit. Sollen > Variationen abgefangen werden, errechnest Du aus dem neuen Passwort die > nicht erlaubten Variationen, und testest jede Variation gegen die Liste > der alten Passwörter. Kostet etwas mehr Rechenzeit. Wie schon gesagt, das funktioniert nicht, weil jeder Teilstring aus den alten PW einen anderen Hash ergibt. Du hast pro altes PW aber nur einen einzigen gespeichert. Also Blödsinn was du da schreibst. Und es ist auch nicht nötig, da es wesentlich einfacher und auch performanter ist, die alten PW einfach mithilfe des neuen PW zu verschlüsseln, denn das neue PW gilt als sicher und die alten ohnehin als Wegwerfware. Deren einziger noch existierender Nutzen ist lediglich sicherzustellen, dass der Nutzer keine Strings daraus für das neue PW benutzt. > In der Alte-Passwort-Liste können auch vereinfachte Versionen vom > Passwort gespeichert werden (natürlich als Salt+Hash), z.B. nur in > Kleinbuchstaben, oder als statistischer Stempel, vom dem ein Hash+Salt > gespeichert wird. Du weißt aber schon, dass moderne Salt+Hash Verfahren den Hash mehrmals mit sich selber hashen um die Rechenzeit bei einem bruteforceangriff zu erhöhen? Das müsstest du hier auch machen und wenn du dann alle Variationen eines alten PW speichern willst, dann verfielfacht sich der Aufwand um den Faktor grob geschätzt passwortlänge^variationsmöglichkeiten für nur eine feste Länge und dann das ganze nochmal mit jedem möglichen String, den man aus der gesamten passwortlänge herausschneiden könnte. Das wäre nicht nur sehr viel rechnen, sondern würde auch noch jede Menge Speicherplatz erfordern und dann geh mal von > 1 Mio Nutzern aus. Das skaliert also auch noch ziemlich schlecht.
Nano schrieb: > Ein Hash nutzt hier nichts, weil du mit dem Hash nicht auf > den String schließen kannst. Ergänzung: mit vertretbarem Aufwand.
Nano schrieb: > Du redest hier Blödsinn, Immer das gleiche: Je weniger Wissen vorhanden, desto aggressiver... > weil man dann einen alten String in einem neuen > PW dann gar nicht erkennen könnte, genau dafür werden die alten PW aber > gespeichert. Ein Hash nutzt hier nichts, weil du mit dem Hash nicht auf > den String schließen kannst. In der DB stehen 3 Passwörter, das dritte ist das Aktuelle: ID SALT KEY ----------------- 1 salt1 key1 [ = PBKDF2(pw1, salt1) ] 2 salt2 key2 [ = PBKDF2(pw2, salt2) ] 3 salt3 key3 [ = PBKDF2(pw3, salt3) ] Nun muss nur sichergestellt werden, dass das alte Passwort (pw_alt) gültig ist und das neue Passwort (pw_neu) nicht einem alten Passwort entspricht. Es wird berechnet: - check = PBKDF2(pw_alt, salt3) - old1 = PBKDF2(pw_neu, salt1) - old2 = PBKDF2(pw_neu, salt2) - old3 = PBKDF2(pw_neu, salt3) - salt4 = RANDOM() - key4 = PBKDF2(pw_neu, salt4) Dann wird geprüft: check == key3 && old1 != key1 && old2 != key2 && old3 != key3 Ist das gegeben, wird das neue Passwort akzeptiert und die Datenbank erweitert um: ID SALT KEY ----------------- 4 salt4 key4 ...aber, ganz ehrlich, das sind absolute Basics.
Super Sache, darum gehts aber schon gar nicht mehr. Es ging darum, wie man evtl. ohne das Speichern aller alten Kennwörter im Klartext erkennen soll, wenn ein neues Kennwort einem älteren ähnlich ist. Also wie verhindere ich, daß der User "katze2" als Passwort benutzt wenn er vorher "katze1" hatte? Edit: Ohne daß ich "katze1" als altes Kennwort gespeichert habe.
:
Bearbeitet durch User
Einer schrieb: > Nano schrieb: >> Du redest hier Blödsinn, > > Immer das gleiche: Je weniger Wissen vorhanden, desto aggressiver... > >> weil man dann einen alten String in einem neuen >> PW dann gar nicht erkennen könnte, genau dafür werden die alten PW aber >> gespeichert. Ein Hash nutzt hier nichts, weil du mit dem Hash nicht auf >> den String schließen kannst. > > In der DB stehen 3 Passwörter, das dritte ist das Aktuelle: > > ID SALT KEY > ----------------- > 1 salt1 key1 [ = PBKDF2(pw1, salt1) ] > 2 salt2 key2 [ = PBKDF2(pw2, salt2) ] > 3 salt3 key3 [ = PBKDF2(pw3, salt3) ] > > Nun muss nur sichergestellt werden, dass das alte Passwort (pw_alt) > gültig ist und das neue Passwort (pw_neu) nicht einem alten Passwort > entspricht. Es wird berechnet: > > - check = PBKDF2(pw_alt, salt3) > - old1 = PBKDF2(pw_neu, salt1) > - old2 = PBKDF2(pw_neu, salt2) > - old3 = PBKDF2(pw_neu, salt3) > - salt4 = RANDOM() > - key4 = PBKDF2(pw_neu, salt4) > > Dann wird geprüft: > > check == key3 && old1 != key1 && old2 != key2 && old3 != key3 > > Ist das gegeben, wird das neue Passwort akzeptiert und die Datenbank > erweitert um: > > ID SALT KEY > ----------------- > 4 salt4 key4 > > ...aber, ganz ehrlich, das sind absolute Basics. Es ist und bleibt falsch. Mal angenommen das älteste Passwort heißt "Schafhirtenhund" und jetzt versucht der Nutzer ein neues zu erstellen und weil er sich nicht so viel merken will, will er für das neue Passwort einen Teilstring wiederbenutzen. Er tippt also ein: "Piratenhirtenwiesel" So, und jetzt zeig mal mit deinem obigen Blödsinn auf, wie du erkennen willst, dass er den Teilstring "hirten" wieder benutzt? Das gilt es nämlich zu verhindern. Ich lag da also schon richtig mit dem Urteil "Blödsinn", aber du hast überhaupt nicht verstanden, was ich geschrieben habe. Das sieht man jetzt recht gut.
Ben B. schrieb: > Den Benutzernamen hashe ich in der DB nicht, der steht im Klartext drin > und wenn der User das möchte, kann er ihn auch per Cookie wiederhaben um > ihn nicht bei jedem Login selber eingeben zu müssen. Eine serverseitige Datenbank zumindest teilweise auszulesen oder darauf auch schreiben zu können sind zwei sehr unterschiedliche Dinge. Obendrein Zugriff auf den Sourcecode und die Konfiguration der Webapplikation zu erlangen ist nochmal eine vollkommen andere Angelegenheit. Deswegen verwenden meine Webapplikationen für wichtige Daten wie Benutzernamen nur Einweg-Hashes. Für Benutzernamen nutze ich dabei gerne Einweg-Hashes mit einem bekannten Salt der nur in der Konfig der Webanwendung gespeichert ist. Ein Angreifer der nur Zugriff auf die Datenbank erlangen konnte hat damit keine Chance an die Benutzernamen zu kommen. Nichtmal dann wenn er in die Datenbank schreiben kann. Bei Applikationen bei denen es wirklich um wichtiges geht habe ich sogar einen eigenen Datentyp für meine Datenbank (PostgreSQL) entwickelt welcher die Daten transparent symmetrisch verschlüsselt. Um diese Daten zu entschlüsseln braucht der Angreifer nicht zur lesenden Zugriff auf die Datenbank sondern auch auf die Konfiguration meiner Software (oder neuerdings auf das TPM des Servers). Das heißt der Angreifer kann sogar die Festplatte aus meinen Servern klauen und hat trotzdem keine Chance weil das Secret woanders ist. Es ist halt auch wesentlich einfacher eine Festplatte, SSD oder gar eine winzige NVmE aus dem Rechenzentrum zu schmuggeln als eine komplette Maschine. Und ach so: Backups zu verschlüsseln ist ebenfalls eine prima Sache. Nur so als Tipp am Rande gemeint weil ich zu oft gesehen habe daß das vernachlässigt wird. > Ich verwende sowas nur um den Password-Hash-String künstlich zu > verlängern, Das hilft bei modernen Kryptoalgorithmen halt nichts. Im Gegenteil: wenn Du eine vorhersagbare Zeichenkette wie in Deinem Fall einen Klartext-Benutzernamen im Passwort-Hash speicherst wird das Knacken einfacher.
Einer schrieb: > Nano schrieb: >> weil man dann einen alten String in einem neuen >> PW dann gar nicht erkennen könnte, genau dafür werden die alten PW aber >> gespeichert. Ein Hash nutzt hier nichts, weil du mit dem Hash nicht auf >> den String schließen kannst. > > In der DB stehen 3 Passwörter, das dritte ist das Aktuelle: > > ID SALT KEY > ----------------- > 1 salt1 key1 [ = PBKDF2(pw1, salt1) ] > 2 salt2 key2 [ = PBKDF2(pw2, salt2) ] > 3 salt3 key3 [ = PBKDF2(pw3, salt3) ] Damit kannst Du nur erkennen ob Dein Benutzer ein altes PW wiederverwendet. Alle mir bekannten Algorithmen die die Ähnlichkeit von Zeichenketten berechnen können bedürfen der Klartextversionen beider Zeichenketten.
Nano schrieb: > Ich lag da also schon richtig mit dem Urteil "Blödsinn", aber du hast > überhaupt nicht verstanden, was ich geschrieben habe. Ihr redet an einander vorbei. Dein Gegenüber will verhindern daß seine Benutzer zwischen zwei Paßworten hin und her oszillieren. Du hingegen möchtest es auch erkennen und verhindern wenn Deine Benutzer ähnliche ältere Paßworte benutzen -- und zwar nicht nur hinsichtlich der Ähnlichkeit ihres alten und neuen Paßwortes sondern auch bezüglich ihrer Paßworthistorie. Um Ähnlichkeiten zwischen Zeichenketten zu erkennen bedarf es aber der beiden betreffenden Zeichenketten im Klartext. Die wollen wir jedoch nicht in unserer Datenbank speichern. Und aus den Hashes können wir keine Ähnlichkeiten sehen. Haargenau das ist ja die ganze Idee von Hashes. Möglicherweise -- ich habe das noch nicht zuende gedacht -- könnte es gehen, die Buchstaben der einzelnen Passworte gehasht zu speichern. Denn eine gute Änderung eines Passwortes fragt natürlich das alte Passwort ab. Also kann man dieses alte Passwort in Buchstaben zerlegen und mit zufälligen Salzen hashen und es dann bei der Eingabe auf Ähnlichkeiten prüfen indem man das alte PW buchstabenweise hasht und mit den älteren buchstabenweise gehashten Versionen des Paßworts vergleicht.
Aus der Unix- bzw. Windows AD Praxis kenne ich folgendes Verhalten: - beim Passwortwechsel wird das neue und vorherige verglichen und bei zu hoher Ähnlichkeit (je nach Settings) abgelehnt, das geht weil ja beide abgefragt werden. Alte Passworter werden in dieser Hinsicht nicht geprüft, geht ja nicht da nur einige (10?) alte Hashes gespeichert werden (siehe Sheeva P.) Das führt dann dazu das die Leute folgendes machen: "password1" wird ungültig, Änderung in "tempsecret", dann Änderung in "password2" ... so geht es weiter bis "password9" und dann geht es von vorne los. In der Praxis sind Passwörter oben natürlich maximal komplex... (mindestens 100 Zeichen und je ein Groß-/Kleinbuchstabe, Zahlen, Sonderzeichen, mindestens je ein kyrillisches / Thai und Sanskit...
Sheeva P. schrieb: > Nano schrieb: >> Ich lag da also schon richtig mit dem Urteil "Blödsinn", aber du hast >> überhaupt nicht verstanden, was ich geschrieben habe. > > Ihr redet an einander vorbei. Dein Gegenüber will verhindern daß seine > Benutzer zwischen zwei Paßworten hin und her oszillieren. Ich habe ja ihm vorher gesagt, was das Ziel ist. Es ist also kein vorbeireden, sondern er hat's nicht verstanden. > Du hingegen > möchtest es auch erkennen und verhindern wenn Deine Benutzer ähnliche > ältere Paßworte benutzen -- und zwar nicht nur hinsichtlich der > Ähnlichkeit ihres alten und neuen Paßwortes sondern auch bezüglich ihrer > Paßworthistorie. Korrekt. > Um Ähnlichkeiten zwischen Zeichenketten zu erkennen bedarf es aber der > beiden betreffenden Zeichenketten im Klartext. Korrekt. > Die wollen wir jedoch > nicht in unserer Datenbank speichern. Verschlüsselt geht das und das aktuellste PW, das nur als Hash vorliegt, ist der Schlüssel zum Entschlüsseln. > Und aus den Hashes können wir > keine Ähnlichkeiten sehen. Haargenau das ist ja die ganze Idee von > Hashes. > > Möglicherweise -- ich habe das noch nicht zuende gedacht -- könnte es > gehen, die Buchstaben der einzelnen Passworte gehasht zu speichern. Wollte es man so machen, wie "Einer" es mit einem hash machen will, dann müsste man jeden möglichen Teilstring als Hash speichern und dann beim setzen neuer PW auch dort jeden Teilstring hashen und dann mit den anderen Hash vergleichen. Das ist aber ein viel zu großer Rechen und Speicheraufwand und habe ich oben ja schon erwähnt. Das einfachste ist wirklich einfach die ganzen alten PW mit dem neuen Passwort zu verschlüsseln und so zu speichern. Man könnte das sogar so machen, das das Entschlüsseln und verschüsseln, und vergleichen der Teilstrings mit dem neuen zu setzenden PW nur auf dem Client stattfindet und der Server nur die verschlüsselten PW kriegt. > Denn > eine gute Änderung eines Passwortes fragt natürlich das alte Passwort > ab. Korrekt. > Also kann man dieses alte Passwort in Buchstaben zerlegen und mit > zufälligen Salzen hashen und es dann bei der Eingabe auf Ähnlichkeiten > prüfen indem man das alte PW buchstabenweise hasht und mit den älteren > buchstabenweise gehashten Versionen des Paßworts vergleicht. Wie schon gesagt, wenn man das über Hashs macht, dann müsste man jeden möglichen Teilstring hashen und diese Hashs alle speichern. Das ist ein viel zu großer Aufwand und auch nicht nötig, weil man mit dem aktuellsten PW, das auf dem Server nur als Hash vorliegt, immer ein Passwort zum Verschlüsseln und entschlüsseln hätte. Mal angenommen, wie haben die alten Passwörter A, B, C, D und E und F ist das aktuelle PW, dann wäre würde das so aussehen: { A, B, C, D, E } = verschlüsselt mit F F = gehashed Ein Paar Monate später soll der Nutzer das PW erneut ändern und es soll verhindert werden, dass er sich aus den Teilstrings alter PW bedient. Also überträgt man { A, B, C, D, E } in Verschlüsselter Form auf den Clienten, nach dem dieser sich eingeloggt und mit F am Server authentifiziert hat und entschlüsselt dort A bis E. Dann setzt man das neue Passwort G und vergleicht G mit den Teilstrings aus { A, B, C, D, E, F } Ist das getan und alles korrekt, so dass G gesetzt werden kann. Dann werden { A, B, C, D, E, F } mit G verschlüsselt und G gehashed. Dann kommen auf den Server dann die Daten und liegen dann dort folgendermaßen vor: { A, B, C, D, E, F } = verschlüsselt mit G G = gehashed Wird das PW erneut geändert, dann sieht's so aus: { A, B, C, D, E, F, G } = verschlüsselt mit H H = gehashed Und gehashed heißt hier natürlich nach den aktuellsten Verfahren mit Salt usw..
> wenn Du eine vorhersagbare Zeichenkette wie in Deinem Fall einen > Klartext-Benutzernamen im Passwort-Hash speicherst wird > das Knacken einfacher. Das glaube ich nun wieder nicht, solange die Hashfunktion sicher ist. Schlimmstenfalls bringt es genau gar nichts, aber auf jeden Fall klaue ich einem Angreifer Rechenzeit bei einem Bruteforce-Angriff, wenn er statt eines vielleicht 10 Zeichen Passworts einen String mit 50..60 Bytes hashen muß. Dazu verwende ich auch immer hohe Werte für den Aufwand der Hashfunktion, nur damit dem kleinen Bruteforcer der Spaß dran vergeht. Man könnte das auch ins Extreme treiben und ~50kByte bekannte zufällige Daten dranhängen. Die müsste ein Angreifer dann bei jedem Bruteforce-Versuch mithashen. Das dürfte dem so richtig schön den Tag versauen.
nano schrieb: > Wird das PW erneut geändert, dann sieht's so aus: > { A, B, C, D, E, F, G } = verschlüsselt mit H > H = gehashed Das funktioniert nicht. Um die Oldpws umzuschlüsslen erst entschlüsseln. Und dem Angreifer den Hash des aktuellen PW zu geben der dann der symmetrische Schlüssel ist möchtest Du auch nicht.
Das Knechten der Benutzer mit schwachsinnigen Passwort Regeln bringt doch nichts. Ich bin dazu uebergegangen entweder das vorgeschlagene neue Passwort zu nehmen, oder irgendwelche Tasten zu druecken, soviel wie eben noetig, wenn's 30 Character sind ist auch ok. Mit aber nichts zu merken. Einfach die Passwort Reset Funktion anzuwerfen und mir ein Neues senden zu lassen. Auf einer Webseite, die ich betreue ist das eigentlich die bevorzugte Methode. Einen Button : "ich moechte einlogen", eingabe der email, und es wird ein Einmal-Link auf das email gesendet. Der ist dann auch heftig lang. Es gibt auch die Moeglichkeit eines Alternativ Passwortes.
Mir fallen mehrere Varianten ein, wie man das umsetzen kann. Alle basieren darauf, vor dem Hashen des ursprünglichen Passworts entweder Varianten zu erzeugen oder Sub-Elemente zu extrahieren, und deren Hashes ebenfalls abzuspeichern. Dasselbe macht man mit dem neuen Passwort auch, und schaut ob die Varianten oder irgendwelche Sub-Elemente übereinstimmen. IIRC macht Facebook etwas ähnliches, die generieren beim Setzen plausible Typos für die erstellten Passwörter, speichern alle Hashes der Typo-Varianten ebenfalls ab und akzeptieren dann jede dieser Varianten.
foobar schrieb: >> Ich war immer der Meinung, das Passwort wird auf den >> Servern nicht im Klartext gespeichert, sondern nur ein Hash davon. > > Das macht jeder wie er Lust und Laune hat. Da wäre mal eine gesetzliche Regelung wirklich sinnvoll. Wer Passwörter im Jahr 2021 in Klartext speichert, gehört einfach 3 Jahre eingesperrt.
> Sub-Elemente zu extrahieren, und deren Hashes > ebenfalls abzuspeichern Daraus könnte recht schnell ein Sicherheitsrisiko entstehen wenn die Hashes der recht kurzen Zeichenketten dann in rainbow tables auftauchen. Oder die Regeln nach denen die Hashes erstellt wurden und reproduziert werden können, finden sich im Code, die Salts evtl. in der Datenbank. Es dürfte kein großes Problem sein, gegen die recht kurzen unbekannten Zeichenketten einen Bruteforce-Angriff zu fahren. Evtl. kann ich mir daraus sogar das aktuelle Kennwort zusammenreimen. Ich finde man sollte diesen Passwort-Änderungszwang oder das Zurückweisen "gebrauchter" Kennwörter einfach lassen. Erstens ist der Benutzer sowieso immer selbst für sein Kennwort verantwortlich und kann ein unsicheres wählen wenn er Lust hat - das einzige was ich machen kann ist, ihm da bestimmte Regeln auferlegen wie Sonderzeichen oder Ziffern verwenden und das Kennwort dadurch sicherer zu machen. Lustigerweise klappt das nicht, wenn das Kennwort bereits als Hash übertragen wird, weil der Server dann nicht sehen kann, welchen Mist der User womöglich eingegeben hat. Ein "admin" sieht dann wie ein total sicheres Kennwort aus. Und zweitens - wie schon gesagt - führt das nur zu anderen Kennwörtern, aber nicht zu besseren.
Sven B. schrieb: > IIRC macht Facebook etwas ähnliches, die generieren beim Setzen > plausible Typos für die erstellten Passwörter, speichern alle Hashes der > Typo-Varianten ebenfalls ab und akzeptieren dann jede dieser Varianten. Das wäre je echt blöd. Warum so ein Aufwand für so wenig Nutzen. Die sollten besser zusätzlich noch einige Standardpasswörter wie "1234" oder "Passwort" akzeptieren. Es könnte ja sein, dass der Benutzer das Passwort eines anderen Accounts genutzt hat. Aber mal ernsthaft, was sollte sowas bringen? Der Passwortschutz ist dadurch sicher, dass es genaues Kennen des Passwortes erfordert, um Zugriff zu bekommen. Das aufzuweichen, indem man nicht das eine, sondern viele verschiedene Passwörter akzeptiert, hat doch nichtmal einen Nutzen. Ein Benutzer, der sich vertippt, gibt das Passwort halt nochmal ein. Jemand, der als Passwort "Wiederstand" nimmt, wird auch bei späterer Eingabe wieder "Wiederstand" nehmen, weil er offensichtlich das für die richtige Schreibweise hält. Oder jemand benutzt absichtlich "Wiederstand", damit eine Wörterbuchattacke, die nur die richtige Schreibweise berücksichtigt, ins Leere läuft (in dem Beispiel ist das nicht so super sinnvoll, in anderen Zusammenhängen aber eventuell schon).
"Wiederstand" wird bei einer Wörterbuchattacke definitiv getroffen, das Wort kommt auch wenns falsch geschrieben ist so oft vor, auch in den entsprechenden Witzen darüber... in einem guten Wörterbuch steht's drin.
Sheeva P. schrieb: > nano schrieb: >> Wird das PW erneut geändert, dann sieht's so aus: >> { A, B, C, D, E, F, G } = verschlüsselt mit H >> H = gehashed > > Das funktioniert nicht. Um die Oldpws umzuschlüsslen erst entschlüsseln. > Und dem Angreifer den Hash des aktuellen PW zu geben der dann der > symmetrische Schlüssel ist möchtest Du auch nicht. Warum soll das nicht funktionieren? Klar funktioniert das. Du hast zuerst: { A, B, C, D, E, F } = verschlüsselt mit G G = gehashed Dann lässt du den Nutzer das PW G und das neue Passwort H eingeben, damit ist G temporär im Klartext vorhanden. Jetzt entschlüsselst du { A, B, C, D, E, F } und hältst es temporär im Klartext. Dann überprüfst du damit das neue Passwort H, ob das okay ist. Ist es okay, verschlüsselst du mit H die Passwörter { A, B, C, D, E, F, G } und gibst dem Nutzer das Okay, das das neue PW akzeptiert wurde und alles okay ist. Der ganze Prozess zwischen dem Abschicken der Eingaben und dem Überprüfen geht in der Regel so schnell, dass der Nutzer da kaum Latenz hat.
Ben B. schrieb: > Ich finde man sollte diesen Passwort-Änderungszwang oder das > Zurückweisen "gebrauchter" Kennwörter einfach lassen. Erstens ist der > Benutzer sowieso immer selbst für sein Kennwort verantwortlich und kann > ein unsicheres wählen wenn er Lust hat - das einzige was ich machen kann > ist, ihm da bestimmte Regeln auferlegen wie Sonderzeichen oder Ziffern > verwenden und das Kennwort dadurch sicherer zu machen. Das stimmt nicht. Du kannst das vom Nutzer eingegebene Passwort gegen eine öffentlich bekannte Passwortliste vergleichen und einfache Passwörter wie 12345678 oder Password damit gleich im Vorfeld ablehnen. IMO gehört das auch zu den Sorgfaltspflichten einer verantwortungsbewussten Webseite, das so etwas gemacht wird. Denn man muss auch mit IT-fernen Daus rechnen, die sich der Folgen von trivialen Passwörtern gar nicht bewusst sind.
Sorgfaltspflichten... sorry aber nun hört's auf. Soll ich dem DAU auch noch seine Windeln wechseln oder was? Vor allem wenn ich von solchen sicherheitsbewussten Leuten nur noch einen Hash des Passworts gesendet bekomme, das "12345" oder "admin" somit überhaupt nicht sehe. Nö, so nicht.
Der Hash ist für das Speichern da, damit das PW nicht im Klartext gespeichert werden muss. Es ist also völlig legitim, das Passwort an den Server über einen verschlüsselten Übertragungsweg im Klartext zu verschicken und bei der Passworterstellung mit obigen Überprüfungsmethoden wie PW-Listen auch notwendig.
Ben B. schrieb: > Sorgfaltspflichten... sorry aber nun hört's auf. Soll ich dem DAU auch > noch seine Windeln wechseln oder was? Vor allem wenn ich von solchen > sicherheitsbewussten Leuten nur noch einen Hash des Passworts gesendet > bekomme, das "12345" oder "admin" somit überhaupt nicht sehe. Vielleicht solltest Du Dich mal mit der Rechtslage vertraut machen. Da gibt es solche garstigen Dinge wie die "DSGVO" und den "Stand der Technik" und wie bei nahezu jedem Vertrag natürlich eine Sorgfaltspflicht. Nur so ein Tipp.
Nano schrieb: > Der Hash ist für das Speichern da, damit das PW nicht im Klartext > gespeichert werden muss. > > Es ist also völlig legitim, das Passwort an den Server über einen > verschlüsselten Übertragungsweg im Klartext zu verschicken und bei der > Passworterstellung mit obigen Überprüfungsmethoden wie PW-Listen auch > notwendig. Absolut korrekt. An dieser Stelle müssen wir mal differenzieren zwischen einer Transport- und der Einwegverschlüsselung von spezifischen Daten. Eine Transportverschlüsselung über TLS schützt die Daten gegen ein Abgreifen auf dem Transportweg. So etwas kennen wir von TLS (früher: SSL). Im Prinzip ist das eine Art der symmetrischen Verschlüsselung denn die Daten müssen von den beiden Kommunikationspartnern vor jeder Datenübertragung ver- und danach entschlüsselt werden. Denn wenn die Server Deiner Bank den Überweisungsempfänger nicht wieder entschlüsseln können überweist Du Dein Geld... genau. Transportverschlüsselung schützt Daten gegen Angreifer die die Kommunikation mitlesen könn(t)en. Eine Einwegverschlüsselung ist für Daten erforderlich die beiden Seiten vor der Kommunikation bekannt sein müssen. Welche Art von Daten könnte das sein? Genau: Login-Credentials zum Beispiel. Diese Art von Verschlüsselung kann im Idealfall nicht mehr entschlüsselt werden. Das ist aber auch gar nicht nötig weil ich auf der Serverseite die bereits verschlüsselten Daten vergleichen kann. Für solche Zwecke gibt es eigene kryptografische Hashfunktionen wie SHA. Diese Art einer Verschlüsselung schützt Deine Daten gegen Entschlüsselung und praktisch gegen Menschen die irgendwie an Deine Datenspeicherinhalte kommen. Kommen wir mal zum SALT: sogar ein einfacher SALT aus zwei 8Bit-Ganzzahlen hat bereits 2^^255 Möglichkeiten. Das wäre dann offenbar eine Zahl mit 77 Stellen. 578960446186580977117854925043439539266349923328202820197287920039565648 19968 Rainbowtables? Ick lach mir dot! ;-)
sheevaplug schrieb: > Kommen wir mal zum SALT: sogar ein einfacher SALT aus zwei > 8Bit-Ganzzahlen hat bereits 2^^255 Möglichkeiten. Jo, mit Vollbitverschlüsselung ...
Blödsinn. Was hat die Sicherheit von fremden Passwörtern mit meinen Pflichten aus der DSGVO zu tun, vor allem wenn der Server (den ich evtl. betreibe) nur den Hash eines Passworts sieht? Da kann ich nicht mal mehr prüfen, ob das Passwort die geforderte Mindestlänge hat. Soll ich mir jetzt die Hashwerte aller unsicheren Kennwörter hinlegen? Gewissermaßen verstoße ich damit ja gleich wieder gegen die DSGVO, da ich damit probiere, das Kennwort des DAU zu erraten. Hallo Herr DAU. Bitte geben Sie ein Passwort an! > pass Das Passwort muß mindestens 5 Stellen lang sein. > 12345 Das Passwort muß Buchstaben enthalten. > admin Das Passwort muß Großbuchstaben enthalten. > Admin Das Passwort muß Zahlen enthalten. > Admin1 Das Passwort muß Sonderzeichen enthalten. > Admin1!! Dieses Kennwort ist leider unsicher, wählen Sie ein anderes. > LECKMICHAMAAAAAAAARSCH!!!!!!!!!!!!!!!!!! ... und schwupps hat der DAU keinen Bock mehr auf die Seite oder der Admin bekommt einen Anruf "Anmelden geht nicht, fix that ASAP!!"
Ben B. schrieb: > Dieses Kennwort ist leider unsicher, wählen Sie ein anderes. >> LECKMICHAMAAAAAAAARSCH!!!!!!!!!!!!!!!!!! > Dieses Passwort ist schon vergeben. Oliver
> Dieses Passwort ist schon vergeben.
Genau... Auf jeden Fall beißt Herr DAU in genau diesem Augenblick
ein größeres Stück aus seiner Tastatur heraus.
(Edit: ... und so richtig verübeln kann man's ihm nicht)
:
Bearbeitet durch User
Ben B. schrieb: > ... und schwupps hat der DAU keinen Bock mehr auf die Seite oder der > Admin bekommt einen Anruf "Anmelden geht nicht, fix that ASAP!!" Da ist was wahres dran :-) Allerdings kann man die Regeln gleich mit auf die Seite schreiben. Das setzt allerdings voraus, dass der DAU in der Lage und willig ist zu lesen.
:
Bearbeitet durch User
Ben B. schrieb: > Hallo Herr DAU. Bitte geben Sie ein Passwort an! >> pass > Das Passwort muß mindestens 5 Stellen lang sein. >> 12345 > Das Passwort muß Buchstaben enthalten. >> admin > Das Passwort muß Großbuchstaben enthalten. >> Admin > Das Passwort muß Zahlen enthalten. >> Admin1 > Das Passwort muß Sonderzeichen enthalten. >> Admin1!! > Dieses Kennwort ist leider unsicher, wählen Sie ein anderes. >> LECKMICHAMAAAAAAAARSCH!!!!!!!!!!!!!!!!!! Du hast vergessen "Das Passwort muss zwischen 8 und 12 Zeichen lang sein". Ich weiß nicht mehr, welcher das war, aber ein bekannter Anbieter von professioneller Software (oder auch Hardware?) hatte diese Beschränkung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.