Sony Ericssons Code-Memo - einfach clever oder nur einfach?

[Mithrandir]

Hi,

Gestern abend hab ich ein wenig mit meinem Sony Ericsson* Handy gespielt und mir zum erstmal richtig die Anwendung "Code-Memo" angesehen. SE schreibt über die Anwendung im dazugehörigen Hilfefenster:

Zitat:

Verwenden Sie die Anwendung Code-Memo zum Speichern persönlicher Daten wie Kreditkartencode, Kennwörter usw.

Hui, da ist sich jemand also sehr sicher. ;)

Funktionsweise...

Wenn man die Anwendung zum ersten Mal startet, erwartet sie die Eingabe eines Passworts. Dies muss 4-stellig sein, darf aber auch führende nullen beinhalten. Dann muss man ein "Prüfwort" angeben. Anschließend kommt man zu einer Liste, wo man neue Codes speichern kann. Das funktioniert nach dem Schema "Titel => Code".

Wenn ich jetzt die Anwendung verlasse, und wieder betrete, dann werde ich zur Eingabe des Passworts aufgefordert. Gebe ich nun das richtige Passwort ein, erscheint mein Prüfwort und ich kann mir meine Passwörter ansehen.

Gebe ich ein falsches Passwort ein, dann erscheint ein Prüfwort, und ich bekomme die Titel zu sehen, und auch Passwörter, allerdings nicht die, die ich eingegeben habe. Das heißt, man erhält kein direktes Feedback, ob der eingegebene Code richtig ist. Man sieht zwar, das z.B. unter "Kreditkarte" ein Passwort hinterlegt ist, allerdings nicht, ob das auch stimmt.

Außerdem achtet die Software darauf, nur numerische Codes nur durch Ziffern zu ersetzen und auch die Länge bei zu behalten. So kann es z.b. nicht passieren, dass im Titel "EC-Pin" steht und als Code dann "4x3d". Damit wäre die Software ja sofort entlarvt. ;)

Gibt man übrigens ein Passwort erneut ein, was man schonmal eingegeben hat, dann sieht man wieder dieselben falschen Daten, wie man sie unter dem Passwort schonmal gesehen hat. Das heißt, dasselbe Passwort zweimal hintereinander eingeben und gucken, ob sich was ändert, funktioniert auch nicht.

...Kritik...

Vor ungefähr 1 1/2 Jahren hat das Frauenhofer Institut herausgefunden, dass in der Anwendung eine Sicherheitslück besteht. Kurz zusammengefasst: Die Anwendung hat bei den generierten Zufallspasswörtern gerne mal Zeichen benutzt, die sich nicht über die Handytastatur eingeben ließen, bspw. %,<,>,@ . Man kann die Symbole zwar über "Mehr" -> "Symbole einfügen" beim SMS schreiben hinzuholen, aber bei der Codeeingabe ist genau dieser Punkt ausgeblendet, was dazu geführt hat, das falsch Codes recht schnell entlarvt wurden.

Inzwischen ist diese Lücke allerdings behoben. ;)

...und eigene Überlegung

Ist das Verfahren jetzt so clever, wie es aussieht? Angenommen, statt der 4 Ziffern würde ich Passwörter mit alphanumerischen Zeichen zulassen und die länge nicht begrenzen. Selbst auf das Prüfwort könnte man ja noch verzichten. Wie sicher wäre so eine Anwendung dann, evtl. auch für den PC? Und wie sieht es mit der Umsetzbarkeit aus?


Gruß,
Daniel


*[im folgenden nur noch "SE" genannt]

[JasonDX]

Zitat:

Zitat von Daniel G

...und eigene Überlegung

Ist das Verfahren jetzt so clever, wie es aussieht? Angenommen, statt der 4 Ziffern würde ich Passwörter mit alphanumerischen Zeichen zulassen und die länge nicht begrenzen. Selbst auf das Prüfwort könnte man ja noch verzichten.

Das "clevere" an dem Prinzip ist, den außenstehenden nicht wissen zu lassen, ob das Passwort jetzt richtig war oder nicht, bzw. nur einen "Hinweis" (per Prüfwort) darauf zu geben. Das Prüfwort ist aber unbedingt notwendig: Wenn ich bspw. mein Passwort verwechsle, und z.B. die Nummer meiner EC-Karte auslesen will, weiß ich ohne Prüfwort nicht, ob das jetzt wirklich die richtige Nummer ist. Das Prüfwort selbst ist aber auch die bzw. eine eventuelle Einstiegslücke. Zumindest wäre interessant zu wissen, was für Prüfwörter erscheinen, wenn man ein falsches Passwort eingibt. Unter der Annahme, dass der Anwender eher ein Prüfwort aus dem deutschen Sprachgebrauch verwenden wird, lassen sich dann evt. die möglichen Passwörter einschränken. Dies geht auch, wenn man bspw. manche ungültige Daten herausfiltern kann. (Zum Beispiel das Gültigkeitsdatum der Kreditkarte: 9821 ist da sicherlich kein gültiger Wert ;) )

Zitat:

Zitat von Daniel G

Wie sicher wäre so eine Anwendung dann, evtl. auch für den PC? Und wie sieht es mit der Umsetzbarkeit aus?

Die Umsetzbarkeit sollte absolut kein Problem darstellen. Die Sicherheit einer solchen Anwendung hängt primär von der Funktion ab, mit der die Codes in Kombination mit Passwort verschlüsselt werden, und natürlich von der Prüfwort-Geschichte. Aber für mehr Gedankenspielereien ists noch zu früh am Morgen :drunken:


greetz
Mike

PS: Ich freue mich auf nen Post von Hagen :D *Wissenshungrig auf den Favorit-Knopf drück* :stupid:

[Mithrandir]

Hi Mike,

Zitat:

Zitat von JasonDX

Zumindest wäre interessant zu wissen, was für Prüfwörter erscheinen, wenn man ein falsches Passwort eingibt. Unter der Annahme, dass der Anwender eher ein Prüfwort aus dem deutschen Sprachgebrauch verwenden wird, lassen sich dann evt. die möglichen Passwörter einschränken.

Dann wird es sehr einfach, da die generierten Prüfwörter allesamt zusammengewürfelte Buchstaben sind, bspw. "xgfss" oder ähnliches.

Zitat:

Zitat von JasonDX

PS: Ich freue mich auf nen Post von Hagen :D *Wissenshungrig auf den Favorit-Knopf drück* :stupid:

Ich mich auch, das war auch meine Absicht... :) :stupid:

[JasonDX]

Zitat:

Zitat von Daniel G

Hi Mike,

Zitat:

Zitat von JasonDX

Zumindest wäre interessant zu wissen, was für Prüfwörter erscheinen, wenn man ein falsches Passwort eingibt. Unter der Annahme, dass der Anwender eher ein Prüfwort aus dem deutschen Sprachgebrauch verwenden wird, lassen sich dann evt. die möglichen Passwörter einschränken.

Dann wird es sehr einfach, da die generierten Prüfwörter allesamt zusammengewürfelte Buchstaben sind, bspw. "xgfss" oder ähnliches.

Dann ist das ganze IMO nur beschränkt sicher. Wie gesagt, das Prinzip beruht darauf, möglichst wenig Aufschluss darauf zu geben, ob das Passwort nun richtig war oder nicht. Das System selbst weiß das nichtmal. Wenn wir aber aus den erhaltenen Daten (z.B. ein unglaubwürdiges Prüfwort, oder ein ungültiges Verfallsdatum der Kreditkarte) schließen können, dass das Passwort falsch war, sinkt die Sicherheit des Systems.
Für ungültige Codes ließe sich das ganze evt. noch umgehen, indem man bspw. eine bijektive "Zwischenfunktion" einbaut, die aus der Menge der gültigen Daten auf bspw. die Menge der natürlichen Zahlen abbildet.
Das Prüfwort ist IMO das größte Problem an der Geschichte. Dem entgegenzuwirken gibts evt. mehrere Möglichkeiten:

1. Komplett weglassen, was aber einiges an Risiko mitsich bringt
2. Eine Liste von möglichen Prüfwörtern einfügen. Da gibts dann wiederum 2 Unterteilungen:
   1. Nur ein Passwort führt zum richtigen Prüfwort. Alle anderen Passwörter bilden auf die anderen Prüfwörter ab. Bringt aber das Problem mitsich, dass man mit etwas Bruteforce immernoch Prüfwörter ausschließen kann. (Durch probieren, welche Prüfwörter durch mehr als nur ein Passwort generiert werden)
   2. Das richtige Prüfwort kann von mehreren Passwörtern generiert werden. Dann kanns aber u.U. dazu kommen, dass man das falsche Passwort eingibt, das richtige Prüfwort, aber die falschen Codes kriegt. Die Wahrscheinlichkeit für einen solchen Fall ließe sich evt. durch eine hohe Menge an möglichen Prüfwörtern und durch eine gut verteilte Funktion (Gemeint: ähnliche Passwörter generieren unterschiedliche Prüfwörter) minimieren.

greetz
Mike

[Mithrandir]

Zitat:

Zitat von JasonDX

Dann ist das ganze IMO nur beschränkt sicher.

Naja, aber der potentielle Hacker erwartet ja vielleicht nur ein richtiges Wort. Mir verbietet ja niemand, mir ein "Wort" ala "qpvns" auszudenken. ;) Aber im Regelfall wird wohl ein "echtes" Wort benutzt, stimmt.

Die Frage ist doch, ob ich so ein Prüfwort wirklich "zwingend" benötige. Denn das ich ein falsches Passwort eingegeben habe, merke ich ja spätestens daran, dass mein Passwort, dass ich verwenden will, nicht passt. Mit Prüfwort merke ich das halt, bevor ich es benutzen will. Aber ist dieser Komfort die verringerte Sicherheit wert?

[JasonDX]

Zitat:

Zitat von Daniel G

Die Frage ist doch, ob ich so ein Prüfwort wirklich "zwingend" benötige. Denn das ich ein falsches Passwort eingegeben habe, merke ich ja spätestens daran, dass mein Passwort, dass ich verwenden will, nicht passt. Mit Prüfwort merke ich das halt, bevor ich es benutzen will. Aber ist dieser Komfort die verringerte Sicherheit wert?

Sie ist definitiv kein muss - aber wenn ich erst merk, dass das Passwort falsch war, sobald mir meine EC-Karte schon eingezogen wurde, ist das natürlich "Suboptimal".
Evt. kann man das ganze auch per Option (de)aktivieren. D.h. standardmäßig ausschalten, aber dem unsicheren Benutzer die Option freilassen. ;)

greetz
Mike

[Florian H]

Die Sache mit dem Prüfwort ist doch dieselbe wie mit normalen Passwörtern.
Wenn man als Prüfwort "asd02j" benutzt, ist es ziemlich sicher. Wenn das Prüfwort aber "geheim" ist, ist das ebenso wie ein Passwort "geheim" ziemlich unsicher.

[Mithrandir]

Zitat:

Zitat von Florian H

Wenn man als Prüfwort "asd02j" benutzt, ist es ziemlich sicher. Wenn das Prüfwort aber "geheim" ist, ist das ebenso wie ein Passwort "geheim" ziemlich unsicher.

Stimmt, so gesehen hast du recht. ;)

@Mike: Joar, das wäre ne Möglichkeit ;)

[hitzi]

Nur wenn niemand anderes als man selber das Prüfwort kennt ist es ziemlich egal, ob man "asd02j" oder "geheim" verwendet. Derjenige der versucht in das Codememo zukommen, kann nicht sicher sein, ob die angezeigte Zeichenfolge "asd02j" richtig oder falsch ist.

[JasonDX]

Zitat:

Zitat von hitzi

Nur wenn niemand anderes als man selber das Prüfwort kennt ist es ziemlich egal, ob man "asd02j" oder "geheim" verwendet. Derjenige der versucht in das Codememo zukommen, kann nicht sicher sein, ob die angezeigte Zeichenfolge "asd02j" richtig oder falsch ist.

Naja, wenn man bspw. nen Bruteforce drüberlaufen lässt, und 1 Prüfwort "geheim" und 9999 Prüfwörter komische Zeichenfolgen ergeben, ists ziemlich wahrscheinlich, dass das Passwort, das zu "geheim" gführt hat, richtig ist. Und die Funktion so zu definieren, dass für jedes gespeicherte Prüfwort bei manchen falschen Passwörtern auch Wörter aus dem Sprachgebrauch rauskommen können ist - von einer Liste wie oben in 2. beschrieben abgesehen - ein äußerst komplexes Problem.

greetz
Mike

[mkinzler]

Vielleicht, wenn man das "falsche" Prüfwort zusätzlich festlegen könnte. Dieses wäre dann auch "Sinnvoll"

[Mithrandir]

Zitat:

Zitat von mkinzler

Vielleicht, wenn man das "falsche" Prüfwort zusätzlich festlegen könnte. Dieses wäre dann auch "Sinnvoll"

Wie meinen? :gruebel:

[Florian H]

Zitat:

Zitat von mkinzler

Vielleicht, wenn man das "falsche" Prüfwort zusätzlich festlegen könnte. Dieses wäre dann auch "Sinnvoll"

Äh.. du meinst sowas wie "wenn das Passwort stimmt, kommt "richtigesprüfwort" raus, sonst "festgelegtesfalschesprüfwort"?
Das würde doch das komplette System aushebeln, wenn die Software weiß, welches Passwort richtig und welches falsch ist 8O

[himitsu]

Zitat:

Zitat von mkinzler

Vielleicht, wenn man das "falsche" Prüfwort zusätzlich festlegen könnte. Dieses wäre Dann auch "Sinnvoll"

dann müßte man dieses aber auch noch irgendwo EXTRA mit speichern.

Dann filtere ich es mir aus den Daten und lass solange Passwörter prüfen, bis dieses Passwort nicht mehr erscheint.

Das Prüfwort müßte also mit verschlüsselt werden.



Man könnte auch statt einem Prüfwort eine Prüfzahl erstellen und dann je nach Zahl aus einem mitgeliefertem Wörterbuch ein Wort auswählen.

Dann würde es zumindestensn nach der Entschlüsselung (egal ob richtig oder falsch) immer ein "gutes" Prüfwort entstehen, welches dann der Mensch sich besser merken könnte, als die Prüfzahl.

[JasonDX]

Zitat:

Zitat von himitsu

Man könnte auch statt einem Prüfwort eine Prüfzahl erstellen und dann je nach Zahl aus einem mitgeliefertem Wörterbuch ein Wort auswählen.

Dann würde es zumindestensn nach der Entschlüsselung (egal ob richtig oder falsch) immer ein "gutes" Prüfwort entstehen, welches dann der Mensch sich besser merken könnte, als die Prüfzahl.

Dann gibts aber die 2 Probleme, die ich schon weiter oben beschrieben habe:

Zitat:

Zitat von jasonDX

• Nur ein Passwort führt zum richtigen Prüfwort. Alle anderen Passwörter bilden auf die anderen Prüfwörter ab. Bringt aber das Problem mitsich, dass man mit etwas Bruteforce immernoch Prüfwörter ausschließen kann. (Durch probieren, welche Prüfwörter durch mehr als nur ein Passwort generiert werden)
• Das richtige Prüfwort kann von mehreren Passwörtern generiert werden. Dann kanns aber u.U. dazu kommen, dass man das falsche Passwort eingibt, das richtige Prüfwort, aber die falschen Codes kriegt. Die Wahrscheinlichkeit für einen solchen Fall ließe sich evt. durch eine hohe Menge an möglichen Prüfwörtern und durch eine gut verteilte Funktion (Gemeint: ähnliche Passwörter generieren unterschiedliche Prüfwörter) minimieren.

greetz
Mike

[himitsu]

Bruteforce bringt nur was, wenn du die Lösung kennst, oder eine Rückkopplung ales "ja, das ist richtig" bekommst.

wenn es zu "jedem" Passwort/Passworthast ein Prüfwort gibt, plausibles Prüfwort gibt, dann kann ein Programm daraus nicht erkennen, ob das gewählte Passwort richtig ist.

Wenn man das Lösugswort verschlüsselt und es bei der Entschlüsselung viele Prüfwörter gibt, welche kein plausibles Wort ergeben, dann könnte man in solchen Fällen davon ausgehen, daß das gewählte Paswort falsch ist und muß nur noch von den wenigen übriggebliebenen Passwort-Prüfwort-Kombinationen auswählen.

OK, bei z.B. einem MD5-Hash für das Prüfwort, gäbe es unmassen an theoretischen Prüfwörtern, aber wenn man davon ausgeht, daß der Benutzer sich nur verschreibt und nicht was vollkommen anderes eintippt, könnte man dieses auf eine kleinere Liste kürzen, mehreren Hashs das selbe Prüfwort geben.
hieße dann ein Prüfwort für mehere (unterschiedliche) Passwörter, also für Bruteforce würde es noch schwieriger, wenn man überhaupt einen angriffspunkt auf das Prüfwort hätte und die Wortliste würde klein genug.

Das Prüfwort soll ja nur ein Hinweis für den EINEN Benutzer sein, ob er sich "etwas" vertippt hat.
Wenn man aber das Prüfwort nicht direkt mit der Verschlüsselung verbindet und es keine Möglichkeit gibt rauszufinden welches der möglichen Lösungswörter richtig wäre, dann kann man darüber doch auch keinen Angriff starten.

[negaH]

Also ich bin skeptisch.

Damit sowas gut funktioniert ist es zwingend das das Passwort alle umkodierten zu schützenden Pins eineindeutig mappt. Dh. ein falsches Passwort erzeugt zu einer kodierten Pin auch nur seinen eineindeutig zugeordneten falschen Wert. Gleiches gilt für das korrekte Passwort, nur dieses erzeugt die korrekten Pins.

Somit kann es sich nur um einen Transposition-Algorithmus handeln. Bei diesem sind zwei Dinge wichtig:
1.) eineindeutiges Mapping, jedes beliebige Passwort muß einen eindeutig unterschiedlichen entschlüsselten Output erzeugen
2.) besteht eine Pin aus Ziffern so muß die verschlüsselte Pin ebenfalls aus Ziffern bestehen, dh. man mappt immer Ziffern zu Ziffern, Buchstaben zu Buchstaben usw. Denn wäre dies nicht so so muß neben der verschlüsselten Pin auch noch verschlüsselt gespeichert werden aus welchen ACSIIs sich diese Pin zusammensetzt. Das bedeutet aber das diese Information nicht mit dem realem Passwort verschlüsselt werden kann sondern mit einem hardcoded gespeicherten Passwort, oder aber unverschüsselt gespeichert würde, was dann aber noch unsicherer wäre. Ergo würde ich vermuten das der Transpositionsalgorithmus immer nur Ziffern zu Ziffern oder Buchstaben zu Buchstaben umkodiert mit Hilfe des Passwortes.

Ein Angreifer weiß also das er mit einem beliebig falschen Passwort eine hoch wahrschenlich falsche Antwort bekommt kann aber an Hand dieser mit Sicherheit erkennen das die richtige Antwort zb. aus 4 Ziffern besteht. Das schränkt den Suchraum bei einer späteren Bruteforce Attacke auf das Zielsystem enorm ein. Die Sicherheit diese Verfahrens basiert im Grunde somit auch auf der Sicherheit des Verfahrens für das diese Pin gedacht ist. Könnte man am Bankautomaten unendlich lange alle Pins durchprobieren, er würde aber zb. wesentlich mehr als 4 Ziffern und Buchstaben ermöglichen so wäre dieser Passwortsafe unsicher und würde das Banksystem kompromittieren, selbst wenn es sicher wäre. Denn nun kann der Angreifer selbst ohne die richtige Pin entschlüsselt zu haben denoch wertvolle Informationen für seine Bruteforce Attacke des Bankautomaten ableiten. Er weiß wieviele Zeichen und was für ein Zeichentypus an jeder Stelle in der realen Pin vorhanden sind. Natürlich unter der Annahme das meine Vermutung der 1 zu 1 Transposition korrekt ist.

Benutzt der User für unterschiedliche Dinge das gleiche Passwort/Pin so kann man dies auch erkennen da deren verschlüsselte Produkte identisch sein müssen.

Grundsätzlich halte ich nichts von einem solchen Verfahren, eine guter Passwortschutzt sollte zumindestens mit viel Zufallsdaten arbeiten.

Man könnte das als OTP-Transpositions Verfahren betrachten und wäre das sicher so dürfte das Passwort nur zufällig, so lang wie der Pin sein und einmalig benutzt werden.

Die dümmste Annahme wäre das die Pin sicher mit zb. AES verschlüsselt wurde und eine Prüfsumme zusätzlich verschlüsselt wurde. Unverschlüsselt wird aber die Falschantwort des Systemes zu diesem Datensatz gespeichert. Somit weis das System welche Falschantwort es liefern muß bei nicht korrekter Entschlüsselung und es weiß auch wie diese Antwort aussehen muß, also Ziffer usw. Das wäre aber ober dämlich da so der Angreifer die eindeutige Falschantwort ermitteln kann und somit einen sicheren Prüfalgorithmus für seine Bruteforce Attacke in der Hand hält.

Generell gilt:
Je mehr Passwörter ( und je komplexer also von guter Qualität diese sind) ein Passwortsafe schützt desto expotentiell stärker muß der eigentlich benutzte Algorithmus und das benutzte Passwortsafe Passwort sein. Denn bei Erfolg knackt man so nicht nur ein Passwort sondern alle im Passwortsafe gespeicherten. Sind diese von besserer Qualität als das Passwortsafe Passwort dann ist das für den Popo.
Ein Passwortsafe ist also im Grunde immer eine dumme Idee, vorausgesetzt, und das ist eben die Außnahme, die geschützten Passwörter sind von guter also unknackbarer Qualität. Die Außnahme, die die Regel ist, ist es nun das die meistens Pins/Passwörter enorm schlecht gewählt sind.

Gruß Hagen

[Mithrandir]

Wahnsinnn... Hagen gibt einen Kommentar ab, und alle sind ruhig... :mrgreen:

Erstmal danke dafür. :thumb:

Mal angenommen, man würde keinen Wert darauf legen müssen, dass die "gefälschten" Passwörter in Länge und Umfang mit den originalen übereinstimmen. Das würde dann doch die Sicherheit erhöhen, weil die Passwörter alleine ja schon schwerer knackbar sind, richtig?

Dann dürften natürlich auch nur Passwörter gespeichert werden, die eben zu Zugängen gehören, die alphanumerische Passwörter erlauben. Im Netz ist das Gott sei Dank in vielen Fällen so, aber die EC-Karten Pin müsste man sich dann trotzdem noch merken...

[Florian H]

Zitat:

Zitat von Daniel G

Mal angenommen, man würde keinen Wert darauf legen müssen, dass die "gefälschten" Passwörter in Länge und Umfang mit den originalen übereinstimmen. Das würde dann doch die Sicherheit erhöhen, weil die Passwörter alleine ja schon schwerer knackbar sind, richtig?

Das ist imo aber doofer als wenn alle die gleiche Länge haben ...
Denn dann muss man nur die Länge (!) eines einzigen Passwortes kennen (z.B. indem man schnell die Sternchen zählt, wenn jemand sein Passwort eintippt) und schränkt sofort die Zahl der möglichen Master-Passworte ein. Das ist wie, wenn man von vorneherein 1-2 Buchstaben des Kontrollwortes kennt.

[Mithrandir]

Zitat:

Zitat von Florian H

Das ist imo aber doofer als wenn alle die gleiche Länge haben ...
Denn dann muss man nur die Länge (!) eines einzigen Passwortes kennen (z.B. indem man schnell die Sternchen zählt, wenn jemand sein Passwort eintippt) und schränkt sofort die Zahl der möglichen Master-Passworte ein. Das ist wie, wenn man von vorneherein 1-2 Buchstaben des Kontrollwortes kennt.

Hrmpf, so gesehen auch wieder wahr...

[Stutz]

Hi,
also ich vermute das das von Hagen angesprochene eindeutige Mapping der Hauptknackpunkt ist. Ich bin zwar net so ganz auf dem aktuellen Stand der Dinge, doch ich könnte mir vorstellen dass es doch etwas zuviel speicherplatz frisst für jede Kombination des Masterpassworts alle Zeichen abzuspeichern, da es eben doch eher nur ein "kleiner Helfer" ist.
Werden die "Ergebnisse" berechnet kann man Rückschlüsse auf die Berechnungsmethode schließen und zur not das abweichende Resultat herausfiltern, bzw wenn die Formel so gestaltet wird dass die richtige Pinnr. herauskommt kann man dies doch schon an den ersten Ergebnissen ablesen.

verzeiht mir wenn ich mich irre oder eine Milchmädchenrechnung aufstelle.

gruß
Stutz

[negaH]

Nene ;)

Wenn sie wirklich ein eineindeutiges Mapping benutzen dann ist das ausreichend und gut. Denn die wahre Sicherheit einer 4 stelligen Alphanummerischen Pin ist eben nur 10^4 = 10000 Kombinationen. Benutzt man ein gleichgewichtetes Mapping, eg. Transposition, vom Passwort zur Ver-Entschlüsselung der Pin so hat man eine exakt gleiche Sicherheit wie die des Pins selber und nicht diejenige des benutzten Passwortes. Denn die Bedingung lautet ja -> jede der 10000 Pins wird mit jedem möglichen Passwort gleichverteilt in 10000 unterschiedliche verschlüsselte Pins gemappt. Das bedeutet es gibt auch nur 10000 4 stellige alphanumerische Passwörter die gültig sind. Man muß sich das ganze einfach vorstellen: Man möchte 4 stellige Pins schützen, merkt sich eine geheime 4 stellige Pin gleicher Bauart und verknüpft nun diese mit den zu schützenden Pins. Raus kommen wieder 4 stellige Pins. Die ganze Mathematik ist so ausfgebaut das eine absolute Gleichverteilung im Mapping/Transposition erfolgt, und dann ist das auch sicher. Natürlich im Rahmen der Komplexität der benutzten Pins. Das war ja auch der Grund für meine Aussage das dieses Sicherheitssystem zu einem überwiegend großen Anteil garnicht die Sicherheit als solches schafft sondern das es der Bankautomat ist der eine fehlerhafte Pin nur dreimal zulässt und dann das Konto komplettt sperrt. Die Sicherheit der Bankautomaten liegt also nicht im Pin sondern in der nur 3 mal durchführbaren Pineingabemöglichkeit in Relation zur Menge aller möglichen Pins, also 10000. Die Wahrscheinlichekit für einen Rateversuch beträgt also 3/10000.

Aber das Verfahren selber ist im Rahmen der Zahlengrößen sehr wohl mathematisch sicher wenn es ein vollkommen gleichverteiltes Mapping der Menge der Pins über die gleichgroße Menge der Passwörter somit der gleichgroßen Menge der verschlüsselten Pins durchführt. Vereinfachen wir das mal. Die Menge der Pins bestünde aus {0, 1}. Die Menge der Passwörter besteht demzufolge auch aus {0, 1} und die Menge der verschlüsselten Pins somit auch aus {0, 1}. Unser Pin wäre 1, unser Passwort wäre 1 und unsere Mappingfunktion ist XOR. 1 xor 1 = 0, 0 ist unsere verschlüsselte Pin. Der Angreifer wird mit exakt 50% Wahrscheinlichkeit ein falsches oder richtiges Passwort auswählen und auf Grund des XOR Mappings somit auch mit 50% Wahrscheinlichkeit die richtige oder falsche Pin angezeigt bekommen. Er selber kann nur mit 50% Wahrscheinlichkeit richtig liegen bei dem Versuch zu raten ob er selber richtig oder falsch geraten hat. Ergo: das Verfahren ist ideal sicher da es mit 50% Wahrscheinlichkeiten keinerlei Informationen die uns in Richtung 40% oder 60% tendieren lassen rauslässt. 50% ist so wie Zufall wie Raten aber nicht Wissen oder Vermuten.

Nun verkomplizieren wir es wieder: Statt 0/1 Ziffern benutzen wir 0..9, statt nur eine Ziffer immer 4. Statt einem binärem XOR benutzen wir ein Dekadisches XOR als Vierfachanordnung. Dieses Dekadische XOR hat also 2*4 Ein- und 4 Ausgänge und jeder Kanal xor'ed eine Ziffer zwischen 0 bis 9. Dann gelten die gleichen Gesetze wie bei dem Bespiel der binären Mengen oben. Es ist ein sicheres Verfahren ansich.

Aber, es schützt eben nicht das Gesamtverfahren für das diese Pins im Grunde benutzt werden. Nur wenn dieses Verfahren auch sicher ist ist der Passwortsafe keine zusätzliche Unsicherheit. Und das ist eben nicht der Fall, denn wie wir alle wissen sind gerade auf Pins der Bankautomaten sehr ausgefeilte Angriffe möglich. Das bedeutet nämlich folgendes: Ein normaler Bankautomaten-Angreifer hat die Pin eines Kunden ausspioniert und auch dessen Passwortsafe mit 9 weiteren geschützten Pins. Nun ist es ein leichtes das Passwortsafe Passwort rauszubekommen und so an die restlichen 9 Pins ranzukommen. Der Passwortsafe hat im Falle eines einzigsten erfolgreichen Angriffes automatisch 9 weitere normalerweise notwendige Angriffe unnötig gemacht, oder kurz gesagt: der Passwortsafe hat die Gesamtsicherheit aller in ihm gespeicherten Pins auf die Sicherheit der schwächsten angreifbaren Pin reduziert. Der Passwortsafe ist also ein Sicherheitsrisiko statt einem Sicherheitsgewinn.

Das zeigt: dieses Verfahren kann nur dann sicher sein wenn es wie beim OTP gefordert ein Passworsafe Passwort nur zufällig und einmalig verwendet. Also pro Pin immer ein neues zufälliges und einmaliges Passwort. Dann und nur dann ist es ideal sicher wie ein math. OTP. Aber dann wird es auch sofort unpraktikabel denn warum sollte ich mir für jede 4-stellige PIN jedesmal ein anderes 4-stelliges Passwort zum Schutz der Pin merken wollen. Man erkennt auch sehr gut das die mathm. Idealvorstelung der perfekten Verschlüsselung, der OTP, ein absolut praktisch untaugliches Verfahren darstellt, es ist also nur eine hypothetische Idealvorstellung, die maximale Grenze mit der man andere Verfahren in Realtion vergleichen wird.

Gruß Hagen

[negaH]

Wenn wir also davon ausgehen das ein Bankautomat nur so sicher ist wie seine 4-stellige Pin dann ist ein solcher Passwortsafe immer eine Bedrohung oder Unsicherheit für alle in ihm gespeicherten Pins so bald es mehr als eine ist.

Stattdessen würde ich lieber einen richtigen Passwortsafe benutzen der mit einem möglichst sehr lang und gut gewähltem Schlüssel und echten sicheren und anerkannten Verfahren wie AES und mit möglichst viel Zufallssalts diese Pins verschlüsselt. Man hat dann zwar nicht mehr das Feature der Falschaussage des Systemes die scheinbar eine richtige Antwort wählt aber das ist auch garnicht nötig. Denn dieses Feature ist nur ein "Tarnen und Täuschen" Feature und sowas ist eben nicht mathematisch real sicher sondern Augenwischerei.

Alles natürlich vorausgesetzt das ich mit meiner Vermutung einer einfachem Mapping richtig liege. Läge ich falsch und die haben wirklich starke Kryptographie benutzt dann frage ich mich wozu das Tarnen&Täuschen Manöver noch gut sein soll. Denn die hies entweder das der ENtwickler nicht auf die Sichherit seiner eigenen Kryptographie vertraut, sie unsicher ist oder es einfach nur ein nettes Verkaufsargument darstellt. Es gibt bei starker Kryptographie nämlich keine Begründung für ein solches Feature.

Wie müssen hier also unterscheiden zwischen
1.) der Sicherheit des Verfarens für eine Pin und ein Passwort ansich
2.) der Sicherheit des Verfahrens für viele Pins und ein Passwort
3.) der Sicherheit des Verfahrens für alle Pins und deren Rahmenbedingungen in denen sie benutzt werden.

Ist die Sicherheit einer einizigen Pin durch ihre Rahmenbedingungen ihrer Benutzung kompromittiert so würde ein solcher Passwortsafe wie eine Lawine auch die Sicherheit aller anderen Pins und deren Rahmenbedingungen brechen. Das ist eben der Knackpunkt bei jedem Passwortsafe.

Gruß Hagen