1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › RSA-Entwickler: Mit Honeywords gegen…

Absoluter Schwachsinn

Anzeige
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Absoluter Schwachsinn

    Autor Mingfu 07.05.13 - 16:03

    Die Idee ist schon nach kurzer Überlegung so bescheuert, dass man nur den Kopf schütteln kann.

    1. Wer bis zur Passwortinfrastruktur vordringen kann, um so ganze Passwortlisten auf dem Server auszulesen, der ist schon so tief im System drin, dass er wohl in den seltensten Fällen darauf angewiesen ist, sich noch mit einem regulären Benutzerzugang am System anzumelden. Selbst wenn: Dann wäre bei einer solchen Eindringtiefe vermutlich auch die Installation eines Trojaners möglich, sodass man die Anmeldevorgänge aufzeichnen kann und so das korrekte Passwort geliefert bekommt.

    2. Wenn die Passwortinfrastruktur bereits unzureichend gegen Angreifer gesichert ist, dann ist es sehr wahrscheinlich auch die Honeyword-Infrastruktur, die das korrekte Passwort abgleicht.

    3. Die Flickschusterei fängt dort an, wo es darum geht "plausible" Honeywords zum tatsächlichen Passwort zu generieren. Es werden da im Paper zwar einzelne Vorschläge gemacht, aber universell einsetzbar ist kein einziger davon.

    Beispiel: Ein Benutzer verwendet das Passwort "passwort". Es hat da wenig Sinn, wenn man da die Zeichen zufällig ersetzt. In einer Liste von "gsa78aadh", "lasuausz", "zuzs9f8f" und "passwort" ist ziemlich offensichtlich, welches Passwort nicht zu den anderen passt und demzufolge der gültige Kandidat ist. Da geht es halt los, dass man das Passwort genau analysieren soll und z. B. Passwörtern, die in Listen auftauchen, ein anderes Listenwort hinzufügen soll usw. Das ist Herumgefrickel ohne wirkliche Sicherheitssubstanz. Auch haben die Autoren nicht gründlich in diesem Punkt nachgedacht. So schlagen sie vor, dass man doch den Benutzer zwingen soll, eine Ziffer im Passwort zu haben, denn die können man immer problemlos ersetzen ohne dass es auffällt. Dabei wurde übersehen, dass viele Benutzer in dem Fall 1337-Speak einsetzen, also z. B. "p4sswort". Wenn man dort eine Liste mit "p1sswort", "p2sswort", "p3sswort" und "p4sswort" macht, ist immer noch der wahrscheinlichste Kandidat ziemlich offensichtlich. Honeywords zu einem vom Benutzer gewählten Passwort zu generieren, ist also überhaupt nicht trivial und der eigentliche Knackpunkt der Sache.

    4. Selbst wenn man die Punkte 1-3 außen vorlässt - die Sache ist in vielen Fällen leicht überwindbar. Die Angewohnheit der Benutzer, die gleichen Zugangsdaten für viele Dienste zu verwenden, lässt sich nämlich als Orakel einsetzen. Da, wenn überhaupt, jeder Dienst sein eigenes Honeyword-System hat, sind die Honeywords des einen Dienst beim nächsten einfach ungültige Passwörter, die keinen Alarm auslösen (höchstens einen, dass es viele Login-Versuche gab - aber das ist bei den vielen Brute-Force-Angriffen inzwischen für viele Dienste normal und damit kein gültiges Alarmierungsmerkmal mehr). Man geht also die Passwortliste einfach beim nächstbesten Dienst durch und probiert, ob man mit einem Zugangspaar dort reinkommt. Damit ist dann auch das gültige Passwort des ursprünglichen Dienstes gefunden.

    Wobei der ursprüngliche Dienst ohnehin in den seltensten Fällen das tatsächliche Ziel des Angriffs ist. Es ist ja gerade bezeichnend für diese Art der Angriffe, dass man irgendeine leicht zu öffnende Kiste aufmacht, um mit den dortigen Zugangsdaten dann bei ganz anderen Diensten einzusteigen, bei denen der Benutzer die gleichen Daten verwendet. Dagegen hilft die Honeyword-Methode kein Stück weit und ist vollkommen nutzlos.



    2 mal bearbeitet, zuletzt am 07.05.13 16:22 durch Mingfu.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Absoluter Schwachsinn

    Autor Himmerlarschundzwirn 07.05.13 - 16:06

    Ich bin da eher Laie, aber deine Überlegungen gelten ja jetzt nur für Klartextpasswörter, oder? Sieht die Sache bei Honeyhashes (So nenne ich es jetzt einfach mal) nicht schon wieder ganz anders aus?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Absoluter Schwachsinn

    Autor Mingfu 07.05.13 - 16:18

    Es wird bei den Hashes schon davon ausgegangen, dass du sie in der Regel per Brute-Force bzw. mit Passwortlisten "zurückrechnen" kannst, indem du einfach ausprobierst, ob dein Passwortkandidat nach dem Hashen den gleichen Hashwert hat. Es gibt natürlich grundsätzlich mehrere Zeichenketten, die den gleichen Hash ergeben könnten - aber wenn "passwort" und "d66RS/&GDFGUDbhdgstasgasdha7s88" den gleichen Hashwert hätten, wäre ersteres doch der deutlich wahrscheinlichere Kandidat. Da Kollisionsresistenz eine der Grundanforderungen an kryptographische Hashfunktionen ist, ist es auch nicht sehr wahrscheinlich, dass du überhaupt ein anderes Passwort mit dem gleichen Hash finden kannst, als das, welches auch der Benutzer verwendet hat.

    Wir können uns also bei der Betrachtung auf Klartextpasswörter beschränken. Ganz im Gegenteil: Hättest du eine sichere Hashfunktion in dem Sinne, dass das Durchprobieren vieler Passwortkandidaten so langsam ist, dass es nicht effizient betrieben werden kann, dann würdest du nicht vor dem Problem stehen. Denn dann könnte der Angreifer aus dem Hash das Passwort nicht erhalten und damit auch keinen Unfug anstellen. Der Nachteil solch aufwändig zu berechnender Hashfunktionen ist, dass es natürlich auch für den Server bei der Passwortprüfung dann lange dauert, sodass die Gefahr eines DoS-Angriffs besteht, indem man den Server mit vielen parallelen Anmeldeversuchen einfach überlastet (deshalb lässt sich dieses System auch bei vielgenutzten Systemen kaum einsetzen, weil dort schon die regulären Anmeldungen praktisch einen DoS-Angriff darstellen würden).



    1 mal bearbeitet, zuletzt am 07.05.13 16:18 durch Mingfu.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Absoluter Schwachsinn

    Autor Himmerlarschundzwirn 07.05.13 - 16:22

    Ich sehe das Problem. Danke für die Aufklärung ;-)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Absoluter Schwachsinn

    Autor a user 07.05.13 - 16:22

    ich sehe das anders:

    1. dein authentifizierungsserver muss und sollte nicht der gleiche sein auf den du dich einloggst oder der die gesuchten daten enthält. d.h. zugriff auf die passworthashes bedeutet nicht automatisch zugriff auf die daten.

    2. die installation eines trojaners auf dem authentifizierungsserver kann (leicht) entdeckt werden, bzw. auch aus ganz anderen gründen problematisch sein.

    3. ich habe mir nicht angeschaut, wie die authoren sich die honeyword generierung im einzelnen vorstellen. mag sein, dass sie verhaltensabhängige eigenschaften nicht oder nur ungenügend berücksichtigen.
    dann wäre daran noch zu arbeiten. ich hätte da schon ideen.

    4. dein punkt 4 trifft nur zu, wenn du andere passwörter der nutzer bereits kennst.
    und eine garantie wäre es dann immer noch nicht. es reicht ein honeypassword zu übersehen, und der hacker fällt auf, wenn er es benutzt.

    und ob die passwörter nur geklaut werden, um einen anderen dienst zu hacken ist wieder ne ganz andere geschichte.

    nun, ich sehe zwar auhc keine all zu große relevanz für die praxis, aber ich finde deine kritik ist überwiegend nicht berechtigt.

    edit2 : deine beschreibung klingt sehr stark wie aus der sicht eines entwickler für übliche webangebote. es gibt aber noch ganz andere szenarien wo so etwas von relevanz wäre/ist.



    2 mal bearbeitet, zuletzt am 07.05.13 16:26 durch a user.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Absoluter Schwachsinn

    Autor DrWatson 07.05.13 - 16:23

    Naja, wenn der login mit dedizierten Ressourcen stattfindet, werden nur die logins langsam, nicht der Rest der Seite

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: Absoluter Schwachsinn

    Autor Mingfu 07.05.13 - 16:26

    DrWatson schrieb:
    --------------------------------------------------------------------------------
    > Naja, wenn der login mit dedizierten Ressourcen stattfindet, werden nur die
    > logins langsam, nicht der Rest der Seite

    Das ist schon richtig, aber was nützt dir der Rest der Seite, wenn du gar nicht erst reinkommst, weil die Login-Server dicht machen.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: Absoluter Schwachsinn

    Autor DrWatson 07.05.13 - 16:35

    1. Die Nutzer die schon auf der Seite sind, können sie weiter nutzen.
    2. Gilt das für jeden DOS Angriff. Da gibt es auch Maßnahmen gegen - am Ende geht dem Angreifer die Puste aus.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: Absoluter Schwachsinn

    Autor dabbes 07.05.13 - 16:35

    Wo der Server liegt ist im Prinzip egal.
    Selbst wenn du 27 verschiedene Server verwendest, i. d. R. laufen die alle auf gleicher Softwarebasis. Wenn das System, die Datenbank oder das verwendete Backend (perl, python, php, java, whatever) einen Bug haben, dann nützen dir auch 27 Server nichts.

    Lediglich ein Zugriff über einen Bug in der eigenen Applikation wird verringert, aber wenn da einer schon einen Bug ausnutzen kann, dann nützt die Beste Authentifizierung der Welt nichts mehr.

    Man sollte vor allem an ein Cloud-Szenario denken (amazon s3 usw.) wo ein Angreifer direkt an irgendwelche Daten kommt, obwohl die eigene Applikation "perfekt" programmiert wurde.
    Das schlimmste sind doch keine Bugs und Brute-Force Attacken, sondern wenn ganze Datenbestände runtergeladen werden.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: Absoluter Schwachsinn

    Autor a user 07.05.13 - 16:44

    dabbes schrieb:
    --------------------------------------------------------------------------------
    > Wo der Server liegt ist im Prinzip egal.
    > Selbst wenn du 27 verschiedene Server verwendest, i. d. R. laufen die alle
    > auf gleicher Softwarebasis. Wenn das System, die Datenbank oder das
    > verwendete Backend (perl, python, php, java, whatever) einen Bug haben,
    > dann nützen dir auch 27 Server nichts.

    was redest du da?

    auf dem authentifizierungsserver läuft eine authentifizierungssoftware.

    auf den anderen rechner, die den dienst bereitstellen, läuft eine andere software, und sie müssen noch nicht einmal von aussen direkt erreichbar sein. ihre daten können durchgeschläust werden, nach freischaltung durch den auth-server.

    >
    > Lediglich ein Zugriff über einen Bug in der eigenen Applikation wird
    > verringert, aber wenn da einer schon einen Bug ausnutzen kann, dann nützt
    > die Beste Authentifizierung der Welt nichts mehr.
    was heißt heir lediglich? das ist wenn dann das wahrscheinlichste.

    wenn ein bug in der auth-software des auth-servers (oder in einer anderen komponente auf dem auth-server), dann passiert genau das, wovon im paper die rede ist: die passwort-hash-table wird geklaut.

    aber an die anderen server kommt man durch den exploit so noch lange nichr ran.

    >
    > Man sollte vor allem an ein Cloud-Szenario denken (amazon s3 usw.) wo ein
    ... warum sollte man "vor allem" an solch ein szenario denken?

    es geht in der abreit weder um alle szenarien noch um die, die du dir gerade zum verlgeichen wünscht. hier geht es erst einmal nur um das prinzip.

    und offenbar fällt dir entweder die erfahrung oder die vorstellung für welche szenarien so etwas interessant seien kann.



    1 mal bearbeitet, zuletzt am 07.05.13 16:45 durch a user.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  11. Re: Absoluter Schwachsinn

    Autor DrWatson 07.05.13 - 16:45

    Auf das Problem wird doch schon im Artikel teilweise eingegeangen:

    Die Anwendung kennt den Benutzernamen und eine liste aus Passwörter (von denen eins das richtige ist)

    Ein anderer dienst, nenen wir ihn mal "Honeychecker" kennt gar nichts, sondern hat einen algorithmus, mit dessen hilfe sich aus er passwortliste schließen lässt, an welcher stelle das richtige passwort steht.

    Der Honeychecker bekommt also nur ein passwort und die passwort liste und sagt dann der Anwendung, ob das passwort richtig ist.

    Nehmen wir mal an, die Anwendung basiert auf linux und python, dann kann der honeychecker auf einer ganz anderen technologie basieren, z.B. OpenBSD + Haskell, er kann auch in hardware implementiert sein weil er so einfach ist.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  12. Re: Absoluter Schwachsinn

    Autor TheBigLou13 07.05.13 - 16:46

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    ...
    > Beispiel: Ein Benutzer verwendet das Passwort "passwort". Es hat da wenig
    > Sinn, wenn man da die Zeichen zufällig ersetzt. In einer Liste von
    > "gsa78aadh", "lasuausz", "zuzs9f8f" und "passwort" ist ziemlich
    > offensichtlich, welches Passwort nicht zu den anderen passt und demzufolge
    > der gültige Kandidat ist. (...)

    Was hälst du davon - das passwort "passwort" wird so überhaupt nicht abgelegt, sondern es werden 5 verfremdete varianten abgelegt:
    p4S5w0rt
    PA55woRT
    pAsSWOr7
    ...

    das original-pw "passwort" gibt es dementsprechend gar nicht. Die tabelle muss beim generieren in irgend einer form nur rausfinden, welches der 5 richtig ist - daher wäre hier die honeyword "generator"-frage schon geklährt, weil alle pws iwie gleich aussehen.
    Vor allem wenn man das nun nicht so stupide macht wie in dem beispiel grade, sondern zum beispiel nach einem zufälligen muster auf bitebene aus leserlichem text 5 unleserliche byte-ketten macht.

    da frag ich mich direkt - was ist an md5-verschlüsselten pws in der datenbank eigentlich auszusetzen?
    diese kriegt man doch idr eh nicht geknackt, wenn es nicht grade standard-pws sind, die eh schon alle crack-tools kennen wie "password, 123456, hallo welt"

    Benutzer wird von Ihnen ignoriert. Anzeigen

  13. Re: Absoluter Schwachsinn

    Autor Mingfu 07.05.13 - 16:50

    a user schrieb:
    --------------------------------------------------------------------------------
    > ich sehe das anders:
    >
    > 1. dein authentifizierungsserver muss und sollte nicht der gleiche sein auf
    > den du dich einloggst oder der die gesuchten daten enthält. d.h. zugriff
    > auf die passworthashes bedeutet nicht automatisch zugriff auf die daten.

    Das mag in einigen Fällen stimmen, in den meisten nicht. Denn eine abgeschottete Dreifachinfrastruktur - Daten, Passwörter, Honeywordpointer - sind die wenigsten Leute in der Lage schon rein aufwandsmäßig zu betreiben, vor allem nicht sicher. Und das ist ja genau das Problem: Es werden ja gezielt Dienste mit schwacher Sicherheit gesucht, um mit deren Listen dann bei besser gesicherten Diensten normale Anmeldungen vorzunehmen.

    > 2. die installation eines trojaners auf dem authentifizierungsserver kann
    > (leicht) entdeckt werden, bzw. auch aus ganz anderen gründen problematisch
    > sein.

    Trojanerentdeckung ist inzwischen alles andere als trivial geworden. Unter Windows sind kaum noch entdeckbare Rootkits absoluter Standard, unter Linux wird darüber nicht öffentlich gesprochen. Aber dass es inzwischen problemlos eingesetzt wird, zeigt ja gerade erst die Meldung zur Kompromittierung von Reisebuchungen. Eine große Problematik würde ich also dort nicht unterstellen, es ist nur im Moment nicht notwendig, dass man so vorgeht, weil man halt die Liste auch einfach so erhalten und nutzen kann. Eine neue Angriffsqualität würde es aber nicht bedingen.

    > 3. ich habe mir nicht angeschaut, wie die authoren sich die honeyword
    > generierung im einzelnen vorstellen. mag sein, dass sie verhaltensabhängige
    > eigenschaften nicht oder nur ungenügend berücksichtigen.
    > dann wäre daran noch zu arbeiten. ich hätte da schon ideen.

    So einfach ist das halt nicht. Sicher kann man einen gewissen Abdeckungsgrad durch Kombination verschiedener Möglichkeiten erhalten, wurde auch so vorgeschlagen. Aber für alle denkbaren Fälle dort Lösungen zu haben, die auch für jedes DAU-Passwort funktionieren, das ist unrealistisch. Und damit hat man das Problem, dass der Angreifer sich die sicheren Kandidaten aus der Liste heraussuchen kann. Es reicht ihm ja vermutlich, wenn er z. B. bei einem Bezahldienst 10 % aller Kundenkonten kompromittiert und damit Unfug macht - er muss ja gar nicht auf 100 % kommen. Während du für jedes denkbare Passwort eine sichere Honeywordgenerierung brauchst, braucht der Angreifer meist nur für eine viel geringere Anzahl eine sichere Entscheidungsmöglichkeit. Das ist also ein sehr asymmetrischer Krieg mit dir auf der schlechteren Seite.

    > 4. dein punkt 4 trifft nur zu, wenn du andere passwörter der nutzer bereits
    > kennst.
    > und eine garantie wäre es dann immer noch nicht. es reicht ein
    > honeypassword zu übersehen, und der hacker fällt auf, wenn er es benutzt.

    Nein, das hast du falsch verstanden. Wenn ich deine Passwortliste, inklusive Honeywords in die Hände bekomme (meinetwegen pro Benutzer 1 Passwort + 19 Honeywords), anschließend z. B. bei Google teste, welche der Benutzer dort gleiche Zugangsdaten verwenden, indem ich jeden Benutzernamen mit seinen 20 Passwortkandidaten durchprobiere, dann werde ich - falls der Benutzer bei beiden Diensten die gleichen Passwörter verwendet - genau das gültige Passwort finden, mit dem ich mich hinterher gefahrlos bei dir anmelden kann ohne Alarm auszulösen.

    Wenn Google keine Honeywords verwendet, ist das trivial - dann löse ich dort logischerweise nie Alarm aus. Falls Google Honeywords verwendet, dann sind es auf jeden Fall andere als du (denn wenn die Honeyworderzeugung einheitlich wäre, dann würde sie auch der Angreifer kennen können und damit die Honeywords selbst herausfinden). Damit würde ich also bei Google ebenfalls keinen Alarm auslösen. Selbst wenn es zufällig mal ein gleiches Honeyword wäre: Der Alarm wär bei Google, die sind aber gar nicht das eigentliche Ziel, sondern das bist du, der davon logischerweise nichts merkt. Denn zu dir komme ich erst hinterher wieder mit einer gültigen Liste aller wirklichen Passwörter, die ich bei Google bestätigen konnte.

    > und ob die passwörter nur geklaut werden, um einen anderen dienst zu hacken
    > ist wieder ne ganz andere geschichte.

    Das ist aber meist der eigentliche Knackpunkt. Die Gefahr ist ja oft gar nicht der ursprünglich kompromittierte Dienst. Nicht selten sind das irgendwelche Foren oder andere Belanglosigkeiten, die ihre Nutzerdaten verloren haben. Der Witz ist ja meist gerade, wo man diese Daten noch überall verwenden kann.



    1 mal bearbeitet, zuletzt am 07.05.13 16:53 durch Mingfu.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  14. Re: Absoluter Schwachsinn

    Autor Mingfu 07.05.13 - 17:15

    TheBigLou13 schrieb:
    --------------------------------------------------------------------------------
    > Was hälst du davon - das passwort "passwort" wird so überhaupt nicht
    > abgelegt, sondern es werden 5 verfremdete varianten abgelegt:
    > p4S5w0rt
    > PA55woRT
    > pAsSWOr7
    > ...

    Das nützt dir leider gar nichts. Wenn der Benutzer jetzt zur Anmeldung "passwort" eingibt, dann brauchst du ja auf dem Anmeldeserver ein deterministisches Verfahren, um auf das gültige Passwort aus der Liste zu kommen, um damit dann auch den Honeyword-Test zu bestehen. Wie willst du das machen, insbesondere auch so, dass der Angreifer keine Chance hat, diese Information zu erhalten? Ich hoffe jetzt nicht mit "das Verfahren muss man natürlich geheimhalten" - das wäre nur security by obscurity - keine gute Idee.

    > da frag ich mich direkt - was ist an md5-verschlüsselten pws in der
    > datenbank eigentlich auszusetzen?
    > diese kriegt man doch idr eh nicht geknackt, wenn es nicht grade
    > standard-pws sind, die eh schon alle crack-tools kennen wie "password,
    > 123456, hallo welt"

    Da bist du leider auf dem falschen Dampfer. Für MD5 ohne Salt gibt es fertige Tabellen mit denen man praktisch jedes Passwort augenblicklich ermitteln kann. Salt ist also absolute Grundvoraussetzung - also eine jeweils einzigartige, zufällige, ausreichend lange Zeichenfolge, die man nicht geheimhalten muss, aber die an das Passwort vor dem Hashen angehangen wird, um längst berechnete Standardtabellen nicht nutzen zu können. Salt im Klartext und der Hash aus Passwort + Salt werden dann gemeinsam gespeichert. Salt sollte idealerweise für jedes Passwort auch anders sein, damit der Angreifer für jedes Passwort einzeln Brute-Force-Angriffe führen muss und nicht einfach nur einen Angriff fährt und jeweils die ganze Liste gleich darauf abprüfen kann.

    Aber selbst wenn du das beachtest (und am besten statt MD5 auch die SHA-Familie nimmst), so ist meist genau das Problem, dass ein erstaunlich großer Anteil der Nutzer verdammt einfache Passwörter verwendet. Du kannst als Angreifer also mit dem Durchgehen von Passwortlisten (ggf. mit einigen Modifikationen, z. B. indem man noch eine Ziffer mit anhängt, ...) sehr schnell ans Ziel kommen und eine stattliche Anzahl Passwörter auf diese Weise ermitteln. Das liegt daran, dass eine Hashfunktion so ziemlich die ungünstigste Möglichkeit zur Sicherung derartiger Informationen ist. Denn Hashfunktionen sind darauf ausgelegt, sehr schnell sehr große Datenmengen verarbeiten zu können, denn das ist ja das Hauptanwendungsgebiet. Damit kann man aber auch sehr schnell und sehr einfach entsprechende Brute-Force-Angriffe darauf ausführen - zumindest wenn es nur so wenige Zeichen geht, wie es bei Passwörtern der Regelfall ist.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  15. Re: Absoluter Schwachsinn

    Autor a user 07.05.13 - 17:26

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > a user schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ich sehe das anders:
    > >
    > > 1. dein authentifizierungsserver muss und sollte nicht der gleiche sein
    > auf
    > > den du dich einloggst oder der die gesuchten daten enthält. d.h. zugriff
    > > auf die passworthashes bedeutet nicht automatisch zugriff auf die daten.
    >
    > Das mag in einigen Fällen stimmen, in den meisten nicht.
    1. ist das irrelevant. "erfindungen" werden nicht immer für die meisten fälle gemacht. für die meisten fälle ist ein smartcard zum anmelden am rechner mit kanonen auf spatzen geschossen. ich hab für meine kiste daheim sogar ein autologin.
    und die meisten nutzer bräuchten sich daheim auch nicht mit passwort zu authentifizieren.

    das macht es nicht unwichtig für firmenrechner.

    2. wenn ich mir so die news der letzten jahre anschaue, dann war ne verdammt große menge dabei, wo ausschließlich login daten geklaut wurden.

    > Denn eine
    > abgeschottete Dreifachinfrastruktur - Daten, Passwörter, Honeywordpointer -
    > sind die wenigsten Leute in der Lage schon rein aufwandsmäßig zu betreiben,
    > vor allem nicht sicher.
    das sehe ich anders.

    > Und das ist ja genau das Problem: Es werden ja
    > gezielt Dienste mit schwacher Sicherheit gesucht, um mit deren Listen dann
    > bei besser gesicherten Diensten normale Anmeldungen vorzunehmen.
    nein. das ist ein anderes problem. das paper will hier keine lösung bieten für alle probleme, die in der praxis vorkommen. es will einen baustein zur verbesserung beitragen.
    >
    > > 2. die installation eines trojaners auf dem authentifizierungsserver
    > kann
    > > (leicht) entdeckt werden, bzw. auch aus ganz anderen gründen
    > problematisch
    > > sein.
    >
    > Trojanerentdeckung ist inzwischen alles andere als trivial geworden. Unter
    > Windows sind kaum noch entdeckbare Rootkits absoluter Standard,
    öhm, was hat das mit dem was ich oben schrieb zu tun?
    wir reden hier von einem authentifizierungsserver und nicht von deinem heimpc.

    um von aussen ohne physischen zugriff einen trojaner zu installieren, der sich zwischen den systemkomponenten hängen kann, die die passwörter übermitteln/verarbeiten, bedarf es recht einschneidender änderungen am laufenden system, z.b. die betroffene software neustarten (d.h. auch systemsoftware). das kann man sehr leicht überwachen, insbesondere veränderungen am inhalt der systempartitionen.

    das ist natürlich bei einem heim-pc so nicht möglich. und bei windows ohne schwieriger, weil eine solche überwachung aufgrund der registry, die alles zusammenwürfelt nochmal um eine ganze ecke komplexer wird. aber genau wie deine aussage hierzu, ist das schleichtweg ein anderes thema.

    eine trojaner-installation von aussen auf einem server, der nur für die authentifizierung zuständig ist, ist nicht schwer.

    > unter Linux
    > wird darüber nicht öffentlich gesprochen.
    ich bitte dich. was soll der quatsch. natürlöich wird darüber öffentlich gesprochen, sogar WEIT öffentlicher als bei vorkommnissen unter windows.

    > > 3. ich habe mir nicht angeschaut, wie die authoren sich die honeyword
    > > generierung im einzelnen vorstellen. mag sein, dass sie
    > verhaltensabhängige
    > > eigenschaften nicht oder nur ungenügend berücksichtigen.
    > > dann wäre daran noch zu arbeiten. ich hätte da schon ideen.
    >
    > So einfach ist das halt nicht.
    sagt ja (noch) keiner. und? das macht es noch lange nicht zum "absoluten schwachsinn", was ich von deiner reduktion auf die nur dir bekannten szenarien, oder sagen wir die gewichtung der nur dir wichtigen szenarien nicht behaupten kann.

    > Sicher kann man einen gewissen
    > Abdeckungsgrad durch Kombination verschiedener Möglichkeiten erhalten,
    > wurde auch so vorgeschlagen. Aber für alle denkbaren Fälle dort Lösungen zu
    > haben, die auch für jedes DAU-Passwort funktionieren, das ist
    > unrealistisch. Und damit hat man das Problem, dass der Angreifer sich die
    > sicheren Kandidaten aus der Liste heraussuchen kann.
    anders als der honypotsteller darf der angreifer keinen fehler machen. ein honyword und das ziel ist erreicht.

    selbst wenn er die vermeintlich sicheren (was auch immer hier sicher bedeuten soll) bestimmen könnte, es könnte dennoch ein passendes honeyword dazu geben, auch wenn im allgemeinen es schwer ist eines für alle fälle zu bestimmen.

    > Es reicht ihm ja
    > vermutlich, wenn er z. B. bei einem Bezahldienst 10 % aller Kundenkonten
    > kompromittiert und damit Unfug macht - er muss ja gar nicht auf 100 %
    > kommen.
    wir reden hier wieder von einem speziellen szanrio, dass dir offenbar wichtig ist.

    ich wiederhole: honyword soll nicht alle dir wichtigen szenarien verbessern. die welt dereht sich nicht nur um das was du kennst oder was dir wichtig ist.

    > Während du für jedes denkbare Passwort eine sichere
    > Honeywordgenerierung brauchst, braucht der Angreifer meist nur für eine
    > viel geringere Anzahl eine sichere Entscheidungsmöglichkeit. Das ist also
    > ein sehr asymmetrischer Krieg mit dir auf der schlechteren Seite.
    >
    nur, wenn es um das eben obige szenario geht. du redest von einzelnen szenarien, in denen das honyword verfahren vieleicht nichts nützt. das macht es aber nicht absolut schwachsinnig!

    ein neues verfahren zur beschleunigung von feststoffrakten nützt den meisten auch nichts.

    > > 4. dein punkt 4 trifft nur zu, wenn du andere passwörter der nutzer
    > bereits
    > > kennst.
    > > und eine garantie wäre es dann immer noch nicht. es reicht ein
    > > honeypassword zu übersehen, und der hacker fällt auf, wenn er es
    > benutzt.
    >
    > Nein, das hast du falsch verstanden. Wenn ich deine Passwortliste,
    > inklusive Honeywords in die Hände bekomme (meinetwegen pro Benutzer 1
    > Passwort + 19 Honeywords), anschließend z. B. bei Google teste, welche der
    > Benutzer dort gleiche Zugangsdaten verwenden, indem ich jeden Benutzernamen
    > mit seinen 20 Passwortkandidaten durchprobiere, dann werde ich - falls der
    > Benutzer bei beiden Diensten die gleichen Passwörter verwendet - genau das
    > gültige Passwort finden, mit dem ich mich hinterher gefahrlos bei dir
    > anmelden kann ohne Alarm auszulösen.

    offenbar hab ich dich doch nicht falsch verstanden. aber du mich. aber das ist nich so wichtig.

    aber ich hoffe du erkennst selbst, warum dein vorschlag da oben sehr unpraktisch ist.... um es mal wie du asuzudrücken... in den meisten fällen.

    und wenn wir mal wieder deine kleine welt verlassen, und hier nicht von einem 0-8-15 web-dienst reden, wo nutzer die gleichen passwörter auch wo anders ntuzen, sondern z.b. vom enterpreis-xy-group-netzwerk (auf das auch externe zugreifen können), dann sind das zimlich sicher keine passwörter, die der nutzer wo anders auch nutzt. ich hab mit so etwas beruflich zu tun.

    > > und ob die passwörter nur geklaut werden, um einen anderen dienst zu
    > hacken
    > > ist wieder ne ganz andere geschichte.
    >
    > Das ist aber meist der eigentliche Knackpunkt.

    ehrlich, langsam reicht's

    erst beschimfst du die arbeit als absoluter schwachsinn und formulierst deinen post so, dass es in jedem szenario unbrauchbar ist und jetzt redest von den dir wichtigen und deiner meinung nach häufigsten szenarien und tust so, als ob alles was auf deine szenarien nicht anwendbar ist keine daseinsberechtigung hat.

    nein, die welt hat auch noch ganze andere bedürfnisse und anwendungsfälle als du sie kennst!




    1 mal bearbeitet, zuletzt am 07.05.13 17:26 durch a user.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  16. Re: Absoluter Schwachsinn

    Autor DrWatson 07.05.13 - 17:41

    a user schrieb:
    --------------------------------------------------------------------------------
    > um von aussen ohne physischen zugriff einen trojaner zu installieren, der
    > sich zwischen den systemkomponenten hängen kann, die die passwörter
    > übermitteln/verarbeiten, bedarf es recht einschneidender änderungen am
    > laufenden system, z.b. die betroffene software neustarten (d.h. auch
    > systemsoftware). das kann man sehr leicht überwachen, insbesondere
    > veränderungen am inhalt der systempartitionen.

    Genau das. Vor allem in Cloud-Umgebungen werden häufig fertige Images verwendet.

    Man spaziert nicht so einfach in Read-Only-Images!

    Benutzer wird von Ihnen ignoriert. Anzeigen

  17. Re: Absoluter Schwachsinn

    Autor Mingfu 07.05.13 - 17:42

    Ich glaube, es hat wenig Sinn auf dem Niveau weiter zu diskutieren. Ich möchte eigentlich nicht einen Wettstreit aufnehmen, wer mehr Formatierungstags auf seinen Text anwenden kann.

    Ich nehme zur Kenntnis, dass es für dich kein Problem ist, sichere absolut heterogene und gegeneinander vollständig abgeschottete Systeme zu betreiben, Trojaner zu erkennen, zu einem Passwort vergleichbare ununterscheidbare Passwörter zu generieren und Nutzer dazu zu bringen, ihre Passwörter für jeden Dienst individuell zu wählen.

    Aus einer solch luxeriösen Position heraus, kommen natürlich Spielereien zum Vertreiben der Langweile gerade recht. Ich beschäftige mich dann aber doch lieber mit praxisrelevanten Szenarien.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  18. Re: Absoluter Schwachsinn

    Autor DrWatson 07.05.13 - 17:49

    Viel Spaß Captain Resignation!

    Du hast sicher mehr Ahnung als Ari Juels und Ronald Rivest.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  19. Re: Absoluter Schwachsinn

    Autor a user 07.05.13 - 17:50

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > Ich glaube, es hat wenig Sinn auf dem Niveau weiter zu diskutieren.
    warum fängst du dann mit so etwas schon in der titelzeile an?

    > Ich nehme zur Kenntnis, dass es für dich kein Problem ist, sichere absolut
    > heterogene und gegeneinander vollständig abgeschottete Systeme zu
    > betreiben, Trojaner zu erkennen, zu einem Passwort vergleichbare
    > ununterscheidbare Passwörter zu generieren und Nutzer dazu zu bringen, ihre
    > Passwörter für jeden Dienst individuell zu wählen.
    OO DAS ist es was du verstanden hast?

    nun, in dem fall hat dies tatsächlich keinen sinn.

    ich meine wenn ich 100 mal betone, dass es verschiedene szenarien gibt und nicht alle so aussehen, wie du das kensnt und du daraus machst, dass ich jetzt ganz allgemeine ohne probleme jeden dienst auf der welt so konfigurieren kann und nutzer dazu bringen kann für jeden dienst einzigartige passwörter zu generieren (woher du das hast ist mir schleierrhaft, aber ich kann dir sagen, das konzerne wie bmw, vw für die passwortgestützten externen zugriffe spezielle auflagen haben, die garantieren, dass du wo anders ähnliche passwörter sicher nicht verwendest),
    dann weiß ich auch nicht weiter.

    denn dann sollte man dir erst einmal das lesen beibrigen, bevor du über paper mit security als thema urteilen darfst.
    >
    > Aus einer solch luxeriösen Position heraus, kommen natürlich Spielereien
    > zum Vertreiben der Langweile gerade recht. Ich beschäftige mich dann aber
    > doch lieber mit praxisrelevanten Szenarien.

    hier haben wir es wieder: deine praxis ist nicht die praxis der ganzen welt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  20. Re: Absoluter Schwachsinn

    Autor a user 07.05.13 - 17:52

    wenigstens passt der titel des thread zum author.

    am anfang hatte ich ja noch verständnis und dahcte man könnte diskutieren. es kann leicht passieren, dass man die welt nur aus dem eigenen bedarf heraus sieht.

    aber er scheint absolut resistent dagegen zu sein zu erkennen, dass es noch weit mehr auf dieser welt gibt als seine web-dienste.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


IPv6: Der holprige Weg zu neuen IP-Adressen
IPv6
Der holprige Weg zu neuen IP-Adressen
  1. Containerverwaltung Docker 1.2 erlaubt Regelung von Containerneustarts
  2. Stellenanzeige Facebook will Linux-Netzwerkstack wie in FreeBSD
  3. Für Azure Microsoft gehen US-IPv4-Adressen aus

Formel E: Motorsport zum Zuhören
Formel E
Motorsport zum Zuhören

Raspberry B+ im Test: Sparsamer Nachfolger für mehr Bastelspaß
Raspberry B+ im Test
Sparsamer Nachfolger für mehr Bastelspaß
  1. Erweiterungsplatinen Der Raspberry Pi bekommt Hüte
  2. Odroid W Raspberry Pi-Klon für Fortgeschrittene
  3. Eric Anholt Langsamer Fortschritt bei Raspberry-Pi-Grafiktreiber

  1. Deutsche Grammophon: Klassik streamen mit bis zu 320 Kbps
    Deutsche Grammophon
    Klassik streamen mit bis zu 320 Kbps

    Klassische Musik aus dem Katalog des traditionsreichen Schallplattenlabels Deutsche Grammphon im Stream: Das ermöglicht die App DG Discovery, die jetzt für iOS verfügbar ist.

  2. Alibaba: Milliardenschwerer Börsengang wohl Mitte September
    Alibaba
    Milliardenschwerer Börsengang wohl Mitte September

    Es könnte der größte Börsengang der US-Geschichte werden - und dabei handelt es sich bei Alibaba um ein chinesisches Unternehmen. Jetzt mehren sich die Hinweise, dass der IPO für Mitte September 2014 geplant ist.

  3. Test Infamous First Light: Neonbunter Actionspaß
    Test Infamous First Light
    Neonbunter Actionspaß

    Gleiche Stadt, andere Superkräfte: Die alleine lauffähige Erweiterung First Light für das letzte Infamous hat schick-bunte Grafik, eine schwungvolle Story - und endlich eine sympathische Hauptfigur.


  1. 13:09

  2. 12:21

  3. 12:20

  4. 11:52

  5. 11:31

  6. 19:04

  7. 18:14

  8. 18:00