Userauthentifizierung ohne Cookie: wie?

Hallo Community.

Ich habe eine ASP:NET Anwendung mit der ich per Socket mit einer Software kommuniziere.
Dazu erstelle ich eine Login Seite auf der Name und Passwort eingegeben werden.
Diese Daten werden dann per Socket zur Anwendung gesendet und geprüft, ob der User in der Software existiert.
Das geht einwandfrei.

Jetzt sollte ich eben diesen User über viele ASP Seite hin identifizieren können.
Per Cookie möchte ich das nicht machen, da mir dieses zu unsicher erscheint.
Ich denke jeder kann heutzitage ein Cookie kopieren und auf nen anderen Rechner Transferrieren und schon kann er sich mit nem Fremden User anmelden.

Also Cookie und somit FormsAuthentication fällt flach.

Was gibts noch für Möglichkeiten?
Ich könnte eine globale Struktur verwalten und Name, Passwort dort eintragen. Dazu müsste ich dann eben diese Daten von Seite zu Seite weitergeben und jedesmal mit der Struktur abgleiche, ob as der User ist oder nicht...aber das erscheint mir unnötig kompliziert.

Wie macht "man" das denn so?

Grüße schuppsl

Hallo,
wenn du schon ASP.NET einsetzt, könntest du Profile benutzen
http://www.odetocode.com/articles/440.aspx

Hallo schuppsl

Es gibt nur Sessions oder Cookies und ggf. noch Windows Auth (Vorzugsweise im Intranet).
Siehe auch:

• zugangskontrolle für weitergeleitete seite (Grundlagen Session / Cookies)
• http://www.aspnetzone.de/forums/permalink/196767/196767/ShowThread.aspx#196767 (Gründe und Einsatz)
• http://www.aspnetzone.de/forums/permalink/63570/63573/ShowThread.aspx#63573 (Eine andere Erklärung der Techs)

Unsicher ist das nicht wirklich, da brauchts schon einigen Aufwand und schlechte Programmierung damit da was schiefgeht.
Grösstes Problem ist die unsichere Übertragung im Netz, da wäre SSL / https dein Stichwort.

@CB.NET
Profiles ist nur eine serverseitige API, die aber auch auf Cookies setzt.

Gruss Peter

Stichwort: 44 Worte

Der erste Link funktioniert nicht...

Hallo Schupps

Der erste Link funktioniert nicht...

Sorry, gefixt.

Gruss Peter

Ja aber Sessions funktionieren aber auch mit Cookies, also genau dasselbe.
Cookies sind zu einfach manipulierbar.

Profiles ist nicht machbar, da ich den User aus einer verschlüsselten Datei auslese.

Was gäbe es für alternativen?

Unsicher ist das nicht wirklich, da brauchts schon einigen Aufwand und schlechte Programmierung damit da was schiefgeht.

Ich stelle mir ein Büro vor indem ein Abteilungsleiter mehr Rechte in der Webanwendung als die Mitarbeiter hat.
Loggt sich der Abteilungsleiter ein, bekommt ein cookie, geht mal 3 minuten weg vom PC, der Mitarbeiter geht schnell hin, kopiert sich das Cookie auf seinen Rechner und schon hat er Zugriff als Abteilungsleiter.

Deswegen keine cookies.

nur so als frage. was für ein problem hast du mit dem cookie??

du musst ja nciht benutzername und passwort reinschreiben. reicht wenn du eine guid oder irgendeinen hash reinlegst, der nur für die aktuell laufende session gültig ist und wenn der user länger als sagen wir mal 30 minuten keine aktion durchgeführt hat, dann ist die hash/guid ungültig und muss sich nochmals anmelden.... was ist daran bitte unsicher? wenn du es zusätzlich mit der angemeldeten maschine verbinden willst dann lass in den generierten hash noch den computernamen oder ähnliches miteinfließen.

Hallo schuppsl

Ja aber Sessions funktionieren aber auch mit Cookies, also genau dasselbe.

Nein, dann hast du scheinbar meine Link nicht gelesen / verstanden.

Hast du die Geschichte mit den Cookies mal ausprobiert?
Du kannst die Mechanismen natürlich zusätzlich absichern, wie auch immer.

Bspw. die aktuelle IP auf dem Server zwischenspeichern und auf diese abfragen, etc...

Gruss Peter

Hallo schuppsl

Ja aber Sessions funktionieren aber auch mit Cookies, also genau dasselbe.
Nein, dann hast du scheinbar meine Link nicht gelesen / verstanden.

Gruss Peter

Aber das schreibst Du doch selbst:

Ein Session ist ein temporäres Cookie auf deinem PC,

Und wenn ich in dieser Session Daten vom Benutzer speichern will, wird das sehr wol in einem Cookie gespeichert...

Und wenn ich in dieser Session Daten vom Benutzer speichern will, wird das sehr wol in einem Cookie gespeichert... nein, nur die SessionID wird in einer Art temporärem Cookie beim Client gespeichert. Die eigentlichen Daten bleiben auf dem Server.

Aber um die Daten zuzuordnen muss aus dem -wenn auch temporären- cookie die SessID ausgelesen werden.
Wird die SessID manipuliert, bzw. auf einen anderen PC übertragen und dort als cookie gespeichert, hat der User alle Daten...und eben im schlimmsten Fall kann er sich dann als Admin einloggen, da er ja die Sess ID hat...

Hallo schuppsl

Nicht "hat er alle Daten", sondern er hat die Identität.
Darum gibt es auch noch Tricks, dies zu vermindern (Und einfach ist ein Session Hijacking wahrlich auch nicht).

In der IT ist nichts wirklich sicher, aber zumindest so sicher wie es geht.

Gruss Peter

Welche "Tricks"wären denn das?

Ja, er hat die Identität und auch somit die Daten die an diese Indentität gekoppelt sind.
Klar ist alles irgendwie unsicher, ich möchte mir eben auch sicher sein, daß ichs richtig verstanden habe und dann entsprechend programmieren kann.

Der Angreifer muss ja das Cookie klauen so lange die Session noch gültig ist.

Eine alternative wäre, wie bereits oben beschrieben, die IP auszulesen und an die SessID koppeln, aber da weiß ich nicht., ob das bei jedem Linux oder Mac OS geht, da diese OS'ses Clientseitig durchaus zum Einsatzgbebiet kommen werden...

Aber um die Daten zuzuordnen muss aus dem -wenn auch temporären- cookie die SessID ausgelesen werden. das ist logisch, ja.
Wird die SessID manipuliert, bzw. auf einen anderen PC übertragen und dort als cookie gespeichert, hat der User alle Daten...und eben im schlimmsten Fall kann er sich dann als Admin einloggen, da er ja die Sess ID hat... es ist sehr schwierig, eine SessionID zu klauen und noch schwieriger sie auf einen andernen Rechner zu übertragen, geschweige denn seinem WebClient die fremde SessionID unter zu jubeln. Du muss bedenken, dass eine Session standardmäßig 20 Minuten nach der letzten Useraktivität abläuft oder wenn der Benutzer das Browerfenster schließt. Temporäre Cookies und SessionIDs werden vom Browser nur im Arbeitsspeicher gehalten und nicht wie normale Cookies als Textdatei auf der Platte abgelegt. Das klauen von Sessions geht also IMHO nur per eingeschläustem Code (JavaScript und/oder Bilder) auf der Webseite. Und das ist schon knifflig genug...

Temporäre Cookies und SessionIDs werden vom Browser nur im Arbeitsspeicher gehalten und nicht wie normale Cookies als Textdatei auf der Platte abgelegt.

Wenn ich aber eine neue Session per Session.Add anlege, wird da ein Cookie als Textdatei angelegt...

Eine SessID kann man somit ganz leicht auslesen, zumindest kann ich in jedem Browser die SessID ansehen.
Diese kann ich mir zb. aufschreiben, falls der Chefe mal schnell vom PC weg ich (und noch eingeloggt ist) und mir ein eigenes Cookie mit der SessID anlegen.
Diese Session wäre ja dann noch nicht abgelaufen...würde so etwas gehen?

Wenn ich aber eine neue Session per Session.Add anlege, wird da ein Cookie als Textdatei angelegt... Tatsächlich? Welcher Browser und Version? Was steht drinn in der Datei?

Eine SessID kann man somit ganz leicht auslesen, zumindest kann ich in jedem Browser die SessID ansehen.
Diese kann ich mir zb. aufschreiben, falls der Chefe mal schnell vom PC weg ich (und noch eingeloggt ist) und mir ein eigenes Cookie mit der SessID anlegen.
Diese Session wäre ja dann noch nicht abgelaufen...würde so etwas gehen? probiers mal aus, das würd mich mal interessieren. nicht mit dem Cookie vom Chef, aber evtl. mit dem vom Arbeitskollegen.

Das steht drin:
Name ASP.NET_SessionId
Value: dicikjezkepf3454n0vf45...
Host: Localhost
...
Secure: no
Expires: end of Session

Werds mal ausprobieren.

Also ich habs nun getestet, zumindest wenn ich die SessID über die URL transferiere.
Kopiere ich die SessID auf einen anderen PC/Browser werden mir die gespeicherten Daten,in diesem Fall der Name angezeigt.
Somit würden auch eventuelle Berechtigungen die ich diesem User zuweise übertragen werden.

Wenn ich aber eine neue Session per Session.Add anlege, wird da ein Cookie als Textdatei angelegt... Also ich hab das ebenfalls gerade ausprobiert. und es wird kein Cookie gespeichert, weder im Verzeichnis Cookies, noch im Tempordner des IE...ich gehe dem heute Abend mal nach, dann hab ich mehr Zeit

Also ich habs nun getestet, zumindest wenn ich die SessID über die URL transferiere.
Kopiere ich die SessID auf einen anderen PC/Browser werden mir die gespeicherten Daten,in diesem Fall der Name angezeigt.
Somit würden auch eventuelle Berechtigungen die ich diesem User zuweise übertragen werden. autsch, das ist böse.
Der Bösewicht muss in dem Fall aber immernoch zugriff auf den Rechner haben...

autsch, das ist böse.
Der Bösewicht muss in dem Fall aber immernoch zugriff auf den Rechner haben...

Ja das muss er.
Das Ganze wird ja auch noch mit Name/Passwort gesichert, aber wenn der böse Mann mal schnell an Chefs Rechner geht, kann das locker ausgehebelt werden.
Der Chef ist dann natürlich selbst Schuld, wenn er die Anwendung nicht beendet.

Ich denke, am Besten wirds sein, die SessID an Request.UserHostAdress zu koppeln.
Aber ist dann natürlich auch leicht manipulierbar.

Salute zusammen

@schuppsl
Browser?
Version?

Gruss Peter

FF,der aktuellste und IE7 auf Win XP Prof.
Aber kann es sein, daß generell eine Sess.ID erzeugt wird, unabhängig von Session.Add?
Ich denke das wird der Fall sein.

Aber kann es sein, daß generell eine Sess.ID erzeugt wird, unabhängig von Session.Add?
Ich denke das wird der Fall sein. jep, das ist standartmäßig so.

Diese kann ich mir zb. aufschreiben, falls der Chefe mal schnell vom PC weg ich (und noch eingeloggt ist) und mir ein eigenes Cookie mit der SessID anlegen.

1. kann ich mir gut vorstellen, dass das deine letzte Aktivität für diese Firma war wenn man es herausbekommt.
2. gibt es genau für diese Situationen, in denen Algorithmen und Co. nicht mehr greifen können, Datenschutzbestimmungen, die in jeder Firma die mit IT zu tun hat eigentlich Pflicht sind. Dein Chef handelt in dem Moment sehr wahrscheinlich gegen diese Bestimmungen. Gerade das Sichern des eigenen Arbeitsplatzes wurde bei meinem letzten Arbeitgeber sehr groß geschrieben.

Diese kann ich mir zb. aufschreiben, falls der Chefe mal schnell vom PC weg ich (und noch eingeloggt ist) und mir ein eigenes Cookie mit der SessID anlegen.

1. kann ich mir gut vorstellen, dass das deine letzte Aktivität für diese Firma war wenn man es herausbekommt.
   2

Warum? Prinzipiell kann ich genau dafür nichts, da ist der Chefe selbst schuld.

Also ich habs nochmal getestet.
Kopiere ich mir die URL und gehe auf einen anderen Rechner, geht es nicht, es kommt die Meldung "Verbindung fehlgeschlagen".

Also scheint ASP.NET diese Sicherheit irgendwie mit eingebaut zu haben, oder woran liegt das.
Ohne die SessID kann ich die Anwendung natürlich aufrufen...

evtl bindet er die sessionid intern an die ip des clients?

Warum? Prinzipiell kann ich genau dafür nichts, da ist der Chefe selbst schuld.

Hehe, das ist ja geil.
Wenn mein Chef das nächste mal den Autoschlüssel auf seinem Tisch liegen lässt und kurz auf Toilette geht werd ich mal ne Spritztour machen und die Karre dann verkloppen. Ist er ja selbst schuld wenn er ihn liegen lässt.

Oder anders gesagt ist er dran zu kriegen wenn daraus resultierend die Firma darunter leidet. Aber du glaubst doch nicht wirklich, dass du deinen Arbeitsplatz behältst wenn du Daten vom Rechner des Chefs klaust.

btw hab ich vor Kurzem gehört das jemandem gekündigt wurde, weil er eine Portion Nudeln aus dem Kühlschrank gegessen hat.

du kannst doch in der session vom httprequest den dns namen und die ip der clientmaschine speichern und bei jedem aufruf überprüfen (obwohl ich glaube das das asp intern auch macht) und schon kann man mit dem cookie auf einem anderen rechner ncihts mehr anfangen.

Warum? Prinzipiell kann ich genau dafür nichts, da ist der Chefe selbst schuld.
Aber du glaubst doch nicht wirklich, dass du deinen Arbeitsplatz behältst wenn du Daten vom Rechner des Chefs klaust.

Nein natürlich nicht, ich hatte das Ganze jetzt aus der Sicht des ASP-Programmierers gesehen, nicht vom "Bösesicht".

ich habs nochmal genau getestet, es geht auch von einem anderen PC aus, wenn die Session ID kopiert wird.
Ich hatte lediglich vergessen, das localhost gegen die IP meines Rechners auszutauschen.

Also es geht ganz einfach indem man die Sess ID kopiert, bzw. irgendwie auf nen anderen Rechner bringt.

du kannst doch in der session vom httprequest den dns namen und die ip der clientmaschine speichern und bei jedem aufruf überprüfen (obwohl ich glaube das das asp intern auch macht) und schon kann man mit dem cookie auf einem anderen rechner ncihts mehr anfangen.

Ja, genau das wäre eine vorhin genannte Vorgehensweise.
Wird denn die IP immer ausgelesen oder gibts da irgendwelche Beschränkungen, zb. wenn ich die "NoScript" Erweiterung aktiviere, Javascript oder sonstwas deaktiviere im Browser?
Geht das auf jedem Linux/Mac OS System?

Müsste man mal testen...

wenn du die ip serverseitig nicht hast dann kannst du auch kein response senden. ich denke das ist unabhängig vom os/script/noscript/browser ^^

Salute zusammen

Genau, die IP muss bekannt sein (ggf. Hostname der dann aufgelöst wird). Ansonsten kann ja nichts "irgendwohin" geschickt werden 🙂
Sie ist auch immer bekannt, denn bekanntlich kommt vor einer Antwort immer eine Anfrage. Und anonym gehts im Internet ja auch nicht.

Gruss Peter

Ja da habt Ihr wohl recht...so werde ichs machen.

Hallo zusammen,

auch wenn dieser Thread schon etwas älter ist, hier noch ein Phänomen das wir mal hatten.

ASP.Net 1.1 Applikation, Session über URL.

Diese URL (mit Session) wurde dann von dritter Seite verlinkt. Das irritierende daran war, dass bei einem Klick auf diesen Link auf dem Server eine Session erzeugt wurde und diese die in der URL angegebene Session-ID bekam. Wenn bereits diese ID zu einer Session gehörte, so hat der Server tatsächlich den jeweils anderen Client als berechtigt bzw. Session-Eigner angesehen. Hierdurch kam also nur durch eine falsche Verlinkung(!) ein Session-Hijacking zustande.

Was man dagegen tun kann ist ja weiter oben schon beschrieben.

🙂

Xynratron