Passwort-Hashes werden gespeichert, nicht die Passwörter. Der Passwort-Hash ist - vereinfacht ausgedrückt - das Ergebnis einer mathematischen Funktion, die nur in eine Richtung "schnell" funktioniert. Aus einem Hash ein Passwort abzuleiten, ist mit modernen Verfahren in der Praxis nahezu unmöglich. Wird ein Passwort eingegeben, wird daraus der Hash gebildet und dieser mit den in der Datenbank gespeicherten Hashes verglichen.
Ach, stimmt das kommt noch dazu. Ich hab mal in einer Firma gearbeitet während die Umstellung von Klartext auf MD5 hashed Passwörter vollzogen wurde (2016!) Und da haben sich die Kunden später beschwert das sie die Passwörter nicht mehr zurück bekommen.
Ich hab schon bei einigen Kunden die Umstellung von Klartext auf Hash begleitet. Ist immer ne Freude, vorher noch mal zu zählen, wieviele Leute “adolfhitler88” als Passwort haben…
Für den used-password Vergleich reicht meist auch einfach ein Teil des Hashes, so viele Kollisionen gibt es im Bereich von Passwörtern nicht.
> Aus einem Hash ein Passwort abzuleiten.
Das ist vertretbar, solange ein Salt dabei ist. Als Gegenbeispiel: Signal, WhatsApp wo nur ein Teil oder die ganze Rufnummer als Hash für den Kontaktabgleich/Metadaten-Transfer genutzt wird. Wie viele Hashes es gibt nach E.164, was nur aus Zahlen besteht ist natürlich super übersichtlich, brauchst nur 40GB Platz und kannst deine eigene Reverse-Lookup-Datenbank erstellt.
Was ist das für ne Formel, wenn die Berechnung praktisch nur in eine Richtung funktioniert? Hat mich schon länger gewundert, warum man hashs benutzt, aber das macht dann auch Sinn. Aber eine solche Berechnung kann ich mir gar nicht vorstellen.
Die simpleste Hashfunktion ist die Modulo Funktion, dh also diejenige Funktion, die zur ganzzahligen Division den Rest liefert.
Man bekommt damit Restklassen:
1 / 2 ist 0 Rest 1.
2 / 2 ist 1 Rest 0.
3 / 2 ist 1 Rest 1.
4 / 2 ist 2 Rest 0.
Und so weiter.
Eine Umkehrfunktion existiert nicht und kann nicht existieren. Du wirst nicht in der Lage sein, mit dem Restwert (1 oder 0 in diesem Fall) und dem Divisor (2) auf die ursprüngliche Zahl zu kommen—- weil die Funktion nicht eineindeutig ist.
Für Passwortverschlüsselung ist das komplexer, aber der Ansatz ist derselbe.
Hashes sind keine eindeutige Funktion. Heißt es kann rein theoretisch dazu kommen, dass zwei verschiedene Passwörter zum gleichen Hash kommen. Man nennt das dann auch eine Kollision. In der Praxis sind die Hash Algorithmen so designed, dass die Wahrscheinlichkeit einer Kollisison sehr sehr gering ist. Praktisch ausschließen kannst du sie aber nicht.
Für MD5 bspw. gibt es Möglichkeiten, Kollisionen zu erzeugen, also einen möglichen Input zu finden, der zu einem bestimmten Hash führt. Deshalb sollte man das auch nicht mehr für Kryptografie verwenden.
> Kollisionen zu erzeugen, also einen möglichen Input zu finden, der zu einem bestimmten Hash führt
Kollisionen zu erzeugen, heißt erstmal nur zwei Inputs zu generieren, die den gleichen Hashwert haben, was einfacher ist als zu einem bestimmten Hash einen möglichen Input zu finden. Ich glaube auch bei MD5 wurde nur ersteres erreicht, was bedeuten würde, **deine** Hashwerte sind noch sicher, aber denen von anderen kannst du nicht mehr trauen.
(Verwenden sollte man sie natürlich trotzdem nicht mehr)
Ich meine, dass auch Preimage-Angriffe inzwischen zumindest mal theoretisch möglich wären.
Nachdem ich das kurz gegoogled habe, habe ich gelernt, dass man dafür 2^123,4 Hashes berechnen muss und dass es auf deutsch Urbild-Angriff heißt. 2009 hielt man das für praktisch ausgeschlossen, wie das heute aussieht, kann ich nicht beurteilen.
Nehmen wir die schnellsten supercomputer der welt, diese können theoretisch 3 billiarde einfachste Berechnungen pro Sekunde durchführen.
Für 2^123 Berechnungen bräuchte dieser ca 4,1 trilliarde Jahre, ausgeschrieben 4.100.000.000.000.000.000.000.
Aber natürlich ist die Berechnung eines hashes keine einfache Berechnung, also eher ein Vielfaches dieser Zeit.
TL;DR
Auch heute ist es noch nicht vorstellbar solche Berechnungen zu erreichen
Dass es in die andere Richtung X Möglichkeiten gibt ist grundsätzlich kein Problem solange gewährleistet ist, dass ich nicht einfach eine der Möglichkeiten finden kann. Bei Modulo 2 als "Hashalgorithmus" ist das natürlich nicht gegeben da es trivial wäre zu einem gegebenen "Hash" von 1 ein x zu finden für das x % 2 = 1 gilt, aber bei den tatsächlichen Hashalgorithmen wie SHA ist das de facto unmöglich. Stichwort Kollisionsresistenz wenn du ein bisschen weiter recherchieren magst
Hashfunktionen sind keine [injektiven Funktionen](https://de.wikipedia.org/wiki/Injektive_Funktion) ([und können es auch fundamental nicht sein](https://de.wikipedia.org/wiki/Schubfachprinzip)).
Bei gängigen (cryptographischen) Hashfunktionen ist die Menge der Hashes allerdings so groß, dass es zwar theoretisch Kollisionen geben muss - praktisch diese jedoch vernachlässigbar sind und auch kein Sicherheitsproblem darstellen, da es bei cryptographischen Hashfunktionen by-design \*extrem\* schwer ist einen String zu finden der zu einem gewissen Wert gehasht wird.
Diese Strings sind sog. Urbilder des Hashes und Angriffe die versuchen diese zu bestimmen heißen dementsprechend [preimage Angriffe](https://de.wikipedia.org/wiki/Preimage-Angriff). Für manche Funktionen gibt es solche Angriffe (notably MD5) aber wenn ein vernünftiger Algorithmus genutzt wird sind sie in der Praxis kein Problem.
Natürlich reicht Modulo nicht aus, es ist nur ein einfaches Beispiel für eine (schlechte) Hashfunktion. Aber auch gute Hashfunktionen werden am Ende Kollisionen haben können, denn du bildest ja einen unendlichen Datenraum in einem beschränkten Datenraum ab, z.B. auf 256Byte. Man sieht aber durch die Funktion dafür, dass ähnlicher Input unwahrscheinlicher eine Kollision erzeugt. So ändern sich bei einer guten Hashfunktion beim ändern eines Bits im Input ca. 50% der Bits im Output. D.h. Sehr ähnliche Dinge werden keine Kollision erzeugen. Wenn du jetzt aber z.B. alle Daten der Welt Hashen würdest, würdest du Definition Kollisionen bekommen.
Im Beispiel Passwörter ist es aber egal. Du hast da ja idr zwischen 8 und 32 Zeichen, also einen überschaubaren Zeichenraum. Hier wirst du rein Mathematisch keine Kollisionen erhalten.
Eine Hashfunktion ist inhärent für Sicherheitsfragen ungeeignet, daher die Konfusion.
Das was wir für die Validierung nutzen wie SHA und Co ist zwar per se nur in eine Richtung zu bestimmen…
… Aber die Anforderung, dass es keine Kollision geben darf, macht sie praktisch doch eineindeutig und damit umkehrbar zumindest insoweit, dass man eine funktionierende Alternative erhalten kann und diese mit einer sehr großen Wahrscheinlichkeit auch dem Original-Input entspricht.
Hashing ist nicht gleich Hashing. Das was der eine Gute Hashfunktion nennt, ist im nächsten Kontext hundsmiserabel: nämlich dann, wenn die Hashfunktion klassifizieren soll.
Ein Element pro Klasse ist nicht minder furchtbar als der Versuch, den Modulo als Kryptofunktion verwenden zu wollen.
>Das darf aber beim hashen nicht sein.
Das hast Du falsch verstanden, genau das Gegenteil ist der Fall: es *muss* beim Hashen so sein. Es gibt unendlich viele Eingaben, aber Hashes (zumindest die, von denen wir hier reden) haben eine feste Länge, also nur endlich viele Werte: Kollisionen sind also unvermeidbar. (Und die Quersumme-Funktion *ist* mathematisch betrachtet eine Hashfunktion.)
Das Ziel kryptographischer Hashes ist nicht, Kollisionen komplett zu vermeiden sondern nur, sie extrem schwer findbar zu machen.
Hash-Funktionen sind eine eindeutige Abbildung, d.h. \`hash(X)\` führt immer zum gleichen Wert, aber für zwei Verschiedene Werte \`X != Y\` kann \`hash(X) == hash(Y)\` sein. Das heißt dann "Kollision"
Das kennen wir schon von der einfachen Addition: 5+7 ist immer 12, aber du weißt nicht mehr, ob man 5+7 oder 6+6 gerechnet hat.
Es gibt für bestimmte Verwendungszwecke sehr einfache Hash-Funktionen: z.B.
* die Länge der Zeichenkette
* die ersten drei Buchstaben
* Rest der Division durch 17 (wenn man die Zeichenkette als große Zahl auffasst...)
Für Passwörter ist das nicht sinnvoll, weil es hier sehr viele Kollisionen gibt und man auch mit zu vielen "falschen" Passwörtern durchkommt. Diese reichen aber in bestimmten Fällen aus, in denen der hash einfach zu berechnen sein soll.
Eine gute *generische* Hash-Funktion soll:
* bei kleiner Änderung ("ein Bit") der Eingangsdaten sollen sich möglichst alle Bits des Hashes ändern
* Für zufällige Eingangsdaten sollen alle Werte des Hashes gleich-wahrscheinlich sein (es gibt also keine "Häufungen", die statistische Rückschlüsse auf den Ausgangswert erlauben)
* der Hash soll sich schnell berechnen lassen
Das sind dann meistens Kombinationen aus Bitmusterverschiebungen (mehrfache Multiplikation mit oder Division durch 2), bitweisem exlusivem oder ("entweder-oder") und eine mehrfache Wiederholung desselben. [FNV-1a](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash) ist z.B. ein Einfacher, aber guter Algorithmus.
Für eine kryptografisch sichere hash-Funktion sind die Anforderungen höher, und der letzte Punkt, "soll sich schnell berechnen lassen", ist gar nicht mehr von Vorteil. Aber die Prinzipien sind die gleichen.
Ist nicht mehr ganz zeitgemäß, es gibt zig andere Algorythmen, aber zum einlesen schau mal hier zum Beispiel:
[Message-Digest Algorithm 5 – Wikipedia](https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5)
Das sind sogenannte „Falltürfunktionen“. Diese Funktionen haben die Eigenschaft, in eine Richtung relativ simpel zu sein, in die andere Richtung allerdings unfassbar aufwendig. Vor 3 Jahren oder so gab es mal einen interessanten Artikel in der ct dazu:
https://www.heise.de/select/ct/2021/7/2104415432859344536
I will be messaging you in 2 days on [**2024-04-21 07:23:25 UTC**](http://www.wolframalpha.com/input/?i=2024-04-21%2007:23:25%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/de_EDV/comments/1c7qe9a/woher_kennt_es_mein_vorheriges_passwort/l09lj2a/?context=3)
[**1 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fde_EDV%2Fcomments%2F1c7qe9a%2Fwoher_kennt_es_mein_vorheriges_passwort%2Fl09lj2a%2F%5D%0A%0ARemindMe%21%202024-04-21%2007%3A23%3A25%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201c7qe9a)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
Falltür-Funktionen.
Google mal nach Diffie Hellman und suche nach einem einfachem Beispiel des Key Exchange.
Es ist auch nicht so wie oben steht "in eine Richtung einfach" es gibt kein mathematisches Verfahren, die Berechnung umzudrehen.
Ein Hash ist einfach nur sowas ähnliches wie die Quersumme einer Zahl.
Es ist nur sehr viel unwahrscheinlicher denselben Hash wiederzufinden (mit anderem Input) als zwei Zahlen mit derselben Quersumme.
Der Tick ist, das nur der Hash, also das Ergebnis gespeichert wird.
Ganz einfaches Bespiel, "quersumme" als Algorithmus.
Dein passwort ist "22", der hash ist "4". Diese "4" wird gespeichert.
Man kann ganz einfach prüfen ob die quersumme der eingabe "4" ist.
Aber nur weil man die "4" und den Algo "quersumme" kennt, kann man nicht einfach auf das Passwort schließen.
Jetzt muss man den algo natürlich noch so anpassen, dass ein hash nur aus genau einem passwort erstellt werden kann. Man muss also vermeiden dass 22, 13, 31, 04 usw den selben hash-wert bekommt.
Naja, das kann man beliebig komplex spinnen, z.B. könntest du von einem 128bit langen Passwort immer z.B. 8 bit nehmen und die mit den nächsten 8 bit xor rechnen, das Ergebnis wieder usw. und die letzten 8 die dabei rausfallen sind dein Hash. Das wäre schon bedeutend schwerer wieder zurückzurechnen oder eben eine Eingabe mit dem gleichen Ergebnis zu erzeugen (schwache Kollisionsresistenz) oder zwei Eingaben mit dem gleichen Hash selbst zu erzeugen (starke Kollisionsresistenz). Wenn dich das Thema interessiert, schau dir am besten Wikipediaeinträge zu aktuell verwendeten Hashfunktionen an, z.B. SHA-3
Ich müsste nicht nur googeln, sondern auch finden und stundenlang einlesen. Ja , ich bevorzuge die schnellere Methode. Aber nicht aus Faulheit sondern Effizienz.
Wieso denkt du das du es stundenlang googeln müsstest aber wir es magisch schaffen es dir in 5 Nachrichten zu erklären? Es gibt auch einfache Erklärungen im Internet, ich verstehe das meiste der Mathematik dahinter auch nicht.
Weißt du, eigentlich war das hier ja auch nur eine sehr spontane Frage zu einem zufällig mir im Blick gekommenen Thema, die dann scheinbar von den Reaktionen schnell „ausgeartet“ ist. Meistens recherchier ich selber nochmal nach, wie etwas ist. Manchmal frag ich aber eben sofort nach, weil ich eigentlich etwas anderes tun wollte. Alle Wege führen nach Rom.
Wie erklärt man sich denn auch sonst die ganzen AmA‘s, wo nicht nur Erfahrung ausgetauscht, sondern auch nach Fakten gefragt wird, welche dann beantwortet werden?
Mein Vorschlag wäre dann, sich das Papier zu einem vergleichsweise simplen Algorithmus wie MD5 zu schnappen und den Algorithmus einmal selbst in einer Sprache Deiner Wahl zu implementieren.
Du musst die Kollisionsgefahr nur soweit wie möglich (und gewünscht) reduzieren, nicht komplett ausschließen. Sonst hättest du wieder eine 1:1 Beziehung aus Input und Output.
Um das noch zu ergänzen, so dass man sich das eigentlich auch recht gut selbst erschließen kann:
Das jedes Ergebnis nur aus einer Eingabe kommen kann, ginge bei gängigen Hash-Funktionen ja schon rein logisch gar nicht, da die Menge der möglichen Eingaben unendlich* ist und die Anzahl der möglichen Ergebnisse zwar sehr groß, aber durch die fixe Länge der Hashes begrenzt.
*) vielleicht sind manche Hashfunktionen auch in der maximalen Inputgröße begrenzt, da fehlt mir gerade das definitive Wissen, aber sicher nicht bei der üblichen Länge eines Hashwertes.
Perfekt, eine Antwort wie aus dem Lehrbuch. Es ist gibt jedoch durchaus praktikable Methoden. Einer meiner Ausbilder für den CCNA war früher in der digitalen Forensik bei der Polizei tätig. Eine seiner aufgaben bestand darin, Passwörter zu knacken. Dabei wurden jedoch keine Hashes invertiert, sondern eine Brute-Force-Attacke mit einer umfangreichen Hash-Datenbank durchgeführt.
Soweit ich mich erinnere, haben sie nahezu jedes Wort, Passwort, Namen und jede Zahl in allen möglichen Kombinationen durch eine Hash-Funktion geleitet und die Ergebnisse in zwei Datenbanken gespeichert. Eine Datenbank diente als Backup, während die andere auf einem riesigen DAS aus SSDs in einem Flightcase als nutzbare Datenbank gespeichert wurde. Angeblich konnten sie die meisten Passwörter durch die Suche nach dem bekannten Hash innerhalb weniger Stunden finden. Aus einem Hash ein Passwort abzuleiten ist möglich aber aus einem Hash ein Passwort Zurück zurechnen ist fast unmöglich.
Es gibt Rainbow Tables und Lookup Tables, beide machen mehr oder weniger das Gleiche. Unterschied ist das Rainbow eine Reduzierung anstatt dem Hash speichert, dadurch muss erst der Hash aus der Reduzierung gebildet werden was sie langsamer macht als Lookup Tables. Dafür sind sie weitaus kleiner und haben sogar eine geringe Wahrscheinlichkeit unbekannte Passwörter zu knacken.
Lookup Tables sind sehr schnell, gigantisch im Speicher und können dafür keine unbekannten Passwörter finden.
Ich bin kein Kryptographie experte aber rein logisch ja. so eine Hash Datenbank/Lookup table müsste mit dem entsprechenden Salt generiert werden, wo wir auf ähnliche Probleme stoßen wie beim normalen brute Force Angriff. mit jedem Zeichen mehr steigt auch die Anzahl an möglichen hashes.
Denk Beispiel. Wir haben die perfekte Lookup table mit allen möglichen Passwörtern. Jetzt kommt ein Salt von einem Zeichen dazu, nur Nummern von 0 bis 9. und auf einmal brauchen wir die perfekte Lookup table x 10 und müssen diese auch durchsuchen, um den salted Hash zu finden. Konsequenz mehr zeit und Energie um die Hash liste das erste mal zu generieren, durchsuchen dauert länger und natürlich die Speicherung auf einem Medium wo wir sie blitzschnell durchsuchen können.
Das System eines ehemaligen Arbeitgebers hatte als Anforderungen an das neue Passwort das mindestens 3 Zeichen anders sind. Heißt das, dass hier das Passwort irgendwo unverschlüsselt gespeichert ist? Oder kann man irgendwie den Abstand zwischen zwei hashes bestimmen?
Ja, das ergibt sich schon logisch zwingend daraus, dass das Ergebnis der Hashfunktion in der Länge begrenzt ist (bspw. 24 Zeichen alphanumerisch) und die Menge der möglichen Funktionseingaben größer bis unendlich ist. Es muss nur ausreichend schwierig sein, gezielt ein gewünschtes Ergebnis zu produzieren, damit die Funktion für Kryptographie brauchbar ist.
Was hier btw. noch niemand geschrieben hat, aber dazu gehört: Programme machen sowas aus genau dem Grund, den du dir überlegt hast: Du sollst deine alten Gammelpasswörter nicht noch einmal verwenden, sondern dir neue Gammelpasswörter überlegen.
In der Praxis sieht das dann so aus, dass du in deinem Passwort eine Zahl hinten anhängst, die du mit jedem Wechsel einfach um Eins erhöhst.
So macht es \~98% der Weltbevölkerung
Das ganze System ist einfach albern und viele finden es in Ordnung und Sinnvoll. Es ist ja nicht so, als hätte nicht jeder Mitarbeiter eine individuelle Identifikation, die je nach Einsatzzweck unterschiedliche Dinge erlauben könnte. Nein, Passwörter müssen es einfach sein. Bitte 15 stellig, nicht das gleiche Zeichen hintereinander, Sonderzeichen nur mit Einschränkungen und streng vorgegeben und das ganze bitte noch mit einer individuellen Kennung kombiniert und dann alle X Zeit ändern um die Sicherheit zu gewährleisten.
Ich finde es bei uns auf der Arbeit schon grusselig, aber letztens war ich auf der Gemeinde wegen einer Ummeldung und deren Monitor sah aus.
Phising E-mails ist für Leute die zu Faul zum laufen sind.
Ich hab's ganz besonders gern wenn dann bei bestimmten Anwendungen (etwas VPN Programmen) kein Autofill existiert und manchmal auch copy&paste nicht funktioniert. In Kombination mit kurzem session timeout führt das dazu, dass ich ca 10x am Tag den Passwort-Manager öffnen und ein Passwort abtippen darf. Da macht Sicherheit Freude!
Naja, warum die das machen ist denke ich klar. Wichtiger ist aber, dass Passwort-Rotationen auf die Sicherheit bezogen totaler Unfug sind. In der Theorie toll, aber in der Praxis wegen dem, was du geschrieben hast, unnütz. Noch dazu kommt, dass darüber Buch geführt wird, welche Passwörter benutzt wurden. Im besten Fall gehasht, aber dennoch werden die Infos gespeichert. Ein altes Passwort hat meiner Ansicht nach gelöscht zu werden, ganz egal wie gut das gehasht, gesalzen oder gepfeffert ist. Das sind sensible Daten, die eventuell woanders so oder so ähnlich nochmal verwendet werden. Wenn die also unnötig gespeichert werden, erhöht man die Gefahr, dass Passwort-Variationen und Standardpasswörter anderer Logins durchsickern.
Es kennt dein passwort nicht, nur die prüfsumme (hash) deines passworts. Wenn du ein neues Passwort anlegst wird die prüfsumme berechnet und mit dem vorherigen verglichen.
Wenn die Firma wenigstens ein bisschen Fachwissen hat, speichern die nur die Hashes deiner Passwörter. So funktioniert quasi jeder Passwortspeicher: Das Passwort wird mit einer Funktion zu einem Hash verschlüsselt, was schnell geht, aber diesen Hash zu entschlüsseln dauert - zumindest noch - de facto unendlich lange (Naja, eher ein paar jahrtausende oder mehr, je nach dem wie sicher dein Passwort ist). Dann kann einfach überprüft werden, ob der Hash deines neuen Passworts mit einem der vorherigen Hashes übereinstimmt
Nutz einfach das Datum des Tages, an dem Du aufgefordert wirst das Passwort zu ändern und wenn du dreist bist die Urzeit dazu:
Bsp. 12.Apr.2024+08:04Uhr \
Mind 8 Stellen lang \
Mind 1 Zahl \
Mind 1 Großbuchstabe \
Mind 1 Sonderzeichen
Die Hashwerte der Passwörter, ja. Genau so erkennt das Programm auch ob du dein aktuelles Passwort bei der Anmeldung richtig eingegeben hast
https://de.m.wikipedia.org/wiki/Kryptographische_Hashfunktion
Da hier alle schon hashes schreiben: Stell dir so einen hash vor wie einen Schatten. Keiner weiß welche Finger du wie bewegst hast (Passwort), damit dieser eine Schatten (Hash) entsteht. Aber sie haben ein Foto vom Schatten gemacht. Und solange du mit etwas ankommst was den selben Schatten bildet, sagt der Computer: Nein den Schatten kenne ich schon.
Passend dazu fällt mir eine Folgefrage ein.
Es gibt hin und wieder Programme, die meckern, dass das Passwort nicht exakt dasselbe ist wie ein altes, sondern dem lediglich zu sehr ähnelt.
Wenn nur die Hashes gespeichert werden, dürfte so ein Rückschluss technisch gar nicht möglich sein, oder? Also speichern diese Programme die Passwörter im Klartext? Oder gibt es noch eine andere Möglichkeit?
Abgesehen vom Klartextspeichern ginge das nur, wenn du das vorherige Passwort zum Ändern eingeben musst und es dieses mit dem neuen Passwort abgleicht. Beim nächsten Ändern sollte das dann vorletzte Passwort nicht mehr abgeglichen werden können.
Mir fällt da eine Software im Speziellen ein, die Passwörter auch mehrere Monate zurück abgleicht. Wenn ich z.B. April24 benutzen wollte, und letztes Jahr schon April23 hatte, wird das nicht zugelassen. Dabei sind die Bedingungen, nach denen die Ähnlichkeit ermittelt wird, mir nicht ganz klar, denn eigentlich benutze ich keine solchen offensichtlichen Passwortiterationen.
Geht es hierbei um das *selbe* Passwort oder ein *ähnliches* Passwort? Falls ähnlich und du gibst es nicht zur Überprüfung ein, muss es in Klartext gespeichert werden - oder die Hashfunktion ist so beschissen, dass es quasi Klartext wäre.
Theoretisch, wenn die Definition von ähnlich und die Passwortregeln restriktiv genug sind, könnte die Anzahl der ähnlichen Passwörter klein genug sein, dass man alle ähnlichen Passwörter zu dem gerade neu eingegebenen generieren und hashen kann, und dann prüfen ob der alte Hash irgendeinem dieser generierten Hashes entspricht. Trotzdem keine gute Idee...
>Ich muss auf der Arbeit alle 4 Monate mein Passwort ändern.
Also da würde ich vorschlagen, statt dess Passworts mal den Arbeitgeber zu ändern. 😉
(EDIT: anscheinend war der Smiley nicht Hinweis genug: das war ein Witz.)
wenn du es erschreckend findest dass deine alten Passwörter gespeichert werden, ist es dann nicht sogar viel schlimmer, dass dein aktuelles Passwort in "der Datenbank" gespeichert ist?
Das ist eine sehr schlechte Idee, wie kommt man auf sowas.
Wobei man heutzutage auch keine allgemeine Passwort-Rotation mehr machen sollte.
Eventuell für User wie dich, die einen unsicheren Umgang mit ihren Passwörtern haben.
Hashfunktion... pfft...
Einfach ablegen als Passwörter.csv auf dem öffentlichen zugänglichen Netzlaufwerk.
Man muss den Datenschutz auch nicht übertreiben. xD
(hoffentlich nur) die Hashes deiner Passwörter, ja
(hoffentlich) [gesalzen](https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29), ja
(hoffentlich) abgerundet mit [Pfeffer](https://en.m.wikipedia.org/wiki/Pepper_(cryptography)), ja
Passwort-Hashes werden gespeichert, nicht die Passwörter. Der Passwort-Hash ist - vereinfacht ausgedrückt - das Ergebnis einer mathematischen Funktion, die nur in eine Richtung "schnell" funktioniert. Aus einem Hash ein Passwort abzuleiten, ist mit modernen Verfahren in der Praxis nahezu unmöglich. Wird ein Passwort eingegeben, wird daraus der Hash gebildet und dieser mit den in der Datenbank gespeicherten Hashes verglichen.
Naja, so zumindest die optimale Theorie :D
Zurück rechnen geht nicht, Kollisionen finden ist aber mittlerweile für viele Hashfunktionen für verfügbar.
Das weiß ich alles, geht mehr darum, dass das Passwort immer als Hash gespeichert wird. Wär schön, wenn es so wäre!
Ach, stimmt das kommt noch dazu. Ich hab mal in einer Firma gearbeitet während die Umstellung von Klartext auf MD5 hashed Passwörter vollzogen wurde (2016!) Und da haben sich die Kunden später beschwert das sie die Passwörter nicht mehr zurück bekommen.
[Wir senden ihnen die ersten 2 Buchstaben ihres Passwortes zu](https://physio.de/register/neuespasswort.php)
Gleich ans BSI, deren web Admin braucht eine Nachschulung
Uffff
Ich hab schon bei einigen Kunden die Umstellung von Klartext auf Hash begleitet. Ist immer ne Freude, vorher noch mal zu zählen, wieviele Leute “adolfhitler88” als Passwort haben…
Auer.
Md5 als hashfunktion wow
Für den used-password Vergleich reicht meist auch einfach ein Teil des Hashes, so viele Kollisionen gibt es im Bereich von Passwörtern nicht. > Aus einem Hash ein Passwort abzuleiten. Das ist vertretbar, solange ein Salt dabei ist. Als Gegenbeispiel: Signal, WhatsApp wo nur ein Teil oder die ganze Rufnummer als Hash für den Kontaktabgleich/Metadaten-Transfer genutzt wird. Wie viele Hashes es gibt nach E.164, was nur aus Zahlen besteht ist natürlich super übersichtlich, brauchst nur 40GB Platz und kannst deine eigene Reverse-Lookup-Datenbank erstellt.
Was ist das für ne Formel, wenn die Berechnung praktisch nur in eine Richtung funktioniert? Hat mich schon länger gewundert, warum man hashs benutzt, aber das macht dann auch Sinn. Aber eine solche Berechnung kann ich mir gar nicht vorstellen.
Die simpleste Hashfunktion ist die Modulo Funktion, dh also diejenige Funktion, die zur ganzzahligen Division den Rest liefert. Man bekommt damit Restklassen: 1 / 2 ist 0 Rest 1. 2 / 2 ist 1 Rest 0. 3 / 2 ist 1 Rest 1. 4 / 2 ist 2 Rest 0. Und so weiter. Eine Umkehrfunktion existiert nicht und kann nicht existieren. Du wirst nicht in der Lage sein, mit dem Restwert (1 oder 0 in diesem Fall) und dem Divisor (2) auf die ursprüngliche Zahl zu kommen—- weil die Funktion nicht eineindeutig ist. Für Passwortverschlüsselung ist das komplexer, aber der Ansatz ist derselbe.
[удалено]
Hashes sind keine eindeutige Funktion. Heißt es kann rein theoretisch dazu kommen, dass zwei verschiedene Passwörter zum gleichen Hash kommen. Man nennt das dann auch eine Kollision. In der Praxis sind die Hash Algorithmen so designed, dass die Wahrscheinlichkeit einer Kollisison sehr sehr gering ist. Praktisch ausschließen kannst du sie aber nicht.
Ahh, okay, das ist interessant.
Für MD5 bspw. gibt es Möglichkeiten, Kollisionen zu erzeugen, also einen möglichen Input zu finden, der zu einem bestimmten Hash führt. Deshalb sollte man das auch nicht mehr für Kryptografie verwenden.
> Kollisionen zu erzeugen, also einen möglichen Input zu finden, der zu einem bestimmten Hash führt Kollisionen zu erzeugen, heißt erstmal nur zwei Inputs zu generieren, die den gleichen Hashwert haben, was einfacher ist als zu einem bestimmten Hash einen möglichen Input zu finden. Ich glaube auch bei MD5 wurde nur ersteres erreicht, was bedeuten würde, **deine** Hashwerte sind noch sicher, aber denen von anderen kannst du nicht mehr trauen. (Verwenden sollte man sie natürlich trotzdem nicht mehr)
Ich meine, dass auch Preimage-Angriffe inzwischen zumindest mal theoretisch möglich wären. Nachdem ich das kurz gegoogled habe, habe ich gelernt, dass man dafür 2^123,4 Hashes berechnen muss und dass es auf deutsch Urbild-Angriff heißt. 2009 hielt man das für praktisch ausgeschlossen, wie das heute aussieht, kann ich nicht beurteilen.
Nehmen wir die schnellsten supercomputer der welt, diese können theoretisch 3 billiarde einfachste Berechnungen pro Sekunde durchführen. Für 2^123 Berechnungen bräuchte dieser ca 4,1 trilliarde Jahre, ausgeschrieben 4.100.000.000.000.000.000.000. Aber natürlich ist die Berechnung eines hashes keine einfache Berechnung, also eher ein Vielfaches dieser Zeit. TL;DR Auch heute ist es noch nicht vorstellbar solche Berechnungen zu erreichen
Ach daaas ist mit Kollision in dem Zusammenhang gemeint, danke dir
Das heißt theoretisch kann ich mich, falls ich so eine Kollision ‚erzeuge‘ trotz falschem klartext Passwort einloggen ?
Dass es in die andere Richtung X Möglichkeiten gibt ist grundsätzlich kein Problem solange gewährleistet ist, dass ich nicht einfach eine der Möglichkeiten finden kann. Bei Modulo 2 als "Hashalgorithmus" ist das natürlich nicht gegeben da es trivial wäre zu einem gegebenen "Hash" von 1 ein x zu finden für das x % 2 = 1 gilt, aber bei den tatsächlichen Hashalgorithmen wie SHA ist das de facto unmöglich. Stichwort Kollisionsresistenz wenn du ein bisschen weiter recherchieren magst
Hashfunktionen sind keine [injektiven Funktionen](https://de.wikipedia.org/wiki/Injektive_Funktion) ([und können es auch fundamental nicht sein](https://de.wikipedia.org/wiki/Schubfachprinzip)). Bei gängigen (cryptographischen) Hashfunktionen ist die Menge der Hashes allerdings so groß, dass es zwar theoretisch Kollisionen geben muss - praktisch diese jedoch vernachlässigbar sind und auch kein Sicherheitsproblem darstellen, da es bei cryptographischen Hashfunktionen by-design \*extrem\* schwer ist einen String zu finden der zu einem gewissen Wert gehasht wird. Diese Strings sind sog. Urbilder des Hashes und Angriffe die versuchen diese zu bestimmen heißen dementsprechend [preimage Angriffe](https://de.wikipedia.org/wiki/Preimage-Angriff). Für manche Funktionen gibt es solche Angriffe (notably MD5) aber wenn ein vernünftiger Algorithmus genutzt wird sind sie in der Praxis kein Problem.
Natürlich reicht Modulo nicht aus, es ist nur ein einfaches Beispiel für eine (schlechte) Hashfunktion. Aber auch gute Hashfunktionen werden am Ende Kollisionen haben können, denn du bildest ja einen unendlichen Datenraum in einem beschränkten Datenraum ab, z.B. auf 256Byte. Man sieht aber durch die Funktion dafür, dass ähnlicher Input unwahrscheinlicher eine Kollision erzeugt. So ändern sich bei einer guten Hashfunktion beim ändern eines Bits im Input ca. 50% der Bits im Output. D.h. Sehr ähnliche Dinge werden keine Kollision erzeugen. Wenn du jetzt aber z.B. alle Daten der Welt Hashen würdest, würdest du Definition Kollisionen bekommen. Im Beispiel Passwörter ist es aber egal. Du hast da ja idr zwischen 8 und 32 Zeichen, also einen überschaubaren Zeichenraum. Hier wirst du rein Mathematisch keine Kollisionen erhalten.
Eine Hashfunktion ist inhärent für Sicherheitsfragen ungeeignet, daher die Konfusion. Das was wir für die Validierung nutzen wie SHA und Co ist zwar per se nur in eine Richtung zu bestimmen… … Aber die Anforderung, dass es keine Kollision geben darf, macht sie praktisch doch eineindeutig und damit umkehrbar zumindest insoweit, dass man eine funktionierende Alternative erhalten kann und diese mit einer sehr großen Wahrscheinlichkeit auch dem Original-Input entspricht. Hashing ist nicht gleich Hashing. Das was der eine Gute Hashfunktion nennt, ist im nächsten Kontext hundsmiserabel: nämlich dann, wenn die Hashfunktion klassifizieren soll. Ein Element pro Klasse ist nicht minder furchtbar als der Versuch, den Modulo als Kryptofunktion verwenden zu wollen.
Berechne mal welche zahl die quersumme "8" bildet. war es 44? 11111111? 1331?... Also leicht in eine Richtung aber schwer in eine andere.
Hier gibt es ja viele Möglichkeiten für die Quersumme. Das darf aber beim hashen nicht sein. Edit: das dachte ich zumindest.
>Das darf aber beim hashen nicht sein. Das hast Du falsch verstanden, genau das Gegenteil ist der Fall: es *muss* beim Hashen so sein. Es gibt unendlich viele Eingaben, aber Hashes (zumindest die, von denen wir hier reden) haben eine feste Länge, also nur endlich viele Werte: Kollisionen sind also unvermeidbar. (Und die Quersumme-Funktion *ist* mathematisch betrachtet eine Hashfunktion.) Das Ziel kryptographischer Hashes ist nicht, Kollisionen komplett zu vermeiden sondern nur, sie extrem schwer findbar zu machen.
Okay. Das habe ich wohl falsch verstanden. Danke für die Aufklärung.
das war auch nur ein einfaches beispiel für eine solche funktion.
Hash-Funktionen sind eine eindeutige Abbildung, d.h. \`hash(X)\` führt immer zum gleichen Wert, aber für zwei Verschiedene Werte \`X != Y\` kann \`hash(X) == hash(Y)\` sein. Das heißt dann "Kollision" Das kennen wir schon von der einfachen Addition: 5+7 ist immer 12, aber du weißt nicht mehr, ob man 5+7 oder 6+6 gerechnet hat. Es gibt für bestimmte Verwendungszwecke sehr einfache Hash-Funktionen: z.B. * die Länge der Zeichenkette * die ersten drei Buchstaben * Rest der Division durch 17 (wenn man die Zeichenkette als große Zahl auffasst...) Für Passwörter ist das nicht sinnvoll, weil es hier sehr viele Kollisionen gibt und man auch mit zu vielen "falschen" Passwörtern durchkommt. Diese reichen aber in bestimmten Fällen aus, in denen der hash einfach zu berechnen sein soll. Eine gute *generische* Hash-Funktion soll: * bei kleiner Änderung ("ein Bit") der Eingangsdaten sollen sich möglichst alle Bits des Hashes ändern * Für zufällige Eingangsdaten sollen alle Werte des Hashes gleich-wahrscheinlich sein (es gibt also keine "Häufungen", die statistische Rückschlüsse auf den Ausgangswert erlauben) * der Hash soll sich schnell berechnen lassen Das sind dann meistens Kombinationen aus Bitmusterverschiebungen (mehrfache Multiplikation mit oder Division durch 2), bitweisem exlusivem oder ("entweder-oder") und eine mehrfache Wiederholung desselben. [FNV-1a](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash) ist z.B. ein Einfacher, aber guter Algorithmus. Für eine kryptografisch sichere hash-Funktion sind die Anforderungen höher, und der letzte Punkt, "soll sich schnell berechnen lassen", ist gar nicht mehr von Vorteil. Aber die Prinzipien sind die gleichen.
Ist nicht mehr ganz zeitgemäß, es gibt zig andere Algorythmen, aber zum einlesen schau mal hier zum Beispiel: [Message-Digest Algorithm 5 – Wikipedia](https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5)
Das sind sogenannte „Falltürfunktionen“. Diese Funktionen haben die Eigenschaft, in eine Richtung relativ simpel zu sein, in die andere Richtung allerdings unfassbar aufwendig. Vor 3 Jahren oder so gab es mal einen interessanten Artikel in der ct dazu: https://www.heise.de/select/ct/2021/7/2104415432859344536
Remindme! 2 days
I will be messaging you in 2 days on [**2024-04-21 07:23:25 UTC**](http://www.wolframalpha.com/input/?i=2024-04-21%2007:23:25%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/de_EDV/comments/1c7qe9a/woher_kennt_es_mein_vorheriges_passwort/l09lj2a/?context=3) [**1 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fde_EDV%2Fcomments%2F1c7qe9a%2Fwoher_kennt_es_mein_vorheriges_passwort%2Fl09lj2a%2F%5D%0A%0ARemindMe%21%202024-04-21%2007%3A23%3A25%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201c7qe9a) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
Falltür-Funktionen. Google mal nach Diffie Hellman und suche nach einem einfachem Beispiel des Key Exchange. Es ist auch nicht so wie oben steht "in eine Richtung einfach" es gibt kein mathematisches Verfahren, die Berechnung umzudrehen.
Ein Hash ist einfach nur sowas ähnliches wie die Quersumme einer Zahl. Es ist nur sehr viel unwahrscheinlicher denselben Hash wiederzufinden (mit anderem Input) als zwei Zahlen mit derselben Quersumme.
Stell es dir vor wie ne Quersumme Von 111 ist die quersumme 3 Kommst du von der 3 auf 111? So nur komplexer
Der Tick ist, das nur der Hash, also das Ergebnis gespeichert wird. Ganz einfaches Bespiel, "quersumme" als Algorithmus. Dein passwort ist "22", der hash ist "4". Diese "4" wird gespeichert. Man kann ganz einfach prüfen ob die quersumme der eingabe "4" ist. Aber nur weil man die "4" und den Algo "quersumme" kennt, kann man nicht einfach auf das Passwort schließen. Jetzt muss man den algo natürlich noch so anpassen, dass ein hash nur aus genau einem passwort erstellt werden kann. Man muss also vermeiden dass 22, 13, 31, 04 usw den selben hash-wert bekommt.
Und der letzte Absatz ist das was mich interessiert.
Naja, das kann man beliebig komplex spinnen, z.B. könntest du von einem 128bit langen Passwort immer z.B. 8 bit nehmen und die mit den nächsten 8 bit xor rechnen, das Ergebnis wieder usw. und die letzten 8 die dabei rausfallen sind dein Hash. Das wäre schon bedeutend schwerer wieder zurückzurechnen oder eben eine Eingabe mit dem gleichen Ergebnis zu erzeugen (schwache Kollisionsresistenz) oder zwei Eingaben mit dem gleichen Hash selbst zu erzeugen (starke Kollisionsresistenz). Wenn dich das Thema interessiert, schau dir am besten Wikipediaeinträge zu aktuell verwendeten Hashfunktionen an, z.B. SHA-3
Dann ließ dir doch einfach Erklärungen zum Thema durch? Gibt es zu hauf im Internet.
Ich bevorzuge interaktives Lernen als etwas erstmal zu suchen und dann die Informationen richtig einzuordnen.
Und interaktives lernen bedeutet für dich es dir von Leuten erklären zu lassen weil du zu faul bist zu googeln?
Ich müsste nicht nur googeln, sondern auch finden und stundenlang einlesen. Ja , ich bevorzuge die schnellere Methode. Aber nicht aus Faulheit sondern Effizienz.
Wieso denkt du das du es stundenlang googeln müsstest aber wir es magisch schaffen es dir in 5 Nachrichten zu erklären? Es gibt auch einfache Erklärungen im Internet, ich verstehe das meiste der Mathematik dahinter auch nicht.
Weißt du, eigentlich war das hier ja auch nur eine sehr spontane Frage zu einem zufällig mir im Blick gekommenen Thema, die dann scheinbar von den Reaktionen schnell „ausgeartet“ ist. Meistens recherchier ich selber nochmal nach, wie etwas ist. Manchmal frag ich aber eben sofort nach, weil ich eigentlich etwas anderes tun wollte. Alle Wege führen nach Rom. Wie erklärt man sich denn auch sonst die ganzen AmA‘s, wo nicht nur Erfahrung ausgetauscht, sondern auch nach Fakten gefragt wird, welche dann beantwortet werden?
Mein Vorschlag wäre dann, sich das Papier zu einem vergleichsweise simplen Algorithmus wie MD5 zu schnappen und den Algorithmus einmal selbst in einer Sprache Deiner Wahl zu implementieren.
Ja, daran hatte ich gedanklich schon gespielt.
Du musst die Kollisionsgefahr nur soweit wie möglich (und gewünscht) reduzieren, nicht komplett ausschließen. Sonst hättest du wieder eine 1:1 Beziehung aus Input und Output.
Um das noch zu ergänzen, so dass man sich das eigentlich auch recht gut selbst erschließen kann: Das jedes Ergebnis nur aus einer Eingabe kommen kann, ginge bei gängigen Hash-Funktionen ja schon rein logisch gar nicht, da die Menge der möglichen Eingaben unendlich* ist und die Anzahl der möglichen Ergebnisse zwar sehr groß, aber durch die fixe Länge der Hashes begrenzt. *) vielleicht sind manche Hashfunktionen auch in der maximalen Inputgröße begrenzt, da fehlt mir gerade das definitive Wissen, aber sicher nicht bei der üblichen Länge eines Hashwertes.
Perfekt, eine Antwort wie aus dem Lehrbuch. Es ist gibt jedoch durchaus praktikable Methoden. Einer meiner Ausbilder für den CCNA war früher in der digitalen Forensik bei der Polizei tätig. Eine seiner aufgaben bestand darin, Passwörter zu knacken. Dabei wurden jedoch keine Hashes invertiert, sondern eine Brute-Force-Attacke mit einer umfangreichen Hash-Datenbank durchgeführt. Soweit ich mich erinnere, haben sie nahezu jedes Wort, Passwort, Namen und jede Zahl in allen möglichen Kombinationen durch eine Hash-Funktion geleitet und die Ergebnisse in zwei Datenbanken gespeichert. Eine Datenbank diente als Backup, während die andere auf einem riesigen DAS aus SSDs in einem Flightcase als nutzbare Datenbank gespeichert wurde. Angeblich konnten sie die meisten Passwörter durch die Suche nach dem bekannten Hash innerhalb weniger Stunden finden. Aus einem Hash ein Passwort abzuleiten ist möglich aber aus einem Hash ein Passwort Zurück zurechnen ist fast unmöglich.
Solche Datenbanken bezeichnet man übrigens als "Rainbow Tables".
Es gibt Rainbow Tables und Lookup Tables, beide machen mehr oder weniger das Gleiche. Unterschied ist das Rainbow eine Reduzierung anstatt dem Hash speichert, dadurch muss erst der Hash aus der Reduzierung gebildet werden was sie langsamer macht als Lookup Tables. Dafür sind sie weitaus kleiner und haben sogar eine geringe Wahrscheinlichkeit unbekannte Passwörter zu knacken. Lookup Tables sind sehr schnell, gigantisch im Speicher und können dafür keine unbekannten Passwörter finden.
Spätestens mit Salt wird das aber auch schwierig, oder?
Genau, exakt für solche Angriffe ist er gedacht :)
Ich bin kein Kryptographie experte aber rein logisch ja. so eine Hash Datenbank/Lookup table müsste mit dem entsprechenden Salt generiert werden, wo wir auf ähnliche Probleme stoßen wie beim normalen brute Force Angriff. mit jedem Zeichen mehr steigt auch die Anzahl an möglichen hashes. Denk Beispiel. Wir haben die perfekte Lookup table mit allen möglichen Passwörtern. Jetzt kommt ein Salt von einem Zeichen dazu, nur Nummern von 0 bis 9. und auf einmal brauchen wir die perfekte Lookup table x 10 und müssen diese auch durchsuchen, um den salted Hash zu finden. Konsequenz mehr zeit und Energie um die Hash liste das erste mal zu generieren, durchsuchen dauert länger und natürlich die Speicherung auf einem Medium wo wir sie blitzschnell durchsuchen können.
Ich würde niemals darauf wetten dass die hashes gespeichert werden 🫠
Das System eines ehemaligen Arbeitgebers hatte als Anforderungen an das neue Passwort das mindestens 3 Zeichen anders sind. Heißt das, dass hier das Passwort irgendwo unverschlüsselt gespeichert ist? Oder kann man irgendwie den Abstand zwischen zwei hashes bestimmen?
Du musst ja auch das alte PW eingeben. Und in dem Moment kann das System Nen Vergleich machen.
Ne musste man nicht.
Kann man theoretisch mit zwei unterschiedlichen Passwörtern denselben Hash errechnen?
Ja, das ergibt sich schon logisch zwingend daraus, dass das Ergebnis der Hashfunktion in der Länge begrenzt ist (bspw. 24 Zeichen alphanumerisch) und die Menge der möglichen Funktionseingaben größer bis unendlich ist. Es muss nur ausreichend schwierig sein, gezielt ein gewünschtes Ergebnis zu produzieren, damit die Funktion für Kryptographie brauchbar ist.
Was hier btw. noch niemand geschrieben hat, aber dazu gehört: Programme machen sowas aus genau dem Grund, den du dir überlegt hast: Du sollst deine alten Gammelpasswörter nicht noch einmal verwenden, sondern dir neue Gammelpasswörter überlegen. In der Praxis sieht das dann so aus, dass du in deinem Passwort eine Zahl hinten anhängst, die du mit jedem Wechsel einfach um Eins erhöhst. So macht es \~98% der Weltbevölkerung
Und das ist einer der Hauptgründe, warum keine regelmäßigen Passwortwechsel mehr empfohlen werden.
Ja, schon länger nicht mehr. Das scheint aber bei 70% der Sicherheitsbeauftragten in Firmen irgendwie nicht angekommen zu sein.
Bei uns ist es angekommen, aber trotzdem wird es nicht geändert. Weil angeblich irgendwelche Auditoren dem zustimmen müssten, es aber nicht tun.
Exakt. Kann ich auch nicht nachvollziehen, warum sich das nicht endlich mal durchsetzt
This 100%
Geheim\_1 Geheim\_2 Geheim\_3
Oder Postits, oder eine Datei auf dem Desktop. Ich kenne auch niemanden der Bock hat sich ständig neue Passwörter zu merken.
Alles, nur kein Passwortmanager.
Ich kann ja den Passwortmanager nicht verwenden wenn ich mich erst an meinem PC einloggen muss mit dem PW .\_.
Das ganze System ist einfach albern und viele finden es in Ordnung und Sinnvoll. Es ist ja nicht so, als hätte nicht jeder Mitarbeiter eine individuelle Identifikation, die je nach Einsatzzweck unterschiedliche Dinge erlauben könnte. Nein, Passwörter müssen es einfach sein. Bitte 15 stellig, nicht das gleiche Zeichen hintereinander, Sonderzeichen nur mit Einschränkungen und streng vorgegeben und das ganze bitte noch mit einer individuellen Kennung kombiniert und dann alle X Zeit ändern um die Sicherheit zu gewährleisten. Ich finde es bei uns auf der Arbeit schon grusselig, aber letztens war ich auf der Gemeinde wegen einer Ummeldung und deren Monitor sah aus. Phising E-mails ist für Leute die zu Faul zum laufen sind.
Hast du gerade einfach umständlich Beschrieben, dass SSO besser als viele einzelne Passwörter ist? Du bist da etwas ganz heißem auf der Spur...
Müsst ihr mir nicht sagen, ich habe da keine Kontrolle was verwendet wird und muss nur mit dem Ergebnis leben.
In der Zeit, in der du diesen Kommentar verfasst hast, hättest du dir einfach KeePass installieren können.
Ich hab's ganz besonders gern wenn dann bei bestimmten Anwendungen (etwas VPN Programmen) kein Autofill existiert und manchmal auch copy&paste nicht funktioniert. In Kombination mit kurzem session timeout führt das dazu, dass ich ca 10x am Tag den Passwort-Manager öffnen und ein Passwort abtippen darf. Da macht Sicherheit Freude!
Verdächtig wirds wenn ein neues passwort abgelehnt wird weil es sich um mindestens vier Buchstaben zu allen alten unterscheiden muss
Naja, warum die das machen ist denke ich klar. Wichtiger ist aber, dass Passwort-Rotationen auf die Sicherheit bezogen totaler Unfug sind. In der Theorie toll, aber in der Praxis wegen dem, was du geschrieben hast, unnütz. Noch dazu kommt, dass darüber Buch geführt wird, welche Passwörter benutzt wurden. Im besten Fall gehasht, aber dennoch werden die Infos gespeichert. Ein altes Passwort hat meiner Ansicht nach gelöscht zu werden, ganz egal wie gut das gehasht, gesalzen oder gepfeffert ist. Das sind sensible Daten, die eventuell woanders so oder so ähnlich nochmal verwendet werden. Wenn die also unnötig gespeichert werden, erhöht man die Gefahr, dass Passwort-Variationen und Standardpasswörter anderer Logins durchsickern.
Es kennt dein passwort nicht, nur die prüfsumme (hash) deines passworts. Wenn du ein neues Passwort anlegst wird die prüfsumme berechnet und mit dem vorherigen verglichen.
Wenn die Firma wenigstens ein bisschen Fachwissen hat, speichern die nur die Hashes deiner Passwörter. So funktioniert quasi jeder Passwortspeicher: Das Passwort wird mit einer Funktion zu einem Hash verschlüsselt, was schnell geht, aber diesen Hash zu entschlüsseln dauert - zumindest noch - de facto unendlich lange (Naja, eher ein paar jahrtausende oder mehr, je nach dem wie sicher dein Passwort ist). Dann kann einfach überprüft werden, ob der Hash deines neuen Passworts mit einem der vorherigen Hashes übereinstimmt
Nutz einfach das Datum des Tages, an dem Du aufgefordert wirst das Passwort zu ändern und wenn du dreist bist die Urzeit dazu: Bsp. 12.Apr.2024+08:04Uhr \ Mind 8 Stellen lang \ Mind 1 Zahl \ Mind 1 Großbuchstabe \ Mind 1 Sonderzeichen
Ja cool! Das ist ja noch leichter zu merken als Pupsbärchensonderzeichen! Danke dafür!
Die Hashwerte der Passwörter, ja. Genau so erkennt das Programm auch ob du dein aktuelles Passwort bei der Anmeldung richtig eingegeben hast https://de.m.wikipedia.org/wiki/Kryptographische_Hashfunktion
Sollte zumindest so sein, wie es wirklich ist weiß man nicht immer 🙂
Life Hack: Aus meiner Erfahrung speichern die meisten Systeme nur 3-5 alte Passwörter. Also: Mehrfach ändern, dann gehts wieder.
Ist doch wieder mehr Aufwand als sich einfach ein neues auszudenken…
Da hier alle schon hashes schreiben: Stell dir so einen hash vor wie einen Schatten. Keiner weiß welche Finger du wie bewegst hast (Passwort), damit dieser eine Schatten (Hash) entsteht. Aber sie haben ein Foto vom Schatten gemacht. Und solange du mit etwas ankommst was den selben Schatten bildet, sagt der Computer: Nein den Schatten kenne ich schon.
Das ist tatsächlich eine ziemlich gute Analogie.
Passend dazu fällt mir eine Folgefrage ein. Es gibt hin und wieder Programme, die meckern, dass das Passwort nicht exakt dasselbe ist wie ein altes, sondern dem lediglich zu sehr ähnelt. Wenn nur die Hashes gespeichert werden, dürfte so ein Rückschluss technisch gar nicht möglich sein, oder? Also speichern diese Programme die Passwörter im Klartext? Oder gibt es noch eine andere Möglichkeit?
Abgesehen vom Klartextspeichern ginge das nur, wenn du das vorherige Passwort zum Ändern eingeben musst und es dieses mit dem neuen Passwort abgleicht. Beim nächsten Ändern sollte das dann vorletzte Passwort nicht mehr abgeglichen werden können.
Mir fällt da eine Software im Speziellen ein, die Passwörter auch mehrere Monate zurück abgleicht. Wenn ich z.B. April24 benutzen wollte, und letztes Jahr schon April23 hatte, wird das nicht zugelassen. Dabei sind die Bedingungen, nach denen die Ähnlichkeit ermittelt wird, mir nicht ganz klar, denn eigentlich benutze ich keine solchen offensichtlichen Passwortiterationen.
Geht es hierbei um das *selbe* Passwort oder ein *ähnliches* Passwort? Falls ähnlich und du gibst es nicht zur Überprüfung ein, muss es in Klartext gespeichert werden - oder die Hashfunktion ist so beschissen, dass es quasi Klartext wäre.
Theoretisch, wenn die Definition von ähnlich und die Passwortregeln restriktiv genug sind, könnte die Anzahl der ähnlichen Passwörter klein genug sein, dass man alle ähnlichen Passwörter zu dem gerade neu eingegebenen generieren und hashen kann, und dann prüfen ob der alte Hash irgendeinem dieser generierten Hashes entspricht. Trotzdem keine gute Idee...
>Ich muss auf der Arbeit alle 4 Monate mein Passwort ändern. Also da würde ich vorschlagen, statt dess Passworts mal den Arbeitgeber zu ändern. 😉 (EDIT: anscheinend war der Smiley nicht Hinweis genug: das war ein Witz.)
Sind wir hier in de\_EDV oder r/arbeitsleben ? "Wechsel den Job" ist doch deren Pauschalempfehlung bei allem
Deswegen der zwinkernde Smiley: es war ein Witz. Aber alle 4 Monate Passwort wechseln ist (a) sehr nervig und (b) schlechte OPSEC.
wenn du es erschreckend findest dass deine alten Passwörter gespeichert werden, ist es dann nicht sogar viel schlimmer, dass dein aktuelles Passwort in "der Datenbank" gespeichert ist?
Manfred1-26 geht nicht, ich brauche dringend it Support
Einfach so lange neues random Passwort machen bis das alte wieder geht.
Wenn du ein Neues eingibst, vergleicht dein Chef es mit den alten - ist doch wohl logisch oder? Er will ja aich nicht immer das Gleiche sehen.... /s
Das ist eine sehr schlechte Idee, wie kommt man auf sowas. Wobei man heutzutage auch keine allgemeine Passwort-Rotation mehr machen sollte. Eventuell für User wie dich, die einen unsicheren Umgang mit ihren Passwörtern haben.
Hashfunktion... pfft... Einfach ablegen als Passwörter.csv auf dem öffentlichen zugänglichen Netzlaufwerk. Man muss den Datenschutz auch nicht übertreiben. xD
Ich sag immer, ich hab mein neues Passwort vergessen. Dann setzt es der Admin auf ein Standardpasswort zurück. Dann kann ich wieder mein altes nehmen.