Überlegung zum Passwortschutz beim Webserver

[Robikon]

Hallo,

so wie ich es verstanden habe, bietet der eibPC bislang keinen Passwortschutz was die Benutzeroberfläche des Webservers betrifft. Ein solches Feature soll, wie ich es verstanden habe, in Zukunft mal folgen. Im Folgenden habe ich mal meine Überlegungen aufgeführt, wie man einen solchen Schutz etwas differenzieren könnte.

Generell könnte man eine Sperrung vielleicht 2-stufig ausführen: Erstens keine Erlaubnis zur Änderung eines Werts, aber der aktuelle Werte wird anzeigt. Zweitens keine Erlaubnis zur Änderung und auch kein Anzeigen des aktuellen Status.

Eine Überlegung wäre außerdem, dass man nicht nur ganze Seiten mit Passwort sperren kann (z.B. Seite der Heizungsregelung), sondern auch nur einzelne Webicons (z.B. Aquarium-Licht im Wohnzimmer). Diese Sperrung könnte man eventuell durch ein zusätzliches Webicon-Argument (z.B. protected) realisieren. Dieser Webicon-Sperrung könnte man vielleicht auch 2-stufig (s.o.) ausführen.

Eventuell ist es auch möglich, dass das Passwort den Webserver für eine vorgegebene Zeit (z.B. 2 Minuten) oder bis zu einer bestimmten Dauer von Untätigkeit (z.B. 30 Sekunden) komplett entsperrt. Das würde verhindern, dass ein Benutzer bei vielen geschützten Bereichen jedes Mal wieder ein Passwort eintippen müsste.

Was meint Ihr?

[salixer]

Nun, das hört sich natürlich erstmal gut an. Allerdings sollte dabei auch klar sein, dass das umfangreiche Änderungen nötig macht, die nicht mal auf die schnelle eingebaut sind. Vor allem, da es sich dabei ja um sicherheitsrelevante Funktionen handelt.

[Robikon]

Danke für die rasche Antwort. Keine Sorge, ich erwarte keine Wunder *g*

Für mich sind es erstmal lediglich Überlegungen, die mir persönlich aber nicht unter den Nägel brennen.

[Tessi]

Ich würde ein System mit mehreren Gruppen vorschlagen, wie es moderne Filesysteme handhaben. Mit Eingabe eines Passwortes hat man dann die Freigaben einer oder mehrerer Gruppen. Für jede Seite kann dann festgelegt werden, von welchen Gruppen sie aufgerufen werden kann, für einzelne Elemente kann festgelegt werden, welche Gruppen sie angezeigt bekommen und welche Gruppen sie verändern können. Je nach Gruppe bekommt man also gar nicht erst alles zu sehen.

Als einfachste Implementierung würde ich vorschlagen, es gibt 32 Gruppen und jedes Element bekommt zusätzlich einen 32-Bit Wert, in dem bitweise codiert ist, welche Gruppen es lesen kann und änderbare Elemente haben zusätzlich einen zweiten 32-Bit Wert, in dem bitweise codiert ist, welche Gruppen es ändern können.
Für jedes Passwort wird in einem 32-Bit Wort gespeichert, welche Gruppen es enthält. Es kann also deutlich mehr als 32 geben. Ich würde mich freuen, wenn die Liste dynamisch wird. Man könnte ja einen String verwenden, und darin Passwörter und zugehörige Masken speichern.
Nachtrag:
Es sollte ein 32-Bit-Wort geben, das aktiv ist, bevor ein Passwort eingegeben wird, quasi ein Gast-Account. Wer keine Sicherheit benötigt, setzt hier alle Bits und ist dann 'anmeldefrei'. 'Paranoide' (also ich auch) setzen hier alles auf Null, dann geht nichts ohne Passwort. Extrovertiertere geben hier schon mal Leserechte an nicht so schützenswerten Daten, z.B. Außentemperatur...
Nachtrag Ende.

So können die Funktionen des Gebäudes gruppiert werden und jeder Nutzer des Gebäudes könnte ein eigenes Passwort bekommen das dann definiert, welche Funktionsgruppen ihm zugänglich sind.

Das Ganze muß über HTTPS gehen und ein Login ist nur so lange gültig wie die Verbindung besteht. Ob ein weiterer Timeout notwendig ist, kann ich noch nicht sagen...

Diese Umsetzung vermeidet öftere Passwortabfragen, man hat normalerweise nur eines mit den Freigaben, die man braucht bzw. zugebilligt bekommt. Der 'Hausherr' benötigt ggf. ein zweites mit 'Administratorfunktion', das eine Gruppe enthält, die eben auf alles Zugriff hat - aber auch nur, sofern er das im Normalfall eben nicht haben will.
Wenn sonst also keiner das Aquariumlicht abschalten können soll, muß dieses in eine Gruppe, die nur den Passwörtern 'berechtigter' Nutzer zugeordnet ist. Es spricht doch nichts dagegen, das diese nach einem Login dann immer schalten könnten.

Bleibt die Frage an enertex: Ist man dort gewillt, ein solch "kompliziertes" System umzusetzen?
Und die Frage an alle Nutzer des EibPCs: Ist Euch das recht oder zu kompliziert? Als kleine Hilfestellung: Seht Euch mal die Rechtevergabe bei Windoof an, die ist weit komplexer, bislang haben aber alle damit ganz gut leben können.

[Uwe!]

Seht Euch mal die Rechtevergabe bei Windoof an, die ist weit komplexer, bislang haben aber alle damit ganz gut leben können.

ich glaub der Vergleich hinkt....Ich behaupte einfach mal >90% aller Windows User haben die Rechteverwaltung noch nie angefasst, geschweige denn verstanden!

Aber ich bin bei Dir, dass ein Passwortschutz langfrsitig nötig ist. Eine Web-Oberfläche lädt immer dazu ein, sie auch von "außen" bedienbar zu machen, dann aber eben nicht für jeden.

Deine beschriebene Variante wäre so ziemlich das Optimum. Ich könnte auch schon mit weniger leben (je Passwort wird Lesen bzw. Lesen/Schreiben definiert)

[Tessi]

Ich behaupte einfach mal >90% aller Windows User haben die Rechteverwaltung noch nie angefasst, geschweige denn verstanden!

Ich befürchte mal, Du hast recht!
Aber die meisten davon werden wohl auch keinen EibPC verwenden wollen...

Aber ich bin bei Dir, dass ein Passwortschutz langfrsitig nötig ist. Eine Web-Oberfläche lädt immer dazu ein, sie auch von "außen" bedienbar zu machen, dann aber eben nicht für jeden.

Deine beschriebene Variante wäre so ziemlich das Optimum.

Das höre ich doch gerne...

Ich könnte auch schon mit weniger leben (je Passwort wird Lesen bzw. Lesen/Schreiben definiert)

PSSSST! Nicht so laut!
Wir wollen doch das Optimum haben, oder?

Aber zugegeben, es sollte sinnvolle Defaultwerte geben, die Nutzer ohne Sicherheitsbedarf erlauben, Webseiten zu erstellen und sofort nutzen zu können, ohne sich über die Konfiguration von Gruppen und Passwörtern den Kopf zerbrechen zu müssen, so wie es Windoof vormacht.
D.h. defaultmäßig gehören alle neuerstellten Elemente einer Gruppe zum Lesen und Ändern an (quasi der Andmingruppe) und diese ist defaultmäßig schon ohne Passwort aktiv. Nutzer mit Sicherheitsbedürfniss vergeben sofort für diese 'Admin'-Gruppe ein Passwort und legen für den 'Normalgebrauch' ggf. weitere an. Die 'Sorglosen' lassen alles auf Default (wie auch bei Windoof) und freuen sich, das es so einfach geht.

[Robikon]

Finde ich klasse, dass dieses Thema noch so viel Diskussionspotential hat. Sicherlich kann es man bei einer möglichen späteren Implementierung nicht allen Anwendern recht machen, aber besser es geht zu 50% in die gewünschte Richtung als Stillstand. Aber diese Befürchtung habe ich beim eibPC eher nicht.

[Tessi]

Es geht letzlich nicht darum, es allen Anwendern in allen Punkten recht zu machen, sondern einfach für mehr Kunden eine Problemlösung sein zu können als eventuelle Alternativprodukte.
Das Windoof so kompliziert ist, war sicher nicht der Wunsch der Anwender, aber eine zwingende Folge der vielen verschiedenen Anforderungen. Jede Vereinfachung würde durch dann nicht mehr erfüllte Anforderungen mehr Kunden ausschließen, als neue gewinnen. Wenn alle ein wenig über die Komplexität jammern, aber dennoch damit arbeiten können, ist das besser, als wenn ein paar wunschlos glücklich sind, für viele anderen aber das Produkt keine Alternative mehr ist, weil es wesentliche Anorderungen nicht erfüllen kann.
Enertex muß hier abwägen, wir können die Argumente dazu liefern.
Mein Standpunkt: Flexibilität ist wichtiger als Einfachheit.
Über eine komplizierte Funktion ärgere ich mich ein paar mal beim Programmieren, über eine fehlende die ich brauche aber solange ich das Gerät nutze.

[enertegus]

Es geht letzlich nicht darum, es allen Anwendern in allen Punkten recht zu machen, sondern einfach für mehr Kunden eine Problemlösung sein zu können als eventuelle Alternativprodukte..

Wie wäre es etwa so;
page(Keller)...
user:$Keller$
password:$MyAccountPass$
...
page(Wohnzimmer)...
user:$Wohnen$
password:$MyAccountPass2$

[Uwe!]

ein erster Ansatz!

Wenn ich aber als Ergebnis haben will, das z. B. A nur auf Keller, B auf Keller und Wohnen und C nur auf Wohnen zugreifen kann, dann muss B sich entweder mit mehreren User/Passwörtern rumschlagen (innerhalb einer Sitzung), oder ich muss "user: & password:" merhfach vergeben können. => was keine optimale Lösung wäre, aber da die meisten vermutlich auch nicht mehr als 10 User bräuchten, noch erträglich wäre.

[bmx]

Wie wäre es etwa so;
page(Keller)...
user:$Keller$
password:$MyAccountPass$
...
page(Wohnzimmer)...
user:$Wohnen$
password:$MyAccountPass2$

Ich würde vorschlagen eine Benutzerliste vorzugeben mit passwörtern

[EibPCUser]
//nummer;passwort;gruppe(n)
1=admin;meinpasswort;admin,familie
2=mama;xx0815xx;familie,eltern
3=fritz;4711abc;familie,kinder
4=gast;gast;guests
5=ewerk;givememoney;vampire

[Webserver]
page(Keller) $admin$,$familie$
page(Wohnzimmer) $familie$
page(Dachgeschoss) $familie$
page(Zaehlerstaende) $familie$,$vampire$

Gruß,
Bernd

[vento66]

@bmx

5=ewerk;givememoney;vampire

You made my day! ROFL

[Tessi]

Und ich bleibe bei dem was ich unter #4 vorgeschlagen habe. Einfach weil es sehr viele Freiheiten lässt.

[enertegus]

Und ich bleibe bei dem was ich unter #4 vorgeschlagen habe. Einfach weil es sehr viele Freiheiten lässt.

Die Rechtevergabe mit Bitcodierung erscheint mir zu komplex.

[Tessi]

Die Bitcodierung ist ja nur ein Vorschlag zur technischen Umsetzung. Der Nutzer soll sich nicht direkt damit auseinandersetzen (bei NTFS bearbeitet man die ACLs ja auch nicht von Hand - viele Nutzer wissen nicht einmal das es sie gibt).

Wichtig ist, es können verschiedene Nutzer mit verschiedenen Passwörtern angelegt werden und für jedes einzelne Element kann irgendwie festgelegt werden, wer es überhaupt sehen kann und wer auch was damit machen kann (z.B. Schalten oder Wert verändern).

Die Zwischenstufe der Gruppen habe ich in Anlehnung an die Rechteverwaltung der meisten Multiuserbetriebssysteme vorgeschlagen, da dies die Wartung vereinfacht. Dabei könnten mehrere User zu einer Gruppe gehören aber auch umgekehrt ein User zu mehreren Gruppen.

Das mag komplex klingen und ist es auf Systemebene vielleicht auch aber ich finde Flexibilität wichtiger als Einfachheit, siehe auch meine Aussagen in #8.