G.Schuster

Nö.
Wenn man ein Zeitfenster von z.B. 5 Minuten hat ist der Wert in der Zeit gültig.

Mit "reiner" Verschlüsselung machst du dich wieder angreifbar für Replay-Attacken.
Nutzt du hingegen noch einen Salt hast du das gleiche Problem - dieser muss auch an den Server übergeben werden, sonst bleibt's beim immer gleichen Text den du übergibst.

Mein Vorschlag ist ein durchaus bekanntes "Protokoll", ich hab mir das nicht selbst ausgedacht.
Für die Authentifizierung bzw. eine relativ sichere Übergabe des Passworts ist so ein Verfahren durchaus geeignet, es braucht nicht immer asymmetrische Verschlüsselung oder PKI, das kostet alles auch entsprechend Rechenleistung/Geschwindigkeit.

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5

Mister Ad

Sirke

Ich habe gerade dein Protokoll nochmal angesehen und die Uhrzeit ist so oder so Unsinn, weil du diese mitsendest, genauso wie die Nonce. Der Client darf also selbst entscheiden, welche Nonce und welche Zeit er sendet. Findet man also einen Client, welcher eine falsche zu frühe Uhrzeit hat, dann veranlasst man eine Authentifikation und blockt die Nachricht und schneidet diese mit. Anschließend kann man diese Nachricht zur richtigen Uhrzeit verwenden und sich einloggen. Schon ist das Protokoll gebrochen...

Verschlüsselung hat nichts mit Replay Angriffen zu tun, weil es durchaus symm Krypto Protokolle gibt, welche sogar beweisbar sicher sind! Man einigt sich auf ein gemeinsames Geheimnis und zeigt durch irgendein kryptographisches Primitiv, dass man das geteilte Geheimnis kennt! Das kann man Verschlüsselungen, MACs oder Hashes erreichen...

Klar braucht es nicht zwingend asymm Krypto, aber wenn man nur ein Profil verändern möchte, dann würde eine signierte und verschlüsselte Nachricht ausreichen und jeder neue Benutzer müsste "bloß" ein neues Zertifikat ausgestellt bekommen. Klar ist das ein Aufwand, aber eine bestehende PKI könnte es ja geben...

...ohne einen ordentlichen Anforderungskatalog können wir eh nur raten und unvollständige oder unsichere Protokolle liefer...

G.Schuster

Es ist NICHT "mein" Protokoll!

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5

Sirke

...dann dein vorgeschlagenes! Es bleibt aber unsicher...

crime4549

Moin,

kleines bsp. meiner seits in wie weit das Sinn oder Unsinn ist überlasse ich euch.

Serverseitige zufallsgenerierung eines öffentlichen Keys in kombo mit sessionID wird an den Client übergeben,128 Zeichen alphanumerisch sollten langen.

Serverseitig wird ein Fingerprint erstellt, z.b. AES 3des blowfisch, wie beliebt und dieser wird in der dB abgelegt, sammt session id und Key.

User meldet sich am Server über den Öffentlichen Key an, Gegenprüfung der übergeben Werte, am Server, anhand der zuvor gewählten verschlüsselung.

Anhand div. sonstigen attributen wie ts etc. kann die Gültigkeit des Keys ermittelt werden.


sollte relativ sicher sein.

Ob sinn oder unsinn, wie gesagt, überlasse ich euch..
ich bin jetzt müde.. doppelschicht zu ende..


Grüße

__________________
Egal wie tief man die geistige Messlatte auch hängen mag, jeden Tag findet sich einer, der aufrecht darunter durchlaufen kann.

G.Schuster

Auch wenn der Thread nun schon etwas älter ist - und weil ich gerade wieder über was bezüglich WS-AUTH gestolpert bin...
http://www.oasis-open.org/committees...rofile-1.1.pdf
Lies' und staune, dass mein Vorschlag in Abschnitt 3 genau so beschrieben ist.
Ich denke mal, ein Technik-Komitee mit Chairs von IBM und MS sowie Editoren von IBM, MS, Sun und Verisign wird das nicht zum Spaß vorschlagen.

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5

Renner

Haut mich, aber ist es nicht so, dass in dem "Verfahren von G. Schuster, dass nicht von ihm ist" von einer unverschlüsselten Verbindung ausgegangen wird?

Wenn ich deinen Einwand richtig verstehe, willst du diesem Verfahren unterstellen, dass es anfällig für eine Man-in-the-Middle-/Abhör-Attacke ist. Trifft dies bei unverschlüsselten Verbindungen nicht für jedes Verfahren zu? Ich meine zumindest ein Session Hijacking wäre bei unverschlüsselten Verbindungen immer denkbar. Allein der Schwierigkeitsgrad kann erhöht werden.

Bitte korrigiert mich, wenn ich falsch liege, aber:
Durch das geschilderte Verfahren wird m.E. zum einen verhindert, dass der Angreifer an das Passwort kommt (Nonce + Timestamp + Sha) und zudem auch noch eine maximale Gültigkeit des Credentials (Timestamp) gewährleistet.

In einem Umfeld, in dem absichtlich auf eine verschlüsselte Verbindung verzichtet würde - ich weiß gar nicht, ob dies vom Threadersteller überhaupt gewollt ist - dürfte dies doch in der Summe eine beträchtliche Erhöhung der Hürde darstellen.

Eventuell wäre es denkbar, dass der Timestamp vom Server kommt und an die Session gebunden wird. Auf den Nonce könnte man meines Erachtens eh verzichten, da er einem Angreifer bekannt ist. Oder überseh ich da was?

G.Schuster

Das ist im Grunde egal.
Wenn man ein einheitliches Zeitformat verwendet, das die Zeitzone beinhaltet, hat man auch kein Problem mit der Client-Zeit.
Und mal ehrlich: wer nichtmal NTP laufen hat braucht sich auch nicht zu einem gesicherten Webservice verbinden

Ein bisschen mehr zu salzen schadet dieser Suppe nicht.
Das ist Sinn und Zweck des Nonce - mit dem ein Angreifer nichts anfangen kann.

Ich sehe den Sinn dieses Verfahrens im allgemeinen darin, Passwörter relativ sicher übertragen und vor allem Replay-Attacken durch erneutes Senden der gleichen Daten zu verhindern.
Und dafür eignet es sich meiner Meinung nach recht gut.
MitM mit direkter Request-Änderung lässt sich damit natürlich nicht verhindern, aber dafür gibt's dann ja wieder die Verschlüsselung/Signierung.

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5