Passwortzugänge auf Webseiten - Passwortschutz
Auf einer Webseite sind mehr oder weniger regelmäßig Passwörter der Besucher zu speichern. Das gilt insbesondere für Foren und auch für Blogs so dieser offen ist für fremde Nutzer. Und im ersten Beitrag zur Kategorie Datenschutzicons möchte ich auf die unterschiedlichen Möglichkeiten eingehen, wie man so etwas organisieren kann. Und damit werden aus dem Beitrag heraus die verschiedenen Formulierungen für eine Datenschutzerklärung einer Webseite hergeleitet.
Vorraussetzung bei der Passwortspeicherung ist ein existierendes voll- oder halbautomatisches An- und Abmeldeverfahren für neue Nutzer. Bei einer Seite wie dieser in der nur wenige Fremdautoren teilnehmen dürfen genügt das halbautomatische Verfahren. Ich trage die Startnutzerdaten ein, inklusve eines Startpasswortes und teile alles dem betreffenden per E-Mail mit. Er kann dann nach dem ersten Einloggen das Passwort ändern und dann ist er unabhängig von mir.
In den weitaus meisten Foren wird allerdings mittlerweile das vollautomatische An- und Abmelden praktiziert und zwar nach dem Double-Opt-In-Verfahren. Der Anwender trägt seine Daten in ein Formular ein und zu den Daten gehört eine ihm gehörende E-Mail-Adresse. Darauf hin bekommt er eine E-Mail geschickt mit einem Bestätigungslink und damit ist geklärt, dass der Anmelder der Eigentümer der E-Mail-Adresse wirklich ist.
Ob nun das erste Passwort zufällig erzeugt wird, oder der Nutzer es irgendwo eingibt, dass hat Sicherheitstechnisch keine Bedeutung und auch ob das Double-Opt-In-Verfahren genutzt wird oder eben die Eintragung durch den Webmaster, das sind Probleme, die eher in den Bereich einer Bedienungsanleitung gehören.
In die Datenschutzerklärung gehören die Informationen darüber, wie man den Schutz des Passwortes realisiert hat. Denn wenn mittlerweile schon IP-Daten als personenbezogene Daten angesehen werden, dann ist es eine E-Mail-Adresse in jedem Fall. Mit der Anmeldung auf einer Webeite entstehen jedenfalls personenbezogene Daten.
Etwas dass in eine Datenschutzerklärung gehört, dass ist die Aussage darüber, ob jeder jederzeit in der Lage ist, das Passwort zu ändern und zwar automatisch. Wir haben also die Antwortmöglichkeiten:
Das Passwort wird dem Nutzer einmalig zugewiesen und er kann es nicht ändern.
Das Passwort wird dem Nutzer zugewiesen und er bekommt alle x Tage/Wochen/Monate ein neues per E-Mail mitgeteilt.
Die Passwortverwaltung untersteht dem Nutzer. Er kann es jederzeit ändern
So viel zu den Antwortmöglichkeiten darüber wie statisch ein Passwort ist. Wenden wir uns dem Abspeichern des Passwortes zu.
Das Passwort wird in einer Textdatei oder einer Datenbank gespeichert.
Diese drei Größen – Benutzername, E-Mail und Passwort – sind die Minimalkonfiguration für den sinnvollen Betrieb einer Webseite. Andere zu den persönlichen Daten hinzuzurechnende Parameter zählen unausgesprochen zum folgenden hinzu.
Drei potenzielle Einträge wären:
| Benutzername | E-Mail-Adresse | Passwort |
|---|---|---|
| bienemaja | a.b@irgendwo.tld | sumsum |
| reiner | c.d@woanders.tld | reiner |
| peter | e.f@daunddort.tld | weisnicht |
Auch hier braucht man in einer Datenschutzerklärung nicht anzugeben, ob die Daten in einer Textdatei stehen oder in einer Datenbank. Und auch technische Angaben zur Datenbank sind unnötig. Wichtig ist hier nur eine Aussage:
Das Passwort wird im Klartext abgespeichert.
Diese Aussage ist die einzig wichtige, die es dem Anwender ermöglicht, das Gefährdungspotenzial eines so abgespeichertes Passwortes einzuschätzen.
Bei ganz normalen Wartungsarbeiten kann jeder Admin in die Datenbank sehen und die Passworte direkt lesen. Weiter: Der oder die Administratoren des Servers kennen damit nicht nur das Passwort, sondern auch das und die E-Mail-Adresse.
Da viele Menschen die Passworte an mehreren Stellen einsetzen, besteht für die “Kaste der Administratoren” also die Möglichkeit des Identitätsdiebstahls. Sie können sich mit dem Passwort, dass diese auf der Seite x erfahren haben, auf der Seite y einzuloggen versuchen und dann als bienemaja, reiner oder peter auftreten.
Darüber hinaus werden diese Daten beim Backup kopiert und ggf. werden die Backupbänder auch einmal entsorgt. Je nach Geschwindigkeit in der das geschieht und je mach Sorgfalt, die beim Entsorgen an den Tag gelegt wird, können also durchaus die gesamten Tabellen in falsche Hände geraten.
Die Lösung der großen Firmen: Rollen und Rechte
Die oder wenigstens einen Teil der Probleme kann man damit lösen, dass man Datenbanken einsetzt, die eine umfangreiche Rechteverwaltung ermöglichen. So kann man bei Datenbanken wie etwa Oracle einem Wartungs- und Backupadmin die Leserechte für diese Tabellen entziehen.
Eine solche Lösung erfordert nicht nur eine teure Datenbank, hier sind auch mehrere Personen erforderlich. Es ist klar. Es ist für mich im Grunde kein Problem, Oracle auf dem Server zu installieren und mir mit einem Set von drei Passwörtern mit unterschiedlichen Rollen und Rechten, selbst die Leserechte dieser Tabellen zu entziehen, für ein oder zwei Zugänge. Allerdings bleibt dabei immer ein Admin-Passwort übrig, mit dem ich doch Zugang habe.
Mit einer Rollen und Rechtetechnik aber lassen sich durchaus Zugriffe auf die Daten an 2 oder mehr Passwörter und damit Personen binden. Damit ist der Zugriff nur noch nach dem 4, 6 oder 8 Augenprinzip möglich, je nachdem wie weit man diese Regelung dann fasst.
Hier an dieser Stelle ist eine Standardformulierung weder möglich noch nötig. Diese Konzepte sind individuell und so diese vorliegen muss man eben die entsprechenden Sätze aus dem Gesamtkonzept in die Web-Erklärung einbringen.
Was aber tun kleine Firmen, die keine Ressourcen haben für ein solches Konzept?
Verschlüsselte Passwörter
Eine höhere Sicherheit für die abgespeicherten Passwörter erreicht man, wenn man dieses verschlüsselt und zwar mit einer sogenannten Einweg- oder Hash-Verschlüsselung.
Eine Hash-Verschlüsselung hat die Eigenschaft, dass man von einem Passwort her den Hash-Wert zwar berechnen kann, nicht aber vom Hash-Wert das Passwort.
Für diejenigen, die sich das nicht vorstellen können: Eine allerdings sehr schlechte Hash-Funktion ist der Rest bei einer ganzzahligen Division. Mein Passwortzahl ist 28 und ich speichere ab 28 Modulo 5 – 28:5 = 5 Rest 3 – also drei. Mein Hash-Wert ist 3.
Wenn ich mich später einloggen will, dann gebe ich die 28 wieder ein, dass System berechnet wiederholt den Hash-Wert und erhält wiederholt die 3, vergleicht dies mit dem Eintrag in der Datenbank und ist bestätigt den Login-Versuch.
Natürlich ist die Modulo-Funktion zur Erklärung zwar sehr schön. Sie ist aber in der Praxis absolut unbrauchbar. Sie ist aber die Grundlage für praktisch alle Hash-Funktionen. Es ist ein wiederholtes Ausschneiden von Zeichensequenzen, Dividieren und schließlich die Ermittlung von Divisionsresten.
Wenn wir unseren Datensatz mit einer bestimmte Hash-Funktion sichern, zum Beispiel den MD5, dann erhalten wir:
| Benutzername | E-Mail-Adresse | Passworthash |
|---|---|---|
| bienemaja | a.b@irgendwo.tld | cf1c2f84aee675205f2d93e5006b0cd8 |
| reiner | c.d@woanders.tld | ad7acdf44719d1f54f3b4ac08f6605a7 |
| peter | e.f@daunddort.tld | e1159af570beeb942458a788bc47c39a |
Ein solches gehashtes Passwort ist praktisch für den Administrator einer Seite nicht mehr lesbar. Wir haben also eine wichtige Formulierung in einer solchen Erklärung:
Das Passwort wird Einwegverschlüsselt – Hash-Wert – abgespeichert.
Wenn Sie sich einmal verschiedene Prüfsummen ansehen wollen, dann finden Sie hier unter “German Freeware” das Programm DPASHA. Damit können Sie von allen möglichen Daten alle möglichen Prüfsummen (Hash-Werte) ermitteln. Derzeit sind in diesem Programm wohl 21 verschiedene Hash-Wert-Formeln implementiert (version 1.95).
Damit sind die Daten auf einem Server recht sicher. Problematisch wird es nur bei Backups. Hier werden die Einträge in eine Sicherungsdatei geschrieben, vom Server herunter geladen und ggf. auf einer separaten Festplatte gesichert oder auf CD gebrannt. Was auch immer hier geschieht, das Material wandert irgendwann auf den Abfall.
Ungeachtet der Tatsache, dass diese Entsorgungsproblematik auch in ein Datenschutzkonzept gehört, möchte ich hier nur damit fortsetzen, was dies für die Passworte bedeutet.
Dabei muss man beachten, dass mehre Millionen abfragen an einen Webserver sehr schnell auffallen. Wenn die Hash-Werte nicht mehr auf dem Server sind, dann sind diese wieder gefährdet. Daher ist die nächste Frage:
Muss man den Namen der Hash-Funktion in der Datenschutzerklärung angeben?
Die klare Antwort lautet hier eigentlich “Jein”. Auf der einen Seite wird der Laie kaum verstehen um was es eigentlich geht, wenn man von MD5 schreibt oder SHA1 oder ähnlichem. Der Besucher sollte sich ja irgenwann mit dem Seitenangebot befassen und nicht Technik und oder Jura studieren, nur um die Datenschutzerklärung lesen zu können. Auf der anderen Seite aber stecken in der Softwareauswahl enorme Sicherheitspotenziale, die man als Laie wengstens vom Begriff her kennen sollte.
Um die Gefährdung abschätzen zu können, die mit einer bestimmten Hash-Funktion verbunden ist, hat man unter anderem eine Sofware entwickelt mit dem Namen John the Ripper. Es ist eine Brute-Force-Software, veröffentlicht unter Open-Source.
Wenn Sie sich diese Software herunterladen wollen, dann sollten Sie wissen, dass Teile daraus auch in Schadroutinen zu finden sind. Demzufolge wird ihr Virenscanner Alarm schlagen. Da solche Seiten durchaus auch Angriffen ausgesetzt sind, empfiehlt es sich durchaus mit der angegebenen Prüfsumme zu testen, ob Veränderungen vorgenommen wurden (mit dem Programm DPASHA).
Bei den Arbeiten mit John the Ripper zeigt sich zwar auch, dass die Passwortqualität deutlich mehr zu Buche schlägt als die verwendete Hash-Funktion. Mit einem Salt- oder Nonce-Wert (weiter unten erläutert) wird dieses Problem aber dann auf andere Art gelöst.
Bei der Auswahl der Hash-Funktion steht die Frage: Sicherheit durch Rechenzeit oder Komfort – also schneller Zugang durch schnelle Hash-Funktionen (z.B. md5) oder Sicherheit durch langsame (z.B. Bcrypt). Gerade Bcrypt ist so gebaut, dass man parametrierbar die Rechenzeit erhöhen kann. Man kann sich das so vorstellen, dass eine Prüfsummenberechnung mehre Male hintereinander durchgeführt wird.
Damit zwingt man einen Angreifer in viele und aufwändige Berechnungen und wenn die Prüfung eines Passwortes 0,5 Sekunden dauert auf einem normalen Rechner, dann ist bei einer Community von 20 Personen die CPU-Belastung erträglich. Aber dann wird auch in 10 Jahren noch keiner versuchen, diese Tabelle mit einem mit einem Brute-Force-Verfahren zu knacken.
Kein Backup für das Passwort
Eine relativ einfache zusätzliche Sicherheit wäre in dem Fall eine Auslagerung der Datenbanktabelle “Passwort” und die Erklärung eines bewußten Backupverzichtes für diesen Teil. Das ist natürlich nur dann möglich, wenn die Anwender bei nicht vorhandenen Passwörtern sich dann über die E-Mail-Adresse wieder ein neues Passwort zulegen können.
Unsere Tabelle von oben sähe dann aus:
Zum einen die bisherige Tabelle
| Benutzername | E-Mail-Adresse | Passwort-ID |
|---|---|---|
| bienemaja | a.b@irgendwo.tld | 1 |
| reiner | c.d@woanders.tld | 2 |
| peter | e.f@daunddort.tld | 3 |
Und dann eben die ausgelagerte und nicht mehr dem Backup unterzogene Passworttabelle.
| Passwort-ID | Passworthash |
|---|---|
| 1 | cf1c2f84aee675205f2d93e5006b0cd8 |
| 2 | ad7acdf44719d1f54f3b4ac08f6605a7 |
| 3 | e1159af570beeb942458a788bc47c39a |
Hier ist an Stelle des Passwortes einfach eine Passwort-ID eingeführt. Eine versteckte Datei auf dem Rechner enthält dann die Beziehungen von ID und Passworthash und auf diese Datei dürfen nur bestimmte Prozesse zugreifen.
Bei einem Plattencrash bekommen alle User eine Mitteilung, dass die Platte gecrasht ist und die Passworte verloren gingen. Diese Mail enthält dann ein Aktivierungslink für ein neues Passwort.
Hier wäre in der Datenschutzerklärung die Aussage wichtig:
Die Passwörter sind bei uns in einer separaten Tabelle hinterlegt, die bei Datensicherungen nicht berücksichtigt wird.
Passwörter werden mit Salt-Wert und Verschlüsselung abgespeichert
Sogeannte Rainbow-Table-Cracker finden das zu einem Hash-Wert abelegte Wort folgendermaßen. Ausgehend von einem einfachen Wörterbuch werden alle Worte und Wortkombinationen mit bis zu ca. 15 Buchstaben berechnet und tabelliert. Das Ergebnis dieser Berechnungen kann man dann in eine Datei schreiben und auf eine DVD brennen. Wenn man nun einen unbekannten Hash-Wert vorfindet, dann sucht man diesen auf der DVD und mit dem finden hat man das Passwort gecrackt.
Eine deutlich höhere Sicherheit kann man erreichen, wenn man zu jedem Passwort einen Zufallswert oder sogar mehrere Zufallswerte berechnet. Der Fachmann spricht hier von einem SALT-Wert. Dieser wird beispielsweise dem Passwort voran gestellt.
Ausgehend von einem Salt-Wert “202cb962ac59075b964b07152d234b70” bei der “bienemaya” wird nun nicht “sumsum” gehasht, sondern “202cb962ac59075b964b07152d234b70sumsum” und das würde zu dem völlig anderen Hashwert führen “aee40d2b1f2dbae03796cf0e588b5882”
Das Problem an dieser Stelle ist: Der Cracker muss nun allen Wortkombinationen seiner DVD eigentlich den String “aee40d2b1f2dbae03796cf0e588b5882” voranstellen und müsste eine personenindividuelle DVD brennen. Die eigentliche DVD ist damit wertlos.
Natürlich kann dieser Saltwert auch wieder entweder in der DB oder auch in einer separaten Datei gespeichert werden, die nicht gesichert wird.
Diese Sicherung wird beschrieben mit dem Satz:
Das Passswort wird mit einem zusätzlichen “Nonce” oder “Salt”-Wert gesichert.
So viel nun zu den Passwörten, die auf Webseiten eingesetzt werden und zu der Frage, was davon wie in die Datenschutzerklärung gehört.