1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Datenleck: Warum Knuddels seine…

Re: Filterfunktion auch ohne Klartext möglich

  1. Thema

Neues Thema Ansicht wechseln


  1. Filterfunktion auch ohne Klartext möglich

    Autor: das Keks 10.09.18 - 15:56

    Die Begründung, Passwörter im Klartext zu speichern, damit Benutzer diese nicht im Chat verschicken können, ist völlig unsinnig und wäre genau so mit gehashten Passwörtern möglich.

    Im Grund wird jedes geschriebene Wort mit dem Passwort abgeglichen um zu schauen ob es im Chat erwähnt wird.
    Und wie prüft man beim Login, ob das eigegebene Passwort dem gespeicherten und gehashten Passwort entspricht?
    Genau, man hasht die Eingabe auf die gleiche Weise und vergleicht die beiden Hashes.

    Also warum für die Filterfunktion nicht einfach die eingegebenen Wörter hashen und diese mit dem Passwort-Hash abgleichen?

  2. Re: Filterfunktion auch ohne Klartext...

    Autor: M.P. 10.09.18 - 16:02

    Nötige Rechenleistung?

  3. Re: Filterfunktion auch ohne Klartext...

    Autor: theonlyone 10.09.18 - 16:08

    Einfache Implementierung, es funktioniert und wird eingebaut.

    Wenn da keiner hinterfragt ob das Feature "Sicherheit" besitzt, dann hinterfragt das nach Wochen und Monaten Laufzeit auch keiner mehr.

  4. Re: Filterfunktion auch ohne Klartext...

    Autor: PHPGangsta 10.09.18 - 18:27

    Rechenleistung? Wohl eher nicht, eine CPU kann mehrere Milionen Hashes pro Sekunde (Mhash) errechnen. Hängt natürlich stark vom genutzten Hash-Algorithmus ab, aber den aller neuesten, besten, aufwändigen haben sie vermutlich nicht genutzt. Würde mich wundern wenn sie PBKDF2, scrypt oder bcrypt mit hohen Kostenfaktoren genutzt haben...

    Hier eine Liste, wie viele MHashes so eine CPU macht (natürlich nur ungefähr, hängt vom Algorithmus ab):
    https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison

    Da mal einen Text mit 10 oder 100 oder 1000 Wörtern zu hashen, ist wohl eher kein Problem, da stellt man noch einen weiteren Server dazu, und schon hat man die nötige Zusatzperformance im Cluster.

    Zur Not kann man das sogar im Client machen lassen, per Javascript im Browser des Users. Dann hat man exakt 0 Zusatzlast auf den Servern.

    Wenn man für diese Funktion die Klartextpasswörter in der Datenbank drin lässt, warum überhaupt Hashes in der Datenbank speichern? Man speichert doch die Hashes nur deshalb, um die Klartextpasswörter los zu werden...

    Ich bin vor Lachen vom Stuhlgefallen als ich den Artikel gelesen hab :-)

  5. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 20:34

    PHPGangsta schrieb:
    --------------------------------------------------------------------------------
    > Rechenleistung? Wohl eher nicht, eine CPU kann mehrere Milionen Hashes pro
    > Sekunde (Mhash) errechnen. Hängt natürlich stark vom genutzten
    > Hash-Algorithmus ab, aber den aller neuesten, besten, aufwändigen haben sie
    > vermutlich nicht genutzt. Würde mich wundern wenn sie PBKDF2, scrypt oder
    > bcrypt mit hohen Kostenfaktoren genutzt haben...
    >
    > Hier eine Liste, wie viele MHashes so eine CPU macht (natürlich nur
    > ungefähr, hängt vom Algorithmus ab):
    > en.bitcoin.it

    Hash-Funktionen kann man grob in zwei Kategorien unterteilen. Solche die möglichst performant sind, z.B. für Cache-Lookups, Suchen, etc... und solche die möglichst inperformant sind, für Sicherheitsanwendungen wie Passwörter.

    Was du vorschlägst ist die Verwendung eines explizit inperformanten Hashes (passwort) in einer Anwendung die typisch performante Hashes benötigt (Suche).
    Das ist unabhängig von der technischen Realisierbarkeit einfach völlig falsch...

    > Da mal einen Text mit 10 oder 100 oder 1000 Wörtern zu hashen, ist wohl
    > eher kein Problem, da stellt man noch einen weiteren Server dazu, und schon
    > hat man die nötige Zusatzperformance im Cluster.

    Für einen Text mit 100 Zeichen und einer maximal erlaubten Passwortlänge von 32 Zeichen musst du grob 3.200 Hashes erzeugen.
    Ich kann wirklich nicht abschätzen wie aufwändig das wäre. Fakt ist aber, du erzeugst Serverseitig eine zusätzliche Last im Bereich mehrerer Größenordnungen. Sowas möchte man normal nicht...
    Weitaus handhabbarer wird es, wenn du dir die Passwortlänge speicherst, dann musst du nur noch ~100 Hashes generieren.

    > Zur Not kann man das sogar im Client machen lassen, per Javascript im
    > Browser des Users. Dann hat man exakt 0 Zusatzlast auf den Servern.

    Aus Performance-Sicht die bessere Lösung. Der Server-Seitig verwendete Hash ist dann sogar irrelevant, wenn die Prüfung Client-seitig erfolgt. Der Client kann ja aus dem Passwort seinen eigenen Hash bilden und muss überhaupt nicht wissen was auf dem Server passiert (und umgekehrt).
    Der Client könnte dann also z.B. md5() verwenden, was recht performant wäre.
    Die Verwendung von md5 wäre hier nicht so kritisch. Es gibt ja keine Datei in der alle 1.8 Millionen Hashes stehen, sondern man kann pro angegriffenem Client dann nur einen Hash ergattern.
    Zu bemerken wäre hier nur, dass es generell oft einfacher ist, einen Client anzugreifen (XSS etc.) statt einen Server. Aber selbst wenn man eine wirklich fiese XSS Lücke findet, kann man maximal alle aktiven Nutzer angreifen und nicht alle.

    Es kann aber gute Grunde geben, warum eine Client-Seitige Prüfung nicht in Frage kommt.
    Client-seitig heisst immer, der Client macht es freiwillig und der Anbieter kann nicht erzwingen dass es passiert.
    Ich weiss nicht wie das bei Knuddels ist, aber wenn es z.B. beliebte Dritt-Clients für die Plattform gibt die der Anbieter nicht kontrollieren kann, hat er hier ein Problem. Wenn er diese unterstützen will, muss er es eben Server-Seitig lösen.

  6. Re: Filterfunktion auch ohne Klartext...

    Autor: starscream 10.09.18 - 16:04

    das Keks schrieb:
    --------------------------------------------------------------------------------
    > Also warum für die Filterfunktion nicht einfach die eingegebenen Wörter
    > hashen und diese mit dem Passwort-Hash abgleichen?
    Rechenleistung, schätze ich. Es ist ein Unterschied den Hash auf der einen Seite ausschließlich bei dem Einloggen zu generieren und auf der anderen Seite jede einzelne Nachricht nach KMP zu partitionieren und den Hashwert aus einzelnen Tokens zu generieren. Schlimmer noch: der Tokenizer kann die Semantik nicht unterscheiden und müsste daher für das zur Verfügung stehende Characterset jede mögliche Kombination der Zeichenkette hashen.

  7. Re: Filterfunktion auch ohne Klartext...

    Autor: Quantium40 10.09.18 - 16:50

    starscream schrieb:
    > Rechenleistung, schätze ich. Es ist ein Unterschied den Hash auf der einen
    > Seite ausschließlich bei dem Einloggen zu generieren und auf der anderen
    > Seite jede einzelne Nachricht nach KMP zu partitionieren und den Hashwert
    > aus einzelnen Tokens zu generieren. Schlimmer noch: der Tokenizer kann die
    > Semantik nicht unterscheiden und müsste daher für das zur Verfügung
    > stehende Characterset jede mögliche Kombination der Zeichenkette hashen.

    Es gibt durchaus Wege, den Großteil der Rechnerei so auf den Client zu verlagern, dass der Server nur noch in wenigen Fällen ein paar vorberechnete Hashes miteinander vergleichen muss.

  8. Re: Filterfunktion auch ohne Klartext möglich

    Autor: lear 10.09.18 - 17:09

    Noch besser: sofern die Passwortvergabe Dictionary Enträge ausschließt und/oder andere Vorgaben (länge, Sonderzeichen,…) macht, fällt die Prüfung für die allermeisten Token humaner Kommunikation aus - selbst Dummheiten wie "Wusel123" werden seltenst regulär auftreten.

    Die "Begründung" ist eine reine - und lächerliche - Schutzbehauptung. Der wahre Grund ist, daß die Qualifikation der Macher dieser "sozialen Plat[t]form" gerade mal bis zum "lustigen" Namen gereicht hat. Die Pseudobegründung unterstreicht das nochmal.
    Passwörter speichert man niemalsnicht im Klartext - aus keinem Grund. Wem das nicht klar ist, ist nicht zu ihrer Verwaltung befähigt. Punkt.

  9. Re: Filterfunktion auch ohne Klartext...

    Autor: Mephir 10.09.18 - 17:13

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Es gibt durchaus Wege, den Großteil der Rechnerei so auf den Client zu
    > verlagern, dass der Server nur noch in wenigen Fällen ein paar
    > vorberechnete Hashes miteinander vergleichen muss.
    Womit theoretisch gleich die nächste Sicherheitslücke aufgerissen wird.
    Initial muss mindestens der hash dem Client bekannt sein. Wenn sich irgendein XSS-Script in den Hashingprozess einklinkt, muss es nur darauf warten, bis es "Ping!" macht.

    Ich würde eher diesen "Filter" anzweifeln; was passiert, wenn ich bspw. mein Passwort "Regenbogen" nenne, und nun meinen Chatpartner darüber aufklären möchte, dass draußen vor der Tür ein schöner Regenbogen erstrahlt.. ?
    Und wer sein Passwort "Hallo" nennt, kann anschließend mit Niemandem mehr chatten?

  10. Re: Filterfunktion auch ohne Klartext...

    Autor: mambokurt 10.09.18 - 17:14

    Quantium40 schrieb:
    ------------------------------------------------------------------------------.
    >
    > Es gibt durchaus Wege, den Großteil der Rechnerei so auf den Client zu
    > verlagern, dass der Server nur noch in wenigen Fällen ein paar
    > vorberechnete Hashes miteinander vergleichen muss.


    Bei einer mobilen App? Wie lange dauerts da wohl bis Beschwerden reinlaufen dass das Senden ne Sekunde dauert und das Handy dabei glüht? ;)

  11. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 17:20

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Es gibt durchaus Wege, den Großteil der Rechnerei so auf den Client zu
    > verlagern, dass der Server nur noch in wenigen Fällen ein paar
    > vorberechnete Hashes miteinander vergleichen muss.


    Kannst du das konkretisieren? Ich halte es für schwer bis unmöglich eine solche Funktion zu implementieren, wenn das Passwort nicht im Original vorliegt.
    Passwörter können (und sollten) ja Sonderzeichen und Ziffern enthalten. Man kann nicht Wörter eines Textes hashen und vergleichen, weil Passwörter eben normalerweise explizit nicht dem Schema eines Wortes folgen.
    Jeder beliebige Teil einer Nachricht könnte das Passwort sein. Theoretisch musst du aus der Nachricht alle Teile ziehen, die ein Passwort sein könnten - und das sind quasi alle Teile mit einer Länge die zur Passwort-Policy passen. Das geht schnell ins Utopische.
    Und dazu kommt, dass die Hash-Algos für Passwörter ja absichtlich nicht performant sind.
    Eine Filterfunktion auf Basis von Hashes ist daher IMHO problematisch.

    Ich hab nie groß über sowas nachgedacht, aber ich denke man bräuchte auf jeden Fall das Passwort für eine korrekte Prüfung. Das bedeutet allerdings noch lange nicht, dass man das Passwort auch im Klartext speichern muss...
    Man könnte das Passwort ja z.B. beim Login (da hat man es ja) symmetrisch verschlüsseln, serverseitig in der Session ablegen und client-seitig, z.B. in nem Cookie, den Schlüssel ablegen.
    Dadurch existiert auf dem Dateisystem des Servers maximal das verschlüsselte Passwort und auf dem Dateisystem des Client nur der Schlüssel.
    Lediglich im Request-Kontext, also beim Absenden einer Nachricht, ist serverseitig (im RAM) beides verfügbar und somit kann das Passwort temporär entschlüsselt und für einen performanten Abgleich genutzt werden. Die zusätzliche Rechenzeit wäre hierbei vernachlässigbar...

    Das war jetzt meine Spontan-Idee die mir während des Schreibens dieses Beitrags kam... Hoffe sie ist nicht absoluter Blödsinn :)

  12. Re: Filterfunktion auch ohne Klartext...

    Autor: PineapplePizza 10.09.18 - 17:12

    das Keks schrieb:
    --------------------------------------------------------------------------------
    > Im Grund wird jedes geschriebene Wort mit dem Passwort abgeglichen

    Dann bringt dich jemand dazu dein Passwort in Gänsefüßchen oder sonst einer Umverpackung zu schreiben. Bzw. oft macht man das sowieso schon so.

    Wenn man wirklich verhindern will, daß jemand sein Passwort ins Chatfenster schreibt, dann kommst du am Klartextpasswort wirklich kaum vorbei. Der Hash weiß nicht wo ein Wort anfängt und wo es aufhört, der Klartext findet den Substring immer.

    Wobei das Gegenargument natürlich auch zählt: wenn du Leerzeichen ins Passwort einbaust um am Filter vorbeizukommen, dann geht das auch mit Klartext wieder. Das ist aber eher unüblich und meistens wird auch nicht allzu genau erläutert, wie so eine Filterfunktion tickt.

    Am Ende ist es doch die bessere Entscheidung, es gar nicht erst zu versuchen, sowas mit Filter zu unterbinden. Denn da kommt dann eh nur "schick mir dein PW doch eben per ICQ" bei raus. Man kann Kommunikation nicht filtern, wenn man nicht alle Kommunikationskanäle kontrolliert.

  13. Re: Filterfunktion auch ohne Klartext...

    Autor: bastie 10.09.18 - 17:13

    Dein Filter funktioniert nicht, wenn das Passwort ein Leerzeichen enthält.
    Du müsstest JEDEN Teil-String der Nachricht salzen, hashen und vergleichen. Der Aufwand steigt quadratisch zur Länge der Eingabe, das ist viel zu viel Rechenleistung!
    Behalte im Hinterkopf: Einen Hash zu berechnen ist absichtlich rechenintensiv, damit man Brute-Force-Attacken erschwert.

  14. Re: Filterfunktion auch ohne Klartext...

    Autor: hyperlord 10.09.18 - 17:20

    Wenn man eine vernünftige Hashfunktion verwendet, dürfte die Rechenzeit eine Rolle spielen.
    Man könnte das natürlich auch etwas schlauer gestalten und z.B. die Passwortlänge speichern - dann müsste man nur noch Worte gleicher Länge hashen und vergleichen.
    Passworte im Klartext zu speichern ist aber absolut unentschuldbar.

  15. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 17:24

    hyperlord schrieb:
    --------------------------------------------------------------------------------
    > Wenn man eine vernünftige Hashfunktion verwendet, dürfte die Rechenzeit
    > eine Rolle spielen.
    > Man könnte das natürlich auch etwas schlauer gestalten und z.B. die
    > Passwortlänge speichern - dann müsste man nur noch Worte gleicher Länge
    > hashen und vergleichen.
    > Passworte im Klartext zu speichern ist aber absolut unentschuldbar.

    Wenn mein Passwort "gestern! 1900" lautet, sind das 13 Zeichen. Es ist aber kein 13 Zeichen langes Wort... Für die Prüfung kann man nicht auf Wortänge gehen, sondern muss alle Teilstrings der Länge 13 hashen und vergleichen... Bei einer Nachricht mit 160 Zeichen sind das 148 Hashes die zu bilden wären :)

  16. Re: Filterfunktion auch ohne Klartext...

    Autor: lear 10.09.18 - 17:40

    Die Passworteingabe könnte 0x20 in 0xA0 umsetzen (oder in eins der absonderlichen Unicode Spezialleerzeichen, die niemals irgendwer irgendwo benutzen wird) - macht in dem Kontext ohnehin mehr Sinn.
    Aber wer glaubt, daß das hier der Grund für die Schlamperei ist, glaubt auch, daß der Storch zu Ostern den Weihnachtsmann bringt…

  17. Re: Filterfunktion auch ohne Klartext...

    Autor: Hotohori 10.09.18 - 17:46

    RFZ schrieb:
    --------------------------------------------------------------------------------
    > hyperlord schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn man eine vernünftige Hashfunktion verwendet, dürfte die Rechenzeit
    > > eine Rolle spielen.
    > > Man könnte das natürlich auch etwas schlauer gestalten und z.B. die
    > > Passwortlänge speichern - dann müsste man nur noch Worte gleicher Länge
    > > hashen und vergleichen.
    > > Passworte im Klartext zu speichern ist aber absolut unentschuldbar.
    >
    > Wenn mein Passwort "gestern! 1900" lautet, sind das 13 Zeichen. Es ist aber
    > kein 13 Zeichen langes Wort... Für die Prüfung kann man nicht auf Wortänge
    > gehen, sondern muss alle Teilstrings der Länge 13 hashen und vergleichen...
    > Bei einer Nachricht mit 160 Zeichen sind das 148 Hashes die zu bilden wären
    > :)

    Leerzeichen im Passwort verbieten > Problem gelöst.

    Ich hab noch nie Leerzeichen in Passwörtern benutzt und meistens geht das meines Wissens nicht mal, da bestimmte Zeichen bei Passwörtern einfach ausgeschlossen werden.

  18. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 17:57

    Hotohori schrieb:
    --------------------------------------------------------------------------------
    > Leerzeichen im Passwort verbieten > Problem gelöst.
    >
    > Ich hab noch nie Leerzeichen in Passwörtern benutzt und meistens geht das
    > meines Wissens nicht mal, da bestimmte Zeichen bei Passwörtern einfach
    > ausgeschlossen werden.

    Zeichen bei einem Passwort auszuschließen muss man (als Entwickler) immer bewusst tun. Technisch hindert dich nichts daran eine Zeichenfolge mit Leerzeichen zu hashen... Ein solcher Schritt sollte gut überlegt sein. Richtige Gründe fallen mir dafür nicht wirklich ein...
    Es macht höchsten Sinn den Nutzer auf eine unglückliche Wahl von Zeichen hinzuweisen... z.B. dass ein Emoji im Passwort vielleicht ungünstig ist, weil man es auf einer PC Tastatur nicht einfach eingeben kann. Aber ich finde das sollte bei einem Hinweis bleiben. Wenn ich ein Emoji im Passwort haben möchte, sollte ich das haben dürfen :)
    Wenn Zeichen verboten sind, ist das of ein Zeichen dafür dass das Passwort noch im Klartext irgendwo verarbeitet wird und die Übertragung z.B. kein UTF-8 kann, oder jemand zu blöd war Entities für ein XML richtig zu encoden und deshalb einfach &, < und > in Passwörtern verbeitet ;)

    Trotzdem musst du dann immernoch jede zusammenhängende Zeichenfolge von erlaubten Zeichen und deren Teilstrings hashen... Das ist immernoch ziemlich viel. Selbst wenn du dir die Passwortlänge merkst, musst du ja immernoch alle möglichen Teilstrings von längeren Wörtern auch hashen etc...
    Ich halte das einfach nicht für praktikabel - und ein Ansatzpunkt für DoS ist es auch...

  19. Re: Filterfunktion auch ohne Klartext...

    Autor: Quantium40 10.09.18 - 17:53

    hyperlord schrieb:
    > Wenn man eine vernünftige Hashfunktion verwendet, dürfte die Rechenzeit
    > eine Rolle spielen.

    Eine typische Chatnachricht liegt im Bereich einer SMS - also unter 160 Zeichen.
    Wenn wenigstens die Länge des Passwortes bekannt ist, wären das gerade mal etwas weniger als 160 zu berechnende Hashes.
    Das schafft selbst der langsamste Mediatek-Prozessor in einem 50¤-Smartphone noch locker nebenbei, selbst wenn da SHA512, gost, Whirlpool oder RIPEMD-160 als Algorithmus genutzt wird.

  20. Re: Filterfunktion auch ohne Klartext...

    Autor: dura 10.09.18 - 18:14

    Und das skaliert dann auf die Nutzerzahl von Knuddels genau wie gut?

  21. Re: Filterfunktion auch ohne Klartext...

    Autor: Quantium40 10.09.18 - 20:43

    dura schrieb:
    > Und das skaliert dann auf die Nutzerzahl von Knuddels genau wie gut?
    Wenn man das Hashen und ggf. eine Vorfilterung der Hahes auf dem Client erledigen lässt, ist die Kundenzahl ziemlich irrelevant. Dann müsste der Server höchstens noch ein paar Werte miteinander vergleichen, was selbst bei der Nutzerzahl von Knuddels kein Problem darstellen sollte. Die Datenbankoperationen rund um das Weiterverteilen von Nachrichten sind da im Vergleich um einige Größenordnungen teurer.

  22. Re: Filterfunktion auch ohne Klartext...

    Autor: Anonymer Nutzer 10.09.18 - 22:38

    wenn ich das auf den client auslagere, auf dem das passwort sowieso im klartext eingegeben wurde, wozu sollte ich dann überhaupt nen hash dafür bilden?

  23. Re: Filterfunktion auch ohne Klartext...

    Autor: redmord 10.09.18 - 22:42

    Damit ein Angreifer in der Webapp von Knuddels nicht einfach console.log(window.knuddelsApp.user.cleartextPassword); ausführen muss, um an das Ding zu kommen. ^^

  24. Re: Filterfunktion auch ohne Klartext...

    Autor: Anonymer Nutzer 10.09.18 - 22:50

    Und das hat ein Angreifer dann bei und/oder vor der Passworteingabe nicht auch schon gekonnt?

  25. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 22:57

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > Und das hat ein Angreifer dann bei und/oder vor der Passworteingabe nicht
    > auch schon gekonnt?

    Passworteingabe / Login ist ein einmaliges Ereignis. Du kannst das weder abgreifen, wenn du mal kurz bei einer Person mit am PC sitzt, noch durch Eingabe irgendwelcher Befehle in die JS Console wenn der Login bereits erfolgt ist.
    Nur persistenter Schadcode könnte es auch beim Login abgreifen.

    Mit der selben Begründung könnte man auch serverseitig das Hashen sparen. Einfach das Passwort beim Login in die Session-Daten aufnehmen und fertig. Dann hat man es im Klartext und kann die Prüfung durchführen.
    Im Schadfall, wenn ein Angreifer Zugriff auf das Dateisystem des Servers erlangt, können so alle Passwörter der aktiven Nutzer abgegriffen werden.
    Das ist schlecht - im Vergleich zum aktuellen Leak wäre es aber fast nichts :D
    Hätten sie es besser mal so gelöst ;)

    Trotzdem... Man macht das so einfach nicht. Auch Serverseitig hat man das Klartext Passwort nur im RAM und auch da bitte nur so kurz wie zwangsweise nötig.

  26. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 22:45

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > wenn ich das auf den client auslagere, auf dem das passwort sowieso im
    > klartext eingegeben wurde, wozu sollte ich dann überhaupt nen hash dafür
    > bilden?

    Weil du auch das nicht möchtest... Jemand der kurz Zugriff auf deinen PC hat, dich dazu verleitet was in deine JavaScript Console einzutippen, oder dir mittels XSS o.ä, Schadcode zukommen lässt, könnte dann einfach dein Passwort abgreifen.

  27. Re: Filterfunktion auch ohne Klartext...

    Autor: Anonymer Nutzer 10.09.18 - 23:02

    Wenn jemand seine Griffel an meinen Client legen kann, kann er niemals nicht den sowieso verändern wie er das für seine Zwecke braucht?

    Sry, bei dem Szenario, hilft imho garnichts, jeder noch so nette Versuch verbrät maximal Rechenleistung, das ist alles.

  28. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 23:13

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > Wenn jemand seine Griffel an meinen Client legen kann, kann er niemals
    > nicht den sowieso verändern wie er das für seine Zwecke braucht?

    Naja, mal kurz was in die JS Konsole eingeben geht schnell und hinterlässt keine Spuren und ist somit auch nicht nachweisbar. Ist schnell gemacht, wenn der Nutzer mal abgelenkt ist.
    Schadsoftware plazieren ist dann doch bisschen mehr Aufwand und hinterlässt Spuren.

    > Sry, bei dem Szenario, hilft imho garnichts, jeder noch so nette Versuch
    > verbrät maximal Rechenleistung, das ist alles.

    Ist eine Meinung. Ich bin anderer Meinung.
    Wenn ich am Client ein Passwort speichere, dann mache ich das trotzdem nicht im Klartext. Wann immer möglich, wird es gehasht. Geht das nicht, wird es zumindest verschlüsselt.
    Es einfach im Klartext auf die Platte zu schreiben, weil man ja eh dran kommt wenn man den Client manipulieren konnte, ist ein Nogo.

  29. Re: Filterfunktion auch ohne Klartext...

    Autor: Cybso 10.09.18 - 18:09

    Aus dem Nachbarthread "Bitte was?":

    Für sowas kann man Rolling Checksums wie Adler32 verwenden.

    Du baust du eine Datenbank auf, in der du jeweils die Adler32-Prüfsumme der letzten (n) Zeichen jedes Passworts speicherst, mit (n) < Mindestpasswortlänge, und zu welchen Passwörter sie gehört. Außerdem benötigst du neben dem hoffentlich gesalzenen Hash noch die tatsächliche Länge des Passworts(*).

    Dann rotierst du im Text jeweils über die letzten n gelesenen Zeichen. Sobald du einen Treffer hast, schaust du nach, ob einer der gespeicherten Passwort-Hashes an der Stelle passt.

    Wenn man dies geschickt implementiert, dann ist es nur wenig aufwendiger, als den Text nach jedem einzelnen Klartextpasswort zu durchsuchen. (*) Allerdings wird es durch die gespeicherte Adler32-Summe möglich, die letzten (n) Zeichen des Passworts zu erraten. In Kombination mit der gespeicherten Länge des Ursprungspassworts wird die Sicherheit deutlich reduziert. Besser als die Klartextvariante ist es dennoch allemal.



    1 mal bearbeitet, zuletzt am 10.09.18 18:10 durch Cybso.

  30. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 10.09.18 - 18:20

    Cybso schrieb:
    --------------------------------------------------------------------------------
    > Aus dem Nachbarthread "Bitte was?":
    >
    > Für sowas kann man Rolling Checksums wie Adler32 verwenden.
    >
    > Du baust du eine Datenbank auf, in der du jeweils die Adler32-Prüfsumme der
    > letzten (n) Zeichen jedes Passworts speicherst, mit (n) <
    > Mindestpasswortlänge, und zu welchen Passwörter sie gehört. Außerdem
    > benötigst du neben dem hoffentlich gesalzenen Hash noch die tatsächliche
    > Länge des Passworts(*).
    >
    > Dann rotierst du im Text jeweils über die letzten n gelesenen Zeichen.
    > Sobald du einen Treffer hast, schaust du nach, ob einer der gespeicherten
    > Passwort-Hashes an der Stelle passt.
    >
    > Wenn man dies geschickt implementiert, dann ist es nur wenig aufwendiger,
    > als den Text nach jedem einzelnen Klartextpasswort zu durchsuchen. (*)
    > Allerdings wird es durch die gespeicherte Adler32-Summe möglich, die
    > letzten (n) Zeichen des Passworts zu erraten. In Kombination mit der
    > gespeicherten Länge des Ursprungspassworts wird die Sicherheit deutlich
    > reduziert. Besser als die Klartextvariante ist es dennoch allemal.

    Wow, das klingt kompliziert ^^
    Zudem heisst das, dass du auch noch Buch führst wie lange die Passwörter der Nutzer sind, und welche Nutzer Passwörter mit gleicher Endung haben... Problematisch wird es vermutlich auch, wenn du n zu groß wählst, weil dann Passwörter < n oder nahe n einfach zu erraten sind. Wählst du n zu klein, ist deine Datenbank nutzlos, weil jeder Eintrag für tausende Passwörter stehen kann.
    Und ganz generell hast du einen großen Impact der gegen deine Hash-Funktion arbeitet...

    Also da finde ich meinen Ansatz mit dem je Sitzung symmetrisch verschlüsselten Passwort das auf Server und Client verteilt wird eleganter. Das hat weder einen Performance-Impact, noch untergräbt es irgendwie die Sicherheit der genutzten Hashfunktion...

  31. Re: Filterfunktion auch ohne Klartext...

    Autor: seronulpha 10.09.18 - 23:37

    Warum habe ich von einer auf der Hand liegenden Lösung noch nicht gelesen?

    Mit Login wird im Session-Cache das Klartext-Passwort gespeichert, solange die Session gültig ist. Serverseitig kann nun damit der Filter bedient werden. Mit Logout oder Zeitablauf oder sonstigen Gründen stirbt die Session und das Klartext-Passwort verschwindet vom Server, eh der Anwender sich wieder anmeldet.

    Das wäre zumindest ein Kompromiss, vorausgesetzt die Session bleibt nicht zig Wochen gültig. Das ganze hat außerdem sicher den Anwendernachteil, dass dies nur bei regelmäßiger Authentifizierung funktioniert. Aber auch das ist ja nicht verkehrt für die Sicherheit.

    Wie gesagt: Ein Kompromiss.

  32. Re: Filterfunktion auch ohne Klartext...

    Autor: RFZ 11.09.18 - 00:03

    seronulpha schrieb:
    --------------------------------------------------------------------------------
    > Warum habe ich von einer auf der Hand liegenden Lösung noch nicht gelesen?

    Weiss ich auch nicht, denn in diesem Thread wird genau das diskutiert ;)

    > Mit Login wird im Session-Cache das Klartext-Passwort gespeichert, solange
    > die Session gültig ist. Serverseitig kann nun damit der Filter bedient
    > werden. Mit Logout oder Zeitablauf oder sonstigen Gründen stirbt die
    > Session und das Klartext-Passwort verschwindet vom Server, eh der Anwender
    > sich wieder anmeldet.

    Ja. Wäre auf jeden Fall besser als die Passwörter persistent in einer Datenbank zu speichern. Wie um 22:57 Uhr geschrieben, können so im Falle dass jemand den Server übernimmt nur die Passwörter von Nutzern abgegriffen werden, die zu diesem Zeitpunkt eine aktive Sitzung haben. Also nur ein Bruchteil aller Nutzer.

    > Das wäre zumindest ein Kompromiss, vorausgesetzt die Session bleibt nicht
    > zig Wochen gültig. Das ganze hat außerdem sicher den Anwendernachteil, dass
    > dies nur bei regelmäßiger Authentifizierung funktioniert. Aber auch das ist
    > ja nicht verkehrt für die Sicherheit.
    >
    > Wie gesagt: Ein Kompromiss.

    Richtig, ein Kompromiss. Es ginge aber sogar noch besser... Statt das Passwort im Klartext in der Session abzulegen, könnte man es dort verschlüsselt ablegen und den Schlüssel am Client in einem Cookie ablegen. Eine Entschlüsselung ist dann bei jedem Web-Request möglich und somit der Filter umsetzbar.
    Jemand der den Server übernimmt kommt aber trotzdem nur auf die verschlüsselten und damit wertlosen Passwörter der aktiven Nutzer. Um diese zu entschlüsseln muss er nun zusätzlich Web-Requests von Clients abfangen können.
    Er muss also einerseits noch tiefer in den Server eindringen und kann andererseits selbst unter den Nutzern mit einer noch gültigen Session nur den Bruchteil angreifen, der auch während des Angriffs aktiv chattet.

    Btw. wenn man solche Daten in der Session ablegt, muss man gut darauf achten wie die garbage collection arbeitet, die die abgelaufenen Sessions bereinigt. Denn vorzugsweise sorgt die dafür dass die Passwörter wirklich nicht mehr auf dem Datenträger wiederherstellbar sind. Genau das tut sie aber normal nicht, da sie nicht für ein sicheres Löschen gemacht ist...

  33. Re: Filterfunktion auch ohne Klartext...

    Autor: Neutrinoseuche 11.09.18 - 07:11

    Es ist besser, nichts was das Passwort betrifft, an den Client zurück zuschicken. Jegliche Prüfung sollte auf dem Server ablaufen.

    Jegliche Übermittlung von Prüfsummen und Schlüsseln ist ein Sicherheitsrisiko, da keine Kontrolle über den Client besteht und dort alle Daten abgefangen werden könnten.

    Jegliche Erhebung von Daten über den Aufbau des Passwortes lässt Rückschlüsse auf den verwendeten Hash-Algorithmus zu und bedeutet eine Schwächung der Sicherheit des Loginsprozesses und der Anwendung selbst.

    Es ist davon abzusehen irgendwelche kritischen Daten wie Passwörter unverschlüsselt zu speichern. Das gilt für Datenbanken, Sessions, Cookies.

    Um den Loginprozess weiter abzusichern, kann man die Daten der Useraccounts, die gehashted Passwörter, die Salt und Pepper Strings in verschiedenen Datenbanken speichern. Das mag vielleicht etwas mehr Aufwand sein, aber im Fall der Fälle ist eventuell nur eine DB kopiert worden.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Hochschule für Angewandte Wissenschaften Hof, Hof
  2. BVV Versicherungsverein des Bankgewerbes a.G., Berlin
  3. Landeshauptstadt Stuttgart, Stuttgart
  4. TenneT TSO GmbH, Bayreuth

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Mobile-Angebote
  1. (u. a. Galaxy S21 mit Galaxy Buds Pro In-Ears und Galaxy Smart Tag für 849€)
  2. 189,99€ (Bestpreis)
  3. 189€ (Bestpreis)
  4. 819€ (Ebay Plus - Bestpreis)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Boeing 737 Max: Neustart mit Hindernissen
Boeing 737 Max
Neustart mit Hindernissen

Die Boeing 737 ist nach dem Flugzeugabsturz in Indonesien wieder in den Schlagzeilen. Die Version Max darf seit Dezember wieder fliegen - doch Kritiker halten die Verbesserungen für unzureichend.
Ein Bericht von Friedrich List

  1. Flugzeug Boeing erhält den letzten Auftrag für den Bau der 747
  2. Boeing 737 Max Boeing-Strafverfahren gegen hohe Geldstrafe eingestellt
  3. Zunum Luftfahrt-Startup verklagt Boeing

Akkuforschung: Wie Lithium-Akkus noch mehr Energie speichern sollen
Akkuforschung
Wie Lithium-Akkus noch mehr Energie speichern sollen

In der Theorie können Lithium-Ionen-Akkus mehr als dreimal so viel Energie speichern wie bislang. Wie kann es in der Praxis mehr werden?
Von Frank Wunderlich-Pfeiffer

  1. Akkuforschung 2020 In Zukunft gibt es spottbillige Akkus in riesigen Mengen
  2. Akkus Quantumscape präsentiert eine halbe Mogelpackung
  3. Entsorgung Tesla wegen Problemen bei Akkurücknahme bestraft

Opel Zafira-e Life im Test: Die Entdeckung der Langsamkeit
Opel Zafira-e Life im Test
Die Entdeckung der Langsamkeit

Der Opel Zafira-e Life ist ein praktischer Kleinbus für Familien und Fahrdienste. Doch längere Fahrten mit dem Elektroauto können zur Geduldsprobe werden.
Ein Test von Friedhelm Greis

  1. Überbuchung Opel kündigt Kaufverträge für den Mokka-e
  2. Opel Nachfrage nach Mokka-e übertrifft Erwartungen
  3. Sportliches Fahrzeug Opel will Monza als Elektroauto neu auflegen