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
> 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.
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:> 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.
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)
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.
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.
