Zugangskontrolle mit Cookies ?

[Steffen]

Hi,

ich habe folgendes Problem:

Ein Perl-Script soll seine Ausgaben nur nach einer Prüfung der Zugangsberechtigung senden. Die Sache ist für eine Intranetanwendung und der Zugang soll nur von bestimmten _Rechner_ aus möglich sein.

Eigentlich ein Fall für .htaccess , aber:
Neulich besuchte der Sohnemann eine an diesem Rechner arbeitende Mitarbeiterin, schaute ihr beim Kennwort eingeben über die Schulter und logte sich dann zuhause selbst ein. Es ist zwar nicht passiert aber generell stellt so etwas (wie übrigens auch die Klebezetteln mit der Passwörtern am Monitorrand ;-)) doch eine Gefahr dar.

Das brachte mich auf folgende Gedanken:
Das beste (einzige ?) Mittel dagegen, dass ein Mitarbeiter ein Passwort verraten / mißbrauchen _kann_ ist doch, dass er es garnicht kennt.
Dazu müßte die Zugangsberechtigung auf den entsprechenden Rechner definiert sein.
Ich dachte jetzt an ein Cookie, dass man auf dem Rechner setzt (das wäre in meinem Fall einfach möglich, da es nur ein paar wenige Rechner sind und ich an alle persönlich ran kann).
Das aufgerufene Script prüft auf das entsprechenden Cookie, wenn's auf dem Cient Rechner gefunden wird, wird der gewünschte Ihnhalt ausgegeben, wenn nicht, eben 'ne einfache, harmlose HTML Seite.
Ein "knacken" von außen (übers Internet) wäre dann doch kaum möglich (außer durch brut force mit allen möglichen Cookienamen / -inhalten ?!?).
Wäre noch die Möglichkeit, dass sich jemand an den berechtigten Rechnern die Cookies anschaut und auf einen anderen kopiert.
Diese Gefahr wäre in meinem speziellem Fall aber kaum gegeben.

Was haltet ihr davon ?

Gruß
Steffen

[Christian Kruse]

Hoi,

Ein Perl-Script soll seine Ausgaben nur nach einer Prüfung der
Zugangsberechtigung senden. Die Sache ist für eine
Intranetanwendung und der Zugang soll nur von bestimmten
_Rechner_ aus möglich sein.

[... abluchsen eines Passworts ...]

Das beste (einzige ?) Mittel dagegen, dass ein Mitarbeiter ein
Passwort verraten / mißbrauchen _kann_ ist doch, dass er es
garnicht kennt.

Du solltest deinen Mitarbeitern vielleicht ein gewisses Mass an
Vertrauen entgegen bringen.

Ich dachte jetzt an ein Cookie, dass man auf dem Rechner setzt
(das wäre in meinem Fall einfach möglich, da es nur ein paar
wenige Rechner sind und ich an alle persönlich ran kann).
Das aufgerufene Script prüft auf das entsprechenden Cookie,
wenn's auf dem Cient Rechner gefunden wird, wird der gewünschte
Ihnhalt ausgegeben, wenn nicht, eben 'ne einfache, harmlose HTML
Seite.

Dann nehme ich mir eine Diskette und speichere die Cookies darauf ab.

Was haltet ihr davon ?

Nicht viel. Sinnvoller waere eine <Limit>- und Auth-Mischung.
Per Limit nur von bestimmten IPs erlauben und per Auth zusaetzlich
nochmal die Passwoerter anfordern. Ausserdem solltest du Passwoerter
nehmen, die nicht so  leicht erraten/mitgeschrieben werden koennen.

Ansonsten hilft nur Aufklaerung. Sprich mit den Mitarbeitern und mach
ihnen begreiflich, wie wichtig es ist, dass sie darauf achten, dass
kein anderer an das Passwort kommen kann.

Gruesse,
 CK

[Steffen]

Hi,

Das beste (einzige ?) Mittel dagegen, dass ein Mitarbeiter ein
Passwort verraten / mißbrauchen _kann_ ist doch, dass er es
garnicht kennt.

Du solltest deinen Mitarbeitern vielleicht ein gewisses Mass an
Vertrauen entgegen bringen.

[1] Das ist die Theorie, schön. Aber die Praxis ist leider nicht ganz so.

Nicht viel. Sinnvoller waere eine <Limit>- und Auth-Mischung.
Per Limit nur von bestimmten IPs erlauben und per Auth zusaetzlich
nochmal die Passwoerter anfordern.

Bei einem Zugriff mitdynamisch vergebenen IP's geht das nicht.

Ausserdem solltest du Passwoerter
nehmen, die nicht so  leicht erraten/mitgeschrieben werden koennen.

siehe [1], leider.

Ansonsten hilft nur Aufklaerung. Sprich mit den Mitarbeitern und mach
ihnen begreiflich, wie wichtig es ist, dass sie darauf achten, dass
kein anderer an das Passwort kommen kann.

siehe [1], leider.

Gruesse,
Steffen

[Christian Kruse]

Hoi,

Du solltest deinen Mitarbeitern vielleicht ein gewisses Mass an
Vertrauen entgegen bringen.
[1] Das ist die Theorie, schön. Aber die Praxis ist leider nicht
ganz so.

Dann solltest du dir ueberlegen, ob du nicht ein paar Mitarbeiter
auswechseln moechtest (wenn es in deiner Macht liegt) oder die Firma
wechseln moechtest. Ich fuer meinen Teil kann meinen Mitarbeitern
vertrauen.

Nicht viel. Sinnvoller waere eine <Limit>- und Auth-Mischung.
Per Limit nur von bestimmten IPs erlauben und per Auth zusaetzlich
nochmal die Passwoerter anfordern.
Bei einem Zugriff mitdynamisch vergebenen IP's geht das nicht.

Natuerlich geht das. Man kann auch IP-Bereiche zulassen.

Ausserdem solltest du Passwoerter
nehmen, die nicht so  leicht erraten/mitgeschrieben werden koennen.
siehe [1], leider.

Was hat das eine mit dem anderen zu tun?

Gruesse,
 CK

[Steffen]

Hi,

Du solltest deinen Mitarbeitern vielleicht ein gewisses Mass an
Vertrauen entgegen bringen.
[1] Das ist die Theorie, schön. Aber die Praxis ist leider nicht
ganz so.

Dann solltest du dir ueberlegen, ob du nicht ein paar Mitarbeiter
auswechseln moechtest (wenn es in deiner Macht liegt) oder die Firma
wechseln moechtest. Ich fuer meinen Teil kann meinen Mitarbeitern
vertrauen.

Verstehe mich bitte nicht falsch. Ich behaupte nicht, dass meinen Mitarbeiter nicht zu trauen wäre. Ein Passwort kann aber z.B. auch durch unauffälliges über die Schulter schauen in die falsche Hände gelangen.
Mit dem Aufklären und informieren ist das auch so eine Sache. Natürlich wird das auch in unsrere Firma gemacht, aber sei doch mal ehrlich, geht's im praktischen Leben nicht oft anders zu als in der schönen Theorie.
Wer achtet wirklich immer darauf, dass beim eingeben von Passwörtern / Pin's niemand zusieht. Geh' mal an die Tankstellen- oder Supermarktkasse.

Ausserdem solltest du Passwoerter
nehmen, die nicht so  leicht erraten/mitgeschrieben werden koennen.

Bei Kryptische Benutzernamen / Passwörter neigen manche Leute gerade dazu, sich diese auf zu schreiben.

Mir gehr es eigentlich auch mehr um die Frage, ob bzw. wie man so eine "Cookie-Zugangskontrolle" von außen knacken könnte.

Gruß

Steffen

[Ed X]

Hi,

Ok, ausgehend von deinem ersten Posting, dass ein Zugang immer nur von
einem Rechner gehen soll, würde ich Passwort vom Standpunkt trennen.

Also der erste Zugriff erfolgt von "dem einen Rechner", daraufhin sendet
das Perlscript einen Cookie (expires sonstewann; path auf die eine Seite
begrenzt), der Rechner sendet bei jeder Authentification seinen Cookie,
das script erkennt ihn daran. Sollte später ein Rechner ohne Cookie auf
das script zuzugreifen, bekommt er auf die Finger. Dieser ganze Prozess
erfolgt unabhängig von der Auth per Passwort. Bedenke bitte das es ein
Gehöriger Verwaltungsaufwand ist, und btw. 100% Sicherheit is nich!

bye eddie

[Steffen]

Hi,

Also der erste Zugriff erfolgt von "dem einen Rechner", daraufhin sendet
das Perlscript einen Cookie (expires sonstewann; path auf die eine Seite
begrenzt), der Rechner sendet bei jeder Authentification seinen Cookie,
das script erkennt ihn daran. Sollte später ein Rechner ohne Cookie auf
das script zuzugreifen, bekommt er auf die Finger. Dieser ganze Prozess
erfolgt unabhängig von der Auth per Passwort.

Ich habe mir das so vorgestellt, dass ich ein weiteres Script schreibe, dass ich z.B. so aufrufe:

http://www.meinServer.de/cgi-bin/setzeCookie.pl?name=DasPasswortCookie&wert=DasPasswort&expires=sonstwann

Ich gehe dann einmal an den "erlaubten" Rechner, setzte das Cookie, (lösche die History ;-)) und dann kann _jeder_ von _diesem_ Rechner aus zugreifen und keiner (außer ich) kann dass Passwort verraten, verschludern, vergessen...

Gehöriger Verwaltungsaufwand

eigentlich nicht, sind nur vier, fünf Rechner.

btw. 100% Sicherheit is nich!

Das wird wohl immer so sein.

Fällt jemanden etwas ein, wie man so etwas von "außen", also nicht am Rechner selbst sonder nur durch Zugriff auf den Server per Internet knacken könnte.
Das ich in dieser Richtung eine Lücke in meiner Gedankenkette habe, ist meine größte Sorge (bei dieser Sache). Die Möglichkeit, dass jemand das Cookie per Diskette "klaut" ist in meinem Fall eher unwahrscheinlich.

Gruß

Steffen

[Ed X]

Hi,

Ich gehe dann einmal an den "erlaubten" Rechner, setzte das Cookie, (lösche die History ;-)) und dann kann _jeder_ von _diesem_ Rechner aus zugreifen und keiner (außer ich) kann dass Passwort verraten, verschludern, vergessen...

Es ist und bleibt unsicher. Szenario:
ein Mitarbeiter ist dochmal "privat" unterwegs gewesen und will seine
Spuren verwischen, wenn er einigermaßen Helle ist, löscht er die
Historie und die Cookies. Und du fängst von vorne an.

Und nur du kennst das Passwort? Vergiss es! Nehme mozilla -> Einstellungen ->
Privacy.. -> Cookies -> view stored cookies und voilà

du kannst natürlich auch eine JS-basierte Hashfunktion einbinden :-)

Alles in allem glaube ich ist es noch sicherer die in einigen Browsern
vorhandenen "Felder vorbelegen"-Funktion zu benutzen.

Fällt jemanden etwas ein, wie man so etwas von "außen", also nicht am Rechner selbst sondern nur durch Zugriff auf den Server per Internet knacken könnte.

Zugriff von Außen ist eigentlich ausgeschlossen, aber die sache bleibt
an sich wackelig. Abgesehen, davon, dass du deinen Mitarbeitern
erklären musst, dass du ihnen das Passwort nicht sagst, d.h. ihnen
nicht vertraust, was sich ganz exzellent auf das Betriebsklima
auswirkt :-(
Und mal hochgerechnet bei 4-5 Rechnern sollte es nur kurz dauern, die
paar Leute aufzuklären, das ist allemal besser.

bye eddie

[Henryk Plötz]

Moin

Hmm, alles in allem glaube ich die amtliche Lösung wäre den Zugriff mit SSL zu machen, jedem Rechner ein Client-Zertifikat auszustellen und das Skript dieses dann überprüfen zu lassen. Das Zertifikat sollte zwar verschlüsselt abgelegt werden, aber dieses Passwort alleine reicht ja dann zum Zugang noch nicht. Sohnemann müsste immerhin noch die Schlüsseldatei mit nach Hause nehmen. Ausserdem: Sobald ein Sicherheitsverstoß bekannt wird, kann man den betroffenenen Schlüssel im Server als ungültig definieren.
Noch amtlicher wird es, wenn der Schlüssel auf Chipkarte oder so 'nem USB-Dingens liegt und jeder Mitarbeiter seinen Schlüssel mit sich rumträgt.

Aber vielleicht bin ich ja doch zu paranoid... :)

Es sollte hier eine Kombination aus IP und Passwort ausreichen. D.h. du nimmst das Passwort wie bisher (kann auch ruhig halb-schwach sein) und erlaubst darüberhinaus keinen Zugriff von der Internetseite. Wenn deine Firewall dann noch gut konfiguriert ist und keinen Einbruch zulässt und gespoofte Pakete wegwirft, dürftest du ziemlich gut fahren.

--
Henryk Plötz
Grüße aus Berlin

[AlexBausW]

Hallo

Wenn Du es für eine Intranetlösung brauchst, dann kannst Du die Zugriffe auch auf einige IPs beschränken:
z.B.: beim Apachen:

order deny,allow
deny from all
allow from 123.45.213

Gerade in einem Intranet sollte die Anzahl zur Verfügung stehender IPs bzw. der entsprechende Bereich überschaubar sein.
Wenn eure Firewall allerdings Zugriffe von außen auf den Server zulässt, wo sogar intern nur bestimmte User mit Passwort rankommen, dann habt ihr imho ein ganz anderes Problem. ;)

Gruß Alex
--
http://www.google.de/search?hl=de&safe=off&q=Rechtschreibung+Standart

[Michael Schröpl]

Hi Steffen,

Ein Passwort kann aber z.B. auch durch unauffälliges über die Schulter
schauen in die falsche Hände gelangen.

ich halte Deine Bedenken unter bestimmten Randbedingungen für
nachvollziehbar - nämlich genau dann, wenn in Deinem Betrieb einige
Mitarbeiter höhere Sicherheitsstandards zu erfüllen haben als andere,
aber nicht aufgrund sonstiger Randbedingungen (z. B. eigenes Zimmer,
wo man ihnen beim Login nicht über die Schulter sehen könnte) ent-
sprechend bevorteilt werden.

Genau dafür aber wäre dann der vollständige Verzicht auf ein Passwort
(auch Dein Cookie liefert ja ein solches) und statt dessen die Verwendung
von IP-Adressen sinnvoller. (Und auch komfortabler für die Anwender.)

Von dynamischen IP-Adressen in einem Intranet halte ich nicht so arg viel;
wenn ihr das einsetzen müßt (weil ihr nicht genügend eigenen IP-Space be-
sitzt), dann könnt ihr aber immer noch separate Pools bilden, also die
unterschiedlichen Sicherheitsklassen von Mitarbeitern in disjunkte IP-
Subräume abbilden.
Und dann greift die IP-basierte Server-Authentifizierung wieder.

Bei Kryptische Benutzernamen / Passwörter neigen manche Leute gerade
dazu, sich diese auf zu schreiben.

Das hat etwas für sich. Aber gerade deshalb ist eine Authentifizierung,
die ganz ohne Kennworte auskommt, sinnvoll.

Mir gehr es eigentlich auch mehr um die Frage, ob bzw. wie man so eine
"Cookie-Zugangskontrolle" von außen knacken könnte.

Dazu müßtest Du genauer beschreiben, was Du mit "von außen" meinst.

Ein Sicherheitskonzept ist immer eine Art Versicherung. Diese bezieht sich
aber auf konkrete "Schadensfälle", in Deinem Fall also konkrete Angriffs-
versuche. Ein Angriff über das Netz ist etwas Anderes als ein physischer
Zugriff auf die Tastatur des Client-Systems; einige Aspekte sind zudem nur
im Zusammenhang mit der eingesetzten Software im Detail zu beantworten.

Konkret der Cookie läßt sich bei jedem Browser irgendwie ansehen - man muß
zwar wissen, wo er gespeichert wird, das findet ein Angreifer aber via
Google mühelos heraus.

Viele Grüße
      Michael

[Stefan Muenz]

Hallo Steffen,

wenn du auf Passwoerter verzichten willst und eine rechner-basierte Authentifizierung willst, solltest du auf jeden Fall eher sicherstellen, dass sich die Rechner mit festen IPs einloggen (Michael hat ja einiges dazu gesagt). Dann kannst du, wie von Christian beschrieben, mit der limit-Direktive in der htaccess-Datei genau auf die erlaubten IPs begrenzen.

Um noch weiter zu gehen, koenntest du dann auf der Startseite hinterm erfolgreich bestandenen htaccess noch ein Formular schalten, dass eine "Session-Nummer" abfragt. Solche Session-Nummern muessten genauso erzeugt, verwaltet und an die authorisierten User ausgegeben werden wie TANs beim Online-Banking. Jeder authentifizierte User koennte einen nackten Ausdruck mit z.B. 100 12stelligen, per Zufall ermittelten Session-Nummern erhalten. Bei jedem Login muss er eine davon angeben, die damit auch verbraucht (vom verarbeitenden Script geloescht) wird. Sind alle 100 verbraucht, wird das durch die vielen Sicherheitsvorkehrungen getruebte Betriebsklima dadurch aufgelockert, dass der User zu einem Schwatz vorbei kommt, um sich neue Session-Nummern abzuholen ;-)

Fuer die Aufbewahrung der Zettel mit den Session-Nummern sollte die Firma naturlich Panzerschraenke installieren, denen auch hereinfliegende Jets nichts anhaben koennen! Dann ist alles wunderbar, und die Sicherheit hat triumphiert ;-)

viele Gruesse
  Stefan