Google Chrome als Browser bietet viele Vorteile, hat jedoch einen großen Nachteil: Die Löschung des Verlaufs bzw. der Daten im Cache ist äußerst unflexibel. In Google Chrome ist es möglich, den Verlauf der letzten Stunden, Tage oder Wochen zu löschen. Was ich vermisse, ist jedoch eine Funktion, die alle Daten löscht, die älter als x Tage bzw. Monate sind.
Zur Lösung des Problems habe ich ein kleines Skript entwickelt, welches ich automatisch beim Anmelden ausführen lasse. Das Skript ist unter Ubuntu Linux getestet, muss also vor dem Betrieb für Windows noch etwas angepasst werden.
Google Chrome Verlauf älter als x Tage löschen
Folgende wichtige Hinweise zum Skript:
Bitte testet das Skript vorab in einer sicheren Umgebung. Prüft, ob die Pfade zu eurem System passen. Legt ein Backup eures Google Chrome Profils an!
Ich nutzte keine Plugins unter Google Chrome. Nutzt ihr Plugins, so muss das Skript angepasst werden. Andernfalls sind die Plugins nach Ausführung des Skriptes weg.
Das Skript löscht alles aus eurem lokalen Google Chrome Profil, außer eure Einstellungen, den Verlauf der letzten x Tage und eure Bookmarks. Dazu gehören auch die in Google Chrome gespeicherten Passwörter.
Zwei-Faktor-Authentifizierung (2FA) oder allgemein Mehr-Faktor-Authentifizierung (MFA) hat in den letzten Jahren stark an Bekanntheit und Bedeutung zugenommen. In diesem Beiträge möchte ich mich auf das Time-based One-time Password (TOTP) Verfahren beschränken, dass wohl bekannteste Verfahren, welches in unzähligen Anwendungen Einzug gehalten hat. Das TOTP Verfahren wird beispielsweise von der 2FA Google Authenticator App verwendet. Viele werden es auch von den kleinen Hardware-Token kennen, welche alle 60 Sekunden ein neues Einmalpasswort generieren und anzeigen.
2FA: Wie funktioniert das TOTP Verfahren?
Das TOTP Verfahren wurde 2011 im Rahmen der Internet Engineering Task Force (IETF) als RFC 6238 veröffentlicht. Beim TOTP Algorithmus handelt es sich um eine Hashfunktion, in welcher ein geheimes Passwort zusammen mit der aktuellen Uhrzeit gehasht wird.
Hinter steckt der HMAC-based One-time Password Algorithmus nach RFC 4226 - vereinfacht gesagt nichts weiter als ein Standard, der auf bestimmte Weise einen Hash bildet.
Dieser Beitrag zeigt, wie ein Netzwerk mit Hilfe von Zertifikaten, sowie 802.1X in einer Microsoft Windows Server 2016 Domäne gesichert werden kann. Das Protokoll 802.1X ermöglicht es, eine Authentifizierung eines Hosts bei Verbindungsherstellung mit einer Netzwerkkomponenten, etwa einem Switch, zu erzwingen. Auf Basis eines Regelwerks kann so beispielsweise realisiert werden, bestimmten Hosts oder gar Nutzern den Zugriff auf das Netzwerk zu erlauben oder zu verbieten bzw. diesen verschiedenen VLANs im Netzwerk zuzuordnen.
Beispielkonfiguration - Aufbau des 802.1X Labs
Die folgende Topologie besteht aus dem Mindestumfang zur Demonstration von 802.1X. Im Detail werden drei Komponenten verwendet:
Ein Microsoft Windows 7 Notebook als aufzunehmenden Client,
ein Microsoft Windows Server 2016 Host, sowie
ein Switch, im Beispiel ein Cisco Catalyst 3560-CG PoE.
Die Vorgehensweise bei Microsoft Windows Server 2012, sowie Windows 8 oder Windows 10 als Client ist vergleichbar. Um reproduzierbare Ergebnisse zu erhalten, verwende ich für die Demonstration eine neue, bisher ungenutzte Windows 7 sowie Windows Server 2016 Installation.
Es folgt die Konfiguration der Netzwerkkomponente, im Beispiel dem Switch. Die folgende Konfiguration dient einer ersten Prüfung, ob alle Geräte im Netzwerk korrekt miteinander verbunden wurden sowie miteinander kommunizieren können.
Initiale Netzwerkkonfiguration
Der Server und das Notebook sind direkt an einen Cisco-Switch angeschlossen. Das Windows 7 Notebook ist mit dem Anschluss Gi0/1, der Windows Server 2012 mit dem Anschluss Gi0/2 des Switch verbunden. Im Lab werde ich das VLAN 20 als Produktiv-VLAN verwenden.
Die initiale Konfiguration des Switch ist wie folgt:
# VLAN 20 anlegen
Switch(config)#vlan 20
Switch(config-vlan)#name Productive
Switch(config-vlan)#exit
# Interface Gi 0/1 als Access-Port im VLAN 20
Switch(config)#int gi 0/1
Switch(config-if)#sw mo ac
Switch(config-if)#sw ac vl 20
# Interface Gi 0/2 als Access-Port im VLAN 20
Switch(config)#int gi 0/2
Switch(config-if)#sw mo ac
Switch(config-if)#sw ac vl 20
# SVI Interface im VLAN 20 anlegen
Switch(config)#int vlan 20
Switch(config-if)#ip address 172.16.0.100 255.255.255.0
Switch(config-if)#no shut
Die Konfiguration verschiebt beide Windows-Hosts in das VLAN 20. Der Switch selbst ist ebenfalls im VLAN 20 unter der IP 172.16.0.100 erreichbar. Im nächsten Schritt werden IP Adressen für die Netzwerkkonnektivität vergeben, beginnend auf dem Windows Server, mit der Adresse 172.16.0.1/24.
User verwenden auf verschiedenen Webseiten häufig gleiche und meist auch schwache Passwörter. Die wenigsten Nutzer im Internet sind technisch so versiert, ausreichende sichere Passwörter generieren und nutzen zu können. Vielfach fehlt ein grundlegendes Basiswissen aus dem Bereich der IT-Sicherheit.
Dies ist aus mehreren Grunde problematisch, denn es kann nicht sichergestellt werden,
dass der Anbieter Passwörter angemessen schützt,
Passwörter durch den Anbieter nicht weitergegeben werden, oder
das Passwörter während der Übertragung an den Webserver nicht mitgeschnitten werden, hierbei ist auch https keine Garantie.
Um die Daten des Users bestmöglich zu schützen, sind an dieser Stelle in erster Linie die Anbieter und Entwickler in der Pflicht. Das Verhalten der Benutzer wird sich auf absehbare Zeit nicht ändern.
Clientseitige Implementierung
Eine Möglichkeit, dass Problem zu mindern, besteht darin, Passwörter zu keiner Zeit unverschlüsselt zu übertragen. Einwegfunktionen zur Sicherung von Passwörtern sollten bereits im Browser des Clients ausgeführt werden.
Der heutigen Beitrag zeigt eine Beispielimplementierung auf Basis von javascript-bcrypt. Passwörter werden als salted bCrypt-Hash gespeichert.
Das Beispiel ist lediglich ein Ansatz und an vielen Stellen noch nicht ausgereift. Fehlerzustände werden z.B. teilweise noch nicht korrekt behandelt oder Brute-Force Angriffe noch nicht migriert. Das Skript stellt lediglich eine Arbeitsgrundlage zur Weiterentwicklung dar.
Passwort setzen/ ändern
Das Passwort wird mit bCrypt und einem zufälligen Salt verarbeitet und anschließend an den Webserver übertragen. Der Webserver speichert den Hash zusammen mit dem Benutzernamen. Der Anbieter hat zu keiner Zeit das Klartextpasswort erhalten.
Zusammenfassung:
Hash erstellen
Hash an Server übertragen
Passwort verifizieren
Auch bei der Verifikation darf das Passwort nicht im Klartext übermittelt werden. Hierbei ergibt sich jedoch die Schwierigkeit, dass der Salt für jeden Nutzer unterschiedlich ist und somit das Passwort nicht einfach erneut als Hash übertragen werden kann. Aus diesem Grund muss beim Login der Salt des Users an die Login-Form übertragen werden.