Benutzerverwaltung

[Tobi]

Hallo zusammen,

ich bastele gerade an einer Benutzerverwaltung mit ASP/VBScript und einer Access DB (Win 2000 OS). Die Benutzerverwaltung soll fuer eine Website sein.

1. Frage
Ich frage mich gerade, ob ich eine Funktion brauche, die Datensaetze lockt. Oder lockt Access automatisch? (Habe da immer eine ldb-Datei bei geoeffneter DB...und eine Fehlermeldung, dass DB exklusiv gelockt ist.) (Wie kann ich checken, ob DB z.B. zu Wartungszwecken gerade gelockt ist?)

2. Frage
Das Passwort der User...sollte man es unverschluesselt in der Datenbank ablegen? (Stichwort: SQL Injection) Sollte man es verschluesseln? Wenn ja, wie? (Links vielleicht?)

3. Frage
Nachvollziehbarkeit. Sollte bei allen Aenderungen in der Benutzerverwaltung eine Sessionid geloggt werden, Datum/Uhrzeit und vielleicht sogar IP Adresse?

4. Frage
Manuelle Freischaltung eines Accounts erst durch einen (Super-)Admin?

5. Frage
Authentifizierung soll ueber Session erfolgen. Reicht der Check, ob eine Session mit bestimmtem Namen gesetzt ist? Kann das sicher sein?

6. Bevorzugt ihr individuelle Rechtevergabe oder Gruppen/Rollen? (Umfang der Seite gegenueber Arbeitsaufwand?)

Gruss
Tobi

[Rouven]

Hi,

nun ja, ich kann dir hier nur meinen eigenen Eindruck vermitteln. Mein Haupterfahrung im ASP-Bereich stammt von einer Adresslisten-Verwaltung, bei der nur bestimmte Personen bestimmte Datensätze bearbeiten dürfen und man darüberhinaus grundsätzlich angemeldet sein muss um überhaupt Einsicht nehmen zu dürfen.

1. Frage
   Ich frage mich gerade, ob ich eine Funktion brauche, die Datensaetze lockt. Oder lockt Access automatisch? (Habe da immer eine ldb-Datei bei geoeffneter DB...und eine Fehlermeldung, dass DB exklusiv gelockt ist.) (Wie kann ich checken, ob DB z.B. zu Wartungszwecken gerade gelockt ist?)

Ich habe mir die Prüfung dieses Zustandes gespart. Man kann dies bestimmt anhand der Err.Number herausfinden wenn man versucht auf die Datenbank zu connecten. Generell kannst du beim Öffnen von z.B. Recordsets im Rahmen des "recordset.Open Source, ActiveConnection, CursorType, LockType, Options" mit Hilfe von Attributen wie LockType einige Eigenschaften setzen. Ich habe das allerdings bei der Größe meiner Adresseliste (ca. 120 Datensätze) nicht für nötig gehalten und arbeite mit den Standardeinstellungen. Meine Updates führe ich generell über SQL-Statements und nicht über Recordsets aus...
Mir ist bei der geringen Nutzerzahl in 12 Monaten Laufzeit nichts über Probleme bekannt, das musst du aber evtl. bei dir neu bewerten...

2. Frage
   Das Passwort der User...sollte man es unverschluesselt in der Datenbank ablegen? (Stichwort: SQL Injection) Sollte man es verschluesseln? Wenn ja, wie? (Links vielleicht?)

Ich setze bei mir einfach als kleine Abschreckung derzeit Base64-Encoding ein. Zudem kannst du natürlich erst einmal deine Access-Datenbank verschlüsseln und dann die Passwörter darin mit irgend einem Algorithmus. Da empfiehlt es sich einfach mal bei google irgendwelche Basic-Seiten zu suchen, die meisten Algorithmen sind so sehr Basic-Code, dass sie sich 1:1 in VBScript kopieren lassen...

3. Frage
   Nachvollziehbarkeit. Sollte bei allen Aenderungen in der Benutzerverwaltung eine Sessionid geloggt werden, Datum/Uhrzeit und vielleicht sogar IP Adresse?

Je nachdem, ob du Missbrauch befürchtest. Es ist generell ja kein sonderlicher Aufwand sich die letzte Änderung zu merken, das sind ja nur 2 Datenfelder, eine AccountID und eine IP-Adresse (die evtl. sogar sowieso als LastLogin-Information beim Account gespeichert ist...). Ich halte mir nicht die IP-Adresse, wohl aber den Benutzeraccount.

4. Frage
   Manuelle Freischaltung eines Accounts erst durch einen (Super-)Admin?

Kann für den Benutzer eine ziemlich lästige Sache sein, wenn z.B. der Admin gerade in Urlaub ist. Ich habe für den kleinen Nutzerkreis die Accounts vorgefertigt gehabt. Eine Alternative wären auch erst einmal billigaccounts die sofort freigeschaltet sind und dann gleichzeitig vom Administrator manuell hochgestuft werden können.

5. Frage
   Authentifizierung soll ueber Session erfolgen. Reicht der Check, ob eine Session mit bestimmtem Namen gesetzt ist? Kann das sicher sein?

Meiner Meinung nach ja, wenn du für eine korrekte Initialisierung und Zerstörung der Session sorgst.

6. Bevorzugt ihr individuelle Rechtevergabe oder Gruppen/Rollen? (Umfang der Seite gegenueber Arbeitsaufwand?)

Generell wird der Aufwand von Gruppen gegenüber individuellen Rechten nicht so groß sein, bis auf eventuelle Mehrfachzuordnung. Zu einem leichten Knoten kann es natürlich kommen, wenn du variable Gruppen mit variablen Rechten hast. Mein Projekt verwendet Einzelvergabe, ein weiteres Projekt verwendet zwar Gruppen, allerdings sind diese von uns global und fest vorgegeben, d.h. weitere Gruppen und Rechteänderungen der Gruppen liegen nicht vor.

[Tobi]

Hallo Rouven,
danke fuer Deinen Erfahrugnsbericht, genau solche Informationen wollte ich haben...

1. Frage
   Mir ist bei der geringen Nutzerzahl in 12 Monaten Laufzeit nichts über Probleme bekannt, das musst du aber evtl. bei dir neu bewerten...

Hoert sich gut an, habe die Datenbank aber auch ueber Locktpe gelockt.

2. Frage

Zudem kannst du natürlich erst einmal deine Access-Datenbank verschlüsseln und dann die Passwörter darin mit irgend einem Algorithmus.

Datenbank verschluesseln? Du meinst Passwort fuer Zugriff setzen? Werde mal nach einem Algorithmus suchen...

3. Frage

Ich halte mir nicht die IP-Adresse, wohl aber den Benutzeraccount.

Hmm...ja Account und Aenderungsdatum wohl...

4. Frage

Eine Alternative wären auch erst einmal billigaccounts die sofort freigeschaltet sind und dann gleichzeitig vom Administrator manuell hochgestuft werden können.

Das hoert sich sehr gut an....

5. Frage
   Meiner Meinung nach ja, wenn du für eine korrekte Initialisierung und Zerstörung der Session sorgst.

Usernamen koennte man ja vielleicht rauskriegen...kann man Session Cookie und Session Object irgendwie erzeugen? (z.B. session object serverseitig ueber ein nicht abgesichertes Formularfeld ?)

6. Frage

allerdings sind diese von uns global und fest vorgegeben, d.h. weitere Gruppen und Rechteänderungen der Gruppen liegen nicht vor.

So werde ichs wohl machen...

Danke & Gruss
Tobi

[Rouven]

Hi

@Sessions:
Die Session-Cookies brauchen dich nicht zu sorgen, die bringen dem Nutzer nur dann etwas, wenn die Session auf dem Server bekannt ist. Für deren Verwaltung ist der nämlich zuständig. Mit dem Cookie erinnert der Browser den Server nur daran, dass er schon angemeldet ist und schon eine Session bekommen hat. Den Inhalt der eigentlichen Session kann der Browser aber nicht manipulieren, den muss ein serverseitiges Skript explizit setzen...