Braucht Jemand ein einfaches Autorisierungssystem mit verschlüsselter Datenübertragung?
Stefan Weinzierl
In den letzten Jahren habe ich ein challenge response System zur
Benutzeridentifikation bzw. Authentifizierung entwickelt.
Bei jedem Vorgang einer einzelnen Autorisation wird hier eine andere
Zahlenkombination zur Identifikation benötigt. Es ist also hier nicht möglich
durch Abhören der "PIN" die Identifikationsdaten zu erschließen. Totz einer
solchen Variabilität in der Identifizierung ist es für den/die Benutzer/in
nicht notwendig unterschiedliche auch unterschiedliche Identifikationsdaten auf
irgendeine Weise zu verwalten, wie es ja z.B. beim PIN-TAN Verfahren der Fall
ist. Um sich über dieses System identifizieren zu können, muss man sich nur
einmalig eine individuelle Permutation der Zahlen von 0 bis 9 zu sich selber
merken. Das ist in zehn bis höchstenfalls fünfzehn Minuten erledigt.Um das
ganze System mit für die meisten so vorstellbaren Anwendungsgebiete mit
wahrscheinlich bei weitem ausreichender Sicherheit realisieren zu können, sind
nur Standardeingabegeräte, wie insbesondere Monitor und Tastatur, bzw.
allgemein verfügbare mobile Datenträger, wie z.B. Disketten erforderlich
Die theoretische Implementierung des Systems ist nun praktisch bis ins letzte
Detail abgeschlossen. Leider ist es mir aber nicht möglich, auch die praktische
Implementierung, sprich die konkrete Programmierung, selbst durchzuführen.Mir
fehlt einfach hierzu so stark das notwendige Wissen, dass es Jahre dauern
würde, bis ich mein Konzept konkret umsetzen könnte. Da mir dieser Umstand
schon von Anfang an klar war, habe ich mein gesamten Konzept auch unter GPL
gestellt habe. Also es kann praktisch jeder, der will und sich dazu imstande
fühlt, selbst weiter entwickeln, an seine Bedürfnisse anpassen, und es auch
geeignet vermarkten. Ich schätze mal, dass ein einigermaßen kompetenter
Programmierer ungefähr drei Tage benötigt, bis die konkrete Implementierung
eines solchen Konzeptes stehen würde.
Natürlich kann ich jezt niemanden dazu zwingen,von meinen Konzepten so überzeugt
zu sein, wie ich es bin, bzw. sie auf irgendeine Weise auch praktisch
umzusetzen. So etwas ist auch nicht notwendig noch würde ich es wollen. Wenn
man derzeitig an so etwas nicht so sehr interessiert ist,oder man noch
irgendwelche Zweifel dagegen hegt, kann man ja zumindest ein Lesezeichen
( http://psypam.de/2formel.html#formel_biomet_psypam )
setzen. Das ist das Konzept auf alle Fälle wert.
Gruss
Stefan
--
Das Schöpferische erkennt durch das Leichte
Das Empfangende vermag durch das Einfache
Lutz Donnerhacke
> In den letzten Jahren habe ich ein challenge response System zur
> Benutzeridentifikation bzw. Authentifizierung entwickelt.
Schön. Kennst Du die existierenden Verfahren?
> Bei jedem Vorgang einer einzelnen Autorisation wird hier eine andere
> Zahlenkombination zur Identifikation benötigt.
Also Einmalschlüssel.
> z.B. Disketten erforderlich Die theoretische Implementierung des Systems
> ist nun praktisch bis ins letzte Detail abgeschlossen. Leider ist es mir
> aber nicht möglich, auch die praktische Implementierung, sprich die
> konkrete Programmierung, selbst durchzuführen.Mir fehlt einfach hierzu so
> stark das notwendige Wissen, dass es Jahre dauern würde, bis ich mein
> Konzept konkret umsetzen könnte.
Soweit so schlecht.
> Natürlich kann ich jezt niemanden dazu zwingen,von meinen Konzepten so
> überzeugt zu sein, wie ich es bin, bzw. sie auf irgendeine Weise auch
> praktisch umzusetzen. So etwas ist auch nicht notwendig noch würde ich es
> wollen. Wenn man derzeitig an so etwas nicht so sehr interessiert
> ist,oder man noch irgendwelche Zweifel dagegen hegt, kann man ja
> zumindest ein Lesezeichen (
> http://psypam.de/2formel.html#formel_biomet_psypam ) setzen. Das ist das
> Konzept auf alle Fälle wert.
Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein Konzept
erkennen.
Frank Meyer
> ( http://psypam.de/2formel.html#formel_biomet_psypam )
Kotz. Allein von der Hintergrundtapete bekommt man Augenkrebs.
Ich weigere mich, sowas zu lesen.
Frank
Stefan Weinzierl
> Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein Konzept
> erkennen.
IKS GmbH
Ihr Partner für
gesicherten Netzbetrieb
solides Datenmanagement
spezifische Komplettlösungen im Hard- und Softwarebereich
Consulting und Service
Verlag IKS Garamond
Ihr Partner für
wissenschaftliche Publikationen
Industrieausgaben
Verlagsdienstleistungen (Edition/Lektorat/Setzerei/Druck)
Beratung und Service zu Publikationsprojekten
Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre Angestellten
nicht einmal in der Lage sind, eine bewusst einfach und verständlich gehaltenen
Darstellung eines Laien, der aber nicht desto trotz auch Hochschulabsolvent
ist, zu erfassen?
Andreas Kretschmer
> Lutz Donnerhacke wrote:
>> Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein Konzept
>> erkennen.
> IKS GmbH
> Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre Angestellten
> nicht einmal in der Lage sind, eine bewusst einfach und verständlich gehaltenen
> Darstellung eines Laien, der aber nicht desto trotz auch Hochschulabsolvent
> ist, zu erfassen?
Eine LKW Poppkorn bitte!!!!1!
end
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
Michael Sçheer
> Es ist also hier nicht möglich
> durch Abhören der "PIN" die Identifikationsdaten zu erschließen. Totz einer
> solchen Variabilität in der Identifizierung ist es für den/die Benutzer/in
> nicht notwendig unterschiedliche auch unterschiedliche Identifikationsdaten auf
> irgendeine Weise zu verwalten, wie es ja z.B. beim PIN-TAN Verfahren der Fall
> ist. Um sich über dieses System identifizieren zu können, muss man sich nur
> einmalig eine individuelle Permutation der Zahlen von 0 bis 9 zu sich selber
> merken.
Kannst Du nicht in einigen Sätzen die Bildungsregel dieser
Einmalschlüssel erklären und angeben, mit welchen Algorithmen deren
Sicherheit steht und fällt? Ich finde es aus Deinem Text sehr schwer
herauszulesen. Ich sehe den Wald vor lauter Tabellen nicht mehr ;)
--
[PGP] 0x360F113D(RSA) * 0x53E9615A(DH/DSS) * http://pgp.autechre.de/
Michael Sçheer
[Lutz]
> Was stellen den die für geistige Dünnbretbohrer ein
Regst Du Dich jetzt mal wieder ab?
Michael H. Fischer
> Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre
> Angestellten nicht einmal in der Lage sind, eine bewusst einfach
> und verständlich gehaltenen Darstellung eines Laien, der aber
> nicht desto trotz auch Hochschulabsolvent ist, zu erfassen?
Klasse. Vielen Dank. Ich ahnte ja schon nach deinen abstrusen
Verschwörungstheorien in Sachen "1&1 sabotiert meine bahnbrechneden
Erkenntnisse", dass du absolut keine Ahnung hast. Jetzt weiss ich es.
Und wunder dich nicht über das, was du hier jetzt sonst noch alles zu
lesen bekommen wirst. Denk einfach mal über das Mantra "Ein
Geisterfahrer? Tausende!" nach.
MfG
Michael H. Fischer
Steffen Barth
> Hallo
> In den letzten Jahren habe ich ein challenge response System zur
> Benutzeridentifikation bzw. Authentifizierung entwickelt.
> Bei jedem Vorgang einer einzelnen Autorisation wird hier eine andere
> Zahlenkombination zur Identifikation benötigt. Es ist also hier nicht möglich
Ich habe mir Deine Seite schon angeschaut, als kürzlich hier einmal die
"Einmalschlüsselfrage" gestellt wurde. Ich muß zugeben, beim Überfliegen
auch nicht ansatzweise das Prinzip verstanden zu haben. Wenn ein
durchschnittlicher Mensch 10 Minuten brauchen soll, um sich eine
Zahlenpermutation zu merken, muß er auch in weiteren 5 Minuten
begreifen, wie er die anzuwenden hat.
Daraufhin solltest Du Dir deine Ausarbeitung nochmal anschauen, ehe Du
hier Leute beleidigst, von denen Du scheinbar auch nicht ansatzweise
Ahnung hast, was sie tun und wer sie sind.
Grüße Steffen
Carsten Krueger
>( http://psypam.de/2formel.html#formel_biomet_psypam )
>setzen. Das ist das Konzept auf alle Fälle wert.
Das bezweifle ich, das geseiere auf der Seite kann doch keine Sau
nachvollziehen.
Gruß Carsten
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam
Urs [Ayahuasca] Traenkner
> Stefan Weinzierl <stefan.w...@t-online.de> wrote:
> >( http://psypam.de/2formel.html#formel_biomet_psypam )
^^^^^^^^^
Bin ich eigentlich der einzige, der hier die ganze Zeit irgendwas
mit "spam" geparst hat?
> Das bezweifle ich, das geseiere auf der Seite kann doch keine Sau
> nachvollziehen.
Sieht so aus.
Gruss Urs...
--
_______
(-) o---|_______|---o (+)
| |
+---------------+ Widerstand ist zwecklos!
Ansgar -59cobalt- Wiechers
> Lutz Donnerhacke wrote:
>
>> Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein
>> Konzept erkennen.
>
> IKS GmbH
> Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre
> Angestellten nicht einmal in der Lage sind, eine bewusst einfach und
> verständlich gehaltenen Darstellung eines Laien, der aber nicht desto
> trotz auch Hochschulabsolvent ist, zu erfassen?
YMMD :'D
cu
59cobalt
--
"Wir nehmen ständig an Glaubwürdigkeit zu."
--Darl McBride (SCO)
Marco Stolpe
ich habe den ganzen Kram auf Deiner Webseite nur überflogen und finde
die Darstellung/Präsentation auch zu schlecht, um mich damit näher zu
beschäftigen. Nur auf einen Punkt will ich kurz eingehen.
Du schreibst in Deiner Einführung:
"Anscheinend ist das menschliche Gehirn im Gegensatz zu elektronischen
Datenverarbeitungssystemen nicht gerade optimal dazu geeignet, sich
eine Vielzahl von komplexen Passwörtern sicher zu merken und im
Bedarfsfall auch präzise wiederzugeben."
Trotzdem gibt es immer wieder Menschen, die bei einer Sendung wie
"Wetten das?" auftreten und sich hunderte Nachkommastellen von einer
Zahl wie Pi merken können. Glaubst Du, die haben ein anderes Gehirn
als andere Menschen? Oder hälst Du es für möglich, dass die
Unfähigkeit, sich komplexe Passwörter einzuprägen, einfach etwas mit
einer schlechten Methodik zu tun haben könnte?
google "Memoriersysteme"
Denke bitte nach dem Lesen noch einmal darüber nach, ob jemand "ein
einfaches Autorisierungssystem mit verschlüsselter Datenübertragung"
benötigt, wenn man sich Passwörter doch einfach ... merken kann!
Grüße,
Marco
Juergen P. Meier
> begin Stefan Weinzierl <stefan.w...@t-online.de> wrote:
>> Lutz Donnerhacke wrote:
>
>
>>> Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein Konzept
>>> erkennen.
>
>
>> IKS GmbH
>
>
>> Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre Angestellten
>> nicht einmal in der Lage sind, eine bewusst einfach und verständlich gehaltenen
>> Darstellung eines Laien, der aber nicht desto trotz auch Hochschulabsolvent
Ist er nicht mal ein Doktor? Mit einem Doktor haette er bei dir doch
automatisch Recht[tm], auch wenn er behaupten wuerde, die Erde sei
flach und eckig.
>> ist, zu erfassen?
>
>
> Eine LKW Poppkorn bitte!!!!1!
Scheisse, mein Bier ist alle....
*Popcorn machend*
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
> Lutz Donnerhacke wrote:
>
Es geht um http://www.telecypher.net/
Jeder, der sich mit den Grundlagen von Kryptologie und Chiffrierung
befasst hat, wird den Text dort hoechstens amysant finden.
>> Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein Konzept
>> erkennen.
>
>
> IKS GmbH
>
> Ihr Partner für
> gesicherten Netzbetrieb
> solides Datenmanagement
> spezifische Komplettlösungen im Hard- und Softwarebereich
> Consulting und Service
>
> Verlag IKS Garamond
>
> Ihr Partner für
> wissenschaftliche Publikationen
> Industrieausgaben
> Verlagsdienstleistungen (Edition/Lektorat/Setzerei/Druck)
> Beratung und Service zu Publikationsprojekten
>
> Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre Angestellten
> nicht einmal in der Lage sind, eine bewusst einfach und verständlich gehaltenen
> Darstellung eines Laien, der aber nicht desto trotz auch Hochschulabsolvent
> ist, zu erfassen?
>
> Gruss
>
> Stefan
>
Auf das ihr auch was zu lachen habt. Merkbefreiung spare ich mir,
sonst spinnt Herr "1-und-1 sabotiert mich!!1!" Weinzierl mich noch mit
in seine Verschwoerungstheorie ein...
(Message-ID: <bpcq35$ffn$08$1...@news.t-online.com>)
Stefan Weinzierl
> Stefan Weinzierl <stefan.w...@t-online.de> wrote:
>
>>( http://psypam.de/2formel.html#formel_biomet_psypam )
>>setzen. Das ist das Konzept auf alle Fälle wert.
>
> Das bezweifle ich, das geseiere auf der Seite kann doch keine Sau
> nachvollziehen.
>
> Gruß Carsten
Hallo Carsten
Weil du der erste Neue im Thread bist, fange ich einfach mal bei dir an:
Die wahre Intension von solchen Posts mit allgemein abwertender Kritik, wie du
und andere sie schreiben, zu erschließen, ist für mich sehr schwierig.
Denn, zwei völlig unterschiedlich zu bewertende Motivlagen können als Beweggrund
solchen Posts zugrunde liegen.
Möglichkeit 1:
Du, bzw. andere, die ähnlich allgemein abfällig schreiben, ohne aber richtig
konkret zu werden, haben sehr wohl verstanden, was auf meiner Website
dargestellt werden soll. Obwohl ich darauf noch nicht einmal ausführlich
eingegangen bin, sind ihnen natürlich auch die Bedeutung bzw. die
wirtschaftlichen Auswirkungen vollkommen bewusst. Angesichts solcher Aussichten
befällt sie nun allerdings eine gewisse verständliche Existenzangst, und
dagegeben versuchen Sie mit ihren Posts anzugehen, indem sie mein Konzept
allgemein abwerten. Solche Posts müsste ich dann im Grunde genommen als
implizite Bestätigung meiner Ansätze und Ideen werten. Denn, um es noch einmal
ganz klar zu machen; Vor etwas, von dessen Wichtigkeit und Bedeutung man nicht
wirklich überzeugt ist, hat man auch keine existentielle Angst. An einer
weiteren datailierten Diskussion über mein Konzept wäre dann
Möglichkeit 2:
Die auf meiner Website dargestellten Konzepte sind wirklich trotz unbestreitbar
vorhandener analytisch-technischer Fähigeiten und verhältnismäßig
übererdurchschnittlicher Intelligenz auf seiten der Leser einfach nicht
verstanden worden. So etwas wäre dann meiner Meinung vermutlich auf Effekte wie
funktionale Gebundenheit oder einem ausgeprägten Hallo-Effekt zurückzuführen.
Mit funktionaler Gebundenheit sind Effekte gemeint, dass, wenn man gelernt hat,
ein Problem auf eine gewisse verhältnismäßig schwierige Art zu lösen, man diese
Lösung auch immer noch anwendet, nachdem sich die Aufgabenstellung so geändert
hat, dass sie eigentlich viel leichter auch zu lösen wäre. Man sieht also
praktisch den Wald vor lauter Bäumen nicht mehr.
Ich konnte mein Konzept nur in einer für viele von Euch andersgeartete
Stillistik und Terminologie darstellen. Das hat vielleicht einige dazu
verleitet, sich vom ersten Eindruck täuschen zu lassen. (Hallo-Effekt) So etwa
nach dem Motto: "Einfache Sprache, d.h. das Konzept ist auch einfach, und
deswegenb nichts wert". In diesem Fall wäre eine weitere Diskussion über meine
Konzepte sicher angebracht.
Aber wie soll ich die beiden Alternativen denn unterscheiden? Im Falle von
konkreten Fragen und Stellungnahmen, wäre die Unterscheidung einfach. Dann ist
der letzte Fall anzunehmen
Gruß
Steffen Barth
> Aber wie soll ich die beiden Alternativen denn unterscheiden? Im Falle von
> konkreten Fragen und Stellungnahmen, wäre die Unterscheidung einfach. Dann ist
> der letzte Fall anzunehmen
Beschreib doch hier mal das, was Du einem User (im Zweifelsfall einem
DAU, Onlinebankingnutzer, Schlipsträger etc.) erzählen würdest, der Dein
System (wenn es irgendwo implementiert wäre) anwenden will/muß.
Grüße Steffen
Thomas Braun
> Trotzdem gibt es immer wieder Menschen, die bei einer Sendung wie
> "Wetten das?" auftreten und sich hunderte Nachkommastellen von einer
> Zahl wie Pi merken können. Glaubst Du, die haben ein anderes Gehirn
> als andere Menschen?
Eher nicht, aber wohl mehr Training. Da die Funktionsweise des menschlichen
Gehirns aber erst zu einem sehr geringen Anteil erforscht und verstanden
ist, kann man da auch nicht 100% sicher sein.
> Oder hälst Du es für möglich, dass die Unfähigkeit, sich komplexe
> Passwörter einzuprägen, einfach etwas mit einer schlechten Methodik zu tun
> haben könnte?
Oder mit Faulheit/Bequemlichkeit ;-)
Aber das hat nur peripher etwas mit security zu tun, oder?
Thomas
--
web: www.software-braun.de / email: sp...@software-braun.de
Wer unbedingt email schicken möchte, bitte "spam" mit meinen Initialen
ersetzen. Der Spam-Account wird nicht regelmäßig gelesen.
Volker Birk
> Du, bzw. andere, die ähnlich allgemein abfällig schreiben, ohne aber richtig
> konkret zu werden, haben sehr wohl verstanden, was auf meiner Website
> dargestellt werden soll.
Du willst lieber gehaltvolle Kritik? Kannst Du haben:
"kognitiv und strukturell" deutet darauf hin, dass Du von Sprachentheorie
keine Ahnung hast, und versuchst, mit sozialwissenschaftlichen oder mit
sprachwissenschaftlichen Theorien formale Sprachen zu beschreiben.
Dieser Denkfehler verhindert vollständig, dass Du zu vernünftigen
Ergebnissen kommen kannst.
Deine Begriffe entbehren allesamt einer sauberen Definition; auch der
Versuch, auf gängige Definitionen zurückzugreifen, schlägt fehl:
Was ist eine "einstellige Zahl"? Meinst Du eine Ziffer? Was meinst Du
mit "Generierungsbereich@Challengetabelle"? Insbesondere, was meint das
'@' darin? Schon der erste Satz ist unverständlich: was meinst Du mit:
"Beim kompatiblem PsyPaM erübrigt sich natürlich die Darstellung
des Autorisationsbereichs."
> Die auf meiner Website dargestellten Konzepte sind wirklich trotz unbestreitbar
> vorhandener analytisch-technischer Fähigeiten und verhältnismäßig
> übererdurchschnittlicher Intelligenz auf seiten der Leser einfach nicht
> verstanden worden.
;-)
Kannst du mal versuchen, auf Deutsch zu erklären, was eigentlich die
Idee bei Deinen Sachen ist?
VB.
--
X-Pie Software GmbH
Postfach 1540, 88334 Bad Waldsee
Phone +49-7524-996806 Fax +49-7524-996807
mailto:v...@x-pie.de http://www.x-pie.de
Frank Meyer
> Die auf meiner Website dargestellten Konzepte sind wirklich trotz unbestreitbar
> vorhandener analytisch-technischer Fähigeiten und verhältnismäßig
> übererdurchschnittlicher Intelligenz auf seiten der Leser einfach nicht
> verstanden worden.
Im Subject sprichst Du von einem "einfachen Autorisierungssystem".
Ein System, welches man nur mit komplizierten Worten erklären kann,
kann nicht "einfach" sein.
Du versuchst, Kompetenz über möglichst komplizierte Sätze (auch
in Deinen Postings) vorzuspiegeln. Tatsächlich erreichst Du damit
aber das Gegenteil. Von Deinem Wirrwarr kriegt man höchstens
Kopfschmerzen.
Frank
Stefan Weinzierl
> Hi Stefan,
>
> ich habe den ganzen Kram auf Deiner Webseite nur überflogen und finde
> die Darstellung/Präsentation auch zu schlecht, um mich damit näher zu
> beschäftigen.
Das MUSS wahrscheinlich auch so sein. Weil ich vermutlich eine ganz andere
Denkstruktur und Herangehensweise an das Problem habe, wie du es hast, drücke
ich mich natürlich einer für dich verhältnismäßig fremden Art und Weise aus.
Dies soll in keiner Weise eine Wertung in irgendeine Richtung sein. Es ist
sogar wahrscheinlich notwendig, damit überhaupt Innovation möglich ist, und ich
z.B.PsyPaM entwickeln konnte. Oder um es einmal platt auszudrücken:
Würde ich genau so reden wie du, würde ich natürlich auch genau so denken wie
du. Ich käme dann auch zu denselben Problemlösungen und Schlüssen wie du. So
etwas würde aber keinen Erkenntnisgewinn bringen. Weil das, was ich da
gedanklich entwickeln würde, ja du schon vorher entwickelt hast. Ich würde
praktisch das Rad nocheinmal erfinden. Aber das du meiner Darstellung nicht
folgen konntest, ist eigentlich überhaupt nicht schlecht. Wenn die darin
vorgestellten Konzepte und Ideen, wirklich so schlecht sind, wie du ja
annimmst, dann hast du nicht viel verloren, sondern vielmehr viel Zeit und
Aufwand gespart. Solltest du das Potential und hier insbesondere die
wirtschaftlichen Möglichkeiten meiner Ideen und Konzepte aber gänzlich falsch
eingeschätzt haben, so ist das auch nicht schlimm. Man kann nicht jede Chance,
die sich einem im Leben bietet, auch erkennen und nutzen. Also, was soll?s?
>
> Du schreibst in Deiner Einführung:
>
>> "Anscheinend ist das menschliche Gehirn im Gegensatz zu elektronischen
>> Datenverarbeitungssystemen nicht gerade optimal dazu geeignet, sich
>> eine Vielzahl von komplexen Passwörtern sicher zu merken und im
>> Bedarfsfall auch präzise wiederzugeben."
>
> Trotzdem gibt es immer wieder Menschen, die bei einer Sendung wie
> "Wetten das?" auftreten und sich hunderte Nachkommastellen von einer
> Zahl wie Pi merken können. Glaubst Du, die haben ein anderes Gehirn
> als andere Menschen? Oder hälst Du es für möglich, dass die
> Unfähigkeit, sich komplexe Passwörter einzuprägen, einfach etwas mit
> einer schlechten Methodik zu tun haben könnte?
Tut mir leid!. Aber wenn ich dein Post so lese, werde ich einfach den Verdacht
nicht los, das du mich mit ihm in hochakedemische und hochphilosophische
Diskussion verwickeln willst, die aber keinen Fortschritt bringen würde,
sondern nur von den eigentlich brisanten Fragen und Problemen ablenken würde.
Es ist doch Schwachsinn, als Beispiele für die Lösung von Alltagsproblemen
Ausnahmeerscheinungen zu benutzen. Das ist doch ungefähr so, wie als würde man
sagen: "Wir brauchen zum Tauchen keine Sauerstoffflaschen, weil es gibt
Menschen, die können 80 Meter tief tauchen"
Meine Website ist ja in drei Teile (komp. PsyPaM, biomet. PsyPaM und 2U), die
inhaltlich verhältnismäßig wenig miteinander zu tun haben, unterteilt. Nun
lenkst du plötzlich die Diskussion auf das kompatible PsyPaM,von dem ja die
ganze Zeit nie die Rede war. Ich habe doch mit meinem Post, das biometrische
PsyPaM vorgestellt und der Allgemeinheit zur Verfügung gestellt oder etwa
nicht? So etwas macht mich natürlich stutzig
> google "Memoriersysteme"
>
> Denke bitte nach dem Lesen noch einmal darüber nach, ob jemand "ein
> einfaches Autorisierungssystem mit verschlüsselter Datenübertragung"
> benötigt, wenn man sich Passwörter doch einfach ... merken kann!
Nichts desto trotz. Ich kann mich ja auch irren, und hier schneidest du ja auch
einen wichtigen Gedanken an:
Zum Einen nämlich kann man sich nämlich Passwörter nicht "einfach" merken.Das
Informationsverarbeitungssystem homo sapiens ist nämlich im Gegensatz zu
Computern nicht darauf konzipiert und eingerichtet, sich eine Vielzahl
komplexer und möglichst zufälliger Zeichenfolgen exakt und präzise einzuprägen
und sie im Bedarfsfall auch wieder genauso exakt und präzise wiederzugeben.
Obwohl Passwortsysteme ja derzeitig in der IT-Technik noch äußerst wichtige und
zentrale Methoden zur Personenidentifikation darstellen, ist der Vorgang der
Generierung, Anwendung und Verwaltung von Passwörtern noch in keiner Weise
präzisiert bzw. operationalisiert worden. Oder mit anderen Worten: Keine Sau
weis, was unter "richtigem" Umgang mit Passwörtern zu verstehen ist, weil sich
noch niemand (Na gut, mit Ausnahme von mir) die Mühe gemacht hat,
klar,eindeutig und in präzisen, positiven Handlungsanweisungen zu beschreiben,
was damit eigentlich konkret gemeint ist. Damit ist das alles auch viel zu
schwammig, um darüber auf fruchtbare Weise zu diskutieren zu können.
Gruß
Besim Karadeniz
Stefan Weinzierl schrieb:
> Würde ich genau so reden wie du, würde ich natürlich auch genau so
> denken wie du. Ich käme dann auch zu denselben Problemlösungen und
> Schlüssen wie du. So etwas würde aber keinen Erkenntnisgewinn
> bringen. Weil das, was ich da gedanklich entwickeln würde, ja du
> schon vorher entwickelt hast. Ich würde praktisch das Rad nocheinmal
> erfinden.
Hm, verwende diese Argumentation keinesfalls in einem philosophischen
Zirkel, in einem Bewerbungsgespräch oder beim Smalltalk während einem
Empfangs, du könntest schweren Schaden erleiden. Und das möglicherweise
nicht nur verbal.
Besim
--
Besim at Karadeniz dot de >> Pforzheim/GER >> PGP (RSA 3072) 0xC3251240
netplanet - Verstehen Sie mal das Internet! - http://www.netplanet.org/
"Radio geht ins Ohr, Fernsehen ins Auge."
-- Robert Lembke, dt. Journalist (1913 - 1989)
Martin Schmitz
> Keine Sau weis, was unter "richtigem" Umgang mit Passwörtern zu
> verstehen ist, weil sich noch niemand [...] mit Ausnahme von mir die
> Mühe gemacht hat [...] zu beschreiben, was damit eigentlich konkret
> gemeint ist.
Ne, klar Atze. Außer Dir hat sich noch niemand Gedanken um die
Verwendung von Passwörtern gemacht.
Selbstverständlich ist das menschl. Gehirn dazu geeignet, sich Sequenzen
von Symbolen zu merken. Hast Du schonmal gesehen, was für komplizierte
Wege durch ein Labyrinth sich eine Ratte merken kann, wenn dort
erfahrungsgemäß das Futter liegt. Fazit: Offensichtlich bist Du dümmer
als eine Ratte, mehr ist auch auf Deinen Webseiten nicht zu lesen.
Popcorn anyone?
cnr,
Martin
Alexander Skwar
> Das MUSS wahrscheinlich auch so sein. Weil ich vermutlich eine ganz andere
> Denkstruktur und Herangehensweise an das Problem habe, wie du es hast, drücke
> ich mich natürlich einer für dich verhältnismäßig fremden Art und Weise aus.
> Dies soll in keiner Weise eine Wertung in irgendeine Richtung sein. Es ist
> sogar wahrscheinlich notwendig, damit überhaupt Innovation möglich ist,
Das ist ja richtig, trotzdem taugt eine "Bleiwüste" wie Deine Webseite
nicht dazu, das es dem Benutzer leicht gemacht wird dem Inhalt zu folgen.
Du hast auf einer Seite schlicht zu viel Text.
Zumal: Die Art der Darstellung (nur darum geht es jetzt mal!) ist nun
wirklich nicht neu und scheinbar auch nicht (nur) auf Deinem Mist
gewachsen. Keinesfalls ist sie innovativ.
Wie dem auch sei - die Darstellung lädt nicht dazu ein einen so langen Text
zu lesen.
Andererseits scheinen Dir "Bleiwüsten" zu liegen. Auch in Deinen Postings
hast Du immer Kilometer von Text ohne irgendwelche Absätze. Alleine schon
deshalb lese ich Dich ungern. Wobei das alles *gar nichts* über Deinen
Inhalt aussagt.
Alexander Skwar
--
We're Germans and we use Unix. That's a combination of two
demographic groups known to have no sense of humour whatsoever.
-- Hanno Müller <sockp...@hanno.de> in de.comp.os.unix.programming
end
Jonathan Sauer
> [merken von Paßwörtern]
> Es ist doch Schwachsinn, als Beispiele für die Lösung von Alltagsproblemen
> Ausnahmeerscheinungen zu benutzen.
Die meisten Menschen dürften sich Telephonnummern merken können.
> [...]
> Keine Sau weis, was unter "richtigem" Umgang mit Passwörtern zu verstehen
> ist, weil sich noch niemand (Na gut, mit Ausnahme von mir)
Nö. Ich habe mich in meiner Diplomarbeit ebenfalls damit beschäftigt.
Und dabei Quellen herangezogen, die sich damit beschäftigt haben.
> die Mühe gemacht hat, klar,eindeutig und in präzisen, positiven
> Handlungsanweisungen zu beschreiben, was damit eigentlich konkret gemeint
> ist.
"Ein Paßwort muß mindestens X Zeichen lang sein."
"Ein Paßwort muß aus Buchstaben, Ziffern und Sonderzeichen bestehen."
"Ein Paßwort muß sich von den letzten fünf Paßwörtern unterscheiden."
"Ein Paßwort darf nicht aufgeschrieben werden."
"Ein Paßwort darf nicht weitergegeben werden. Auch nicht, wenn jemand
danach fragt. Auch nicht, wenn der Fragende ein Administrator, Manager
o.ä. ist."
Ggfs. noch mit Begründungen.
Was ist daran nicht präzise und "positiv"?
> Gruß
>
> Stefan
Gruß, Jonathan
Stefan Weinzierl
>
> Ich habe mir Deine Seite schon angeschaut, als kürzlich hier einmal die
> "Einmalschlüsselfrage" gestellt wurde. Ich muß zugeben, beim Überfliegen
> auch nicht ansatzweise das Prinzip verstanden zu haben. Wenn ein
> durchschnittlicher Mensch 10 Minuten brauchen soll, um sich eine
> Zahlenpermutation zu merken, muß er auch in weiteren 5 Minuten
> begreifen, wie er die anzuwenden hat.
>
> Grüße Steffen
Damit du es verstehen kannst, muss ich dir wahrscheinlich kurz die Entwicklung
und Evolution des ganzen Konzeptes erklären. Also mach dich auf was gefasst:
Eigentlich wollte ich nur ein System zur Passwortverwaltung entwickeln. Hier war
der Grundansatz Passwörter an Hand von Vorgabedaten über eine allgemeine
Berechnungsvorschrift mittels eines persönlichen Codeschlüssels zu berechnen.
Das konkrete Passwort wird also nicht mehr gemerkt, sondern von Fall zu Fall
erechnet
Gut, hierbei kam mir der Gedanke, dass wenn schon die konkreten
Autorisationsdaten nicht mehr gemerkt werden müssen, dann eigentlich der
Autorisationsdienst aus einem Pool von Vorgabedaten bestimmte auswählen und
diese dem Benutzer vorlegen kann. Der Benutzer rechnet die zugehörigen
Autorisationsdaten aus und identifiziert sich dann. Die Vorteile gegenüber der
Authentifizierung mit Passwörtern sind klar: Der Benutzer braucht sich keine
Passwörter zu merken und Prinzip bedingt ist es unmöglich durch einmaliges
Abhören an die Identifikationsdaten zu gelangen (Dass so etwas ein
challenge-response System heißt, ist mir zugegeben erst klar geworden,als das
ganze Ding schon fertig war.)
Im Laufe der Entwicklung sind nun zu diesem Grundprinzip noch einige
sicherheitstechnische "Gemeinheiten" hinzugekommen:
-Zunächst einmal habe ich die entsprechenden Vogabedaten beim Benutzer
deponiert, und nicht wie ursprünglich geplant beim Autorisationsdienst. Die
Kommunikation zwischen beiden erfolgt über einen Index.Damit kann nicht einmal
der Autorisationsdienst den persönlichen Codeschlüssel erschließen.Dazu würde
er nämlich die Vorgabedaten UND die vereinbarten Identifikationsdaten
benötigen. Auf diese Weise ist es, auch wenn das System verschiedene,
unterschiedliche Autorisationsdienste benutzen, es für den Benutzer nur
notwendig, EINEN EINZIGEN persönlichen Codeschlüssel zu erlernen.
-Ich habe einen Weg gefunden bei jedem Autorisationsvorgang GLEICHZEITIG auch
neue Kombinationen von Identifikationsdaten bzw. Vorgabedaten zwischen
Autorisationsdienst und Benutzer/in zu vereinbaren. Die Autorisationsdaten
änderen sich also im Laufe der Zeit. Das ganze Ding ist DYNAMISCH, und
natürlich damit noch schwieriger anzugreifen.
-Zu guter Letzt werden die zu übermittelnden Identifikationsdaten, durch eine
einfache Rechenoperation im Kopf vor ihrer Übermittlung noch so VERSCHLÜSSELT,
dass nur für den Autorisationsdienst erschließbar ist, wie die Ursprungsdaten
lauten. Also selbst das Abhören einer großen Zahl von verschiedenen Eingaben
über einen langen Zeitraum hinweg nützt jetzt auch nichts mehr. Ich kann
nämlich die Ursprungsdaten nicht herausrechneen.
Das System ist nun natürlich noch so implementiert, dass man es wirklich leicht
handhaben und rechnen kann.Die hier vorgestellten drei Bereich sind aber auf
meiner Website miteinander verschränkt dargestellt, weil ja hier alles zusammen
miteinander erklärt werden muss. Das macht es so kompliziert Aber, glaube mir,
es ist kein Problem dieses Konzept hier jemanden zu erklären, wenn man sich nur
auf die konkrete Implementierung beschränken kann.
Gruss
Stefan
-
Roman Racine
> Kommunikation zwischen beiden erfolgt über einen Index.Damit kann nicht
> einmal der Autorisationsdienst den persönlichen Codeschlüssel
> erschließen.Dazu würde er nämlich die Vorgabedaten UND die vereinbarten
> Identifikationsdaten benötigen. Auf diese Weise ist es, auch wenn das
> System verschiedene, unterschiedliche Autorisationsdienste benutzen, es
> für den Benutzer nur notwendig, EINEN EINZIGEN persönlichen Codeschlüssel
> zu erlernen. -Ich habe einen Weg gefunden bei jedem Autorisationsvorgang
> GLEICHZEITIG auch neue Kombinationen von Identifikationsdaten bzw.
> Vorgabedaten zwischen Autorisationsdienst und Benutzer/in zu vereinbaren.
> Die Autorisationsdaten änderen sich also im Laufe der Zeit. Das ganze Ding
> ist DYNAMISCH, und natürlich damit noch schwieriger anzugreifen.
> -Zu guter Letzt werden die zu übermittelnden Identifikationsdaten, durch
> eine einfache Rechenoperation im Kopf vor ihrer Übermittlung noch so
> VERSCHLÜSSELT, dass nur für den Autorisationsdienst erschließbar ist, wie
> die Ursprungsdaten lauten.
Was an diesem Konzept ist denn so revolutionär? Angenommen, dein System
würde in der Praxis funktionieren und sei so sicher, wie du behauptest, wo
läge denn z.B. der Unterschied zu Public-Key Authentisierungsverfahren (wie
man sie z.B. bei SSH verwenden kann)? Bei SSH und anderen verwandten
Systemen sehe ich jedenfalls noch den Vorteil, dass sich im Optimalfall
beide Seiten gegenseitig über die Authentizität des Gegenübers versichern
können. Das scheint dein System nicht zu können, damit wäre es unter
Umständen sehr einfach attackierbar.
Gruss
Roman
--
Sämtlichen bisherigen "Regeln" von schule.* sind mit sofortiger
Wirkung ausser Kraft gesetzt. Ich werde in Bälde neue, legale und
zweckdienliche Regeln für schule.* etablieren. ("Chiap Zap" in
<9D5A935BD3718B4D...@aawfanqh.xiujplxe>)
Bernd Eckenfels
> -Zu guter Letzt werden die zu übermittelnden Identifikationsdaten, durch eine
> einfache Rechenoperation im Kopf vor ihrer Übermittlung noch so VERSCHLÜSSELT,
> dass nur für den Autorisationsdienst erschließbar ist, wie die Ursprungsdaten
> lauten. Also selbst das Abhören einer großen Zahl von verschiedenen Eingaben
> über einen langen Zeitraum hinweg nützt jetzt auch nichts mehr. Ich kann
> nämlich die Ursprungsdaten nicht herausrechneen.
Ok, fangen wir damit an: Wie sieht das Geheimnis aus (Wertebereich), wie die
Anfrage und wie die Berechnung?
Ich stell mir das so vor:
mein geheimnis:
- meine hand hat 5 finger
- mein fuss hat 5 zehen
- ich habe 3 blomben
die anfrage:
- nenne mir blomben mal finger
das ergebnis:
- 15
Leider kann man sich nur eine sehr geringe Anzahl von Geheimnissen merken,
und eine noch weniger komplizierte Berechnung im Kopf durchfuehren, von
daher bin ich mir nicht so sicher, dass dieses Verfahren im Gegensatz zu
normalen Token Systemen punkten kann.
Aber wie gesagt, nenn uns mal nen konkretes Beispiel:
- was muss der nutzer sich merken
- was muss er berechnen
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Andreas Beck
>> ich habe den ganzen Kram auf Deiner Webseite nur überflogen und finde
>> die Darstellung/Präsentation auch zu schlecht, um mich damit näher zu
>> beschäftigen.
> Das MUSS wahrscheinlich auch so sein.
Das heißt, daß Dein System (so es irgendwie funktioniert) bereits im
Ansatz tot ist.
Systeme, die man nicht mit mathematisch-analytischen Methoden verstehen
kann, sind für Sicherheitssysteme nicht geeignet.
> Aber das du meiner Darstellung nicht folgen konntest,
Ist Dir schon aufgefallen, daß das scheinbar niemand kann?
Kannst Du mal in Form eines Kochrezeptes erzählen, was der Benutzer tun
muss, um sich nach Deiner Methode bei einem System anzumelden?
Also sowas in der Art von:
1. Der Benutzer teilt dem System seine Benutzerkennung mit.
2. Das System sendet eine Challenge, die so-und-so aussieht.
3. Der Benutzer guckt mit Hilfe der Challenge-Felder x und y dort und
dort nach, rechnet x^y mod z
4. Der Benutzer sendet das Ergebnis an das System.
Wie es detailliert funktioniert, etc. kann man dann nachreichen. So wie
es auf der Website dargestellt ist, ist es völlig unverständlich.
Lies mal die einschlägige Dokumentation zu SSH, IPSec etc., dann kriegst
Du eine Vorstellung, wie man sowas hinschreiben muß, damit es direkt
les- und verstehbar ist.
> Solltest du das Potential und hier insbesondere die wirtschaftlichen
> Möglichkeiten meiner Ideen und Konzepte aber gänzlich falsch
> eingeschätzt haben, so ist das auch nicht schlimm. Man kann nicht jede
> Chance, die sich einem im Leben bietet, auch erkennen und nutzen.
> Also, was soll?s?
Jaja ... Du hast den Stein der Weisen gefunden ... das schaffen alle
paar Tage ein paar Leute ...
> Verdacht nicht los, das du mich mit ihm in hochakedemische und
> hochphilosophische Diskussion verwickeln willst,
Irgendwie werde _ich_ den Verdacht nicht los, daß Du genau das haben
willst. Ich habe noch keinen einzigen technisch konkreten Artikel hier
von Dir gelesen. Schwammiges blabla kann man nicht analysieren.
Das hat natürlich Vorteile, wenn das schwammige blabla Unsinn ist, was
ja bei einer Analyse auffallen würde.
> von den eigentlich brisanten Fragen und Problemen ablenken würde.
Von welchen? Was sind Deine Probleme mit den Verfahren? Du sagst, Du
kannst es nicht implementieren. Nun. Hier sind eine Menge Leute, die
klar vorgegebene Algorithmen in Code giessen können.
Es wäre nur nötig, daß Du das mal strukturiert hinschreibst, statt
zusammengewürfelten blabla abzusondern.
> Wir brauchen zum Tauchen keine Sauerstoffflaschen, weil es gibt Menschen,
> die können 80 Meter tief tauchen"
Man taucht eh nicht mit Sauerstoffflaschen. Jedenfalls nicht tiefer als
ca. 6m. Ausnahme bei ECCR, aber auch da braucht man Diluent.
Also mach bitte keine Beispiele, von denen Du keine Ahnung hast.
> Informationsverarbeitungssystem homo sapiens ist nämlich im Gegensatz
> zu Computern nicht darauf konzipiert und eingerichtet, sich eine
> Vielzahl komplexer und möglichst zufälliger Zeichenfolgen exakt und
> präzise einzuprägen und sie im Bedarfsfall auch wieder genauso exakt
> und präzise wiederzugeben.
Das braucht man im Zweifel auch nicht. Wenn man mit vertrauenswürdigen
Cryptoeinheiten arbeitet und nur einen Unlocking Key für den darin
gespeicherten Private Key benötigt, braucht man genau ein Passwort.
> Keine Sau weis, was unter "richtigem" Umgang mit Passwörtern zu
> verstehen ist, weil sich noch niemand (Na gut, mit Ausnahme von mir)
> die Mühe gemacht hat, klar,eindeutig und in präzisen, positiven
> Handlungsanweisungen zu beschreiben, was damit eigentlich konkret
> gemeint ist.
Bahnhof? Koffer klauen? Es gibt präzise formulierbare Passwort-Policies,
mit Hintergrundüberlegungen, warum welche Regeln Sinn machen.
Vielleicht könntest Du und mal in verständlicher Weise darstellen, was
da _Deine_ Regeln dazu sind.
CU, ANdy
Jens Suelwald
[...]
> Zum Einen nämlich kann man sich nämlich Passwörter nicht "einfach" merken.Das
> Informationsverarbeitungssystem homo sapiens ist nämlich im Gegensatz zu
> Computern nicht darauf konzipiert und eingerichtet, sich eine Vielzahl
> komplexer und möglichst zufälliger Zeichenfolgen exakt und präzise einzuprägen
> und sie im Bedarfsfall auch wieder genauso exakt und präzise wiederzugeben.
Ich weiss nicht... ich hab einige recht komplizierte Passwörter im Kopf,
und kann mich nach Belieben an diese erinnern.
Und ich denke, ich bin desswegen kein Einzelfall.
> Keine Sau weis, was unter "richtigem" Umgang mit Passwörtern zu
> verstehen ist, weil sich noch niemand (Na gut, mit Ausnahme von mir) die
> Mühe gemacht hat,
(Wobei dieser gequotete Abschnitt fast wie ne Beleidigung wirkt... *g*)
Hmmm... das denke ich nicht, und ich denke, das nicht nur Du Dir wegen
Passwörter und deren richtigen Umgang Gedanken gemacht hast.
Ich weiss recht gut, was ich mit den Passwörtern machen sollte, die ich
Kopf habe... sowas wie "niemanden mitteilen", "regelmässig ändern",
"sichere Passwörter wählen (Gross/Kleinschreibung, Ziffern) etc...
... und was man damit nicht machen sollte, weiss ich auch. Und ich bin
auch kein Einzelfall, weil ich mir darüber Gedanken mache.
Bis denne,
Jens Suelwald
--
Archer: "I don't recall authorizing a tactical drill"
Reed : "It wouldn't be much of a drill, if everybody knows about it, SIR"
(Enterprise - Singularity - During the tactical alert drill)
Juergen P. Meier
Wie verhinderst du Reply-Angriffe?
> Im Laufe der Entwicklung sind nun zu diesem Grundprinzip noch einige
> sicherheitstechnische "Gemeinheiten" hinzugekommen:
> -Zunächst einmal habe ich die entsprechenden Vogabedaten beim Benutzer
> deponiert, und nicht wie ursprünglich geplant beim Autorisationsdienst. Die
> Kommunikation zwischen beiden erfolgt über einen Index.Damit kann nicht einmal
> der Autorisationsdienst den persönlichen Codeschlüssel erschließen.Dazu würde
> er nämlich die Vorgabedaten UND die vereinbarten Identifikationsdaten
> benötigen. Auf diese Weise ist es, auch wenn das System verschiedene,
> unterschiedliche Autorisationsdienste benutzen, es für den Benutzer nur
> notwendig, EINEN EINZIGEN persönlichen Codeschlüssel zu erlernen.
> -Ich habe einen Weg gefunden bei jedem Autorisationsvorgang GLEICHZEITIG auch
> neue Kombinationen von Identifikationsdaten bzw. Vorgabedaten zwischen
> Autorisationsdienst und Benutzer/in zu vereinbaren. Die Autorisationsdaten
> änderen sich also im Laufe der Zeit. Das ganze Ding ist DYNAMISCH, und
> natürlich damit noch schwieriger anzugreifen.
> -Zu guter Letzt werden die zu übermittelnden Identifikationsdaten, durch eine
> einfache Rechenoperation im Kopf vor ihrer Übermittlung noch so VERSCHLÜSSELT,
> dass nur für den Autorisationsdienst erschließbar ist, wie die Ursprungsdaten
> lauten. Also selbst das Abhören einer großen Zahl von verschiedenen Eingaben
> über einen langen Zeitraum hinweg nützt jetzt auch nichts mehr. Ich kann
> nämlich die Ursprungsdaten nicht herausrechneen.
So, der Authentifizierungsagent soll also nicht wissen, wie du die
Auth-"Daten" berechnest. Wie soll er entscheiden koennen, ob deine
Daten korrekt sind?
> Das System ist nun natürlich noch so implementiert, dass man es wirklich leicht
> handhaben und rechnen kann.Die hier vorgestellten drei Bereich sind aber auf
> meiner Website miteinander verschränkt dargestellt, weil ja hier alles zusammen
> miteinander erklärt werden muss. Das macht es so kompliziert Aber, glaube mir,
> es ist kein Problem dieses Konzept hier jemanden zu erklären, wenn man sich nur
> auf die konkrete Implementierung beschränken kann.
Wie genau unterscheidet es sich von S/Key?
Und werde endlich mal konkret. So schwammig wie du das beschreibst,
kann das alles moegliche und unmoegliche sein.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
Juergen P. Meier
> mein geheimnis:
> - meine hand hat 5 finger
> - mein fuss hat 5 zehen
> - ich habe 3 blomben
>
> die anfrage:
> - nenne mir blomben mal finger
>
> das ergebnis:
> - 15
Wenn ich deine Kommunikation lange genug abhoere, kenne ich alle deine
Geheimnisse.
> Aber wie gesagt, nenn uns mal nen konkretes Beispiel:
>
> - was muss der nutzer sich merken
> - was muss er berechnen
ACK.
Michael H. Fischer
> Denn, zwei völlig unterschiedlich zu bewertende Motivlagen können
> als Beweggrund solchen Posts zugrunde liegen.
Falsch. Du hast die dritte Möglichlkeit vergessen:
Man hat sich deine Seite angesehen, erkannt, dass du das Fehlen von
Substanz mit möglichst viel "Wortnebel" verbergen willst und
festgestellt, dass an deiner Idee weder etwas neues noch gar
bahnbrechendes zu finden ist.
Ich konnte selbst bei sorgfältigstenm Studium deiner Aussagen nichts
finden, was weiterer Aufmerksamkeit Wert gewesen wäre. Du willst das
Rad neu erfinden, fabulierst aber dabei nur quasi von einem
"Mehrdiemensionalen polyquaderförmigen Gegestand mit angewandtem
offsetzentrischem Hohlkern". Das ist lediglich TechnoBabbel ohne
Inhalt.
MfG
Michael H. Fischer
Stefan Weinzierl
>
> Selbstverständlich ist das menschl. Gehirn dazu geeignet, sich Sequenzen
> von Symbolen zu merken. Hast Du schonmal gesehen, was für komplizierte
> Wege durch ein Labyrinth sich eine Ratte merken kann, wenn dort
> erfahrungsgemäß das Futter liegt. Fazit: Offensichtlich bist Du dümmer
> als eine Ratte, mehr ist auch auf Deinen Webseiten nicht zu lesen.
Übertragen wir einmal das Beispiel der Ratte unter Laborbedingungen auf ein
Eichhörnchen, das seinen Wintervorrat wiederfinden will. Hier ist dasselbe
Problem angesprochen nur unter Feldbedingungen.
Das Eichhörnchen hat im Sommer, als ja bekanntlich alles blühte und die Bäume
voller Laub waren, seinen Wintervorrat irgendwo vergraben.
Im Winter, wenn Schnee liegt und die Bäume alle ihr Blätter verloren haben (und
so weiter und so fort), muss es seine Nüsse wieder finden. Es muss also sich
den Weg zu diesen so einprägen, dass es sie auch unter total veränderten
Umweltbedingungen wiederfindet.
Für biologische Systeme sind solche Aufgabenstellungen kein Problem.
Für Computer sehr wohl, wie jeder ganz sicher bestätigen kann, der schon einmal
bei irgendwelchen Progammieraufgaben einen dieser berühmt-berüchtigten
Syntaxfehler gemacht hat.
Computer können dafür viel besser und vor allen Dingen viel fehlerfreier zwei
Sequenzen (Passwörter) daraufhin vergleichen,dass sie wirklich absolut
identisch miteinander sind.
> Popcorn anyone?
Kannst du mir nicht schnell mal einen Algorithmus bauen, der meinen Computer
dazu bringt, sicher Popcorn sicher von Styroporkügelchen zu unterscheiden? Das
bräuchte ich nämlich gerade.
Stefan Weinzierl
> commence followup to Stefan Weinzierl <stefan.w...@t-online.de>:
>
> Das ist ja richtig, trotzdem taugt eine "Bleiwüste" wie Deine Webseite
> nicht dazu, das es dem Benutzer leicht gemacht wird dem Inhalt zu folgen.
> Du hast auf einer Seite schlicht zu viel Text.
Das stimmt natürlich auch. Besser kann ich es derzeitig nicht. Und selbst auf
die Gefahr mich zu wiederholen. Du musst es ja nicht lesen.
>
> Zumal: Die Art der Darstellung (nur darum geht es jetzt mal!) ist nun
> wirklich nicht neu und scheinbar auch nicht (nur) auf Deinem Mist
> gewachsen. Keinesfalls ist sie innovativ.
Schöne Behauptungen. Ich bin gespannt, wie deine Argumente und Beweise für deine
Thesen aussehen. Du hast 48 Stunden Zeit, um gegen anzutreten Ansonsten erlaube
ich mir, mich zum Sieger in dieser Ausseinandersetzung wegen Nichtantrit des
Gegners auszurufen.
> Wie dem auch sei - die Darstellung lädt nicht dazu ein einen so langen Text
> zu lesen.
Du hast wahrscheinlich wieder recht. Ich kann aber derezeitig trotzdem nicht so
schnell daran aussehen.
Volker Birk
> Übertragen wir einmal das Beispiel der Ratte unter Laborbedingungen auf ein
> Eichhörnchen
Merkst Du gar nicht, was Du für ein Problem hast?
Alexander Skwar
> Schöne Behauptungen. Ich bin gespannt, wie deine Argumente und Beweise für deine
> Thesen aussehen. Du hast 48 Stunden Zeit, um gegen anzutreten Ansonsten erlaube
> ich mir, mich zum Sieger in dieser Ausseinandersetzung wegen Nichtantrit des
> Gegners auszurufen.
Wie soll ich beweisen das Bleiwüsten und Kilometer von Text nichts neues
sind?
Alexander Skwar
--
/* Identify the flock of penguins. */
2.2.16 /usr/src/linux/arch/alpha/kernel/setup.c
Norbert Tretkowski
> Schöne Behauptungen. Ich bin gespannt, wie deine Argumente und
> Beweise für deine Thesen aussehen. Du hast 48 Stunden Zeit, um gegen
> anzutreten Ansonsten erlaube ich mir, mich zum Sieger in dieser
> Ausseinandersetzung wegen Nichtantrit des Gegners auszurufen.
Wenn du spielen willst, geh zurueck in den Sandkasten.
--
- nobse
Stefan Weinzierl
> commence followup to Stefan Weinzierl <stefan.w...@t-online.de>:
>
>> Schöne Behauptungen. Ich bin gespannt, wie deine Argumente und Beweise für
>> deine Thesen aussehen. Du hast 48 Stunden Zeit, um gegen anzutreten Ansonsten
>> erlaube ich mir, mich zum Sieger in dieser Ausseinandersetzung wegen
>> Nichtantrit des Gegners auszurufen.
>
> Wie soll ich beweisen das Bleiwüsten und Kilometer von Text nichts neues
> sind?
>
> Alexander Skwar
Was ist konkret offensichtlich nicht auf meinem Mist gewachsen ? Vieles dürften
vielleicht Parallelentwicklungen sein. O.K Das kann man aber klären
Sebastian Posner
> Lutz Donnerhacke wrote:
>> Ich kann dort außer einem wirren Haufen an komplexen Begriffen kein Konzept
>> erkennen.
>
> IKS GmbH
> Verlag IKS Garamond
> [...]
>
> Was stellen den die für geistige Dünnbretbohrer ein, wenn ihre Angestellten
> nicht einmal in der Lage sind, eine bewusst einfach und verständlich gehaltenen
> Darstellung eines Laien, der aber nicht desto trotz auch Hochschulabsolvent
> ist, zu erfassen?
Popcorn!
Sebastian
--
"Ja der weiße Mann aus Texas / Brät den Teufel heut am Spieß,
Und alle, die ein anderes Lied singen / grillt der Mann im Fegefeuer mit"
Fink feat. Peter Lohmeyer / Bagdad Blues ( Der weiße Mann aus Texas)
Alexander Skwar
> Alexander Skwar wrote:
>
>> commence followup to Stefan Weinzierl <stefan.w...@t-online.de>:
>>
>>> Schöne Behauptungen. Ich bin gespannt, wie deine Argumente und Beweise für
>>> deine Thesen aussehen. Du hast 48 Stunden Zeit, um gegen anzutreten Ansonsten
>>> erlaube ich mir, mich zum Sieger in dieser Ausseinandersetzung wegen
>>> Nichtantrit des Gegners auszurufen.
>>
>> Wie soll ich beweisen das Bleiwüsten und Kilometer von Text nichts neues
>> sind?
>>
>> Alexander Skwar
> Was ist konkret offensichtlich nicht auf meinem Mist gewachsen ? Vieles dürften
> vielleicht Parallelentwicklungen sein. O.K Das kann man aber klären
Ah, Missverständnis! Wie ich bereits sagte, geht es mir NUR um die
Darstellung, die Präsentation. Den Inhalt habe ich auf Grund der IMHO
mangelhaften Darstellung gar nicht erst wahrgenommen.
Ob Du inhaltlich bei irgendwem abgekupfert hast, kann ich darum nicht
sagen. Ich weiß es schlicht nicht.
Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
Stefan Weinzierl
> Wie verhinderst du Reply-Angriffe?
Wie sieht ein reply-Angriff aus? Dann kann ich dir sagen, wie ich ihn
verhindere.
> So, der Authentifizierungsagent soll also nicht wissen, wie du die
> Auth-"Daten" berechnest. Wie soll er entscheiden koennen, ob deine
> Daten korrekt sind?
Das ist eben der Trick an der Sache, und das unterscheidet meiner Meinung nach
dieses System auch von herkömmlichen Challenge-response Systemen. Die Daten
welche zur Identifizierung benutzt werden, sind nur Zahlen die bestimmten
Indices zugeordnet werden. Wie diese Daten generiert bzw. gespeichert werden
ist dem Authentifizierungsagenten eigentlich vollkommen gleichgültig.
Um es praktisch zu machen: Der Autorisationsdienst hat in seiner Datenbank (=
Autorisationstabelle) pro Datensatz bestimmte einstellige Zahlenwerte mit
bestimmten Indices verbunden. Nun übermittelt der einige von diesen Indices an
den Benutzer, bzw. an eine Datenbank im Besitz des Benutzers. Diese Datenbank
(=Generierungstabelle) hier beinhaltet im Groben pro Datensatz nur die gleichen
Indices, wie sie auch in der Autorisationstabelle vorhanden sind und
Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
Autorisationsdaten berechnen kann. Die nun entsprechenden Vorgabedaten werden
dem Benutzer vorgelegt. Die so berechneten Daten werden nun verschlüsselt an
den Autorisationsdienst übergeben. Der vergleicht sie mit seinen Werten u.s.w.
Gleichzeitig werden auch neue Index-Passzahl Kombinationen an den
Authentifikationsagenten übermittelt (In die Generierungstabelle muss natürlich
auch den neuen Gegebenheiten angepaßt werden, und entsprechende synchronisiert
werden)
>> Das System ist nun natürlich noch so implementiert, dass man es wirklich
>> leicht handhaben und rechnen kann.Die hier vorgestellten drei Bereich sind
>> aber auf meiner Website miteinander verschränkt dargestellt, weil ja hier
>> alles zusammen miteinander erklärt werden muss. Das macht es so kompliziert
>> Aber, glaube mir, es ist kein Problem dieses Konzept hier jemanden zu
>> erklären, wenn man sich nur auf die konkrete Implementierung beschränken
>> kann.
>
> Wie genau unterscheidet es sich von S/Key?
Als vorläufige Antwort würde ich einmal sagen, dass ich das Prinzip von PsyPaM
verstanden habe, während ich mit dem Begriff von S/Key überhaupt nichts
anfangen kann. Das ist schon einmal für mich ein entscheidender Unterschied
zwischen den beiden Systemen.
> Und werde endlich mal konkret. So schwammig wie du das beschreibst,
> kann das alles moegliche und unmoegliche sein.
Ich bin gerade dabei konkret zu werden. Aber alles der Reihe nach. Solange ich
dir das Grundprinzip des Systems nicht verständlich machen. weil mir z.B. noch
zu viel von deiner Terminologie bzw. deinem Vorwissen fehlt,macht es noch
überhaupt keinen Sinn, dir die konkrete Implementierung des Ganzen erklären. zu
wollen.
Es dauert also noch ein bisschen
Gruß
Stefan
Henryk Plötz
Am Mon, 24 Nov 2003 19:30:47 +0100 schrieb Stefan Weinzierl:
> > Wie verhinderst du Reply-Angriffe?
> Wie sieht ein reply-Angriff aus? Dann kann ich dir sagen, wie ich ihn
> verhindere.
Gemeint war sicherlich "Replay-Angriff": Ein Angreifer beobachtet einen
Auth-Vorgang und spielt die dabei beobachteten Daten einfach wieder ein
um sich selbst Zugang zu verschaffen. Dabei spielt es dann keine Rolle
wie kompliziert die Zugangsdaten zu berechnen sind.
> > Wie genau unterscheidet es sich von S/Key?
>
> Als vorläufige Antwort würde ich einmal sagen, dass ich das Prinzip
> von PsyPaM verstanden habe, während ich mit dem Begriff von S/Key
> überhaupt nichts anfangen kann.
S/Key ist relativ einfach: Man braucht zunächst mal eine sichere
Einweg-Hashfunktion, zum Beispiel MD5. Der Benutzer wählt für sich eine
Passphrase, die natürlich den üblichen Regeln für Passphrasen
entsprechen sollte (lang, nicht aus der Literatur, nicht zu erraten,
usw.).
Bevor es benutzt werden kann, muß das System einmalig initialisiert
werden. Dazu wird die Passphrase genommen und (zum Beispiel) 100 mal mit
mit der Hashfunktion gehasht. Wenn die Passphrase "Ein schöner Tag"
wäre, würde man also MD5(MD5(MD5(MD5....MD5("Ein schöner Tag")...))))
generieren. Diesen Hash speichert man jetzt auf dem System welches die
Authentifizierung vornehmen soll, zusammen mit dem Zähler wie oft
gehasht wurde.
Wenn sich der Benutzer authentifizieren soll, präsentiert ihm das System
den Zähler-1, in unserem Beispiel also 99. Der Benutzer nimmt dann seine
Passphrase und hasht sie wieder, jetzt 99 mal. Diesen Hash übermittelt
er an das System. Das System nimmt sich diesen Hash, hasht ihn noch
einmal und vergleicht das Ergebnis mit dem gespeicherten Wert.
Wenn die Passphrase richtig war, müssten die 99 Hashvorgänge des Users +
dem einen Hashvorgang des Systems das gleiche Ergebnis haben wie die 100
Hashvorgänge die bei der Initialisierung verwendet wurden. Dann wird der
Zugang gewährt.
In diesem Fall speichert das System ausserdem den grade akzeptierten
Hash sowie den aktualisierten Zähler, um sie beim nächsten Vorgang zu
verwenden. In unserem Beispiel würde der Benutzer also eine 98
präsentiert bekommen, seine Passphrase 98 mal hashen, an das System
übermitteln, welches sie noch einmal hasht, usw. usf.
Wenn der Zähler runtergezählt ist, muss das System neu initialisiert
werden.
Das war jetzt die Zusammenfassung des wichtigen Teils. In Wirklichkeit
gibt es noch zwei Details: ein Seed, der auf jedem System anders sein
sollte und mit in den Hash eingerechnet wird; und der Hash wird gefaltet
um ihn kürzer zu machen.
Dann gibt es ausserdem eine Tabelle mit deren Hilfe der Hash in ein
Passwort der Art "BRAE FOR MOON MART FIEF LOSE" umgewandelt wird und nur
dieses Passwort wird vom Benutzer nachher eingetippt.
Es ist nicht unüblich ein paar Einmalpasswörter vorzugenerieren und als
Liste mit sich herumzutragen. Bei jedem Authorisationsvorgang muß man
dann einfach nur das nächste Passwort in der Liste eingeben.
Vorteile: Replay-Attacken werden wirkungslos da jedes Passwort nur
einmal gilt. Und: Auf dem Rechner der die Authentifizierung durchführt
müssen keine geheimen Daten gespeichert werden. Der Rechner kennt
jeweils nur den letzten Hash, bei dem man ohnehin davon ausgehen muß,
dass der Angreifer ihn kennt.
Solange die Einwegfunktion sicher ist (also nicht viel einfacher als mit
Brute Force umzukehren) ist auch das Verfahren sicher.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
Stefan Weinzierl
Hallo Roman,
>
>
> Was an diesem Konzept ist denn so revolutionär? Angenommen, dein System
> würde in der Praxis funktionieren und sei so sicher, wie du behauptest, wo
> läge denn z.B. der Unterschied zu Public-Key Authentisierungsverfahren (wie
> man sie z.B. bei SSH verwenden kann)? Bei SSH und anderen verwandten
> Systemen sehe ich jedenfalls noch den Vorteil, dass sich im Optimalfall
> beide Seiten gegenseitig über die Authentizität des Gegenübers versichern
> können. Das scheint dein System nicht zu können, damit wäre es unter
> Umständen sehr einfach attackierbar.
Zunächst einmal etwas Cut&Paste (siehe oben)
"> So, der Authentifizierungsagent soll also nicht wissen, wie du die
> Auth-"Daten" berechnest. Wie soll er entscheiden koennen, ob deine
> Daten korrekt sind?
Das ist eben der Trick an der Sache, und das unterscheidet meiner Meinung nach
dieses System auch von herkömmlichen Challenge-response Systemen. Die Daten
welche zur Identifizierung benutzt werden, sind nur Zahlen die bestimmten
Indices zugeordnet werden. Wie diese Daten generiert bzw. gespeichert werden
ist dem Authentifizierungsagenten eigentlich vollkommen gleichgültig.
Um es praktisch zu machen: Der Autorisationsdienst hat in seiner Datenbank (=
Autorisationstabelle) pro Datensatz bestimmte einstellige Zahlenwerte mit
bestimmten Indices verbunden. Nun übermittelt der einige von diesen Indices an
den Benutzer, bzw. an eine Datenbank im Besitz des Benutzers. Diese Datenbank
(=Generierungstabelle) hier beinhaltet im Groben pro Datensatz nur die gleichen
Indices, wie sie auch in der Autorisationstabelle vorhanden sind und
Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
Autorisationsdaten berechnen kann. Die nun entsprechenden Vorgabedaten werden
dem Benutzer vorgelegt. Die so berechneten Daten werden nun verschlüsselt an
den Autorisationsdienst übergeben. Der vergleicht sie mit seinen Werten u.s.w.
Gleichzeitig werden auch neue Index-Passzahl Kombinationen an den
Authentifikationsagenten übermittelt (In die Generierungstabelle muss natürlich
auch den neuen Gegebenheiten angepaßt werden, und entsprechende synchronisiert
werden)"
1. Als Indices sind Zeitstempel, wann die einzelnen Kombinationen angelegt
wurden, vorgesehen. Der Autorisationsdienst erhält also nur eine Antwort, wenn
er auch wirklich die Zeitstempel vorweisen kann, welche auch in der
Generierungstabelle verzeichnet sind.
2. Die ganze Kommunikation, (auch die Übermittlung des neu anzulegenden
Zeitstempels) zwischen den einzelnen Agenten wird noch zusätzlich über einen
Schlüssel verschlüsselt, der (irgendwie) aus den Zeitstempeln der LETZTEN DREI
erfolgreichen Logins gebildet wird. (Diese Verschlüsselung hat mit der oben
angesprochenen Verschlüsselung überhaupt nichts zu tun! Die Verschlüsselung
oben führt der user im Kopf durch. Die hier angesprochene natürlich die
beteiligten Rechner)
3.Um die Datenintegrität zwischen Autorisationstabelle und Generierungstabelle
auf Dauer aufrechtzuerhalten, müssen nicht nur die Indices, sprich
Datumstempel, übermittelt werden, welche zur Identifikation benötigt werden (Im
konkreten Fall sind das übrigens drei Autorisationsindices), es muss auch noch
angegeben werden, welcher Datensatz in den beiden Tabellen nun durch einen
neuen ersetzt werden soll (=Modifikationsindex). Wenn es nicht extra angegeben
wird, ist es für einen Außenstehenden nicht erkennbar, welche von den vier zu
übermittelnden Indices nun die drei Autorisationsindices sind, und welcher der
Modifikationindex. Deswegen kann man ja als shared secret vereinbaren, dass bei
jedem Login der Modifikationsindex an einer anderen Stelle steht. Also beim
ersten Login steht der Modifikationsindex an der ersten Stelle. Beim zweiten
Login an der zweiten Stelle u.s.w.. Dadurch werden übrigens die zu
übermittelnden Identifikationsdaten auch noch auf eine weitere zwar einfache,
aber höchst effiziente Art und Weise verschlüsselt.
Gruß
Stefan
Juergen P. Meier
> Wie sieht ein reply-Angriff aus? Dann kann ich dir sagen, wie ich ihn
> verhindere.
Ich hoehre deine Authentifizierung ab. Die aufgezeichneteten Pakete
hebe ich auf und warte darauf, das dein Server eine der bereits
aufgezeichneten Methoden auswaehlt. Daraufhin schicke ich das dazu
passend aufgezeichnete Paket.
>> So, der Authentifizierungsagent soll also nicht wissen, wie du die
>> Auth-"Daten" berechnest. Wie soll er entscheiden koennen, ob deine
>> Daten korrekt sind?
> Das ist eben der Trick an der Sache, und das unterscheidet meiner Meinung nach
> dieses System auch von herkömmlichen Challenge-response Systemen. Die Daten
> welche zur Identifizierung benutzt werden, sind nur Zahlen die bestimmten
> Indices zugeordnet werden. Wie diese Daten generiert bzw. gespeichert werden
> ist dem Authentifizierungsagenten eigentlich vollkommen gleichgültig.
Wie genau lautet dann das Kriterium anhand dessen das System die
korrekte Authentifizierung erkennen koennen soll?
> Um es praktisch zu machen: Der Autorisationsdienst hat in seiner Datenbank (=
> Autorisationstabelle) pro Datensatz bestimmte einstellige Zahlenwerte mit
Also Ziffern.
> bestimmten Indices verbunden. Nun übermittelt der einige von diesen Indices an
Was? Der Zahlenwert (Ziffer) oder ein Index?
> den Benutzer, bzw. an eine Datenbank im Besitz des Benutzers. Diese Datenbank
> (=Generierungstabelle) hier beinhaltet im Groben pro Datensatz nur die gleichen
> Indices, wie sie auch in der Autorisationstabelle vorhanden sind und
Aha. Also hat der Server doch die Authentisierungsdaten des Benutzers.
Das ist ein common secret. Ob das nun ein Passwort oder eine Tabelle
ist, ist prinzipiell irrelevant.
> Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
> Autorisationsdaten berechnen kann. Die nun entsprechenden Vorgabedaten werden
> dem Benutzer vorgelegt. Die so berechneten Daten werden nun verschlüsselt an
Wie verschluesselt?
> den Autorisationsdienst übergeben. Der vergleicht sie mit seinen Werten u.s.w.
Ah. Der Server muss also diese Daten gespeichert haben.
> Gleichzeitig werden auch neue Index-Passzahl Kombinationen an den
> Authentifikationsagenten übermittelt (In die Generierungstabelle muss natürlich
> auch den neuen Gegebenheiten angepaßt werden, und entsprechende synchronisiert
> werden)
>>
>> Wie genau unterscheidet es sich von S/Key?
>
> Als vorläufige Antwort würde ich einmal sagen, dass ich das Prinzip von PsyPaM
> verstanden habe, während ich mit dem Begriff von S/Key überhaupt nichts
> anfangen kann. Das ist schon einmal für mich ein entscheidender Unterschied
> zwischen den beiden Systemen.
S/Key ist ein klassisches Challange-Repsonse Verfahren mit
Einmalpassworten und endlichem Generierungsalgorithmus.
>> Und werde endlich mal konkret. So schwammig wie du das beschreibst,
>> kann das alles moegliche und unmoegliche sein.
> Ich bin gerade dabei konkret zu werden. Aber alles der Reihe nach. Solange ich
> dir das Grundprinzip des Systems nicht verständlich machen. weil mir z.B. noch
> zu viel von deiner Terminologie bzw. deinem Vorwissen fehlt,macht es noch
> überhaupt keinen Sinn, dir die konkrete Implementierung des Ganzen erklären. zu
> wollen.
> Es dauert also noch ein bisschen
Ich habe Geduld. Bis dann also.
Roman Racine
[Beschreibung]
Das ist zwar alles sehr kompliziert, aber soweit ich es gesehen habe, kannst
du eine Man in the Middle Attack nicht verhindern. Jemand (C) koennte den
Traffic zwischen dir (A) und der Gegenstelle (B), bei der du dich
authentisieren willst zu sich umleiten.
Konkret: A will sich bei B einloggen, der Traffic wird im Hintergrund aber
ueber C umgeleitet (nicht unrealistisch, kann z.B. von staatlicher Seite
angeordnet werden, s.
http://www.heise.de/newsticker/data/hob-12.12.02-000/). C sendet die
Anfrage an B weiter und erhaelt irgendeine Frage, die A beantworten muesste
(anhand der von dir geschilderten Tabellen) und legt die Frage A vor. Da A
nun offenbar nicht erkennen kann, dass der Traffic umgeleitet wird, wird er
die Frage richtig beantworten, die Antwort gelangt natuerlich wieder zu C.
C ist nun trivialerweise dazu in der Lage, B die richtige Antwort zu geben
und hat sich an Stelle von A eingeloggt.
Gruss
Roman
Bernd Eckenfels
> Um es praktisch zu machen: Der Autorisationsdienst hat in seiner Datenbank (=
> Autorisationstabelle) pro Datensatz bestimmte einstellige Zahlenwerte mit
> bestimmten Indices verbunden.
also:
i -> w
1 -> 2
2 -> 3
4 -> 1
3 -> 4
so was nennt man eine monoalphabetische substitution
> Nun übermittelt der einige von diesen Indices an
> den Benutzer, bzw. an eine Datenbank im Besitz des Benutzers.
Da wird es schon schwierig, muss der benutzer dazu ne software haben? Ich
gehe mal davon aus, nein, also agent sendet:
agent -> <1,2,3> -> nutzer
> Diese Datenbank
> (=Generierungstabelle) hier beinhaltet im Groben pro Datensatz nur die gleichen
> Indices, wie sie auch in der Autorisationstabelle vorhanden sind
also
i -> w
1 -> 2
2 -> 3
4 -> 1
3 -> 4
benutzer ermittelt mit <1,2,3> indize nun den wert: <2,3,1>
> Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
> Autorisationsdaten berechnen kann.
Was berechnet er?
> Die nun entsprechenden Vorgabedaten werden
> dem Benutzer vorgelegt.
was bekommt der butzer zu sehen?
> Die so berechneten Daten werden nun verschlüsselt an
wie berechnet wer was und wie wird es von wem verschluesselt?
> den Autorisationsdienst übergeben. Der vergleicht sie mit seinen Werten u.s.w.
usw heisst beweis durch handbewegung?
> Gleichzeitig werden auch neue Index-Passzahl Kombinationen an den
> Authentifikationsagenten übermittelt
von wem werden die uebermittelt? wie werden die berechnet?
(In die Generierungstabelle muss natürlich
> auch den neuen Gegebenheiten angepaßt werden, und entsprechende synchronisiert
> werden)
ach, du hast also eine sichere kommunikation vom agenten zum user - mit
dieser annahme kann man alles sicher machen. also butter bei die fisch: wie
werden die neuen index kombinationen an den benutzer uebermittelt?
> Als vorläufige Antwort würde ich einmal sagen, dass ich das Prinzip von PsyPaM
> verstanden habe, während ich mit dem Begriff von S/Key überhaupt nichts
> anfangen kann.
Mal so nebenbei gefragt, nur damit ich weiss dass es sich lohnt weiter
nachzudenken: welche vorbildung hast du und bist/warst du in letzter zeit in
behandliung?
PS: dein konkretes beispiel fehlt immer noch!
Nicolas Berr
> Würde ich genau so reden wie du, würde ich natürlich auch genau so denken wie
> du. Ich käme dann auch zu denselben Problemlösungen und Schlüssen wie du. So
> etwas würde aber keinen Erkenntnisgewinn bringen. Weil das, was ich da
> gedanklich entwickeln würde, ja du schon vorher entwickelt hast.
Wenn das so stimmen würde, wäre ein Wissenstranfer von vorneherein
unmöglich.
Zum Erfolgreichen Wissenstranfer gehört eine eindeutige
Sprachdefinition, die dem einzelnen wenig Freiheit für
Fehlinterpretationen läßt genau so dazu, wie das tatsächliche
Vorhandensein von Mehrwissen auf der einen Seite gegenüber der anderen
Seite...
Du schliesst aber mit Deiner Aussage immer mindestens eines von beidem
aus...
Gruß,
Nicolas
swenuht.nospam
> Stefan Weinzierl <stefan.w...@t-online.de> wrote:
>
>>Übertragen wir einmal das Beispiel der Ratte unter Laborbedingungen auf ein
>>Eichhörnchen
>
>
> Merkst Du gar nicht, was Du für ein Problem hast?
Wahrscheinlich nicht.
Könnte es sein, daß es sich um eine Reinkarnation von
Hans Joss in dcsm handelt?
(einschlägig bekannt in de.sci.mathematik)
Die Art und Weise der Diskussion kommt mir merkwürdig
bekannt vor ...
Thomas
Urs [Ayahuasca] Traenkner
> > Wie verhinderst du Reply-Angriffe?
> Wie sieht ein reply-Angriff aus? Dann kann ich dir sagen, wie ich ihn
> verhindere.
Zu meiner Zeit hat man sich erst die Grundlagen reingetan und
sich dann ueber konkrete Probleme Gedanken gemacht.
Bei Dir ist das umgedreht? Da kriegt man ganz spontan das volle
Vertrauen in Deine Ideen...
Gruss urs...
--
_______
(-) o---|_______|---o (+)
| |
+---------------+ Widerstand ist zwecklos!
Stefan Weinzierl
Das ist richtig! ebenso wie beim PIN und TAN Verfahren als auch bei
schriftlichen Bankanweisung über Fax (damit kannst du ja bekanntlich in der
Regel Millionnebeträge umleiten) kann ich derzeitig einen man-in-the middle
Angriff nicht verhindern.
Stefan Weinzierl
> Stefan Weinzierl wrote:
>
>> > Wie verhinderst du Reply-Angriffe?
>
>> Wie sieht ein reply-Angriff aus? Dann kann ich dir sagen, wie ich ihn
>> verhindere.
>
> Zu meiner Zeit hat man sich erst die Grundlagen reingetan und
> sich dann ueber konkrete Probleme Gedanken gemacht.
>
> Bei Dir ist das umgedreht? Da kriegt man ganz spontan das volle
> Vertrauen in Deine Ideen...
>
> Gruss urs...
Auf deine Kommentare hab jetzt schon gewartet.
Roman Racine
> Das ist richtig! ebenso wie beim PIN und TAN Verfahren als auch bei
> schriftlichen Bankanweisung über Fax (damit kannst du ja bekanntlich in
> der Regel Millionnebeträge umleiten) kann ich derzeitig einen man-in-the
> middle Angriff nicht verhindern.
Möglich, aber im Online-Banking ist dies anders (oder zumindest theoretisch
anders lösbar): Dort kann eine gegenseitige Authentisierung stattfinden.
Der Kunde authentisiert sich über PIN, Streichlistennummer etc. bei der
Bank, diese authentisiert sich z.B. über ein "SSL-Zertifikat" beim Kunden.
Damit beschränkt sich das Problem darauf, die Echtheit des Zertifikats zu
überprüfen bzw. der Firma, die solche Zertifikate signiert zu vertrauen.
Mit deinem System hat man dagegen keine Möglichkeit zu erkennen, ob man mit
der richtigen Gegenstelle verbunden ist, oder ob gerade eine Attacke
stattfindet. Damit ist dein System für wichtige Einsatzzwecke (Remote
Login, Online Banking, evtl. auch E-Mail) nicht brauchbar.
Gruss
Roman
Stefan Weinzierl
> Moin,
>
> Am Mon, 24 Nov 2003 19:30:47 +0100 schrieb Stefan Weinzierl:
>
>> > Wie verhinderst du Reply-Angriffe?
>> Wie sieht ein reply-Angriff aus? Dann kann ich dir sagen, wie ich ihn
>> verhindere.
>
> Gemeint war sicherlich "Replay-Angriff": Ein Angreifer beobachtet einen
> Auth-Vorgang und spielt die dabei beobachteten Daten einfach wieder ein
> um sich selbst Zugang zu verschaffen. Dabei spielt es dann keine Rolle
> wie kompliziert die Zugangsdaten zu berechnen sind.
Gegen "man-in-the middle" habe ich noch keinen Schutz. Aber wie schon
gesagt,PsyPaM dürfte nicht das einzige Authentifizierungsystem sein, das
hiergegen von sich selbst aus keinen Schutz bietet (Vergl. PIN/TAN Verfahren).
Ab er du weisst mich auf ein Problem hin, was ich nocheinmal überdenken muss.
(vgl. http//:psypam.de/4cando.html#e-payment )
>> > Wie genau unterscheidet es sich von S/Key?
>>
>> Als vorläufige Antwort würde ich einmal sagen, dass ich das Prinzip
>> von PsyPaM verstanden habe, während ich mit dem Begriff von S/Key
>> überhaupt nichts anfangen kann.
>
> S/Key ist relativ einfach: Man braucht zunächst mal eine sichere
> Einweg-Hashfunktion, zum Beispiel MD5. Der Benutzer wählt für sich eine
> Passphrase, die natürlich den üblichen Regeln für Passphrasen
> entsprechen sollte (lang, nicht aus der Literatur, nicht zu erraten,
> usw.).
Ich muss es erst noch in meinem Skript schreiben. Aber Eine Passphrase die den
üblichen Regeln für Passphrasen entspricht, ist mit großer Wahrscheinlichkeit
unmöglich für Menschen zu merken bzw. reibungslos zu handhaben. Ich habe jetzt
2 1/2 Jahre versucht, ein System zu entwickeln, mit dem sich unter Anderem
Passphrasen einfach, effizient und sicher verwalten lassen (PsyPaM =
psychologisches Passwortmanagment) Zwar ist es mir gelungen, die Verwaltung und
Handhabung von Passwörtern entscheidend zu verbessern und zu vereinfachen, aber
trotztdem sind die Ergebnisse noch in keinster Weise befriedigend.
Biometrisches PsyPaM kommt eben ohne die Notwendigkeit aus, Passphrasen
handhaben zu müssen.
Wenn ich die Liste bekomme, komme ich rein,
> Vorteile: Replay-Attacken werden wirkungslos da jedes Passwort nur
> einmal gilt. Und: Auf dem Rechner der die Authentifizierung durchführt
> müssen keine geheimen Daten gespeichert werden. Der Rechner kennt
> jeweils nur den letzten Hash, bei dem man ohnehin davon ausgehen muß,
> dass der Angreifer ihn kennt.
> Solange die Einwegfunktion sicher ist (also nicht viel einfacher als mit
> Brute Force umzukehren) ist auch das Verfahren sicher.
Aber "man in the middle" bezüglich des Passwortes geht hier doch genauso
Außerdem was ist mit den ominösen Keyloggern
biometrisches PsyPaM ist absolut sicher gegenüber Keyloggern. Ich will es jezt
hier nicht genau erklären. Sonst wird das alles Aber ich kann es beweisen.
Übrigens, ehrlich danke für deine genaue Erklärung.
Andreas Beck
> Henryk Plötz wrote:
>> Es ist nicht unüblich ein paar Einmalpasswörter vorzugenerieren und als
>> Liste mit sich herumzutragen. Bei jedem Authorisationsvorgang muß man
>> dann einfach nur das nächste Passwort in der Liste eingeben.
> Wenn ich die Liste bekomme, komme ich rein,
Nur wenn der berechtigte Benutzer das nicht merkt. Es genügt, mit einer
niedrigeren Sequenznummer einzuloggen, um die verlorenen Passwörter zu
invalidieren.
> Aber "man in the middle" bezüglich des Passwortes geht hier doch genauso
> Außerdem was ist mit den ominösen Keyloggern
Keylogger sind per Definition witzlos gegen Einmalpasswörter und/oder
brauchbare Challenge-Response Systeme.
Umgebungen, in denen Keylogger ein Problem sind, haben noch ganz andere
Probleme (Session offenhalten, Session komplett simulieren, derweil was
anderes machen, etc. pp.).
CU, ANdy
Stefan Weinzierl
> begin 1 followup to Stefan Weinzierl <stefan.w...@t-online.de>:
>>
>>> Wie verhinderst du Reply-Angriffe?
"man-in-the-middle" klappt
>>>> So, der Authentifizierungsagent soll also nicht wissen, wie du die
>>> Auth-"Daten" berechnest. Wie soll er entscheiden koennen, ob deine
>>> Daten korrekt sind?
Habe ich schon beantwortet. Siehe unten
>
>> Um es praktisch zu machen: Der Autorisationsdienst hat in seiner Datenbank (=
>> Autorisationstabelle) pro Datensatz bestimmte einstellige Zahlenwerte mit
>
> Also Ziffern.
Danke,so kann man die Dinger auch nennen. Mir ist das Synonym hierfür einfach
nicht eingefallen.
>> bestimmten Indices verbunden. Nun übermittelt der einige von diesen Indices
>> an
>
> Was? Der Zahlenwert (Ziffer) oder ein Index?
Die Ziffern, welche über die Indices angefordert werden, sind das eigentliche
common secret. Sie sind also das KRITERIUM nach denen der Auth.Agent
entscheidet, ob sich der Benutzer einwandfrei indentifiziert hat oder nicht. Um
nicht das ganze System ad absurdum zu führen, solltest du die tunlichst NICHT
übermitteln
>> den Benutzer, bzw. an eine Datenbank im Besitz des Benutzers. Diese Datenbank
>> (=Generierungstabelle) hier beinhaltet im Groben pro Datensatz nur die
>> gleichen
>> Indices, wie sie auch in der Autorisationstabelle vorhanden sind und
>
> Aha. Also hat der Server doch die Authentisierungsdaten des Benutzers.
> Das ist ein common secret. Ob das nun ein Passwort oder eine Tabelle
> ist, ist prinzipiell irrelevant.
Ja, nur beim biometrischen PsyPaM braucht der Benutzer sich diese Daten nicht zu
merken, sie werden trotzdem außer beim Auth.Agent (Der braucht sie ja
schließlich) nirgendwo gespeichert. Und trotzdem kann er sich über diese
Ziffern beim Auth.Agent authentifizieren
>> Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
>> Autorisationsdaten berechnen kann. Die nun entsprechenden Vorgabedaten werden
>> dem Benutzer vorgelegt. Die so berechneten Daten werden nun verschlüsselt an
>
> Wie verschluesselt?
Das wird ein bisschen länger, Damit es hier nicht so lange wird, habe ich diesen
Teil in meine Antwort an Bernd Eckenfeld hineingearbeitet. (Hoffentlich schaff
ich die heute noch.Wenn nicht dann morgen)
>> den Autorisationsdienst übergeben. Der vergleicht sie mit seinen Werten
>> u.s.w.
>
> Ah. Der Server muss also diese Daten gespeichert haben.
>
>> Gleichzeitig werden auch neue Index-Passzahl Kombinationen an den
>> Authentifikationsagenten übermittelt (In die Generierungstabelle muss
>> natürlich auch den neuen Gegebenheiten angepaßt werden, und entsprechende
>> synchronisiert werden)
>>>
>>> Wie genau unterscheidet es sich von S/Key?
>>
>> Als vorläufige Antwort würde ich einmal sagen, dass ich das Prinzip von
>> PsyPaM verstanden habe, während ich mit dem Begriff von S/Key überhaupt
>> nichts anfangen kann. Das ist schon einmal für mich ein entscheidender
>> Unterschied zwischen den beiden Systemen.
>
> S/Key ist ein klassisches Challange-Repsonse Verfahren mit
> Einmalpassworten und endlichem Generierungsalgorithmus.
Beim biometrischen PsyPaM habe ich nicht das Problem diese Sch.. Passwörter
handhaben und verwalten zu müssen. Da kann S/key hundertmal sicherer als
biometrisches PsyPaM sein. Solange es das nicht schafft, kommt es an
biometrisches PsyPaM nicht ran.
>
> Ich habe Geduld. Bis dann also.
>
> Juergen
--
Stefan Weinzierl
> Stefan Weinzierl <stefan.w...@t-online.de> wrote:
>> Um es praktisch zu machen: Der Autorisationsdienst hat in seiner Datenbank (=
>> Autorisationstabelle) pro Datensatz bestimmte einstellige Zahlenwerte mit
>> bestimmten Indices verbunden.
>
> also:
>
> i -> w
> 1 -> 2
> 2 -> 3
> 4 -> 1
> 3 -> 4
>
> so was nennt man eine monoalphabetische substitution
Nein, die kommt erst später (Gut zu wissen, wie das heißt. Danke) Das, was ich
hier meine, nennt man eine stinknormale Referenzintegrität.
>> Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
>> Autorisationsdaten berechnen kann.
>
> Was berechnet er?
>
>> Die nun entsprechenden Vorgabedaten werden
>> dem Benutzer vorgelegt.
>
> was bekommt der butzer zu sehen?
Das alles später sonst wird es zu unübersichtlich und zu kompliziert. Aber
soviel kann ich hier schon verraten. Da ist eine monoalphabetische bzw. in
diesem Fall sogar nur eine mononumerische Substitution von zentraler Bedeutunhg
>> Die so berechneten Daten werden nun verschlüsselt an
>
> wie berechnet wer was und wie wird es von wem verschluesselt?
>
>
> Mal so nebenbei gefragt, nur damit ich weiss dass es sich lohnt weiter
> nachzudenken: welche vorbildung hast du und bist/warst du in letzter zeit in
> behandliung?
Für jemanden der gerade unfähig war den Sachverhalt einer einfachen Relation
zwischen zwei Datenbanktabellen kognitiv zu erfassen, ist das aber starker
Toback
Gruss Stefan
Stefan Weinzierl
> Wie verschluesselt (2)
Ich habe es nicht mehr geschaffft. Außerdem war das Post von Bernd Eckenfels
doch nicht so gut für eine genaue Erklärung der Verschlüsselung wie ich dachte.
Ich hänge es dir morgen an dieses Post oder ,wenn du inzwischen etwas
geschrieben hast, an jenes
Bis morgen
Dennis Herbrich
> Bernd Eckenfels wrote:
>
>> Stefan Weinzierl <stefan.w...@t-online.de> wrote:
>> i -> w
>> 1 -> 2
>> 2 -> 3
>> 4 -> 1
>> 3 -> 4
>>
>> so was nennt man eine monoalphabetische substitution
>
> Nein, die kommt erst später (Gut zu wissen, wie das heißt. Danke) Das, was ich
> hier meine, nennt man eine stinknormale Referenzintegrität.
Warum sagst du es dann nicht, sondern schwafelst was von "verbunden"?
>>> Vorgabedaten, mit deren Hilfe der/ die Benuter/in die entsprechenden
>>> Autorisationsdaten berechnen kann.
>>
>> Was berechnet er?
>>
>>> Die nun entsprechenden Vorgabedaten werden
>>> dem Benutzer vorgelegt.
>>
>> was bekommt der butzer zu sehen?
>
> Das alles später sonst wird es zu unübersichtlich und zu kompliziert. Aber
> soviel kann ich hier schon verraten. Da ist eine monoalphabetische bzw. in
> diesem Fall sogar nur eine mononumerische Substitution von zentraler Bedeutunhg
Du bist witzig. Offenbar fehlen dir die einfachsten mathematischen
Grundkenntnisse um ueberhaupt wissen zu koennen wovon du sprichst (das
allein disqualifiziert natuerlich nicht; Fehlende Bildung macht ja
geniale Ideen nicht unmoeglich, eher im Gegenteil), andererseits haelst
Du hier Leute hin mit Schwurbeleien wie "alles zu kompliziert", die
sicherlich in der Lage sind anhand eines konkreten, beispielhaften
"Protokollmitschnitts" den Kern des System zu erfassen und ggf. zu
relativieren, oder zumindest gezieltere Fragen zu stellen. Einen solchen
lieferst du aber nicht, sondern versteckst scheinbar nur ein
mangelhaftes Konzept hinter einer Fassade von Geschwaetz. Es wuerde mich
sehr freuen, wenn ich mich diesbezueglich irrte.
>> Mal so nebenbei gefragt, nur damit ich weiss dass es sich lohnt weiter
>> nachzudenken: welche vorbildung hast du und bist/warst du in letzter zeit in
>> behandliung?
> Für jemanden der gerade unfähig war den Sachverhalt einer einfachen Relation
> zwischen zwei Datenbanktabellen kognitiv zu erfassen, ist das aber starker
> Toback
Ruhig, Brauner. Wer mit unklarer Ausdruckweise Missverstaendnisse
provoziert und dann nachher mit dem Finger zeigt hat verloren. Aber in
wirklich jeder Hinsicht. Und _du_ kannst hier wirklich kein Quentchen
Glaubwuerdigkeit auf's Spiel setzen, die ist eh reichlich knapp.
> Gruss Stefan
Gruss,
Dennis
--
We're Germans and we use Unix. That's a combination of two demographic
groups known to have no sense of humour whatsoever.
-- Hanno Mueller in de.comp.os.unix.programming GPG 0x2B3C646D
Bernd Eckenfels
> Ich muss es erst noch in meinem Skript schreiben. Aber Eine Passphrase die den
> üblichen Regeln für Passphrasen entspricht, ist mit großer Wahrscheinlichkeit
> unmöglich für Menschen zu merken bzw. reibungslos zu handhaben.
"Ich (Bernd) kann mir Passphrases sehr gut merken. Insbesondere weil Stefan das
nicht glaubt !!!"
entspricht mindestens einem 10stelligen passwort.
Bernd Eckenfels
> Keylogger sind per Definition witzlos gegen Einmalpasswörter und/oder
> brauchbare Challenge-Response Systeme.
Wenn man Keylogger unsauber verwendet und damit Session Hijacking meint ...
:)
Gruss
Bernd
Bernd Eckenfels
>> Das alles später sonst wird es zu unübersichtlich und zu kompliziert. Aber
>> soviel kann ich hier schon verraten. Da ist eine monoalphabetische bzw. in
>> diesem Fall sogar nur eine mononumerische Substitution von zentraler Bedeutunhg
>
> Du bist witzig. Offenbar fehlen dir die einfachsten mathematischen
> Grundkenntnisse um ueberhaupt wissen zu koennen wovon du sprichst
Genau, deswegen noch mal die Bitte:
- sag uns was der benutzer sieht
- sag uns was der benutzer (beispielhaft) sich gemerkt hat
- sag uns welche hardware er benoetigt
- sag uns was er im kopf errechnet (einfaches beispiel genuegt)
- sag uns was er eingibt
- sag uns was die gegenstelle berechnet zum pruefen, was sie (beispiehaft) i
nder tabelle stehen hat
Stefan, das ist ganz einfach, wenn du auf diese Bitte nicht eingehen kannst,
dann kann dir ganz sicher kein ITler helfen. (das verfaren umzusetzen).
Aber hier noch mal ne hilfe:
Benoetigt der Benutzer Hardware ausser Rechner/keyboard/monitor//netzzugang
(also ich denke an kamera, scanner, messgeraet)
Benötigt der Benutzer software um die berechnung auszufuehren?
Was musst du von mir wissen, um mir meine persoenliche tabelle zu erstellen,
oder wie wuerde ich das tun?
Wie gross ist meine persoenliche tabelle (anzahl der eintraege, anzahl der
spalten, laenge der eintraege pro spalte) und wie merke ich mir die?
Robert Engelhardt
>> Gruss urs...
> Auf deine Kommentare hab jetzt schon gewartet.
Warum? Weil dir ein qualifizierter Kommentar von einem qualifizierten
Leser unwichtig ist? man Kritikfähigkeit...
Viele Grüße,
Robert Engelhardt
Stefan Weinzierl
Was soll an Allgemeinplätzen ohne argumentativen Untergrund qualifiziert sein?
Stefan Weinzierl
Identifikationsdaten durch Berechnungen, welche der USER ausführt. AUSDRÜCKLICH
wir hier nicht erklärt, was dem user an Vorgabedaten dargeboten wird und wie er
die am Günstigsten zu verarbeiten hat. Hier kann ich nur im Groben den
allgemeinen Algorithmus vorstellen, welcher der user zur Verschlüsselung
durchzuführen hat, und welchen der Server. Er ist nämlich viel zu einfach, als
dass er schnell verstanden werden könnte. Der Rest kommt zu einem späteren
Zeitpunkt. Wem dieses Vorgehen zu langsam ist, den muss ich leider auf meine
Website ( http://psypam.de ) verweisen. Dort kann er all das, was ich jetzt
hier vortrage bzw. noch vortragen werde noch einmal ungefähr in der gleichen
Ausführlichkeit und Länge nachlesen.
Was wissen wir bis jetzt?
Beim Auth.Agenten wird für jeden Benutzer eine Datenbanktabelle geführt, in der
pro Datensatz ein Index zur Anforderung der Identifikationsdaten und eine
Ziffer als eigentliches Vergleichskriterium gespeichert ist. Eigentlich werden
pro Index ZWEI Ziffern in jeweils zwei unterschiedlichen Datenfeldern
gespeichert. Aber, warum das so ist, ist noch lange nicht relevant und würde
und hier nur verwirren. Für unsere Zwecke reicht es vollkommen aus, einmal von
einer Ziffer auszugehen.
Im Rahmen eines Logins werden werden nun drei Indices per Zufallsauswahl
ausgewählt und an den Benutzer übermittelt (Autorisationsindices). Außerdem
muss noch ein Index übermittelt werden, der angibt, welcher Datensatz in der
Autorisations- bzw. der Challengetabelle (Die hat früher Generierungstabelle
geheißen, und versehentlich habe ich bis jetzt hier diesen Begriff
verwendet,Entschuldigung) durch den neuen Datensatz, welcher im Rahmen dieser
Sitzung gebildet werden soll, ersetzt werden soll. Dieser Index ist mit
Modifikationsindex bezeichnet.
Jetzt wird?s spannend!
Der Benutzer oder die Benutzerin muss dem Auth. Agenten also die richtigen
drei(eigentlich sechs, aber dazu wie schon gesagt später.) Ziffern (z[1ident],
z[2ident], z[3ident]] in der richtigen Reihenfolge wieder zurück übermitteln.
Außerdem muss er ihm noch eine Ziffer z[mod]übermitteln, die als neue
Identifikationsziffer, dem Pool der bereits vorhandenen, hinzugefügt werden
soll.
Die Verschlüsselung besteht nun einfach darin, dass die Ziffern (jetzt werden
sie übrigens zu Zahlen, weil jetzt die Mathematik beginnt) nicht alle einzeln
übermittelt werden. Vielmehr wird z[mod] zu jeder der anderen drei Zahlen
addiert, wobei eventuell entstehende Zehnerstellen einfach weggelassen werden
(mod(10)). Die Identifikationsdaten werden also in der Form
z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
Das war?s jetzt für diese Mal
Fortsetzung folgt
Gruss
Stefan
Stefan Weinzierl
Jetzt wird?s spannend!
Fortsetzung folgt
Gruss
Stefan Weinzierl
Jetzt wird?s spannend!
Das war?s jetzt für dieses Mal
Fortsetzung folgt
Lutz Donnerhacke
> Der Benutzer oder die Benutzerin muss dem Auth. Agenten also die richtigen
> drei(eigentlich sechs, aber dazu wie schon gesagt später.) Ziffern (z[1ident],
> z[2ident], z[3ident]] in der richtigen Reihenfolge wieder zurück übermitteln.
> Außerdem muss er ihm noch eine Ziffer z[mod]übermitteln, die als neue
> Identifikationsziffer, dem Pool der bereits vorhandenen, hinzugefügt werden
> soll.
> Die Verschlüsselung besteht nun einfach darin, dass die Ziffern (jetzt werden
> sie übrigens zu Zahlen, weil jetzt die Mathematik beginnt) nicht alle einzeln
> übermittelt werden. Vielmehr wird z[mod] zu jeder der anderen drei Zahlen
> addiert, wobei eventuell entstehende Zehnerstellen einfach weggelassen werden
> (mod(10)). Die Identifikationsdaten werden also in der Form
> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
Das ist ein Witz, oder?
Andreas Beck
> * Stefan Weinzierl wrote:
>> (mod(10)). Die Identifikationsdaten werden also in der Form
>> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
> Das ist ein Witz, oder?
Wenn es einer ist, dann ein sehr schlechter.
Ich konnte jedenfalls nicht lachen. Zugegebenermaßen ist das auch
schwierig, wenn man gerade die Zähne millimetertief in der Tischkante
eingräbt.
CU, ANdy
Ansgar -59cobalt- Wiechers
Nein. Der Witz ist das hier:
| Er ist nämlich viel zu einfach, als dass er schnell verstanden werden
| könnte.
cu
59cobalt
--
"Wir nehmen ständig an Glaubwürdigkeit zu."
--Darl McBride (SCO)
Carsten Krueger
>> Die Verschlüsselung besteht nun einfach darin, dass die Ziffern (jetzt werden
>> sie übrigens zu Zahlen, weil jetzt die Mathematik beginnt) nicht alle einzeln
>> übermittelt werden. Vielmehr wird z[mod] zu jeder der anderen drei Zahlen
>> addiert, wobei eventuell entstehende Zehnerstellen einfach weggelassen werden
>> (mod(10)). Die Identifikationsdaten werden also in der Form
>> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
>
>Das ist ein Witz, oder?
Du solltest nicht so viel lachen, klär den armen Jungen doch mal auf
:-)
Gruß Carsten
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam
Frank Meyer
> Er ist nämlich viel zu einfach, als dass er schnell verstanden
> werden könnte.
Aha.
> Die Verschlüsselung besteht nun einfach darin, dass die Ziffern (jetzt werden
> sie übrigens zu Zahlen, weil jetzt die Mathematik beginnt) nicht alle einzeln
> übermittelt werden. Vielmehr wird z[mod] zu jeder der anderen drei Zahlen
> addiert, wobei eventuell entstehende Zehnerstellen einfach weggelassen werden
> (mod(10)). Die Identifikationsdaten werden also in der Form
> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
mod(10) ist gut. Somit kann man sich alles weitere an seinen 10 Fingern
abzählen ;-)
> Fortsetzung folgt
Hoffentlich nicht.
Frank
Marco Stolpe
> Marco Stolpe wrote:
> [...]
>>Oder hälst Du es für möglich, dass die Unfähigkeit, sich komplexe
>>Passwörter einzuprägen, einfach etwas mit einer schlechten Methodik zu tun
>>haben könnte?
>
> Oder mit Faulheit/Bequemlichkeit ;-)
>
> Aber das hat nur peripher etwas mit security zu tun, oder?
Warum nur peripher? Beim Thema Sicherheit geht es - wenn ich da nicht
ganz falsch liege - nicht bloß um die technische Realisation, sondern
in erster Linie um Richtlinien. In den meisten Firmen dürfte es da
eine Richtlinie für Benutzer geben, möglichst zufällige Passwörter zu
wählen (sagen wir mit 8 Stellen - eigentlich zu wenig - und
Sonderzeichen). Falls die technische Realisation okay ist, hängt nun
die gesamte Sicherheit des Systems an diesen Passwörtern.
So eine Richtlinie bringt aber nichts, wenn sich niemand dran hält.
Und das dürfte in der Realität nur eine geringe Anzahl von Leuten tun.
Die Frage: warum ist das so?
Meiner Ansicht nach, weil unsere Schulbildung (aus welchen Gründen
auch immer) nicht darauf abgestellt ist, den Leuten ordentlich
beizubringen, wie man effizient *lernt* (oder sich etwas einprägt).
Faulheit/Bequemlichkeit ist ja nichts schlechtes. Im Falle der
Automatisierung von Prozesses geht es schließlich auch darum, sich
Arbeit zu sparen/diese zu rationalisieren.
Wenn man dem Benutzer also eine Methodik an die Hand geben könnte, mit
der er sich Passwörter leichter merken könnte, so würde die Richtlinie
vielleicht in einer höheren Anzahl von Fällen befolgt werden. Weil
es für ihn einfacher ist.
Wenn Systeme dadurch sicherer werden könnten, warum gehört eine
Diskussion darüber für Dich dann nur peripher zum Thema "Sicherheit"?
(Oder habe ich Dich irgendwie falsch verstanden? :-)
Schöne Grüße,
Marco
Bernd Eckenfels
> Beim Auth.Agenten wird für jeden Benutzer eine Datenbanktabelle geführt, in der
> pro Datensatz ein Index zur Anforderung der Identifikationsdaten und eine
> Ziffer als eigentliches Vergleichskriterium gespeichert ist.
OK, wieviele Eintraege pro user?
> Der Benutzer oder die Benutzerin muss dem Auth. Agenten also die richtigen
> drei(eigentlich sechs, aber dazu wie schon gesagt später.) Ziffern (z[1ident],
> z[2ident], z[3ident]] in der richtigen Reihenfolge wieder zurück übermitteln.
Gefaherlich, damit kann ein angreifer eine der 999 kombinationen raten. Bei
3 Fehlversuchen pro account und bei 100 accounts hat man da schnell eine
richtige kombination.
> Außerdem muss er ihm noch eine Ziffer z[mod]übermitteln, die als neue
> Identifikationsziffer, dem Pool der bereits vorhandenen, hinzugefügt werden
> soll.
Ja das is schoen, aber die kann man doch abhoeren? ich merk mir einfach dass
an der index position die ziffer x steht, und irgendwann kenn ich dann alle.
> übermittelt werden. Vielmehr wird z[mod] zu jeder der anderen drei Zahlen
> addiert, wobei eventuell entstehende Zehnerstellen einfach weggelassen werden
> (mod(10)). Die Identifikationsdaten werden also in der Form
> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
da man aber z[mod] kennt kann man das locker rueckgaengig machen. Ausserdem
ist es vollkommen unnoetig die zu verschluesseln, vor was soll das
schuetzen?
Bisher hast du ein Verfahren beschrieben bei dem der user eine tabelle haben
muss statt einem passwort. Wie soll er sich die merken? Da sind ja
einmalpasswoerter (TAN listen) einfacher zu handhaben und sicherer.
Stefan Weinzierl
Alles der Reihe nach kommt noch. Aus gegebenem heute schreib ich heut einmal
was zu dem Thread von Lutz Donnerhacke.
Bis dann
Stefan Weinzierl
> * Stefan Weinzierl wrote:
>> (mod(10)). Die Identifikationsdaten werden also in der Form
>> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
>
> Das ist ein Witz, oder?
Wenn ich dein Post richtig interpretiere, meinst du wahrscheinlich, dass diese
Formel hier mit Sicherheit viel zu einfach gestrickt ist,um die
Identifikations- bzw. Modifikationsziffern sicher zu verschlüsseln.
Ich kann aber das Gegenteil beweisen. Zwar nur nach dem Motto, "Stammeln auch
wir, die die Erde gebar." Aber dennoch gültig. Und wenn ich in meiner
Argumentation logische Fehler gemacht haben sollte, können du oder auch Andere
mich ja darauf hinweisen.
A: Voraussetzungen
1. Es werden hier nur Ziffern verwendet. Damit läßt sich bei einer
Entschlüsselung die Richtigkeit der gemachten Transformationen nicht alleine
schon an Hand inhaltlicher Kriterien festmachen. Wenn ich "Mary hat ein kleines
Lamm." verschlüssele, und beim Entschlüsseln so etwas wie "rwti48% qwid!nS
Duio0" rauskriege, weiß ich, dass ich falsch liege, auch wenn ich den
Ursprungstext nicht kenne.
Wenn ich hingegen beim Entschlüseln von "1234" "5678" erhalte, so kann ich
dieses Ergebnis nur alleine durch Testung am Zugang selbst verififzieren.
Alleine über den Inhalt geht das natürlich nicht. Da beim biometrischen PsyPaM
man hierzu im Grunde genommen immer nur eine Möglichkeit hat -darauf wechseln
ja die angeforderten Identifikationsdaten wieder- habe ich immer nur eine
Möglichkeit Damit scheidet brute-force als Angriffsmethode aus. Auch brauchen
die verwendeten Schlüssel nicht so groß zu sein.
2.Da es nur zehn Ziffern gibt (Nein, den Schnulli mit Hexadecimal machen wir
hier nicht, ;-) ), ist auch der Ergebnisraum pro Stelle der Passzahl auf nur
zehn Möglichkeiten beschränkt.
3. Nun zu dem ominösen Mod(10). Wenn ich beim Ergebniss einer Addition zweier
einstelliger Zahlen die eventuell entstehende Zehnerstelle unbeachtet lasse, so
kann dieses Ergebniss theoretisch immer durch eine von allen zehn verfügbaren
Ziffern mit generiert worden sein. Ich kann also den Kreis der verwendeten
Zahlen nicht bei bestimmten Ergebnissen einengen. Es können immer alle zehn
Zahlen sein. Wenn ich die Zehnerstelle beachte, ist das anders. Dann kann z.B.
das Ergebnis "0" nur auf eine einzige Art und Weise entstehen, denn nur 0+0=0.
(Nicht 00. Das ist was anderes.)
Beweis: Ich hab?s ausprobiert, und jeder kann es auch ausprobieren. Dies ist
zwar nicht gerade die eleganteste Form der Beweisführung. Aber für "den
Hausgebrauch" reicht?s.
4.Um Gleichungen mit zwei Unbekannten (und mehr brauchen wir hier nicht)
aufzulösen, sind unbedingt auch zwei unterschiedliche Gleichungen, die jeweils
diese Unbekannten, und zwar nur diese Unbekannten, enthalten, notwendig.
Beweis: Man merkt schon, ich habe meine Diplomarbeit nicht gerade über
Matrizenrechnungen geschrieben, deswegen muss hier als Beweis genügen, dass das
mein Mathematiklehrer in der Schule gesagt hat. Und der muss es ja wissen!
B: Beweis
Es soll ja die zur Identifikation anzugebende einstellige Zahl (z[ident])mit der
im Rahmen dieser Sitzung neuzubildenden Zahl (z[mod]) addiert werden, wobei
eventuell entstehende Zehnerstellen unbeachtet bleiben:
z[ident]+z[mod]=Mod,10(z[result]) ;(Oder so ähnlich)
um das auflösen zu können, wenn mir nur z[result] zur Verfügung steht, brauche
ich eine zweite Gleichung, die wieder nur z[ident] und z[mod] enthält, sonst
kann z[ident] bzw. z[mod] alle zehn Ziffern des Ergebnissraums annehmen.
Nur diese zweite Gleichung bekomme ich nicht, denn das z[mod] dieser Sitzung,
wird ja per definitionem zu einem anderen z[ident] in weiteren, folgenden
Sitzungen, und Rechenoperationen zwischen zwei z[ident] UNTEREINANDER sind
nicht vorgesehen.
z[mod] ist also so eine Art ONE TIME PAD.
Also "q.e.d" oder in diesem Fall "Ich sag? ja: Das Ding hier ist viel zu
einfach, als dass es leicht verstanden werden könnte."
Da besagte Rechenoperationen hier ja im Kopf des Benutzers ausgeführt werden
sollen, ist die GESAMTE zur Übermittlung der Identifikationsdaten benutzte
Kommunikationstrecke immer als ABHÖRSICHER anzusehen. Dies gilt ausdrücklich
auch für eine Protokollierung der Tastatureingaben beim Benutzer.
in der Hoffnung auf konstruktive Beiträge
Gruß
Markus Schaaf
> Lutz Donnerhacke wrote:
>
> > * Stefan Weinzierl wrote:
>
> >> (mod(10)). Die Identifikationsdaten werden also in der Form
> >> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
> >
> > Das ist ein Witz, oder?
>
> Wenn ich dein Post richtig interpretiere, meinst du wahrscheinlich, dass diese
> Formel hier mit Sicherheit viel zu einfach gestrickt ist,um die
> Identifikations- bzw. Modifikationsziffern sicher zu verschlüsseln.
> Ich kann aber das Gegenteil beweisen.
Kannst Du nicht. Wenn ich Deine Ausführungen hier richtig verstehe,
gibt es ein geteiltes Geheimnis zwischen beiden Pateien, welches eine
10-stellige Dezimalzahl ist. Durch passive Beobachtung eine "Logins"
wird ein System aus 3 unabhängigen Gleichungen über mindestens 3, aber
maximal 4 Ziffern der 10 offenbar. Also kennt man nach ungefähr 4
beobachteten Vorgängen das gesamte Geheimnis.
Weitere Hinweise für Dich:
Von der groben Idee her, hast Du ein sog. Challenge-Response-Verfahren
entwickelt. Solche Verfahren sind lange bekannt und gut verstanden.
Beschäftige Dich mit den bekannten, um aus den Fehlern und Design-
Entscheidungen zu lernen.
Versuche, Deine Ideen einem Freund o.ä. zu erklären, bevor Du an die
Öffentlichkeit gehst. Wenn er (oder sie) es nicht versteht, liegt der
Fehler bei Dir, d.h. Du hast es selbst nicht richtig verstanden.
Benutze einfache mathematische Formelsprache oder grafische
Darstellungen, statt kilometerlanger Texte. Achte darauf, daß jeder
Begriff genau definiert wird.
Studiere das, was andere vor Dir gemacht haben. Aus deren Fehlern
kannst Du lernen. Außerdem gewöhnst Du Dich an Fachterminologie.
Eike Sauer
> Ich kann aber das Gegenteil beweisen. Zwar nur nach dem Motto, "Stammeln
> auch wir, die die Erde gebar." Aber dennoch gültig. Und wenn ich in meiner
> Argumentation logische Fehler gemacht haben sollte, können du oder auch
> Andere mich ja darauf hinweisen.
Habe ich das richtig verstanden, man überträgt zu seiner Identifikation
drei Ziffern?
Das heisst, ich habe bei einem wilkürlichen Versuch eine Chance
von 1:1000, autorisiert zu werden, ohne auch nur das Geringste
über "Autorisationsindices", den zu autorisierenden Benutzer oder
deine Methode zu wissen?
Ciao,
Eike
Roman Racine
> Wenn ich dein Post richtig interpretiere, meinst du wahrscheinlich, dass
> diese Formel hier mit Sicherheit viel zu einfach gestrickt ist,um die
> Identifikations- bzw. Modifikationsziffern sicher zu verschlüsseln.
Du verschlüsselst nicht wirklich Daten, sondern verschickst im Gegenteil
Teile des Schlüssels im Klartext. Jemand, der deine Kommunikation abhört,
kann ein Gleichungssystem aufstellen, das durch jede weitere
Authentisierung vervollständigt wird. Nach genügend langer Zeit kann man
analytisch lösen. Man könnte auch einfach so lange dreistellige Zahlen
raten, bis man zufälligerweise die richtige Lösung getroffen hat. Eine
dreistellige Zahl ist durch Brute Force einfacher zu knacken als ein
zweistelliges Passwort und das könnte sich nun wirklich jeder merken.
> alleine schon an Hand inhaltlicher Kriterien festmachen. Wenn ich "Mary
> hat ein kleines Lamm." verschlüssele, und beim Entschlüsseln so etwas wie
> "rwti48% qwid!nS Duio0" rauskriege, weiß ich, dass ich falsch liege, auch
> wenn ich den Ursprungstext nicht kenne.
Das muss nicht sein, z.B. wenn du vor dem Verschlüsseln Redundanz entfernst
(durch Datenkompression). Dein Verfahren ist sogar noch viel einfacher auf
sinnvollen Inhalt zu prüfen als dein obiges Beispiel, nämlich indem man
alle abgehörten Übertragungen in einem Gleichungssystem sammelt und
mögliche Werte darauf überprüft, ob sie mit dem Gleichungssystem vereinbar
sind.
> Alleine über den Inhalt geht das natürlich nicht. Da beim biometrischen
> PsyPaM man hierzu im Grunde genommen immer nur eine Möglichkeit hat
> -darauf wechseln ja die angeforderten Identifikationsdaten wieder- habe
> ich immer nur eine Möglichkeit Damit scheidet brute-force als
> Angriffsmethode aus.
Nein. Brute Force ist bei deinem Verfahren sogar trivial. Bei einer
Wahrscheinlichkeit von 0.001, das richtige Passwort zu treffen, ist die
Wahrscheinlichkeit, mehr als 10'000 Versuche zu benötigen gerade mal
4.5 E-5.
> anderes.) Beweis: Ich hab?s ausprobiert, und jeder kann es auch
> ausprobieren. Dies ist zwar nicht gerade die eleganteste Form der
> Beweisführung. Aber für "den Hausgebrauch" reicht?s.
Das ist kein Beweis. Einen Angreifer interessiert es nicht, ob du
deine Passzahl 7 aus 7*21 = 7 (mod 10) oder 77*31 = 7 (mod 10) resp. 31 +
56 = 7 (mod 10) oder 4 + 23 = 7 (mod 10) generiert hast, denn in der
Arithmetik modulo 10 spielt dies überhaupt keine Rolle.
> 4.Um Gleichungen mit zwei Unbekannten (und mehr brauchen wir hier nicht)
> aufzulösen, sind unbedingt auch zwei unterschiedliche Gleichungen, die
> jeweils diese Unbekannten, und zwar nur diese Unbekannten, enthalten,
> notwendig.
Die Lösung eines unterbestimmten Gleichungssystems ist ein Unterraum. Eine
Dimension enthält bei dir 10 Werte. Selbst wenn ein Angreifer das
Gleichungssystem nicht komplett lösen kann, kann er auf jeden Fall die
Dimension des Problems einschränken. Pro Dimension, um die ein Angreifer
das Gleichungssystem reduziert ergibt sich eine Einsparung des
Rechenaufwands um den Faktor 10.
Ausserdem lässt sich dein Gleichungssystem mit hinreichend vielen Werten
ohne weiteres analytisch lösen. Deine Tabelle hat nur N Unbekannte, pro
Schritt kommen drei neue Gleichungen und nur eine Unbekannte dazu, mit der
Zeit ist das System sogar überbestimmt.
> enthält, sonst kann z[ident] bzw. z[mod] alle zehn Ziffern des
> Ergebnissraums annehmen. Nur diese zweite Gleichung bekomme ich nicht,
> denn das z[mod] dieser Sitzung, wird ja per definitionem zu einem anderen
> z[ident] in weiteren, folgenden Sitzungen, und Rechenoperationen zwischen
> zwei z[ident] UNTEREINANDER sind nicht vorgesehen.
> z[mod] ist also so eine Art ONE TIME PAD.
S.o. Der Angreifer erhält pro abgehörter Authentisierung drei Gleichungen
und eine Unbekannte, so dass das Gleichungssystem nach hinreichend langer
Beobachtung lösbar wird. Ein Gleichungssystem mit ein paar tausend
Variablen hat moderne Software innert Sekundenbruchteilen gelöst.
Unter einem "One Time Pad" versteht man ein Verfahren, bei dem das Chiffrat
*keinerlei* Information über den Klartext enthält, da es zwischen Klartext
und Chiffrat keinerlei Abhängigkeiten gibt. In deinem Verfahren ist jedoch
sämtliche Information im Chiffrat enthalten. Dass dein Verfahren kein One
Time Pad ist, solltest du eigentlich schon daran erkennen, dass dein
Schlüssel immer wieder verwendet wird.
> Da besagte Rechenoperationen hier ja im Kopf des Benutzers ausgeführt
> werden sollen, ist die GESAMTE zur Übermittlung der Identifikationsdaten
> benutzte Kommunikationstrecke immer als ABHÖRSICHER anzusehen.
Wieso? Nur weil ich mein Passwort im Kopf habe, ist die Übertragung dieses
Passworts per Telnet noch lange nicht als abhörsicher anzusehen.
Gruss
Roman
Andreas Beck
> Lutz Donnerhacke wrote:
>>> (mod(10)). Die Identifikationsdaten werden also in der Form
>>> z[1ident]+z[mod]; z[2ident]+z[mod]; z[3ident]+z[mod] übermittelt.
> Wenn ich dein Post richtig interpretiere, meinst du wahrscheinlich,
> dass diese Formel hier mit Sicherheit viel zu einfach gestrickt ist,um
> die Identifikations- bzw. Modifikationsziffern sicher zu
> verschlüsseln.
Ich kann da beim besten Willen keine Verschlüsselung erkennen.
> Ich kann aber das Gegenteil beweisen. Zwar nur nach dem Motto,
> "Stammeln auch wir, die die Erde gebar." Aber dennoch gültig.
Ein Beweis ist nur gültig, wenn er lückenlos und nachvollziehbar ist.
Also schaun wir mal.
> A: Voraussetzungen
> 1. Es werden hier nur Ziffern verwendet. Damit läßt sich bei einer
> Entschlüsselung die Richtigkeit der gemachten Transformationen nicht
> alleine schon an Hand inhaltlicher Kriterien festmachen. Wenn ich
> "Mary hat ein kleines Lamm." verschlüssele, und beim Entschlüsseln so
> etwas wie "rwti48% qwid!nS Duio0" rauskriege, weiß ich, dass ich
> falsch liege, auch wenn ich den Ursprungstext nicht kenne.
Fehlende Relevanz. Wenn Du mir dieser Argumentation auf eines meiner
durchschnittlichen Passwörter losgehst, gewinnst Du im allgemeinen
keinen Blumentopf.
Abgesehen von der reinen Verwendung von darstellbaren Zeichen wirst Du
nicht viel Struktur feststellen. Aber wie wir gleich sehen werden, ist
eine dieser Punkt sowieso nicht relevant.
> Wenn ich hingegen beim Entschlüseln von "1234" "5678" erhalte, so kann
> ich dieses Ergebnis nur alleine durch Testung am Zugang selbst
> verififzieren. Alleine über den Inhalt geht das natürlich nicht. Da
> beim biometrischen PsyPaM man hierzu im Grunde genommen immer nur eine
> Möglichkeit hat -darauf wechseln ja die angeforderten
> Identifikationsdaten wieder- habe ich immer nur eine Möglichkeit Damit
> scheidet brute-force als Angriffsmethode aus.
Nein. Tut es nicht. Dein Geheimnis ist viel zu kurz.
Ich sende Dir so lange 000 als Passwort, bis es stimmt. Kann 000 nicht
vorkommen, hat Dein Verfahren weitere Schwächen.
> Auch brauchen die verwendeten Schlüssel nicht so groß zu sein.
Schlüssel die zu kurz sind, sind immer für Brute Force angreifbar.
Komm jetzt nicht auf den glorreichen Trichter, irgendwelche
Sperrmaßnahmen einzubauen, das ist nur ein Schuß ins eigene Knie.
Wenn man einen Nutzer nach 3x falsch sperrt, ist das eine prima DoS
Möglichkeit.
> 2.Da es nur zehn Ziffern gibt (Nein, den Schnulli mit Hexadecimal
> machen wir hier nicht, ;-) ), ist auch der Ergebnisraum pro Stelle der
> Passzahl auf nur zehn Möglichkeiten beschränkt.
Bedauerlicherweise.
CU, Andy
Stefan Weinzierl
Zunächst einmal danke für deine Hinweise. Ich werde sie beherzigen, so gut mir
das derzeitig möglich ist
Markus Schaaf wrote:
> Kannst Du nicht. Wenn ich Deine Ausführungen hier richtig verstehe,
> gibt es ein geteiltes Geheimnis zwischen beiden Pateien, welches eine
> 10-stellige Dezimalzahl ist.
Manchmal ist es auch ein Glück,wenn einen die anderen nicht richtig verstehen.
Dann hat man die Möglichkeit seine eigenen Fehler selber wieder auszuwetzen.
;-) Aber dazu weiter unten
Nein, das stimmt nicht. Das geteilte Geheimnis besteht aus Einheiten, von denen
jedes eine einstellige Zahl birgt. Über die Anzahl, wieviele solcher Einheiten
nun vom Auth. Agent (und natürlich auch vom user) verwaltet werden,habe ich
keine Aussagen gemacht. Der user muss sich diese Einheiten, von denen ihm zur
Identifikation immer eine Auswahl dargeboten worden wird, sowieso nicht merken.
Er berechnet nämlich an Hand von Vorgabedaten, welche sich in Form und Inhalt
total von wiederzugebenden einstelligen Zahlen unterscheiden, die
Identifikationsdaten von Fall zu Fall aus. Wie ich mir diese Vorgabedaten und
die entsprechenden Berechnungsformeln vorstelle, ist jetzt derzeitig noch nicht
wichtig. Der Pool mit Identifikationsdaten, aus denen immer wieder ein kleiner
Teil zur Identifikation beim konkreten Login ausgewählt wird, kann also
theoretisch UNENDLICH groß sein. Praktisch vereinbaren user/ess und auth.agent
miteinander zu Anfang bei der Initialisierung eines Benutzerskontos eine
sinnvolle Anzahl solcher Indentifikationseinheiten (z.B. 20). Das hat natürlich
über einen sicheren Kommunikationsweg zu passieren, und der/die Benutzer/in
muss die konkreten Ziffern selbst wählen können (Seine Vorgabedaten müssen ja
an die entsprechenden Zahlen angepasst sein, um sie später wieder ausrechnen zu
können). Da nun bei jedem Login eine (eigentlich sind es zwei, die einem
einzigen Index zugeordnet werden, aber dazu später )neue
Identifikationseinheit, sprich einstellige Zahl, generiert wird, lässt man am
Besten den Pool (=Datenbanktabelle) der zu verwaltenden
Indentifikationseinheiten nach und nach zu einem wiederum sinnvollen Umfang
(vielleicht 100 Einheiten oder so) anwachsen. Wenn man diesen Wert erreicht hat
ersetzt man dann bei jedem Login immer einen Datensatz durch den neuen in
dieser Sitzung gebildeten.
Leider funktioniert mein "Beweis" nur, wenn sichergestellt ist, dass zwei
bestimmte Einheiten nicht wiederholt zusammen in einer Anforderungseinheit
verwendet werden. Sie dürfen also, wenn sie einmal zusammen verwendet wurden,
nicht nocheinmal miteinander später zum Login gebraucht werden (Dies habe ich
nicht beachtet :-(( ). Die einfachste und sauberste Lösung für dieses Problem
ist nun einfach über einen entsprechenden Algoritmus sicher zu stellen, dass
die Identifikationseinheiten nicht widerholt zusammen beim Login angefordert
werden.
Stefan Weinzierl
> Stefan Weinzierl schrieb:
> Habe ich das richtig verstanden, man überträgt zu seiner Identifikation
> drei Ziffern?
> Das heisst, ich habe bei einem wilkürlichen Versuch eine Chance
> von 1:1000, autorisiert zu werden, ohne auch nur das Geringste
> über "Autorisationsindices", den zu autorisierenden Benutzer oder
> deine Methode zu wissen?
>
> Ciao,
> Eike
Nein, es sind noch weniger Möglichkeiten. Da dem Auth. Agenten ja die neu zu
bildende Modifikationsziffer (z[mod]) nicht bekannt ist, ist diese frei
wählbar. Auch wird diese Ziffer mit den anderen (z[ident])Ziffern ja
verrechnet. Die Chance für einen willkürlichen Versuch, würde man nur drei
Ziffern auf die beschriebene Weise übertragen, ist also bei 1:100. Diese
Wahrscheinlichkeit wäre im Notfall sogar noch akzeptabel. Beim biometrischen
PsyPaM bliebt diese Wahrscheinlichkeit nämlich über weite Strecken in vollem
Umfang erhalten. Weil hier verhältnismäßig lange immer neue, andere
Identifikationsdaten in immer wieder neuer Reihenfolge angefordert werden, kann
man hier nährungsweise von einem Zufallsexperiment MIT Zurücklegen sprechen.
Um ganz sicher zu gehen, ordne ich einem bestimmten Index immer paarweise ZWEI
Identifikationsdaten (A,bzw.B) zu, welche jeweils in absolut getrennten
Gleichungssystemen verarbeitet werden. Als weitere Verschlüsselungsmaßnahme ist
es nämlich auch noch frei wählbar, welches der beiden Gleichungssysteme zuerst
übermittelt wird. Man kann also zuerst mit B beginnen, und dann A abarbeiten
oder umgekehrt. Die Chance für eine erfolgreichen willkürlichen Versuch
vermindert sich dadurch auf 1:5000, denn es werden nun sechs Ziffern
übermittelt, wobei jeweils für Gleichungssystem A bzw. B 10 Möglichkeiten und
wegen der willkürlichen Reihenfolge von A und B 2 Möglichkeiten frei wählbar
sind (1E^6/(10*10*2)=5000).
Juergen Ilse
Stefan Weinzierl <stefan.w...@t-online.de> wrote:
>> Kannst Du nicht. Wenn ich Deine Ausführungen hier richtig verstehe,
>> gibt es ein geteiltes Geheimnis zwischen beiden Pateien, welches eine
>> 10-stellige Dezimalzahl ist.
> Manchmal ist es auch ein Glück,wenn einen die anderen nicht richtig verstehen.
> Dann hat man die Möglichkeit seine eigenen Fehler selber wieder auszuwetzen.
> ;-) Aber dazu weiter unten
> Nein, das stimmt nicht. Das geteilte Geheimnis besteht aus Einheiten, von denen
> jedes eine einstellige Zahl birgt. Über die Anzahl, wieviele solcher Einheiten
> nun vom Auth. Agent (und natürlich auch vom user) verwaltet werden,habe ich
> keine Aussagen gemacht. Der user muss sich diese Einheiten, von denen ihm zur
> Identifikation immer eine Auswahl dargeboten worden wird, sowieso nicht merken.
> Er berechnet nämlich an Hand von Vorgabedaten, welche sich in Form und Inhalt
> total von wiederzugebenden einstelligen Zahlen unterscheiden, die
> Identifikationsdaten von Fall zu Fall aus.
Schoen. Damit ist im Endeffekt (auch wenn diese Daten nie direkt zwischen
Client und Server getauscht werden) die Zahl bzw. der Datensatz aus dem
die Authentifizierungsdaten berechnet werden das "geteilte Geheimnis".
Dieses besteht (soweit ich dich verstanden habe) aus einer Permutation
der 10 Ziffern, damit gibt es fuer diesen pre-shared-key nicht (wie es
bei einer beliebigen 10-stelligen Dzimalzahl waere) 10^1^keiten sondern nur 10! Moeglichkeiten: viel zu wenig, um fuer einen
"lebenslangen Passwort-Ersatz" auszureichen, denn da wuerde man mit
heutiger Hardware schon problemlos eine Bruteforce-attacke hinbekommen
(man hat ja genug Zeit, um alle Moeglichkeiten auszuprobieren, da dieser
"pre-shared-key" nie ablaeuft ...).
Und bei diesem Gegenargument ist es letztlich *voellig* *gleichgueltig*,
wie du deine Daten verschluesselst oder im Endeffekt das Cahllenge-
Response-Verfahren implementierst ... Schon ein 6-stelliges Passwort
nur aus Kleinbuchstaben und ohne Ziffern und Sonderzeichen bietet schon
mehr als 3 mal so viele Moeglichkeiten als die deinem Verfahren zugrunde
liegende Permutation der 10 Ziffern (und beklanntlich muessen Passworte
nicht nur auf Kleinbuchstaben und 6 Zeichen Laenge beschraenkt sein,
trotzdem wird empfohlen, sie regelmaessig zu aendern ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Markus Schaaf
> > gibt es ein geteiltes Geheimnis zwischen beiden Pateien, welches eine
> > 10-stellige Dezimalzahl ist.
> Nein, das stimmt nicht.
Diese Antwort war so sicher wie das Amen in der Kirche. Zum Einen
habe ich schon gelesen, daß Dein System "irgendwie" komplexer ist,
als Du es hier erklärst; ich kann Dir jedoch nur zu dem antworten,
was Du schreibst. Zum Anderen solltest Du Dich schon fragen, warum
nach so langwierigen Erklärungsversuchen Deinerseits immernoch
alles im Unklaren ist.
> Das geteilte Geheimnis besteht aus Einheiten, von denen
> jedes eine einstellige Zahl birgt.
(Dezimal-)Ziffer.
> Über die Anzahl, wieviele solcher Einheiten
> nun vom Auth. Agent (und natürlich auch vom user) verwaltet werden,habe ich
> keine Aussagen gemacht.
Doch, Du indizierst sie mit einer Dezimalziffer. Jedenfalls möchte
man das nach dem Lesen Deiner (zu wirren) Texte vermuten.
> Der user muss sich diese Einheiten, von denen ihm zur
> Identifikation immer eine Auswahl dargeboten worden wird, sowieso nicht merken.
> Er berechnet nämlich an Hand von Vorgabedaten, welche sich in Form und Inhalt
> total von wiederzugebenden einstelligen Zahlen unterscheiden, die
> Identifikationsdaten von Fall zu Fall aus.
Eigentlich ist das egal. Das alles sind nur Transformationen ein und
desselben Geheimnisses. Egal, woher diese Ziffern kommen, sobald man
sie hat, braucht man den ganzen Rest nicht mehr. Da man diese Ziffern
(und seien es auch mehr als zehn) durch reines Beobachten Deines
Protokolls (sogar) berechnen kann, ist das Protokoll gebrochen, für
den angestrebten Zweck also ziemlich nutzlos.
> wichtig. Der Pool mit Identifikationsdaten, aus denen immer wieder ein kleiner
> Teil zur Identifikation beim konkreten Login ausgewählt wird, kann also
> theoretisch UNENDLICH groß sein.
Kann er natürlich nicht. Wahrscheinlich gibt es nicht mal unendlich
viele Atome im Universum. Egal woraus Du diese Daten ermittelst, sie
können niemals mehr Information enthalten, als Ihr Ursprung. Solange
das etwas ist, was sich eine Person merken oder mit sich führen kann,
wird es nicht /so/ viel Information sein. Bemühe Dich um Sachlichkeit!
> Leider funktioniert mein "Beweis" nur, wenn sichergestellt ist, dass zwei
> bestimmte Einheiten nicht wiederholt zusammen in einer Anforderungseinheit
> verwendet werden. Sie dürfen also, wenn sie einmal zusammen verwendet wurden,
> nicht nocheinmal miteinander später zum Login gebraucht werden (Dies habe ich
> nicht beachtet :-(( ). Die einfachste und sauberste Lösung für dieses Problem
> ist nun einfach über einen entsprechenden Algoritmus sicher zu stellen, dass
> die Identifikationseinheiten nicht widerholt zusammen beim Login angefordert
> werden.
Du hast den "Angriff" nicht verstanden. Für mich wird es jetzt
langweilig. Wenn Du Dich überhaupt noch weiter sinnvoll unterhalten
willst, solltest Du Dein Protokoll hier erstmal vollständig
definieren. Am besten irgendwie mit Gleichungen, Variablen und
Funktionen.
Nochmal kurz zur Erklärung für Dich: Das gemeinsame Geheimnis sei
eine Tabelle mit n Einträgen, jeder eine Dezimalziffer. Die
Tabelleneinträge seien g_1 bis g_n. Der Server sende zu Beginn eine
Challenge aus 4 Indices in diese Tabelle. Nehmen wir als Beispiel
einfach die Indices 1, 2, 3 und 4. Der Client antwortet nun mit 3
Ziffern a_1 bis a_3. Dem Angreifer sind die Indices und die Ziffern
bekannt. Daraus ergibt sich folgendes Gleichungssystem:
a_1 = ( g_1 + g_4 ) mod 10
a_2 = ( g_2 + g_4 ) mod 10
a_3 = ( g_3 + g_4 ) mod 10
oder
g_1 = ( a_1 - g_4 ) mod 10
...
D.h. der Angreifer hat durch Beobachtung eines Vorgangs die Zahl
der Unbekannten um 3 reduziert. Durch Beobachtung weiterer Vorgänge
kann er diese Zahl weiter reduzieren.
Eike Sauer
Stefan Weinzierl schrieb:
> Die Chance für eine
> erfolgreichen willkürlichen Versuch vermindert sich dadurch auf 1:5000,
Entschuldige, selbst ein Passwort mit nur drei Buchstaben wäre
deutlich schwerer zu erraten. Selbst, wenn man nur Kleinbuchstaben
und keinerlei Sonderzeichen verwenden dürfte.
Würdest du einer Bank vertrauen, die dieses System für Homebanking
einsetzt?
Oder wofür hältst du diese Sicherheit für ausreichend?
Ciao,
Eike
Bernd Eckenfels
> Würdest du einer Bank vertrauen, die dieses System für Homebanking
> einsetzt?
Nur so nebenbei: die PIN meiner Bank is bei Homebanking nur 5 stellig. Ich
weiss nicht, ob die bei Fehlversuchen sperren.
Michail Bachmann
> Eike Sauer <ei...@cs.tu-berlin.de> wrote:
>> Würdest du einer Bank vertrauen, die dieses System für Homebanking
>> einsetzt?
>
> Nur so nebenbei: die PIN meiner Bank is bei Homebanking nur 5 stellig. Ich
> weiss nicht, ob die bei Fehlversuchen sperren.
Bei meiner Bank wird das Konto nach 3 Fehlversuchen gesperrt,
Entsperrung durch richtige PIN + TAN.
Selbst wenn jemand die PIN richtig erraet, hat er halt nur
ReadOnly-Zugriff auf das Konto. Nicht schoen, aber auch nicht wirklich
tragisch. Durch regelmaessige PIN-Aenderungen kann man auch dieses
Restrisiko in Grenzen halten.
CU Micha
Andreas Beck
> Bernd Eckenfels <ec...@calista.eckenfels.6bone.ka-ip.net> wrote:
>> Eike Sauer <ei...@cs.tu-berlin.de> wrote:
>>> Würdest du einer Bank vertrauen, die dieses System für Homebanking
>>> einsetzt?
>> Nur so nebenbei: die PIN meiner Bank is bei Homebanking nur 5 stellig. Ich
>> weiss nicht, ob die bei Fehlversuchen sperren.
> Bei meiner Bank wird das Konto nach 3 Fehlversuchen gesperrt,
> Entsperrung durch richtige PIN + TAN.
Wie jetzt? Das würde ja heißen, daß man freundlich weiterprobieren kann
... Mit erhöhtem Aufwand, falls die PIN nicht bekannt ist (in dem Fall
wäre aber ggf. auch das erstmalige Raten einer TAN witzfrei).
Vielleicht habe ich es aber auch nicht richtig verstanden.
Also in meinem Hirn ist angekommen:
1. 3x falsche TAN benutzen => Sperrung.
2. Dann braucht man einen Neulogin mit PIN und TAN - right?
Wie lang ist die PIN?
3. Es gibt kein Limit, wie oft man 2. probieren kann.
Damit würde die Knackzeit auf (Anzahl mögl. PINs * Anzahl mögl TANs / in
der Liste noch verfügbare TANs) steigen.
Allerdings wird dabei die PIN bekannt, so daß bei weiteren Versuchen nur
noch eine TAN geraten werden muß.
Merkt man sich die probierten TANs, kann man auch den Wertebereich für
noch gültige TANs einschränken.
Allerdings hätte man danach wieder nur 3 Möglichkeiten, eine TAN zu
raten, um was ernsthaft Schaden anrichtendes zu machen. Allerdings
hat man bereits den eingeschränkten Wertebereich als Hilfe zur
Verfügung. Das führt dazu, daß (Anzahl mögl TANs / in der Liste noch
verfügbare TANs) in etwa konstant bleibt.
Wenn wir jetzt mal davon ausgehen, daß man einen "frischen" Account hat,
der 100 5-stellige PINs zur Verfügung hat, dann ist die Chance, eine zu
treffen 1:1000.
Also brauchen wir (PIN-Möglichkeiten x 1000), um die PIN zu
brute-forcen.
Für jede "Runde" in der wir eine weitere PIN beim Einloggen verbraten,
haben wir dann 3x die Chance eine PIN zu raten. Diese Chance ist jeweils
1:1000 (nicht 1:10^5 - wegen der Wertebereichseinschränkung durch den
Logon!). Das geht in 99.7% der Fälle schief.
Nun haben wir 99 Versuche, wenn wir noch was anrichten wollen ...
Die Chance daß alle mißlingen liegt bei ca. 74.3% ...
Also bei jedem vierten Konto klappt es ...
Aber ich denke mal bei so massiven Zahlen an fehlgeschlagenen
Entsperrungsversuchen, werden noch andere Maßnahmen greifen ...
> Selbst wenn jemand die PIN richtig erraet, hat er halt nur
> ReadOnly-Zugriff auf das Konto. Nicht schoen, aber auch nicht wirklich
> tragisch.
Wie bekommt am wieder "Write"? Bank anrufen? Dann gilt natürlich meine
Rechnung oben nicht.
CU, Andy
Frank Meyer
>> Bei meiner Bank wird das Konto nach 3 Fehlversuchen gesperrt,
>> Entsperrung durch richtige PIN + TAN.
> Also in meinem Hirn ist angekommen:
>
> 1. 3x falsche TAN benutzen => Sperrung.
^^^
PIN war gemeint.
Deine restlichen Überlegungen sind damit hinfällig, oder?
Gruß,
Frank
Andreas Beck
Kommt drauf an, was dann passiert ... wieder "Entsperrung durch richtige
PIN/TAN"?
Dann nein. Dann kann man die PIN brute-forcen. Mit einem um ca. 1:1000
höheren Aufwand (Tanmöglichkeiten/verfügbare TANs) als ohne die Sperrung.
CU, Andy
Amras Saralondee
[schöne Rechnung zum PIN/TAN knacken]
> Nun haben wir 99 Versuche, wenn wir noch was anrichten wollen ...
> Die Chance daß alle mißlingen liegt bei ca. 74.3% ...
> Also bei jedem vierten Konto klappt es ...
Wirklich sehr beeindruckend. Aber das Problem mit vielen Theorien ist doch,
dass sie häufig ganz banale unter den Tisch fallen lassen.
Bei mir hätte jemand eben keine 99 Versuche mehr, denn wenn mein Konto zwei-
oder dreimal gesperrt worden wäre, weil ein Hirnie versucht die PIN/TAN zu
raten, dann hätte ich mein Konto gewechselt, oder die Bank, oder würde ganz
auf Onlinebanking verzichten.
Anhand der versuchten TAN kann man übrigens nicht auf einen Wertebereich
schließen, da es keinen gibt. Bei mir sind die 100 TAN nicht seriell
verteilt (12400 - 12499), sondern völlig zufällig gewählte, fünfstellige
Zahlenkombinationen, u. U. mit einer oder mehreren führenden Nullen! Da
wird das ganze schon deutlich schwieriger, oder habe ich Dich da flacsh
verstanden?
Ich halte das System schon für *sehr* sicher.
A.S.
Michail Bachmann
> Michail Bachmann wrote:
>> Bernd Eckenfels <ec...@calista.eckenfels.6bone.ka-ip.net> wrote:
>>> Eike Sauer <ei...@cs.tu-berlin.de> wrote:
>>>> Würdest du einer Bank vertrauen, die dieses System für Homebanking
>>>> einsetzt?
>>> Nur so nebenbei: die PIN meiner Bank is bei Homebanking nur 5 stellig. Ich
>>> weiss nicht, ob die bei Fehlversuchen sperren.
>> Bei meiner Bank wird das Konto nach 3 Fehlversuchen gesperrt,
>> Entsperrung durch richtige PIN + TAN.
>
> Wie jetzt? Das würde ja heißen, daß man freundlich weiterprobieren kann
> ... Mit erhöhtem Aufwand, falls die PIN nicht bekannt ist (in dem Fall
> wäre aber ggf. auch das erstmalige Raten einer TAN witzfrei).
>
> Vielleicht habe ich es aber auch nicht richtig verstanden.
> Also in meinem Hirn ist angekommen:
>
> 1. 3x falsche TAN benutzen => Sperrung.
Erstes Level ist PIN.
> 2. Dann braucht man einen Neulogin mit PIN und TAN - right?
> Wie lang ist die PIN?
PIN = 5 Stellen, Buchstaben + Zahlen, TAN = Dezimalzahl, 6 Stellen
> 3. Es gibt kein Limit, wie oft man 2. probieren kann.
Jein, Du muesstest die richtige PIN eingeben und eine gueltige TAN.
D.h. selbst wenn Du zufaellig die richtige PIN erraetst, muesstest Du
immer noch eine gueltige TAN erraten.
> Damit würde die Knackzeit auf (Anzahl mögl. PINs * Anzahl mögl TANs / in
> der Liste noch verfügbare TANs) steigen.
(62^5 * 10^6)/100 = 9161328320000
> Allerdings wird dabei die PIN bekannt, so daß bei weiteren Versuchen nur
> noch eine TAN geraten werden muß.
Nein, Du kannst den Fall gueltigePIN+ungueltigeTAN nicht von ungueligePIN
unterscheiden.
> Merkt man sich die probierten TANs, kann man auch den Wertebereich für
> noch gültige TANs einschränken.
-v bitte. Eine benutzte TAN invalidiert alle vorhergehenden TANs, d.h. im
schlechtesten Fall hast Du die TAN-Liste nach einem Versuch aufgebraucht.
> Allerdings hätte man danach wieder nur 3 Möglichkeiten, eine TAN zu
> raten, um was ernsthaft Schaden anrichtendes zu machen. Allerdings hat
> man bereits den eingeschränkten Wertebereich als Hilfe zur Verfügung.
> Das führt dazu, daß (Anzahl mögl TANs / in der Liste noch verfügbare
> TANs) in etwa konstant bleibt.
Dasselbe Problem wie im letzten Abschnitt.
> Wenn wir jetzt mal davon ausgehen, daß man einen "frischen" Account
> hat, der 100 5-stellige PINs zur Verfügung hat, dann ist die Chance,
> eine zu treffen 1:1000.
??? Meinst Du jetzt TANs? Die sind aber 6-stellig.
Wegen der Eigenschaft der TAN-Listen, ist die Wahrscheinlichkeit eine TAN
zu erraten, bevor das Konto gesperrt wird, ziemlich gering. Ich habe keine
Lust das jetzt genau auszurechenen.
> Also brauchen wir (PIN-Möglichkeiten x 1000), um die PIN zu
> brute-forcen.
>
> Für jede "Runde" in der wir eine weitere PIN beim Einloggen verbraten,
> haben wir dann 3x die Chance eine PIN zu raten. Diese Chance ist jeweils
Daraus werde ich jetzt nicht schlau. Bist Du sicher, dass Du TAN und PIN
richtig verwendest?
> 1:1000 (nicht 1:10^5 - wegen der Wertebereichseinschränkung durch den
> Logon!).
Welche Wertebereichseinschraenkung? Die auf (2*26+10)^5?
> Nun haben wir 99 Versuche, wenn wir noch was anrichten wollen ... Die
> Chance daß alle mißlingen liegt bei ca. 74.3% ...
Nein, siehe Eigenschaften von TANs.
> Also bei jedem vierten Konto klappt es ...
Daher, nein.
> Aber ich denke mal bei so massiven Zahlen an fehlgeschlagenen
> Entsperrungsversuchen, werden noch andere Maßnahmen greifen ...
Man kann es nur hoffen.
>> Selbst wenn jemand die PIN richtig erraet, hat er halt nur
>> ReadOnly-Zugriff auf das Konto. Nicht schoen, aber auch nicht wirklich
>> tragisch.
>
> Wie bekommt am wieder "Write"? Bank anrufen? Dann gilt natürlich meine
> Rechnung oben nicht.
Nein, TAN erraten = 3 Versuche, sonst Konto gesperrt. Entsperrung nach
persoenlicher Vorsprache. Ist nervig, aber nicht tragisch.
CU Micha
Sebastian Posner
>>>> Bei meiner Bank wird das Konto nach 3 Fehlversuchen gesperrt,
>>>> Entsperrung durch richtige PIN + TAN.
>>> Also in meinem Hirn ist angekommen:
>>> 1. 3x falsche TAN benutzen => Sperrung.
>> ^^^
>> PIN war gemeint.
>> Deine restlichen Überlegungen sind damit hinfällig, oder?
> Kommt drauf an, was dann passiert ... wieder "Entsperrung durch richtige
> PIN/TAN"?
3*PIN flasch -> Konto gesperrt.
Dann brauchts eine *unverbrauchte*, *zugeteilte* TAN + die *korrekte* PIN.
Es gibt 1 gültige PIN und max. 100 gültige TAN.
(wobei ich jeweils sogar nur 50 gültige TAN auf einmal bekomme)
Meine TANs sind 6-stellig, PIN akt. 5-stellig.
Somit mußt du eine 5+6-stellige Zahl erraten/brute-forcen, bei der von
dem 6-stelligen Teil max. 100 Kombinationen möglich sind.
Du hast eine Trefferwahrscheinlichkeit von 100/10.000.000.000.
Und endgültig chancenlos bist du, wenn auch bei einem Fehlversuch wegen
falscher PIN beim Entsperren trotz korrekter TAN TAN-Verbrauch eintritt.
Merke: Die Liste der zugeteilten TANs ist nicht als gegeben anzunehmen.
Sebastian
--
"Ja der weiße Mann aus Texas / Brät den Teufel heut am Spieß,
Und alle, die ein anderes Lied singen / grillt der Mann im Fegefeuer mit"
Fink feat. Peter Lohmeyer / Bagdad Blues ( Der weiße Mann aus Texas)
Sebastian Posner
>> Merkt man sich die probierten TANs, kann man auch den Wertebereich für
>> noch gültige TANs einschränken.
> -v bitte. Eine benutzte TAN invalidiert alle vorhergehenden TANs, d.h. im
> schlechtesten Fall hast Du die TAN-Liste nach einem Versuch aufgebraucht.
Nein.
TANs kann man wahlfrei von der Liste verwenden. Das einzige, wann
vorherige TANs gesperrt werden: Wenn man schon eine neue TAN-Liste hat
(weil die alte zur Neige geht) und eine davon verwendet. Dann werden
alle bisher ungenutzten TANs der alten Liste nichtig.
Sebastian Posner
>>>> Würdest du einer Bank vertrauen, die dieses System für Homebanking
>>>> einsetzt?
>>> Nur so nebenbei: die PIN meiner Bank is bei Homebanking nur 5 stellig. Ich
>>> weiss nicht, ob die bei Fehlversuchen sperren.
>> Bei meiner Bank wird das Konto nach 3 Fehlversuchen gesperrt,
>> Entsperrung durch richtige PIN + TAN.
> Wie jetzt? Das würde ja heißen, daß man freundlich weiterprobieren kann
> ... Mit erhöhtem Aufwand, falls die PIN nicht bekannt ist (in dem Fall
> wäre aber ggf. auch das erstmalige Raten einer TAN witzfrei).
>
> Vielleicht habe ich es aber auch nicht richtig verstanden.
> Also in meinem Hirn ist angekommen:
>
> 1. 3x falsche TAN benutzen => Sperrung.
Wer redet hier von TAN?
3* lahcfes PIN ->Sperrung.
> 2. Dann braucht man einen Neulogin mit PIN und TAN - right?
Ja.
> Wie lang ist die PIN?
PIN, wie geschrieben: 5. TAN: 6.
> 3. Es gibt kein Limit, wie oft man 2. probieren kann.
Keine Ahnung. Sinnvollerweise werden auch dabei die benutzten TANs als
verbraucht markiert.
> Damit würde die Knackzeit auf (Anzahl mögl. PINs * Anzahl mögl TANs / in
> der Liste noch verfügbare TANs) steigen.
Nein.
Anzahl mögl. PINs * Anzahl mögl TANs.
Die TAN-Liste hast du nicht.
> Allerdings wird dabei die PIN bekannt,
Nein. Du mußt TAN *und* PIN raten. Und hast selbst wenn du die TAN-Liste
kennst "nur" 100 Versuche. Um eine 5-stellige PIN zu raten ist das nicht
viel.
> so daß bei weiteren Versuchen nur
> noch eine TAN geraten werden muß.
Nein. Du kennst weder PIN noch TAN.
> Merkt man sich die probierten TANs, kann man auch den Wertebereich für
> noch gültige TANs einschränken.
Nein. TANs sind explizit nicht-sequentiell. Wenn du eine gültige
gefunden (und damit im selben Moment verbraucht) hast, hast du keinerlei
Hinweise auf sonstige gültige TAN (außer, nicht verbrauchte TAN +- 1 ->
auch ungültig).
> Allerdings hätte man danach wieder nur 3 Möglichkeiten, eine TAN zu
> raten, um was ernsthaft Schaden anrichtendes zu machen. Allerdings
> hat man bereits den eingeschränkten Wertebereich als Hilfe zur
> Verfügung. Das führt dazu, daß (Anzahl mögl TANs / in der Liste noch
> verfügbare TANs) in etwa konstant bleibt.
Hä? Du rauchst komische Pflanzen :-)
> Wenn wir jetzt mal davon ausgehen, daß man einen "frischen" Account hat,
> der 100 5-stellige PINs zur Verfügung hat, dann ist die Chance, eine zu
> treffen 1:1000.
Ja.
> Also brauchen wir (PIN-Möglichkeiten x 1000), um die PIN zu
> brute-forcen.
Ja.
> Für jede "Runde" in der wir eine weitere PIN beim Einloggen verbraten,
> haben wir dann 3x die Chance eine PIN zu raten.
Der Sinn deiner Worte ist wirr.
PIN wird nicht verbraten. TANs werden verbraten. Und zwar sobald du eine
korrekte eingegeben hast.
Liegst du evtl. den Irrtum auf, du müßtest PIN/TAN beim entsperren
sequentiell eingeben?
> Also bei jedem vierten Konto klappt es ...
Merkwürdige Rechnungen du anstellst.
>> Selbst wenn jemand die PIN richtig erraet, hat er halt nur
>> ReadOnly-Zugriff auf das Konto. Nicht schoen, aber auch nicht wirklich
>> tragisch.
> Wie bekommt am wieder "Write"? Bank anrufen? Dann gilt natürlich meine
> Rechnung oben nicht.
Für *einen* Schreibzugriff (ver)brauchst du eine TAN (TansAktionNummer.
OTP oder so, wissenschon). Nur mit der PIN bekommst du nur Lesezugriff,
d.h. du kannst Kontostand etc. ansehen. Für Überweisungen oder die
Anforderung neuer TAN brauchst du eine TAN. Eine dir zugewiesene,
unverbrauchte solche.
Du machst kein Internet-Banking, oder? *G*
Alexander Skwar
> -v bitte. Eine benutzte TAN invalidiert alle vorhergehenden TANs, d.h. im
> schlechtesten Fall hast Du die TAN-Liste nach einem Versuch aufgebraucht.
Das stimmt ber der Deutschen Bank nicht. Dort gibt es keine Reihenfolge
der TANs, dh. "spätere" TANs invalidieren NICHT "vorherige" TANs auf
der Liste (dh. ich kann die TAN ganz unten rechts auf dem Zettel als
erstes, zweites, n-tes eingeben, und habe trotzdem noch 49 weitere
gültige TANs).
> Welche Wertebereichseinschraenkung? Die auf (2*26+10)^5?
Das stimmt übrigens nicht - zumindest nicht bei der Deutschen Bank, da
dort gewissen Mindestanforderungen an die PIN gestellt werden. Z.B.
keine Sequenzen (12345), keine 5'er Wiederholungen (yyyyy)....
Alexander Skwar
--
Bück dich, Fee. Wunsch ist Wunsch!
Michail Bachmann
> commence 1 followup to Michail Bachmann <nor...@emeraldcity.de>:
>
>> -v bitte. Eine benutzte TAN invalidiert alle vorhergehenden TANs, d.h. im
>> schlechtesten Fall hast Du die TAN-Liste nach einem Versuch aufgebraucht.
>
> Das stimmt ber der Deutschen Bank nicht. Dort gibt es keine Reihenfolge
> der TANs, dh. "spätere" TANs invalidieren NICHT "vorherige" TANs auf
> der Liste (dh. ich kann die TAN ganz unten rechts auf dem Zettel als
> erstes, zweites, n-tes eingeben, und habe trotzdem noch 49 weitere
> gültige TANs).
Hmm, interessant. Kennt jemand hier eine genaue Beschreibung des
TAN-Verfahrens inkl. URL? Ich bin bisher immer von einer Art
S/Key Implementierung ausgegangen, aber ich gebe zu, ich habe mich damit
noch nicht naeher beschaeftigt.
>> Welche Wertebereichseinschraenkung? Die auf (2*26+10)^5?
>
> Das stimmt übrigens nicht - zumindest nicht bei der Deutschen Bank, da
> dort gewissen Mindestanforderungen an die PIN gestellt werden. Z.B.
> keine Sequenzen (12345), keine 5'er Wiederholungen (yyyyy)....
Du hast natuerlich Recht, aber als grober Ueberschlag immer noch besser
als 10^5. Es sei denn, Du kannst mal schnell sagen, wieviel
Kombinationen das nun wirklich sind.
CU Micha
Andreas Beck
> Bei mir hätte jemand eben keine 99 Versuche mehr, denn wenn mein Konto zwei-
> oder dreimal gesperrt worden wäre, weil ein Hirnie versucht die PIN/TAN zu
> raten, dann hätte ich mein Konto gewechselt, oder die Bank, oder würde ganz
> auf Onlinebanking verzichten.
Wie bitte hättest Du das bemerkt?
Ich bin explizit davon ausgegangen, daß _keine_ nur durch externe
Eingriffe rückgängig machbare Sperrung erfolgt.
> Anhand der versuchten TAN kann man übrigens nicht auf einen Wertebereich
> schließen, da es keinen gibt. Bei mir sind die 100 TAN nicht seriell
> verteilt (12400 - 12499), sondern völlig zufällig gewählte, fünfstellige
> Zahlenkombinationen,
[x] Du willst das Posting nochmal lesen.
Wenn man TANs ab 00000 aufwärts durchprobiert und bei 01467 eine trifft,
weiß man, daß weitere TANs erst ab 01468 liegen können, sonst wäre man
bereits vorher reingekommen.
Daher hat man, wenn man von 100 aktiven TANs und 5 Stellen ausgeht eine
"Ratewahrscheinlichkeit" von 1:1000 - konstant bis die TANs alle sind.
> u. U. mit einer oder mehreren führenden Nullen!
Wahnsinn. Ob führende Nullen oder Spaces vor einer Zahl stehen macht
wirklich den Unterschied.
> oder habe ich Dich da flacsh verstanden?
Ja. s.o.
CU, Andy