Thema: Echtheitsüberprüfung 
Autor Deine Nachricht
 : Re: Echtheitsüberprüfung
BeitragVerfasst: Fr 9. Apr 2010, 03:34 
Offline
Profi User
Profi User
Benutzeravatar

Registriert: Mo 10. Aug 2009, 15:28
Beiträge: 653
Wohnort: Pirmasens
Bei der API könnte man die Passwort übertragung nach dem Challenge/Response prinzip machen.
Da gibt es zum Beispiel DIGEST-MD5. Das ist jetzt für dich vielleicht ne ecke kompliziert darum mach ich es mal simpel:

Szenario:
- Am Server ist ein Passwort und Benutzername gespeichert über das man zugriff auf die API hat.
- Ein Programm, welches im Besitz des Benutzernamens und des Passwortes ist (durch Benutzer eingegebekonfiguriert) möchte auf die API zugreifen.

Da HTTP Zustandslos ist, folgt auf jeder Anfrage immer eine Antwort, und es wird dann eine "neue unabhängige" Verbindung benötigt.
Der Ablauf erfolgt dann in etwa so:
  • 1)
  • Client: sendet eine Anfrage nach einer sogenannten "Challenge"
  • Server: antwortet mit einer "Challenge" die der Client angefragt hat, die einen Zufallsgenerierten String enthält und auch ein paar Cookies (oder etwas anderes mit dem der Client identifiziert werden kann), die ebenfalls zufällig generiert sind. Der Client muss diese Cookies dann natürlich bei jeder folgenden Anfrage mitsenden.
  • 2)
  • Client: erstellt einen Hash-wert aus der Kombination: md5(passwort.username.zufallsstring.eigenerzufallsstring) - wobei der "zufallsstring" der vom Server generierte ist. Und "eigenerzufallsstring" ist ein vom Client generierter Zufallsstring.
    Das was der Client dann als "Challenge-Response" zurück zum server sendet ist nur der generierte Hash-wert und der eigene Zufallsstring. (und natürlich die Cookies, separat vom rest).
  • Server: Der Server macht dann auf seiner Seite genau das selbe. Er nimmt das passwort und den usernamen, zusammen mit dem im vorherigen Abschnitt erstellten zufallsstring (den er irgendwo abgelegt hat) und den jetzt vom client gesendeten "eigenerzufallsstring" und erstellt den Hash-wert auf die gleiche Art und weise. Stimmen beide hash-werte überein, die vom Client gesendete und die vom Server eben erstellte, dann hat der Client zugriff zur Api.
    Das was der Server dann zurücksendet ist natürlich eine erfolgreiche Meldung, wenn alles geklappt hat, doer ein "403 unauthorized" oder so ;)

Das ganze Prinzip dient nur einem einzigen Zweck:
Damit das Passwort nicht im Klartext übertragen werden muss.

Die Zufallsstrings dienen als Salt. Auf diese Art und weise wird JEDESMAL ein anderer hash-wert übermittelt, wenn der Client sich einloggen will... selbst wenn man den übertragenen hash-wert irgendwie abfängt und ausliest, so kann man damit nichts anfangen, weil der für das nächste Login nicht mehr verwendet werden kann.
Das originale DIGEST-MD5 ist ein bisschen komplexer.

Wenn das Passwort mit md5 oder ähnlichem in der Datenbank abgelegt ist, ist das auch kein großes Problem, du musst dich quasi nur darauf einigen, dass der Hash dann bisschen anders auf der Client seite generiert wird z.b.: md5(md5(klartextpasswort).username.zufall1.zufall2)

und der server hat md5(klartextpasswort) ja schon, also muss er dort, wenn er das bereits gehashte passwort aus der datenbank nimmt: md5(hashedpasswort.username.zufall1.zufall2)

so ungefähr...

Falls du Fragen dazu hast, nur zu.

mfg Balmung

_________________
Bild


 
 Profil E-Mail senden