User Authentifizieren

S

Sancheck

Legendäres Mitglied
Hallo,

ich habe folgendes Problem:
Ich habe einen mobile Client, der einen Server anspricht (per HTTP Request). Nun will ich aber sicherstellen, dass nur bei diesem Client auf die Befehle reagiert wird.

Der Client ist ein Handy.

Nun eine Idee:
Der Client loggt sich ein.
Der Server sendet dem Client einen TAN per SMS (das authentifiziert den Client).
Der Client tippt den TAN ab und sendet zukuenftig alle befehle des heutigen Tages mit diesem TAN als MD5 Hash.
md5(Befehl+Hash)

Der Server erstellt sich eine MD5 Hashtabelle mit den Befehlen und den TANS. Das sind nur wenige Befehle (20).
Diese vergleicht er dann mit dem gesendeten Hash.


Wer hat eine einfachere Idee?

SSL geht nicht!
 
Ich verstehe den Sinn nicht.

Wenn es eine Authentifizierung und ein Login gibt, dann gibt es normalerweise auch eine Session-Logik, also clientseitig ein Session-Cookie und serverseitig ein Nachverfolgen.

Damit kann das erfolgreiche Login in der serverseitigen Sessionverwaltung hinterlegt werden und wird dann - ausschließlich serverseitig - genutzt, um über mögliche Berechtigungen des Clients zu entscheiden.


Wenn die Session abgehört werden kann, dann kann auch ein zusätzlich mitgeschickter Wert abgehört werden.

Sprich: Ich sehe keinen Sicherheitsgewinn, stattdessen eine unnötige zusätzliche Logik.
 
Hallo,
das mit der Session ist mir schon klar. Aber wodurch erkennt ein Server eine derartige Session?
Ich habe einen Server der nichts unterstuetzt. Das ist auch Absicht. Es handelt sich hierbei um einen Mikrocontroller. Wird eine Session an der angeforderten IP erkannt?
Weil dann koennte durchaus ein Hacker die fremde IP vortaeuschen, und mithilfe der IP eine Interatkion auf dem Server ausfuehren. Er hat dann nicht das Ziel an Daten zu kommen sondern z.b. eine anlage zu steuern.

mfg
 
Nein, eine Session wird an einer nur für diese Session generierter SessionID erkannt, die entweder in einem Cookie oder mit der URL übergeben wird.

Also genau das, was du vorhast. Nur das es für das Erstellen und Handling einer Session schon existierende Befehlssätze gibt und nicht alles neu erfunden werden muss.
 
Hallo TSC;
das ist mir durchaus bekannt. Habe bereits php applikationen mit sessions entwickelt. Aufgrund der Anwendung ist es nun aber noetig auf das ganze zu verzichten und das minimal zu mimplementieren.

Bzgl. SessioNID. Wenn nun ein Hacker die Session ID selbst aussendet so kann er auch befehle ausufuehren.

lg
 
Wie soll er das machen?
Um an eine auf dem Server registrierte SessionID zu kommen müßte er eine Man-in-the-Middle-attacke auf eine existierende Session fahren - davor schützt dich dein Verfahren aber auch nicht.

Im Prinzip besteht kein Unterschied zwischen deinem Verfahren eine ID an die URL zu hängen und einer SessionID die an der URL hängt.

 
QUOTE (Sancheck @ Di 13.10.2009, 22:44)Aber wodurch erkennt ein Server eine derartige Session?


Entweder am Cookie oder an einem Zufallsausdruck in der Url - also genau an dem, was Du manuell implementieren willst.


QUOTE (Sancheck @ Di 13.10.2009, 22:44)Ich habe einen Server der nichts unterstuetzt. Das ist auch Absicht. Es handelt sich hierbei um einen Mikrocontroller. Wird eine Session an der angeforderten IP erkannt?
Weil dann koennte durchaus ein Hacker die fremde IP vortaeuschen, und mithilfe der IP eine Interatkion auf dem Server ausfuehren. Er hat dann nicht das Ziel an Daten zu kommen sondern z.b. eine anlage zu steuern.


Das muß doch irgendein Http-Dienst sein. Wenn das ein selbst geschriebener .NET - Http-Dienst ist, dann dürfte es einfacher sein, diesen um die offizielle Session-Logik innerhalb von .NET zu ergänzen.

Ansonsten muß man das halt per Hand durchpfriemeln: Der Webserver hängt an jeden Link einen Ausdruck id=Zufallsvariable ran und verwaltet eine Tabelle mit Zuordnungen Zufallsvariablen - Nutzer.

Eine IP ist ungünstig. Du weißt nie, was für Pooling-Logiken oder ob eine entsprechende Firewall aktiv ist, die verschiedene interne Nutzer auf eine externe IP abbildet. Und die Sessionvariablen dürfen natürlich nicht erratbar sein - GUIDs eignen sich da immer gut dazu (also 36 Zeichen lange Zufallsausdrücke).

PS: Möglich ist das schon. Ich hatte bei der Entwicklung von Server-Daten mal eine Weile so ein Modell genutzt. Irgendwann habe ich das dann rausgeschmissen und stattdessen Cookies als Pflicht erklärt. Es macht einfach nur wenig Sinn, Links ständig so zu verunstalten.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben