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

Filterfunktion auch ohne Klartext möglich

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Filterfunktion auch ohne Klartext möglich

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

  2. Re: Filterfunktion auch ohne Klartext möglich

    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.

  3. Re: Filterfunktion auch ohne Klartext möglich

    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.

  4. Re: Filterfunktion auch ohne Klartext möglich

    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?

  5. Re: Filterfunktion auch ohne Klartext möglich

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

  6. Re: Filterfunktion auch ohne Klartext möglich

    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.

  7. Re: Filterfunktion auch ohne Klartext möglich

    Autor: Anonymer Nutzer 10.09.18 - 22:50

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

  8. Re: Filterfunktion auch ohne Klartext möglich

    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.

  9. Re: Filterfunktion auch ohne Klartext möglich

    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.

  10. Re: Filterfunktion auch ohne Klartext möglich

    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.

  11. Re: Filterfunktion auch ohne Klartext möglich

    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.

  12. Re: Filterfunktion auch ohne Klartext möglich

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

  13. Re: Filterfunktion auch ohne Klartext möglich

    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
  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. EDAG Engineering GmbH, München
  2. SATA GmbH & Co. KG, Kornwestheim
  3. ElringKlinger AG, Dettingen an der Ems
  4. generic.de software technologies AG, Karlsruhe (Home-Office möglich)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Mobile-Angebote
  1. 699€ (mit Rabattcode "POWERFRIDAY20" - Bestpreis!)
  2. (u. a. Apple iPhone 11 Pro Max 256GB 6,5 Zoll Super Retina XDR OLED für 929,98€)
  3. 159,99€ (mit Rabattcode "POWERFRIDAY20" - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Astronomie: Arecibo wird abgerissen
Astronomie
Arecibo wird abgerissen

Das weltberühmte Radioteleskop ist nicht mehr zu retten. Reparaturarbeiten wären lebensgefährlich.

  1. Astronomie Zweites Kabel von Arecibo-Radioteleskop kaputt
  2. Die Zukunft des Universums Wie alles endet
  3. Astronomie Gibt es Leben auf der Venus?

Demon's Souls im Test: Düsternis auf Basis von 10,5 Tflops
Demon's Souls im Test
Düsternis auf Basis von 10,5 Tflops

Das Remake von Demon's Souls ist das einzige PS5-Spiel von Sony, das nicht für die PS4 erscheint - und ein toller Einstieg in die Serie!
Von Peter Steinlechner


    Chang'e 5: Chinesischer Probensammler ist unterwegs zum Mond
    Chang'e 5
    Chinesischer Probensammler ist unterwegs zum Mond

    Nach 44 Jahren soll eine chinesische Raumsonde endlich wieder Gesteinsproben vom Mond zur Erde bringen.
    Von Frank Wunderlich-Pfeiffer

    1. Raumfahrt Nasa hat überraschenden Favoriten bei Mondlanderkonzept
    2. SLS Nasa bestellt Triebwerke für den Preis einer ganzen Rakete
    3. Artemis Base Camp Nasa plant Mondhabitat