Wie wird bei einer Nutzer-Anmeldung verfahren?
<2015-01-26>
Vorbemerkungen:
Einige Aktionen im openWIM-System dürfen nur von dafür berechtigten Personen durchgeführt werden. So darf beispielsweise nicht jeder einfach das System herunterfahren oder konfigurieren oder dargestellte Inhalte ändern können.
Es muss dafür gesorgt werden, dass der Anmeldevorgang sicher genug ist und möglichst wenige Daten zu den Nutzeraktionen missbräuchlich genutzt werden können. Dafür wird vor allem versucht, Daten möglichst gar nicht erst anfallen bzw. übertragen zu lassen, und wenn das nicht vermeidbar ist, Daten zu verschlüsseln. Anfangs werden jedoch noch keine wirklich "sicheren" Verschlüsselungaverfahren eingesetzt - doch eine "schwache" Verschlüsselung ist schon mal besser wie gar keine!
1. Ablauf beim Login-Vorgang:
Anforderungen an das Verfahren:
- Die Nutzerkennung soll vertraulich bleiben. Sowohl beim Mitlesen der Übertragung als auch auf dem Server soll sie möglichst schwer rückrechenbar sein. Die Verwendung einer identischen Nutzerkennung bei verschiedenen Projekten bzw. Internetpräsenzen soll bei der Datenübertragung und -speicherung möglichst schwierig erkennbar sein.
- Außer der weit verbreiteten Nutzung von Passwort-Eingaben müssen auch andere Autorisierungsverfahren möglich sein. Die Nutzer sollten das zu verwendende Verfahren möglichst selber auswählen können.
- Das Nutzer-Passwort (oder der Wert einer anderen Art von Sicherungs-Code) dürfen den Browser beim Login-Vorgang nur in schwer entschlüsselbarer Form verlassen. Der übertragene Autorisierungs-Wert soll bei jedem Login-Vorgang anders aussehen.
- Auf Nutzerwunsch hin soll die Sicherung des Login auch geräteabhängig durchgeführt werden können, um bei Passwort-Diebstahl und Eingabe an einem "fremden" Gerät eine Anmeldung zu verhindern.
- Der Login-Vorgang muss in angemessener Zeit abgeschlossen werden, damit ein teilfertiges Login nicht missbraucht werden kann.
- Sobald ein Login-Vorgang abgschlossen ist oder abgebrochen wurde, sollen auf dem Server keine der speziellen übertragenen Daten mehr gespeichert sein.
- ...
- "Brute force"-Methoden zum Ausprobieren vieler Passworte etc. müssen ausreichend ausgebremst sein.
- Es muss davon ausgegangen werden, dass ein Client-Script von böswilligen Hackern so modifiziert wird, dass es zum Knacken von Passworten etc. eingesetzt wird. Der Server muss das abfangen können.
- Es ist zu berücksichtigen, dass alle im Server und Client verwendeten Verfahren einschließlich der dafür vorhandenen technischen Dokumentation "öffentlich zugänglich" und nicht "geheim" sind.
- Das Login-Verfahren wird nicht von Anfang an mit den maximal möglichen Sicherheitsvorkehrungen implementiert. Es muss weiterhin auch offen für Verbesserungen und den unvorhergesehenen plötzlichen Ausfall eines Verfahrens gerüstet sein.
Ein Login-Vorgang läuft in mehreren Phasen ab und ist ein Wechselspiel zwischen Nutzer, Client (= Browser) und (Frontend-)Server:
- Der Anmeldevorgang wird initiert. Das geschieht entweder implizit durch den Aufruf einer Aktion, für die eine Nutzeranmeldung notwendig ist oder auch durch einen expliziten Login-Aufruf.
- Parallel zur initialen Anzeige des Login-Dialogs wird automatisch eine Anfrage nach einer Vorgangskennung an den Server geschickt. Dabei wird der aktuelle Zeitpunkt mitgeschickt und temporär für den weiteren Login-Vorgang im Server gemerkt.
Beim Login-Dialog kann derweil vom Nutzer ausgewählt werden, ob zur Verifikation ein Passwort eingegeben oder (sofern möglich) ein anderes Verifizierungsverfahren verwendet werden soll. Auch Nutzerkennung und Passwort (bzw. äquivalente AKtionen) können bereits eingegeben werden. - Vom Server wird als Antwort ein Zufallswert als Vorgangskennung gesendet und temporär gespeichert.
Der vom Client gelieferte Zeitpunkt wird auf ausreichende Aktualität überprüft und zum Vorgang vermerkt. Ist der Zeitpunkt "unbrauchbar", wird die Vorgangsanfrage mitsamt Benstandungsgrund zurückgewiesen und die IP-Adresse des Client auf "Vorsicht" und "gegebenenfalls Ausbremsen" gesetzt. - Vom Nutzer wird beim dargestellten Dialog die Angabe der Nutzerkennung erbeten. Das kann ein (nicht zu kurzer!) x-beliebiger Zeichenstring sein. Diese Eingabe sollte möglichst gegen Ausspähen geschützt werden.
Weiterhin ist das Nutzer-Passwort einzugeben bzw. ein Autorisierungscode auf Basis eines anderen gewählten Verfahrens zu erzeugen. Dieses ist besonders gut gegen Ausspähen zu schützen! - Ist die zuvor automatisch beim Server angeforderte Vorgangskennung eingetroffen, wird der Knopf zum Abschicken des Logins freigegeben.
Mit Betätigen des "Login"-Knopfes wird die Nutzerkennung mit dem Projektnamen zusammengefügt und "gequirlt" (also systematisch verfremdet und auf ein "Einheitsformat" gebracht, dessen Wert auch so im Server abgelegt ist) und dann zusammen mit der Vorgangskennung zum Server geschickt.
Weiterhin wird der eingegebene Autorisierungscode mit der Vorgangskennung möglichst schwer rückrechenbar kombiniert, in ein Standardformat gebracht und dann mit zum Server geschickt.
Soll eine gerätespezifisches Login durchgeführt werden, wird die Gerätekennung (quasi als Passwort-Ergänzung) mit dem eingegebenen Authorisierungs-Code (incl. Projektname) kombiniert "in den Quirl gesteckt". Die Gerätekennung wird also NICHT separat verschickt, sondern ergänzt "nur" die eingegebene Nutzerkennung! - Vom Server wird anhand der Nutzerkennung, der Vorgangskennung und des (gequirlten) Autotrisierungscodes die Identität überprüft.
Dazu werden aus der Datenbasis die notwendigen Nutzerdaten besorgt. Aus der Vorgangskennung und einem gespeicherten Autorisierungs-Basiscode wird analog zum Client ein Autorisierungscode errechnet, der mit dem übertragenen übereinstimmen muss. Für die eventuell verschiedenen Gerätekennungen und andere Bedarfe müssen verschiedene Autorisierungs-Basiscodes bereitgehalten und durchgetestet werden.
Das alles muss innerhalb eines Zeitfensters seit Beginn des Login-Vorgangs geschehen. Gegebenenfalls wird der Vorgang mit "timeout"-Fehlercode abgebrochen. - War die Autorisierung erfolgreich, wird dieses im Server bei der Sitzungskontrolle vermerkt und die zugeteilten Berechtigungen gesetzt. Der Client bekommt eine Erfolgsmeldung - jedoch keine Liste der erteilten Berechtigungen. Im CLient werden keine Berechtigungen geprüft, weil das sehr einfach manipulierbar wäre. Ausschließlich der (Frontend-)Server prüft die Berechtigungen.
Im Fall des Scheiterns bekommt der Client eine entsprechende Benachrichtigung, aus der jedoch NICHT hervorgeht, ob "nur" die Nutzerkennung ungültig war oder der Autorisierungscode (das Passwort).
Wird die Sitzung aus irgendeinem Grunde unterbrochen, geht die Nutzeranmeldung verloren. - ...
- WARNUNG: Das oben geschilderte Verfahren erscheint keineswegs als absolut sicher - es erschwert nur das "Abschnorcheln" von Daten. Bei Bedarf und Möglichkeit werden die Hürden für den Datenklau zukünftig höher gelegt.
2. Ablauf der Nutzer-Registrierung:
...
3. Änderungen an der Nutzer-Registrierung:
Die Nutzer können zu ihrer Registrierung im Laufe der Zeit Änderungswünsche haben. So kann eine andere (einzugebende) Nutzerkennung, ein gerätespezifisches Login, eine andere Benachrichtigungs-E-Mail-Adresse, etc. gewünscht sein. Solche Änderungen müssen jederzeit und direkt von den Nutzern vorgenommen werden können.
...
4. Ablauf der Nutzerprofil-Löschung:
...
Themen hierzuAssciated topics:
Technische WIM-Verfahren Angemeldete Nutzer Personenbezogene Daten
Das könnte Sie auch interessierenFurther readings:
Angemeldete Nutzer im WIM-System
Wofür sind Nutzer-Anmeldungen im WIM-System nützlich oder gar nötig ?
<2014-03-08>
Datenschutzerklärung zu openWIM(.org)
<2018-05-23>
Standard-Request-Parameter
<2013-06-13>
Allgemeine Objektparameter
<2015-03-20>
Steuerung der Darstellung von Objekten
<2019-02-03>
Daten-Layer und -Aktualisierung
<2013-01-06>
Wie bearbeiten Cloud-Server eintreffende Anforderungen der openWIM-Clients?
Wie sind die Schnittstellen und Funktionen gestaltet?
<2016-10-06>
Wie werden Zugriffe auf - ggf. nicht vorhandene - Dateien beim Frontend-Server bearbeitet?
<2015-06-01>
Internet-Links für openWIM-Entwickler
<2020-03-10>
Anordnung von WIM-App-Modulen
<2013-03-28>
Weiterentwicklung des openWIM-Systems
<2018-08-07>
W🚧 Das openWIM-System stellt eine Blog-Mimik bereit
<2019-05-07>
➖ Nächste Schritte zur Ablösung des Legacy-Servers
<2019-05-06>
