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

Filterfunktion auch ohne Klartext möglich

  1. Thema
  1. 1
  2. 2

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 möglich

    Autor: M.P. 10.09.18 - 16:02

    Nötige Rechenleistung?

  3. Re: Filterfunktion auch ohne Klartext möglich

    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.

  4. Re: Filterfunktion auch ohne Klartext möglich

    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.

  5. Re: Filterfunktion auch ohne Klartext möglich

    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.

  6. 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.

  7. Re: Filterfunktion auch ohne Klartext möglich

    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.

  8. Re: Filterfunktion auch ohne Klartext möglich

    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.

  9. Re: Filterfunktion auch ohne Klartext möglich

    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 möglich

    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 möglich

    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 möglich

    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.

  13. Re: Filterfunktion auch ohne Klartext möglich

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

  14. Re: Filterfunktion auch ohne Klartext möglich

    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…

  15. Re: Filterfunktion auch ohne Klartext möglich

    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.

  16. Re: Filterfunktion auch ohne Klartext möglich

    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.

  17. Re: Filterfunktion auch ohne Klartext möglich

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

  18. Re: Filterfunktion auch ohne Klartext möglich

    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.

  19. Re: Filterfunktion auch ohne Klartext möglich

    Autor: dura 10.09.18 - 18:14

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

  20. Re: Filterfunktion auch ohne Klartext möglich

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

  1. Thema
  1. 1
  2. 2

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. Bibliotheksservice-Zentrum Baden-Württemberg (BSZ), Konstanz
  2. Universitätsklinikum Augsburg, Augsburg
  3. Deutsches Elektronen-Synchrotron DESY, Hamburg
  4. Regierung von Oberbayern, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Mobile-Angebote
  1. 599€ (mit Rabattcode "PRIMA10" - Bestpreis!)
  2. 599€
  3. 749€ (mit Rabattcode "PERFECTEBAY10" - Bestpreis!)
  4. 350,10€ (mit Rabattcode "PERFECTEBAY10" - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ausprobiert: Meine erste Strafgebühr bei Free Now
Ausprobiert
Meine erste Strafgebühr bei Free Now

Storniert habe ich bei Free Now noch nie. Doch diesmal wurde meine Geduld hart auf die Probe gestellt.
Ein Praxistest von Achim Sawall

  1. Gesetzentwurf Weitergabepflicht für Mobilitätsdaten geplant
  2. Personenbeförderung Taxibranche und Uber kritisieren Reformpläne

Energiewende: Wie die Begrünung der Stahlindustrie scheiterte
Energiewende
Wie die Begrünung der Stahlindustrie scheiterte

Vor einem Jahrzehnt suchte die europäische Stahlindustrie nach Technologien, um ihren hohen Kohlendioxid-Ausstoß zu reduzieren, doch umgesetzt wurde fast nichts.
Eine Recherche von Hanno Böck

  1. Wetter Warum die Klimakrise so deprimierend ist

5G: Nokias und Ericssons enge Bindungen zu Chinas Führung
5G
Nokias und Ericssons enge Bindungen zu Chinas Führung

Nokia und Ericsson betreiben viel Forschung und Entwicklung zu 5G in China. Ein enger Partner Ericssons liefert an das chinesische Militär.
Eine Recherche von Achim Sawall

  1. Quartalsbericht Ericsson mit Topergebnis durch 5G in China
  2. Cradlepoint Ericsson gibt 1,1 Milliarden Dollar für Routerhersteller aus
  3. Neben Huawei Telekom wählt Ericsson als zweiten 5G-Ausrüster