“Ich bin eingelookt!”
Dies werden Sie in Zukunft vielleicht öfter hören. Und damit ist nicht “eingeloggt” gemeint, sondern SecLookOn.
“Ein Bild schützt mehr als 1000 Passwörter” heißt es dort, doch wie funktioniert das eigentlich?
Bevor ich hier lange herumschwafle, los gehts mit der Schlüsselerzeugung:
Man wählt im folgenden 2 Mal ein Bild, das man sich leicht merken kann und dazu eine Eigenschaft z.B. die Hintergrundfarbe und legt diese als bsp. blau fest. Ich habe den Taschenrechner (Eigenschaft: blaue Form) und das Lüftungsgitter (Eigenschaft: grüner Hintergrund) gewählt.
Nun wählt man eine Eigenschaft, wenn beide Bilder angezeigt werden und wenn keines der beiden gewählten angezeigt wird.
Nun wählt man 6 Orte an denen die Bilder vorkommen können, diese muss man sich merken, alle anderen angezeigten Orte beim Login, sind dann nicht zu beachten. Der Einfachheit halber, habe ich mir die Bilder links und die Eigenschaft rechts symmetrisch angeordnet.
Die Schlüsselerstellung ist jetzt fertig und man kann ihn noch testen, rechts wird der Schlüssel nochmals zur Hilfe eingeblendet.
Login:
Um den Login auszuprobieren gibt es auf dieser Seite 2 fixe Accounts.
Wir verwenden Key-User-D2, den Schlüssel für diesen User findet man im PDF (rechts auf der Seite).
Benutzernamen eingeben
Und dann mehrmals das “Memory” auflösen, im Bsp. hier für User Key-User-D2:
Männlein und Weiblein kommen vor, die Hand nicht. D.h. die Form dafür ist laut obigem PDF der Schmetterling (könnte nat. auch die Hintergrundfarbe oder andere Dinge sein, je nachdem was mein bei der Schlüsselerzeugung eingegeben hat) und dieser hat die Nummer 0. Man klickt auf “0″ und dann das ganze noch ein paar Mal…
Und dann…
Laut SecLookOn soll diese Art der Authentifizierung “Hackerfest” sein. Es wurde auch ein Hackwettbewerb ausgeschrieben, doch es hat niemand geschafft das System zu knacken.
Bin mal gespannt ob sich das System in Onlineshops oder bei Banken etablieren wird 
Super, vielen Dank für den Artikel
Wir wissen mittlerweile alle, dass Seclookon ein Griff ins Klo war…
Aber, wenn ich noch ein Kommentar lesen muss, wo die Rede von Jackson ist, dann werde ich den Post kommentarlos löschen! Das Gequatsche über ihn geht mir massiv auf die Eier. Ende der Durchsage!
Der Vergleich mit Michael Jackson war ja gerade zu prophetisch. Michael Jackson lebt nicht mehr und SecLookOn ist wohl auch den Weg allen Irdischen gegangen. Auf der Homepage ist die letzte News fünf Monate alt, die Link-Seiten führen größtenteils ins Nirvana und für WebLookOn und SecLookOn gibt es mittlerweile Anleitungen, wie man aus zwei bis drei beobachteten Logins den Schlüssel ableitet. Bei SecLookOn kann man den Schlüssel sogar herausfinden, ohne die Antworten zu kennen, die schlechten statistischen Eigenschaften der präesentierten Challenges reichen schon. Und dies waren nur die Ergebnisse von wenigen Betrachtungen, da SecLookOn ja kaum Beachtung erfahren hat. Zurecht, wie sich jetzt zeigt. Unglaublich, dass man heutzutage noch Konzerne findet, die sowas ohne jede Untersuchung implementieren … scheinbar ist das Sicherheitsdenken immer noch nicht in den Köpfen angekommen.
Mein Gott, SecLookOn gibt es immer noch? Erst das Comeback von Michael Jackson und jetzt das. Der gute Herr Schluderbacher, der hier auf edlen Ritter macht, ist schon vor einem Jahr ganz negativ aufgefallen, als er seine unbewiesenen Behauptungen bei Wikipedia als Fakten eingetragen hat. Da fanden sich die gleichen wertlosen Argumente zu Steganographie und Co. die genauso fix von der Community widerlegt wurden.
NStJ: SecLookOn ist schon relativ alt, so ca. vier bis fünf Jahre denke ich (…).
Schludi: Dies ist völlig falsch dargestellt.
Selbst auf der Homepage von SecLookOn stehen Presseartikel von 2004. So oft ich auch rechne, für mich sind das fünf Jahre.
Schludi: Dies ist falsch dargestellt. Statische Passwörter haben statischen Hash. Auch mit ?Salt? verschiebt sich nur der Hash-Wert, das Ergebnis bleibt statisch.
Himmel, wie kommt man auf sowas? Das sich mit Salt lediglich der Hash-Wert “verschiebt” kann als Zeugnis für völlige Ahnungslosigkeit in der Kryptanalyse gesehen werden. Schon einmal etwas von Diffusion und Konfusion gehört? OK, Konfusion ist wahrscheinlich ein alter Bekannter
Mal im ernst, was ändert das an der völlig korrekten Feststellung, dass der SecLookOn-Server den Schlüssel kennt, eine Passwort-Lösung aber bei gehashten Passwörtern nicht?
Schludi: Das ?kein gutes Design? teilen wir uns derzeit übrigens mit allen Token-Herstellern.
Deren Produkte im Gegensatz zu SecLookOn niemals ohne einen weiteren Faktor genutzt werden.
Schludi: Private- & Publik-Key Konzepte sind übrigens sehr aufwändig
Ja, und? Wenn man etwas sicher machen will, muss man Aufwand betreiben. Ist halt so.
NSt.J: Es scheidet also als alleiniges Zugangsverfahren für jede größere Nutzergruppe und in speziellen Umgebungen aus.
Schludi: Hervorzuheben ist, dass hier sehr geschickt Behauptungen als Fakten präsentiert werden ?? ist kein gutes Design ?? die dann später zur Beweisführungen verwendet werden ?? scheidet also ? aus ??. Sehr geschickt und manipulativ.
Wo wird da was verknüpft? Und wie lautet die Antwort auf den berechtigten Einwand, dass in einer großen Gruppe nicht alle das Verfahren werden nutzen können?
NStJ: Es gibt im Gegensatz zu den heute eingesetzten Protokollen keine langjährige Forschung oder wissenschaftliche Erkenntnisse.
Schludi: Nach dieser Darstellung wäre keine einzige Innovation möglich und wir wären heute noch auf den Bäumen. Ein Rad wäre nicht auch heute nicht erfunden, da vor einem Einsatz jahrelange Erfahrung fehlt ?
Hier geht es aber um Sicherheit und um Dinge die man tun könnte aber nicht getan hat. Ich kann mich nicht entsinnen, dass man Airbag und ABS einfach mal so in der freien Wildbahn getestet hat und gleich mit Einführung behauptet hat, die seien sicherer als alles bisher dagewesene.
Schludi: Falsch, für blinde Personen und andere Personen gibt es einen eigenen Zugang.
Das mag sein, sie haben einen EIGENEN sprich anderen Zugang, vielleicht einen unsichereren? SecLookOn nutzen sie jedenfalls nicht.
Schludi: Sonst müssten wir auch Youtube, Windows und Co. verschrotten.
Was ist denn das für ein Vergleich? Darf ich diese Menschen von weiteren Dingen ausschließen, weil sie andere sowieso nicht nutzen können? Ziemlich verdreht.
NStJ: Der Hersteller behauptet einfach, dass es sicher sei ?
Schludi: Es gibt eine unabhängige Studie darüber die gerade dies nachweist.
Wo? Im letzten Jahr wurde ein Gutachten Von Th. Dübendorfer angepriesen, dass aber nur die theoretischen Schlüsselmöglichkeiten beschreibt und keine holistischen Aussagen über die Sicherheit trifft. Auf der Homepage wird weiterhin nur dieses Gutachten erwähnt. Was wurde nun in dieser Studie untersucht und wer hat sie durchgeführt?
NStJ: ? versteckt sich hinter Stenografie und Zero Knowledge, obwohl das Verfahren keine Zero-Knowledge-Eigenschaften und keine steganografischen Elemente hat.
Schludi: Zero Knoledge wurde nicht behauptet, sondern in einem Vergleich erwähnt.
Und damit hat man versucht, sich dies zu Nutze zu machen. SecLookOn hat nicht mit ZK zu tun, deshalb verbietet sich auch ein Vergleich.
Schludi: Was für ein unglaublicher Schwachsinn. Steganografie soll nur dann Steganografie sein wenn es keiner weiß bzw. vermutet?
Jep, so ist es definiert, sonst nennen wird das im allgemeinen Verschlüsselung. SecLookOn hat keins von beiden.
Schludi: Die heute üblichen geheimen gelben Punkte der Laserdrucker sind damit keine Steganigrafie weil ich es hier schreibe und veröffentliche?
Das sind Wasserzeichen. Davon abgesehen verändert eine aufgedeckte Nachricht nichts daran, dass sie mal versteckt werden/sein sollte. Bei SecLookOn passiert nichts dergleichen.
Schludi: Stenganografie soll nur mit Buchstaben möglich sein und nicht mit Bildern?
Wer lesen kann ist klar im Vorteil. Wo wurde so was hier behauptet? Oben steht doch sogar: Steganographie (…) kann z.B. in einem Bild passieren.
Schludi: Dies ist so lächerlich, dass es schon fast witzig wäre.
Hat schon jemand das Glashaus-Gleichnis gebracht? Würde sich gerade anbieten.
Aber egal, den abwegigen Quatsch über Kerckhoffsche Steganographie braucht man wirklich nicht mehr kommentieren. Genau die Diskussion hatten wir letztes Jahr auf Wikipedia. Was daran am Witzigsten ist: Tausende von hilflosen Buchstaben werden geopfert, um hier Unsinn über vermeintliche Steganographie zu verfassen. Aber ich finde kein einziges Wort als Antwort auf die oben sehr schön beschriebenen Man-in-the-Middle- und Phishingangriffe.
NStJ: Responses und One-Time-Keys müssen zusätzlich gespeichert werden.
Schludi: Hier fehlt es offensichtlich an Verständnis, denn der Response IST der One-Time-Key und ist gerade einmal für eine kurze Zeitdauer gültig und nur für diese Dauer vorhanden.
Und für diese muss er gespeichert werden, um ihn prüfen zu können, das ist zusätzlicher Aufwand, da hat Nigel schon ganz recht. Und auch nach meinem Verständnis gibt der Nutzer die Response. Die IST nur dann der One-Time-Key, wenn die Eingabe stimmt. Also muss ich beides zwecks Vergleich speichern.
Schludi: Einen kurzer Ausflug in die Geschichte: Warum gibt es überhaupt 2 Faktor Authentifizierung?
Weil ein Token nur Besitz ist, damit nicht an eine Person gebunden ist und damit schlecht. Ein Passwort allein zu unsicher und damit auch schlecht.
Verständnisfrage: Wo bleibt der Ausflug in die Geschichte?
Schludi: Die Lösung: Man mache aus zwei schlechten Ansätzen eine bessere Lösung.
Aha. Was hat das mit SecLookOn zu tun, das nur einen dieser “schlechten Ansätze”, nämlich das Wissen nutzt?
Schludi: Eine gute wissensbasierte Lösung wie SecLookOn oder eine biometrische Lösung ist schon von sich aus personenbezogen. Ein zweiter Faktor ist damit nicht notwendig.
Wissen kann immer weitergegeben oder z.B. abgehört werden, das gilt auch für den SecLookOn-Schlüssel bei der Vereinbarung, es ist niemals von sich aus personenbezogen. Bei Biometrie werden nur Merkmalskombinationen gespeichert und übertragen. Dies kann manipuliert werden, der Absendepunkt müsste unter Kontrolle des prüfenden Systems stehen, das klappt nicht.
Die 2-Faktor-Authentifikation ist nicht umsonst ein so anerkanntes Prinzip.
Schludi: Ich könnte die ganze Zeit so weiter schreiben.
Glaub ich gern. Inhalt wird ja nicht benötigt, von daher kann man das sicher lange durchhalten.
Schludi: Und ich brauche mich für meine Aussagen nicht hinter einem Pseudonym verstecken.
Naja, dumm war es ja nicht, wenn man sonst gleich verklagt wird.
Wer nur solche Argumente hat bzw. keine, für die man sich keine eigene Phantasiewelt ausdenken muss, dem bleibt wohl wirklich nur übrig, gegen alle vorzugehen, die den Mund aufmachen. Viel Glück dabei.
[Ich entschuldige mich für den Ton dieses Beitrags, aber wer so unverschämt austeilt, der muss auch einstecken können. Nebenbei bemerkt wäre Entschuldigung auch ein gutes Stichwort für Herrn Schluderbacher.]
Ich möchte mich zu Seclookon nicht weiter äußern. Dem Verfasser der meinen Beiträgen zugrunde liegenden Analyse wurden von Herrn Schluderbacher massive rechtliche Konsequenzen angedroht. Zwar ist alles kritisierte objektiv wahr und nachvollziehbar, dennoch komme ich natürlich der Bitte nach, kein Öl in ein Feuer zu gießen, das unter Umständen eine Gerichtsverhandlung anheizen wird.
Ich bitte eindringlich darum, dass sich jeder Interessierte auf Grundlage der hier im Forum gelieferten Denkanstöße eine eigene Meinung bildet.
That?s (really) all Folks!
NStJ
Vorab, mein Name ist Helmut Schluderbacher und ich bin der Erfinder des Verfahrens SecLookOn. Seit kurzem treibt unter dem Namen Nigel St. Jones aber auch unter anderen Namen ein mir seit gestern bekannter Herr mit extrem negativen aber vor allem unrichtigen Informationen im Internet sein Unwesen. Er hat noch gestern ein Schreiben von mir erhalten und ich werde je nach Faktenlage (Informationen und Aussagen die ich noch entdecken werde) dagegen vorgehen.
Doch nun zu den “Informationen” die Herr NStJ hier hinterließ.
NStJ: SecLookOn ist schon relativ alt, so ca. vier bis fünf Jahre denke ich und wird vom Entwickler seitdem recht erfolglos beworben.
Dies ist völlig falsch dargestellt. Wir hatte ein lange Entwicklungszeit (für eine Innovation übrigens üblich) und haben seit Ende 2008 endlich die fertige Version welche auch sofort bei einer großen renommierten Firma zum Einsatz kommt.
NStJ: Dies ist kein gutes Design, heutzutage kennt ein System idealerweise nur einen Hashwert des Geheimnisses oder braucht das Geheimnis gar nicht (privater Schlüssel).
Dies ist falsch dargestellt. Statische Passwörter haben statischen Hash. Auch mit “Salt” verschiebt sich nur der Hash-Wert, das Ergebnis bleibt statisch. Das “kein gutes Design” teilen wir uns derzeit übrigens mit allen Token-Herstellern. Erzählen Sie den renomierten Firmen über diese Aussage, sie werden ein müdes Lächeln ernten. Bei Token geht es übrigens nicht anders. Private- & Publik-Key Konzepte sind übrigens sehr aufwändig (Siehe Signaturkarte) und benötigen in jedem Fall auf beiden Seiten Computer. D.h. nicht die Personen authentifizieren sich sondern die Rechner.
NSt.J: Es scheidet also als alleiniges Zugangsverfahren für jede größere Nutzergruppe und in speziellen Umgebungen aus.
Hervorzuheben ist, dass hier sehr geschickt Behauptungen als Fakten präsentiert werden “… ist kein gutes Design …” die dann später zur Beweisführungen verwendet werden “… scheidet also … aus …”. Sehr geschickt und manipulativ.
NStJ: Es gibt im Gegensatz zu den heute eingesetzten Protokollen keine langjährige Forschung oder wissenschaftliche Erkenntnisse.
Nach dieser Darstellung wäre keine einzige Innovation möglich und wir wären heute noch auf den Bäumen. Ein Rad wäre nicht auch heute nicht erfunden, da vor einem Einsatz jahrelange Erfahrung fehlt …
NStJ: Außerdem können blinde Menschen SecLookOn nicht nutzen. …
und später weiter
… dass in größeren Gruppen immer Menschen mit verschiedenen Defiziten auftauchen werden, eben z.B. blinde oder Menschen mit Assoziationsstörungen, Personen, die sich aufgrund der von Dir dargelegten Usability-Schwächen überfordert fühlen etc.. Deswegen hat SecLookOn unter Anti-Diskriminierungsgesichtspunkten in Behörden, in Firmen mit Betriebsräten etc. nicht wirklich große Chancen.
Falsch, für blinde Personen und andere Personen gibt es einen eigenen Zugang. Sonst müssten wir auch Youtube, Windows und Co. verschrotten. Für jede Nutzergruppe gibt es die geeignete Unterstützung.
NStJ: Der Hersteller behauptet einfach, dass es sicher sei …
Falsch. Es gibt eine unabhängige Studie darüber die gerade dies nachweist.
NStJ: ? versteckt sich hinter Stenografie und Zero Knowledge, obwohl das Verfahren keine Zero-Knowledge-Eigenschaften und keine steganografischen Elemente hat.
Beides falsch. Zero Knoledge wurde nicht behauptet, sondern in einem Vergleich erwähnt. Dies war NStJ sehr wohl bewußt da er es noch selbst zitiert: “… challenge and response CLOSE to a zero knowledge procedure.”
NStJ: ROFL … Steganographie bedeutet, dass das Vorliegen einer Nachricht selbst versteckt wird, das kann z.B. in einem Bild passieren. Ein Beobachter des Bildes soll nicht die Nachricht nicht verstehen oder nicht entschlüsseln können, er soll gar nicht merken, DASS überhaupt eine Nachricht da ist. SecLookOn hat nichts mit Steganographie zu tun, nur weil Bilder darin vorkommen. Ein Beobachter weiß, dass eine Authentifizierung stattfindet, diese wird nicht versteckt.
Was für ein unglaublicher Schwachsinn. Steganografie soll nur dann Steganografie sein wenn es keiner weiß bzw. vermutet? Also eine Modifikation einer Audio-Datei ist nur dann Steganografie wenn es keiner weiß? Eine Modifikation einer Bilddatei ist nur dann Stegenografie wenn keiner die Idee hat es könnte etwas drinnen sein? Die heute üblichen geheimen gelben Punkte der Laserdrucker sind damit keine Steganigrafie weil ich es hier schreibe und veröffentliche? Stenganografie soll nur mit Buchstaben möglich sein und nicht mit Bildern? Dies ist so lächerlich, dass es schon fast witzig wäre.
NStJ: Auguste Kerckhoff sagte hingegen, dass ein Verfahren niemals darauf beruhen soll, dass irgendetwas außer dem Schlüssel verheimlicht wird. Von daher gibt es kein ?Kerckhoffsches Prinzips der grafischen Steganographie?.
Falsch dargestellt bis völliger Unsinn. Das Kerckhoffs?sche Prinzip besagt, dass die Sicherheit eines geheimen Verfahrens einzig und allein auf der Geheimhaltung des Schlüssels beruhen darf, und nicht auf der Geheimhaltung des Verschlüsselungsalgorithmus. Das bedeutet nicht mehr und nicht weniger als dass auch wenn ich vermute oder weiß, dass eine Nachricht enthalten ist und ich auch über die Art und Weise des Algorithmus Bescheid weiß, ich dennoch nicht die Botschaft erkennen darf. Und selbstverständlich gelten diese Prinzipien auch für die Steganografie.
NStJ: Das System ist überaus aufwändig und schlecht gegen Denial-of-Service-Angriffe zu schützen.
Ein typische Behauptung die zeigt wie unseriös hier vorgegangen wird. Natürlich gibt es unterschiedliche Arten von DoS-Angriffen. Für manche ist ein höherer Rechneraufwand notwendig, bei anderen ist SecLookOn sogar wesentlich besser.
NStJ: Responses und One-Time-Keys müssen zusätzlich gespeichert werden.
Hier fehlt es offensichtlich an Verständnis, denn der Response IST der One-Time-Key und ist gerade einmal für eine kurze Zeitdauer gültig und nur für diese Dauer vorhanden.
NStJ: … sondern ausschließlich wissensbasiert und damit gibt es nur einen Faktor …
Einen kurzer Ausflug in die Geschichte: Warum gibt es überhaupt 2 Faktor Authentifizierung?
Weil ein Token nur Besitz ist, damit nicht an eine Person gebunden ist und damit schlecht. Ein Passwort allein zu unsicher und damit auch schlecht.
Die Lösung: Man mache aus zwei schlechten Ansätzen eine bessere Lösung.
Eine gute wissensbasierte Lösung wie SecLookOn oder eine biometrische Lösung ist schon von sich aus personenbezogen. Ein zweiter Faktor ist damit nicht notwendig.
Ich könnte die ganze Zeit so weiter schreiben.
Und ich brauche mich für meine Aussagen nicht hinter einem Pseudonym verstecken.
Es ist fast dasselbe wie Seclookon. Allerdings war Seclookon wohl zu kompliziert, deswegen hat man bei Weblookon die Bereiche und die Zweiteigenschaften weggelassen. Damit vermindert man aber auch die Sicherheit.
Im Ergebnis verwendet Weblookon das gleiche Prinzip und hat die gleichen Schwächen. Allerdings ist Weblookon wegen der fehlenden Bereiche “schlimmer”, denn nach ein paar Beobachtungen hat man aus den sechs Bildern den Schlüssel ermittelt. Vielleicht meinte der Poster “Kein Name” oben dieses System mit seinem Kommentar. Bei Weblookon gibt es endgültig keinen Grund mehr, die Lösung gegenüber Passwörtern zu bevorzugen, trotzdem hat man die skizzierten Mängel.
That?s all Folks!
NStJ
Ich hab jetzt mal kurz drüber geschaut.
Meiner Meinung nach ist es genau dasselbe wie SecLookOn?!
hab mir das ganze da oben durchgelesen. sicher hin oder her, die passwortlösungen sind alle beschissen. seit kurzem gibts eine neue – auch grafische methode- die sicherlich mit seclookon verstrikt ist, jedoch ganz eindeutig nur das passwort im internet beseitigen will. mehr nicht. denke die lösung hat eine riesen zukunft. schaut mal da rein. http://www.weblookon.com
gruizi mitnant
Hallo Unifuzz,
danke für den Beitrag, auf Deine Fragen gehe ich gerne ein.
> ? nicht universell einsetzbar?. Passwörter, Token, Biometrie sind
> ebenfalls nicht universell einsetzbar.
Aber Sie können eigentlich an jeder Stelle eingesetzt werden, an der eine Authentifizierung notwendig ist. Mit SecLookOn geht das nicht, zum Beispiel kann man sich damit nicht an einem Betriebssystem anmelden, da dieses das Geheimnis im Klartext kennen müsste, dazu gleich mehr.
> ?jedes authentifizierende System muss grundsätzlich vor einem Login
> all jene Informationen haben, die notwendig sind um überhaupt eine
> authentifizierung durchführen zu können. (…) Und selbstverständlich
> liegt am Server zu jedem User auch die mit ihm verbundenen Geheimnisse
> vor.
Das ist korrekt, aber dazu gehört nicht zwingend das Geheimnis im Klartext wie bei SecLookOn, es reicht bei gut designten Systemen das Ergebnis einer Einwegfunktion, sprich ein Hashwert. Nimm z.B. Dein Betriebssystem. Du brauchst zur Anmeldung üblicherweise einen Benutzernamen und ein Passwort. Natürlich braucht Dein System folglich Informationen zum Passwort, aber es kennt Dein Passwort nicht, sondern lediglich das Ergebnis, wenn Dein Passwort als Input einer Einwegfunktion verwendet wird. SecLookOn hingegen benötigt das Geheimnis selbst und das ist unter Sicherheitsgesichtspunkten ein schlechtes Design.
> Nach eingehender Prüfung der von Google gemachten Studie über
> seclookon, fällt es mir sehr leicht zu behaupten, daß seclookon dies
> besonders sicher gelöst hat.
Witzig, ich höre immer von so einer Google-Studie. Witzig ist das deshalb, weil Google selbst keine derartige Studie kennt. Ich bitte um Informationen, von was hier gesprochen wird. Vor dem Hintergrund der bekannten Mängel kann ich auch nicht glauben, dass SecLookOn irgendetwas besonders sicher tut.
> ? Geheimnis muss im Klartext vorhanden sein??.. dies hat bei seclookon
> absolut gar keine Relevanz, da sämtliche Geheimnisse von Usern in
> anderer Form verschlüsselt und von aussen nicht zugänglich stets
> vorliegen.
Das hat sehr wohl Relevanz, eben weil SecLookOn das Geheimnis kennen muss. Wenn es verschlüsselt abgelegt wird, fein, aber dann muss SecLookOn auch den Schlüssel haben, das hilft überhaupt nicht.
> ?. Blinde Menschen ?.. leider gibt es blinde Menschen die ebenfalls
> Zugang zu Netzwerken brauchen.
Diese nutzen die elektronischen Medien sogar überproportional.
> Für blinde könnte man nach Bedarf eine Lösung entwickeln.
Richtig. Warum konzentriere ich mich dann nicht darauf, diese sichere Lösung gut zu designen und sie durch alle verwenden zu lassen?
> ? scheidet für grössere Benutzergruppe aus? ganz und garnicht,
Das bezog sich darauf, dass in größeren Gruppen immer Menschen mit verschiedenen Defiziten auftauchen werden, eben z.B. blinde oder Menschen mit Assoziationsstörungen, Personen, die sich aufgrund der von Dir dargelegten Usability-Schwächen überfordert fühlen etc.. Deswegen hat SecLookOn unter Anti-Diskriminierungsgesichtspunkten in Behörden, in Firmen mit Betriebsräten etc. nicht wirklich große Chancen.
> Bei seclookon besteht das Geheimnis zwischen User und Maschine aus
> mehreren Geheimnissen, die jedoch bei einer Abfrage durch die Maschine
> nie enttarnt werden.
Selbst wenn, trotzdem wissen wir nichts über die Sicherheit.
> Eines muss man auch besonders bei seclookon hervorheben. Es wird
> niemals das Geheimnis enttarnt,
Genau das ist völlig ungewiss. Die Firma, die das Verfahren anbietet sagt das so und viele glauben es, es wird aber nie ein Beleg dafür präsentiert.
> Von Zero Knowledge spricht seclookon nicht.
http://www.seclookon.com/seclookon/en_faq.asp: What is SecLookOn? A solution which does software based high secure authentication based on challenge and response close to a zero knowledge procedure.
> ?. Alles was bei seclookon visualisiert wird, basiert bzw. benutzt die
> Methoden des Kerckhoffschen Prinzips der grafischen Steganographie,
> dahinter natürlich auch der Algorithmus und Verfahren.
ROFL. Sorry, ich bemühe mich ja, ernsthaft und der Reihe nach auf alle Punkte einzugehen, aber bitte bitte bitte sprich niemals wieder vom “Kerckhoffschen Prinzips der grafischen Steganographie”, da weiß ich nicht, ob ich Lachen oder Weinen soll, weil das ein Widerspruch in sich ist: Steganographie bedeutet, dass das Vorliegen einer Nachricht selbst versteckt wird, das kann z.B. in einem Bild passieren. Ein Beobachter des Bildes soll nicht die Nachricht nicht verstehen oder nicht entschlüsseln können, er soll gar nicht merken, DASS überhaupt eine Nachricht da ist. SecLookOn hat nichts mit Steganographie zu tun, nur weil Bilder darin vorkommen. Ein Beobachter weiß, dass eine Authentifizierung stattfindet, diese wird nicht versteckt. Auguste Kerckhoff sagte hingegen, dass ein Verfahren niemals darauf beruhen soll, dass irgendetwas außer dem Schlüssel verheimlicht wird. Von daher gibt es kein “Kerckhoffsches Prinzips der grafischen Steganographie”.
> Ich würde nicht unbedingt behaupten dass das System aufwändig ist. Es
> ist lediglich aufwändig für den User sich einmal sein Geheimnis zu
> merken. Beim Login spielt er dann seine Runden ab. Denial of Service
> wurde bei seclookon ebenfalls berücksichtigt.
Ich meine nicht den Aufwand auf der User-Seite, sondern den auf der Systemseite. Die Bearbeitung eines Logins ist bei SecLookOn um ein Vielfaches aufwändiger als bei traditionellen Verfahren, da für jeden Authentifizierungsversuch vier oder mehr grafische Challenges produziert werden müssen. Für jede Challenge ist dabei ein Zugriff auf das Geheimnis nötig, weiterhin wird guter Zufall benötigt und es sind verschiedene Verschiebefunktionen durchzuführen. Responses und One-Time-Keys müssen zusätzlich gespeichert werden. Eine Abwehr von DoS-Angriffen gestaltet sich schwierig, da der Authentifizierungsmechanismus ja gerade am Eingangspunkt zum Netzwerk aufgebaut wird.
> Also wie ein Man-i.t-Middle mit den Daten etwas anfangen kann müsstest
> du da einmal erklären.
Mache ich gern.
SecLookOn bietet auf das Login bezogen überhaupt keinen besonderen Schutz vor MitM-Attacken. Der Angreifer kann übertragene Informationen mitlesen oder auch die Session nach dem Login übernehmen. Dies gilt umso mehr, wenn dem Hinweis des Entwicklers gefolgt wird, SecLookOn könne ohne Verschlüsselung eingesetzt werden.
Wenn man eine Transaktion vornehmen will, die nach der Einwahl noch durch SecLookOn bestätigt werden muss, so macht man sich am einfachsten zu Nutze, dass man dem berechtigten Nutzer beliebige Challenges vorsetzen kann, die dieser für uns lösen wird. Aufgrund der Designschwächen von SecLookOn, insbesondere der Verwendung nur eines Geheimnisses, bemerkt der Nutzer dies nicht.
Beispiel: Der berechtigte Nutzer möchte sich mittels SecLookOn beim Online-Banking authentifizieren. Der Angreifer unterbricht die Verbindung von User und SecLookOn-Server und ruft selbst die SecLookOn-Seite mit der User-Identifikation des berechtigten Nutzers auf. Er erfährt, dass vier C/R-Runden für ein Login genügen. Dem berechtigten User zeigt er an, dass es Fehleingaben von einem vermutlich unberechtigten Einwahlversuch gegeben hat und der Nutzer nun 10 C/R-Runden durchführen müsse. Der Angreifer leitet vom Zielserver die vier tatsächlichen C/R-Runden vom richtigen Login weiter, die der User löst. Die vom User angegebenen Responses leitet der Angreifer wiederum an den Server weiter und ist nun eingewählt.
Um Zeit zu gewinnen, präsentiert er dem User zwei beliebige lösbare C/R-Runden, z.B. früher aufgezeichnete Challenges oder eine leichte Abwandlung von zwei der ersten vier Challenges. Währenddessen generiert der eingewählte Angreifer eine Transaktion, z.B. eine Überweisung. Wiederum stellt das System zur Bestätigung der Transaktion vier Challenges. Diese vier Challenges lässt der Angreifer als vermeintliche Login-C/R-Runden 7 bis 10 vom User lösen. Anschließend wird die Verbindung zum User getrennt, dieser bekommt mitgeteilt, dass das System leider wegen Störungen oder Wartungsarbeiten nicht zur Verfügung stehe. Dem Angreifer quittiert der Ziel-Server die Transaktion. Alternativ zur Transaktion kann der Angreifer je nach System auch eine Sperrung des Zugangs oder einen Schlüsselwechsel initiieren.
> Ebenso ist Pishing relativ sinnlos zu probieren.
Warum? Wie bei jedem rein wissensbasierten Verfahren kann das Geheimnis selbstverständlich gephisht werden.
> Das Sichere an seclookon ist es eben, das niemals das Geheimnis
> preisgegeben wird.
Tatsächlich? Schön. Denn hoffe ich mal, dass der Böse sich an die Spielreglen hält. Teil seiner Bösartigkeit ist aber, dass er uns den Gefallen nicht tut. Eine Phishing-Attacke auf SecLookOn würde z.B. nach der fingierten oder durchgeleiteten Einwahl (oder auch ohne eine solche) darum bitten, den SecLookOn-Schlüssel noch einmal zu bestätigen, z.B. unter dem Vorwand, dass der Schlüssel vom Nutzer in eine neue Datenbank gespeichert werden müsse. Der Nutzer gibt dann in einer der Schlüsselvereinbarung nachempfundenen Prozedur den vollständigen Schlüssel dem Angreifer gegenüber preis. Bitte nicht auf den Nutzer vertrauen, wir hatten auch schon erfolgreiche Phishing-Angriffe, bei denen gleich 10 TANs frei Haus geliefert wurden.
> Seclookon ist eine Zwei-Faktor Authentifizierungsmethode und als
> solche auch anerkannt. Warum?
Das würde ich auch gerne wissen, denn SecLookOn ist rein wissenbasiert und damit eine Ein-Faktor-Authentifizierung. Wer hat etwas anderes anerkannt?
> Dadurch dass der Login durch den User nicht durch eine einmalige
> Eingabe erfolgt, sondern durch die viermalige Eingabe wobei dazwischen
> das System jedesmal eine Prüfung macht, ist eine ZWEI-FAKTOR-
> Authentifizierung gegeben – wenn auch mehrheitlich Knowledgebased.
Nicht mehrheitlich, sondern ausschließlich wissensbasiert und damit gibt es nur einen Faktor oder was wäre denn bitte der zweite? Wenn ich immer nur verschiedene einzelne Buchstaben eines Passworts abfragen würde, macht das mein Passwort auch nicht zur Zwei-Faktor-Authentifizierung.
> Insgesamt ist seclookon eine absolut sichere Lösung,
Also als Security-Mensch erschrecke ich ja sowieso schon, wenn etwas absolut sicher sein soll, aber hier ganz besonders, da es keinen belastbaren Beleg für diese kühne Behauptung gibt und viel dagegen spricht.
That?s all Folks!
NStJ
zu Nigels Kommentar hab ich folgende Fragen bzw. Anmerkungen:
Bin zwar kein Verfechter dieser seclookon Lösung, aber dennoch nach eingehender Prüfung recht angetan davon. Was mir vorweg negativ auffällt ist
1. das mühselige Merken der Bilder und der Bedeutungen – also dem eigentlichen Geheimnis,
2. dass manche Bildschirme bzw. Lichtverhältnisse den Login erschweren,
3. dass die vielen Bilder und Symbole zu absoluter Verwirrung führen,
4. dass kein Proof of Concept vorgelegt werden kann (ausser der Anwender MAGNA- Autozulieferindustrie….sind ja alle Techniker)
aber ich kann nicht nachvollziehen was du geposted hast:
ad 1)
… nicht universell einsetzbar…. Passwörter, Token, Biometrie sind ebenfalls nicht universell einsetzbar. Ich denke, niemand kann heute den Anspruch stellen eine Lösung zu haben die universell einsetzbar ist.
…jedes authentifizierende System muss grundsätzlich vor einem Login all jene Informationen haben, die notwendig sind um überhaupt eine authentifizierung durchführen zu können. Das heisst nichts anderes als dass zumindest eine auslösende Aktion durch einen User gemacht werden muss. Bei Passwort/Username Lösungen ist dies schlichtweg die Eingabe von PW+UN und die Auslösung (Session) durch die Eingabetaste. In diesem Moment erhält das System nicht nur den “Befehl” etwas zu tun, sondern auch gleich den Vorschlag für die Prüfung der Richtigkeit des eingegebenen PW+UN.
Bei Seclookon ist dies genauso der Fall, da zu aller erst eine Session durch den User beantragt werden muss. Dies tut er indem er zB. einen Usernamen oder seine secLookon ID in ein Feld eingibt. Mit dieser Information kann das System eine erste Zuordnung machen und schlägt daraufhin eine Reihe von Bildern und Symbolen dem User vor. Selbstverständlich erfolgt dies am Server. Und selbstverständlich liegt am Server zu jedem User auch die mit ihm verbundenen Geheimnisse vor. Nach eingehender Prüfung der von Google gemachten Studie über seclookon, fällt es mir sehr leicht zu behaupten, daß seclookon dies besonders sicher gelöst hat. Wie sehr ein Server per se geschützt ist muss aus einem anderen Blickwinkel gesehen werden, denn dieser Schutz hat mit seclookon rein garnichts zu tun.
… Geheimnis muss im Klartext vorhanden sein…….. dies hat bei seclookon absolut gar keine Relevanz, da sämtliche Geheimnisse von Usern in anderer Form verschlüsselt und von aussen nicht zugänglich stets vorliegen.
…. Blinde Menschen ….. leider gibt es blinde Menschen die ebenfalls Zugang zu Netzwerken brauchen. Selbstverständlich sollen diese nicht davon ausgeschlossen sein. Die Mehrheit ist glücklicherweise nicht blind. Für Farbenblinde ist seclookon absolut einsetzbar. Für blinde könnte man nach Bedarf eine Lösung entwickeln.
… scheidet für grössere Benutzergruppe aus… ganz und garnicht, wäre nur die Oberfläche (GUI) von seclookon nicht nur so bescheuert und komplex. Ich bin sicher, dass man da einiges vereinfachen könnte. Seclookon scheint eine reine Inhouse Server Lösung zu sein, womit von vornherein ja die grössere Nutzergruppe ausscheidet. Ich denke aber, dass dieses Verfahren absolut “smashing” für den Login i Internet wäre, nur gibts da halt keine Lösung.
ad 2)
also bei diesem Punkt hast Du dich oder dein Freund nicht wirklich bemüht tiefer reinzusehen. Meinem Verständnis nach sagt seclookon nichts anderes, als dass bei jeder wissensbasierender Authentifizierungsmethode zuvor ein Geheimnis zwischen dem User und einer Maschine beschlossen werden muss. Beim Beispiel Passwort wäre dies eben das Passwort und der Username mit dem eine Maschine etwas anfangen kann und nach Erkennung/Prüfung eine Authorisierung vergeben kann.
Bei seclookon besteht das Geheimnis zwischen User und Maschine aus mehreren Geheimnissen, die jedoch bei einer Abfrage durch die Maschine nie enttarnt werden. Die Geheimnisse sind: 1. Bild, 2. Bild, die Bedeutung bei Erscheinen von Bild 1, die Bedeutung bei Erscheinen von Bild 2, die Bedeutung bei Erscheinen von Bild 1 und 2, die Bedeutung bei Erscheinen keines der Bilder 1 und 2, sowie die Platzierung der möglichen Kombinationen auf einer Matrix von 6 x 6 Bildern und Bedeutungen. Da sind also viele Geheimnisse versteckt.
Eines muss man auch besonders bei seclookon hervorheben. Es wird niemals das Geheimnis enttarnt, da lediglich One-Time-Codes das Wissen des Users über sein Geheimnis bestätigbar machen. Das System reagiert ja auch bei falscher Eingabe, indem es einfach noch eine Abfragerunde anhängt. …. Von Zero Knowledge spricht seclookon nicht. …. Alles was bei seclookon visualisiert wird, basiert bzw. benutzt die Methoden des Kerckhoffschen Prinzips der grafischen Steganographie, dahinter natürlich auch der Algorithmus und Verfahren.
ad 3)
Ich würde nicht unbedingt behaupten dass das System aufwändig ist. Es ist lediglich aufwändig für den User sich einmal sein Geheimnis zu merken. Beim Login spielt er dann seine Runden ab. Denial of Service wurde bei seclookon ebenfalls berücksichtigt.
ad 4)
Also wie ein Man-i.t-Middle mit den Daten etwas anfangen kann müsstest du da einmal erklären. Ebenso ist Pishing relativ sinnlos zu probieren. Ganz einfach deshalb, weil dann der Böse erst einmal die gesamte Software selbst haben müsste und aber auch gleichzeitig über alle Geheimnisse von Usern verfügen müsste. Das Sichere an seclookon ist es eben, das niemals das Geheimnis preisgegeben wird. Also der Böse für ein erfolgreiches pishing ja zunächst einmal dem User über das Wisse seines Geheimnisses abfragen müsste. Dies geht aber nicht da der Böse das Geheimnis ja nicht kennt.
Seclookon ist eine Zwei-Faktor Authentifizierungsmethode und als solche auch anerkannt. Warum? ein User muss zwar seine Geheimnisse (Mehrzahl!!) wissen > also wissensbasierend, gleichzeitig benötigt er aber auch eine Maschine die im zweiten, dritten und vierten Schritt weitere Geheimnisse abfrägt. Das klingt recht kompliziert ist es aber nicht wenn man einen Login mit seclookon nachvollzieht:
1. Schritt: user gibt einen Usernamen oder ID oÄ. ein und meldet sich somit bei seclookon an (1. Schritt wissenbasierend bei User)
2. Schritt: die Maschine erkennt den Usernamen oÄ. und sendet einen Vorschlag zur Prüfung über das Wissens ob des Geheimnisses (2. Schritt hardware)
3. Schritt: Der User weiss wie er die erste Abfrage beantworten muss, indem er einen One-Time-Code sequentiell per Tastatur eingibt. (3. Schritt Abfrage von Knowledge)
4. Schritt: das System reagiert nur insofern, als dass es eine weitere Abfrage sendet
5. Schritt: der User geht genauso vor wie bei Schritt 3
6. Schritt: wie Schritt 4
7.Schritt: wie Schritt 5 usw.
Nach vier oder mehr Abfragerunden bzw. Antworten vergleicht das System erst ob die Antworten des Users für die Authentifizierung ausreichen. Wenn ja ist der user eingeloggt, wenn nein dann werden weitere Abfragerunden angehängt.
Dadurch dass der Login durch den User nicht durch eine einmalige Eingabe erfolgt, sondern durch die viermalige Eingabe wobei dazwischen das System jedesmal eine Prüfung macht, ist eine ZWEI-FAKTOR-Authentifizierung gegeben – wenn auch mehrheitlich Knowledgebased.
Insgesamt ist seclookon eine absolut sichere Lösung, nur sehr fraglich ob sie in dieser vorliegenden Version ihren Weg in den Markt finden kann. Ein gigantischer Beitrag zu mehr Sicherheit im Netz wäre es wenn eine Abwandlung dieser Lösung – also einfacher, schneller und flexibler für den User – für das Internet zu Verfügung stünde. Vielleicht denkt diese Firma mal daran, daß es da viel mehr Möglichkeiten gäbe. Wie gesagt – das wäre eine tolle Sache. Grüße
Auch wenn ich dem Verfahren insgesamt Mängel attestieren muss, ist für mich nicht ohne Begründung einsichtig, wie man aus lediglich 30 Beobachtungen das Geheimnis ermitteln soll. Wenn die Felder gute statistische Eigenschaften aufweisen, dann weiß ich nach 30 Tafeln eigentlich gar nichts, weil ich ja nicht weiß, welche Felder die beobachtete Response enthielten. Das rettet das Verfahren insgesamt nicht, aber Fairness muss sein.
That’s all Folks!
NStJ
Und wie oft muss ich jemandem über die Schulter schauen, damit ich die Lösung für 30 Tafeln weiß?!
Da ist es schon einfacher von jemandem das PW abzugucken.
Außerdem: wenn du hier ein Kommentar abgibst, gib wenigstens einen richtigen Namen und eine g’scheite Maildadresse an – mit Sicherheit kein Spam!
Die Standardvariante (die man auf ihrer Seite testen kann) lässt sich einfach brechen sobald man die Lösung für ca 30 Tafeln kennt.
Vielen Dank für deine Ausführungen!
Wie ich das System damals gefunden habe, war ich erfreut, dass jemand mal Alternativen zu Passwörtern ausprobiert (ohne gleich auf Kartenleser u.ä. loszugehen), habe die Sicherheit oder Tauglichkeit aber auch nicht weiter hinterfragt.
Doch auch diesmal war’s keine brauchbare Option zu den guten alten Passwörtern.
Ich fürchte, es ist doch eine schlechte Idee. SecLookOn ist schon relativ alt, so ca. vier bis fünf Jahre denke ich und wird vom Entwickler seitdem recht erfolglos beworben. Die Fachpresse nimmt (zu Recht?) kaum Notiz von dem Verfahren. Ein Studienkollege hat gerade noch einmal die aktuelle Version untersucht und seine Analyse ist ziemlich vernichtend.
SecLookOn ist kaum geeignet, bestehende Authentifizierungsverfahren abzulösen. Warum ist das so?
1.) SecLookOn ist nicht universell einsetzbar. Es ist nicht für lokale Anmeldungen oder ein Offline-Authentifizierung geeignet, weil das authentifizierende System das Geheimnis bei der Erstellung der Challenges bereits kennen muss. Deshalb muss das Geheimnis im Klartext vorhanden sein und zwar bereits bevor die Identität des sich Authentifizierenden bestätigt ist. Dies ist kein gutes Design, heutzutage kennt ein System idealerweise nur einen Hashwert des Geheimnisses oder braucht das Geheimnis gar nicht (privater Schlüssel). Außerdem können blinde Menschen SecLookOn nicht nutzen. Es scheidet also als alleiniges Zugangsverfahren für jede größere Nutzergruppe und in speziellen Umgebungen aus. Von daher sollte man sich wohl gleich auf das nötige alternative Verfahren konzentrieren.
2.) Das Geheimnis ist von unbekannter Güte. Der Hersteller behauptet einfach, dass es sicher sei und niemand Bilder und Eingaben zusammenbringen kann. Ob dies wirklich so ist, weiß man aber nicht. Wenn man die Regeln so festlegst, dass Sie für einen selbst einfach sind, sind sie dann nicht vielleicht auch für den Angreifer einfach? Es gibt im Gegensatz zu den heute eingesetzten Protokollen keine langjährige Forschung oder wissenschaftliche Erkenntnisse. Stattdessen verrennt sich der Hersteller lieber bei der Verwendung von Begriffen aus dem Bereich der IT Security und versteckt sich hinter Stenografie und Zero Knowledge, obwohl das Verfahren keine Zero-Knowledge-Eigenschaften und keine steganografischen Elemente hat.
3.) Das System ist überaus aufwändig und schlecht gegen Denial-of-Service-Angriffe zu schützen.
4.) Die Aussagen des Herstellers zur Resistenz gegen Phishing und Man-in-the-Middle-Attacken sind sachlich falsch. SecLookOn ist ein rein wissensbasiertes Verfahren und es gibt kein Hindernis, dieses Wissen abzuphishen oder das Wissen des berechtigten Nutzers im Rahmen einer Man-in-the-Middle-Attacke für sich arbeiten zu lassen.
5.) Der Hacker-Wettbewerb ist wie jeder andere Wettbewerb nicht mehr als ein Werbegag. Es bedeutet nichts, dass niemand eine Lösung eingereicht hat. Wenn ein Ganove beim Knacken Erfolg gehabt hätte, hätte der doch wohl auf ein iPhone verzichtet und gewartet bis Seclookon irgendwo eingesetzt wird. Davon abgesehen verdient ein IT-Experte am Tag mehr, als ein iPhone wert ist, von daher hat sich sicher niemand lange mit dem Verfahren beschäftigt, der sich auskennt. Aktive Angriffe (die entgegen der Ausführungen des Herstellers sehr wohl möglich sind) werden gar nicht betrachtet.
Kurzum: Zwar ist SecLookOn nicht in jedem Fall automatisch völlig unsicher, es gibt aber keinen guten Grund anzunehmen, dass SecLookOn sicherer sei als herkömmliche Authentifizierungsverfahren. Anderseits gibt es aber gute Gründe, an einem vergleichbaren Sicherheitsniveau zu zweifeln. Unter dem Strich bleibt ein Verfahren, dass keine erwiesenen Vorteile hat, sondern im Tausch für systematische Probleme (DoS-Anfälligkeit, Klartextschlüssel) nur ein unbekanntes Sicherheitsniveau bietet. Warum sollte jemand das Verfahren einsetzen?
That?s all Folks!
NStJ
Jetzt weiß ich was SecLookOn ist
Keine schlechte Idee!
mfg
Bitte und Danke
Danke für den informativen Post.
Nettes Blog, BTW.