[DEC] OneTimePasswords

[Meflin]

Hi,
könnte mir mal einer die funktion des onetimepasswords erklären (die ich glaube ich net so ganz gechecket habe). also der client weis das korrekte passwort ( :stupid: ), der server auch. der client bildet jetzt irgendwie ein paar hashes (?) und sendet diese an den server. oder wie? was? ahhhh... (*gg*)

*MFG*

[generic]

auf dem server laeuft ein timer. mit diesem timer wird ein passwort errechnet.
der client, besser der user hat einen kleinen schluesselanhaenger z.b. von rsa labs,
welches den selben timer laufen hat. auf dem schluesselaenhaenger steht dann der variable teil des
passworts.

http://www.rsasecurity.com/images/SecurID_fob.jpg
(der kleine lcd balken gibt an wann es ein neues pw gibt)

da die timer gleich laufen wissen server und client immer das aktuelle passwort.
das passwort aendert sich alle 5 minuten. ist ein passwort einmal benutzt sperrt der server
dieses. der user muss dann schlimmsten 5 minuten warten um sich erneut anzumelden.

gruss

[HeikoDD]

server bildet eine liste von n+1 Hash Werten, sendet an den clienten n-1 hash werte,
client meldet sich jetzt mit nHash wert beim Server an, der berecht den n+1 Hashwert und
vergleich dieses ergebnis mit dem gespeicherten n+1 hash wert, stimmen beide überein
dann ist alles im lot. der client verwirft nHash der server speichert den hash wert. usw.
das geht so bis die tan-liste alle ist.
geht glaub ich auch anderes rum, sprich der client erzeugt die tan liste und sendet dem server n+1 hash ... oder so.

wie das mit dem generator von RSA für passwörter funktionieren soll und
wie die synchronisiert werden sollten, tja keine ahnung.

oder meintest du die otp verschlüsselung? in dem fall bilde einen buffer von ECHTEN zufallswerten der sogroß ist wie der buffer den du verschlüsseln willst, verXORe beide miteinander und schmeiß die zufalls werte wech. das wars.

OTP der nachweislich einzige sichere symmetriche Verschlüsselungsansatz. Leicht in der umsetzung, schwer in der realität zu bewerkstelling.


am besten frag hagen, der weiß so etwas sehr genau ...

[Meflin]

ah thx jetzt hab ichs gechecked. aber warum reicht nicht ein hash?

[negaH]

Hi,

vorweg, beim OTP Verfahren das in DEC benutzt wird handelt es sich um das S/KEY OTP.
Der Server kennt dabei NICHT das Benutzerpasswort, den nur der Benutzer soll dies kennen, es ist sein Geheimnis.

Die komplette Sicherheit basiert auf der Sicherheit einer secure One Way Function, also zB. einer Hash Funktion. Diese Funktionen können Daten nur in eine Richtung konvertieren.

Was passiert nun beim S/KEY:
1.) der Benutzer muß sich erstmal registrieren und bekommt vom Server verschiedene Parameter übermittelt.
2.) der Benutzer registriert sich indem er dazu sein Passwort eingibt
3.) ab nun kann der Benutzer sich immer wieder erneut sichr einloggen ohne erneute Registration.

Die Idee hinter S/KEY ist sehr einfach.

Der Benutzer benutzt sein Passwort und berechnet von diesem einen Hashwert. Nun berechnet der Benutzer von diesem Hashwert wieder einen neuen Hashwert, und von diesem wiederum einen neuen, und so fort und so weiter...
Wichtig ist, es entsteht eine Liste, basierend vom Benutzerpasswort von einzelnen Hashwerten die immer vom vorherigen Hashwert bis hin zum Passwort voneinander abhängig sind. Der Server übermittelt nun bei der Registration wie oft diese sequentielle Berechnung stattzufinden hat. Zb. 1000, also 1000 mal soll ein Hash vom Hash vom Hash vom Hash vom... berechnet werden.
Nachdem dies geschehen ist sendet der Benutzer den 1000'enden Hashwert als Startwert zum Server, der Server speichert 1000 -1 = 999 unter dem Benutzerkonto ab, mitsamt dem 1000'end Hashwert.
Beim nächsten Login sendet der Server die 999 an den Benutzer. Dieser gibt sein Passwort ein und berechnet 999 mal den Hash vom Hash vom Hash.. Er sendet diesen 999'ten Hashwert an den Server, dieser berechnet EINMAL den Hashwert davon und vergleicht diesen mit dem gespeicherten 1000'enden Hashwert. Sind beide identisch so weiß der Server das der Client in der Lage ist die kompletten succesiven Hashwerte ausgehend vom richtigen Passwort zu berechnen. Also nur einer der das Passwort kennt kann ALLE Hashs vom Hash vom Hash vom Hash.... berechnen, und der Server vergleicht den aktuellen Hashwert mit dem logischen Nachfolgehash davon den er ja beim letzten Login erhalten hat.
Somit weis selbst der Server NICHT welcher Hashwert der Vorgängrhashwert ist, denn das ist nur mit dem Passwort berechenbar.

War der Login erfolgreich so speichert der Server im Benutzerkonto nun 999-1 = 998 und den gerade vom Benutzer empfangen Hashwert ab.

Gruß Hagen

[negaH]

Die RSA Token berechnen vorwärtsgerichtet ausgehend von einen Startwert eine Zahl nach der anderen. Würde man also den verwendeten Algorithmus kennen ist es sehr wahrscheinlich das man diese Verfahren brechen kann. Eben aus diesem Grunde hat RSA bis heute nicht das verwendete Verfahren veröffentlicht und verkauft meines Wissens nach auch nicht die Server Software. Eben auch ein weiterer Grund warum die Tokens selber in einer "einbruchssicheren" Hardware stecken. Diese Token haben primär reingarnichts mit dem S/KEY OTP Verfahren zu tun.

Das S/KEY Verfahren wurde übrigens angeblich gebrochen. Nicht der Algorithums selber ist unsicher sondern die Art und Weise wie der Server abgesichert werden muß. Hat ein Angreifer Zugriff auf die Server erlangt so ist es für ihn ein leichtes den zum Benutzerkonto gespeicherten Hashwert durch einen eigenen zu ersetzen. Das fatale daran ist das der Server eben nicht verifizieren kann ob eine solche Manipulation durchgeführt wurde. Beim nächsten Login des Benutzers könnte es auch der Angreifer sein. Allerdings, wenn ein Angreifer schon in den Server eindringen kann, dann ist es eigentlich wenig sinnvoll diese Logins zu manipulieren, denn er hat ja schon Zugang zum Server.

Gruß Hagen

[Meflin]

merci beaucoup, jetzt ists mir glasklar :party: