REST - absichern

[webald]

Kann mir mal einer sagen ob mein Gedanke vernünftig ist?

Ich erstelle gerade verschiedene Funktionen zum abrufen und auch Ändernvon Daten und diese sollen als Webservice veröffentlicht werden. Ob SOAP oder REST spielt eigentlich keine Rolle, aber bei REST werden die Timeout-Probleme kleiner sein als bei SOAP.

Das ganz soll aber natülich sicher sein. Ob ein Client berechtigt ist oder nicht läßt sich ja einfach über eine Userrechte-Tabelle lösen. Bleibt das Problem des Passworts und der Daten.

1. Zugriff nur via https. Werden aber Anfragen versehentlich doch per http verschickt, so wäre ein unverschlüsseltes Password auslesbar. Diese Lösung behagt mir nicht

2. Mit jeder Anfrage an den Webservice werden die zu sendenden Daten übertragen. Diese Daten werden mit einem Hash des Passwortes verschlüsselt. Dem Server ist der Hash des Passwortes eines User aber ja bekannt und er kann die Daten entschlüsseln. Damit wäre User/Passwort-Prüfung und Datenverschlüsselung in einem gegeben. Außerdem wäre so auch eine Datenübertragung per http möglich.

Richtig?

Linkback: https://www.modified-shop.org/forum/index.php?topic=31797.0

[hendrik]

https verschlüsselt nicht nur die Übertragung sondern identifiziert auch den Server. Stichwort 'Man in the middle'. Anfragen per HTTP würde ich durch eine geeignete Server- oder Softwarekonfiguration unterbinden. HTTP wird gar nicht bedient.

Gruß
Hen

[webald]

ja, mit https kann man den Server identifizieren, aber der Client ist damit immer noch anonym. Daher muss der Client vom Server auch authentifiziert werden, was üblicherweise mit User/Passwort funktioniert. Nun kommt aber der von Dir angesprochene Man-in-the-middle und schreibt User und Passwort mit.

Das ist der Grund warum ich Daten und Passwort so verqirlen würde, dass man selbst beim mitschreiben damit nichts anfangen könnte. Das gehashte Passwort ist quasi der private-key, der nur Server und dem jeweiligen User bekannt ist und was bei meiner Lösung nie im Klartext übertragen wird. Ein Man-in-the-middle müßte das gehashte Passwort zurückübersetzen um es 1. benutzen und 2. an die Daten gelangen zu können.

Nochmal zu Verdeutlichung:
Client -> Passworthash x Daten = QuierledData
QierledData over http/https -> Server
Server -> QuierledData / Passworthash = Daten

Da die Daten verschlüsselt sind und auch der Passworthash nicht lesbar ist spielt es keine Rolle Daten per http oder https zu übertragen, wobei https die Sache für Angreifer erschwert. Ein Man-in-the-middle kann nur QuierledData mitschneiden, aber ohne Passworthash damit nix anfangen.

[hbauer]

Wäre ein Client-Zertifikate als sicherer Login-Ersatz nicht eine denkbare Lösung. (z.b. hier http://www.phpgangsta.de/client-zertifikate-als-sicherer-login-ersatz)

Ich hab das nicht durch gedacht aber das scheint mir ein Ansatz zu sein

Gruß

Hagen

[webald]

Das ist auf den ersten Blick eine einfache Lösung, aber dann muss ma für jeden Client ein Zertifikat ausstellen und hoffe, dass der Client sein Zertifikat auch sicher aufbewahrt.

Mein Ansatz soll vielmehr eine allgemeine Lösung zum Datenaustausch werden. Denkbarer Nutzen sind dann etwa die Anbindung des eigenen ERP/Fibu/Wawi aber auch die Übertragung von Bestellungen von Kunden aus deren System, Koppelung mehrerer Shops und ähnliches. Drittanbietersollen einen definierten Zugriff auf den Shop erhalten und eigene Lösungen entwickeln können ohne das wir am Shop etwas ändern müssen.

[hendrik]

Dein Gedankengang ist m.E. ok. So arbeiten auch Identifizierungsysteme im Internet. Über asymetrische Verschlüsselung wird ermittelt ob der Gegenüber im Besitz eines privaten Schlüssels ist. Die verschlüsselte Übertragung, anders als bei deinem Konzept, erfolgt dann über symmetrische Verschlüsselung deren Schlüssel vorher asymetrisch ausgehandelt und übertragen wird.

Gruß
Hen