Password Security
Solange Sie sich noch per Kennwort anmelden, sollten Sie sich Gedanken über den Schutz machen. Username und Kennwort sind in der Regel zu schwach und ein zweiter Faktor bringt sehr viel.
Überlegungen zum Kennwort
Ehe Sie sich in dem weiteren Artikel vertiefen sollten Sie sich folgende Eckpunkt im Gedanken durchgehen:
- Jedes Kennwort ist gut, solange es
niemand sonst kennt oder einfache erraten
oder ausprobiert werden kann
Denken Sie an ihre PIN auf der EC/Kreditkarte, die mit 4 Stellen als "sicher" angesehen wird. Vier Stellen sind auch i.O., weil nach drei Fehlversuchen die Karte ungültig wird. Ein Dieb hat also eine 3/10000 = 0,03% Wahrscheinlichkeit für einen Erfolg. - Solange ein Kennwort sicher ist, muss es auch
nicht geändert werden.
Es wird nämlich nicht besser, wenn ein Anwender es regelmäßig ändern muss. Er fängt dann nämlich an z.B. laufen Nummern anzuhängen. Wenn ein altes Kennwort bekannt wird, ist das aktuell einfach zu erahnen. - Komplexität ist störend
Komplexität zwingt die Anwender sich Kennworte aufzuschreiben und erschwert die Eingabe auf fremden Tastaturen, da die Belegung der Sonderzeichen oft abweichend ist. Nicht alle Systeme können mit allen Sonderzeichen umgehen. Letztlich erhöht sich die Anzahl der versehentlichen Lockouts mit "Kennwort Reset"-Vorgängen. - Länge gewinnt
Komplexität wird immer angeführt, weil damit Dictionary-Angriffe erschwert würden. Wenn ein Kennwort aber nur wenige Stellen länger ist, dann können Sie dies genauso erreichen. - Ein unsichereres Kennwort muss sofort
geändert werden
Selbst 30 Tage "Änderungszwang" sind zu lange. Das bedeutet aber, auch dass Sie Login-Vorgänge überwachen müssen, um "Ungereimtheiten" zu erkennen. Zudem können Sie als Zusatzschutz z.B. abhängig vom Netzwerkort (Internet oder Intern), Client (Bekannt/Managed/unbekannt) oder Zeitpunkt zusätzliche Abfragen anfordern (MFA)
Daher plädiere ich für lange Kennworte, die nie geändert werden müssen. Stattdessen muss das System die Nutzung der Zugangsdaten überwachen und Unregelmäßigkeiten (wechselnde Orte, unübliche Zeiten etc.) erkennen, den Anwender informieren/fragen oder das Konto einschränken bis der Anwender die Legitimation bestätigt hat.
Wechsel Sie eigentlich auch alle paar Monate ihre Türschlösser auf Verdacht aus, weil sie sich sicherer fühlen?. Das machen Sie doch auch nur, wenn ein Schlüssel abhanden kommt oder jemand anderes ihre Tür unerwartet aufschließen kann. Es ist wichtiger die Öffnungsvorgänge mit den Personen zu verbinden um Gegenmaßnahmen einleiten zu können.
Mittlerweile (März 2018) ist dies sogar eine Empfehlung von Microsoft und anderen Diensten:
Abschalten ist auch in der Cloud einfach
Microsoft Password Guidance
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf
BSI Grundschutz: ORP.4 Identitäts- und
Berechtigungsmanagement
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/bausteine/ORP/ORP_4_Identit%C3%A4ts-_und_Berechtigungsmanagement.html
- Password policy recommendations
https://docs.microsoft.com/de-de/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide - Security baseline (DRAFT) for Windows 10
v1903 and Windows Server v1903
https://blogs.technet.microsoft.com/secguide/2019/04/24/security-baseline-draft-for-windows-10-v1903-and-windows-server-v1903/
"Why are we removing password-expiration policies?" - Microsoft Recommending Non-Expiring
Passwords to Office 365 Customers
https://practical365.com/security/microsoft-recommending-non-expiring-passwords-to-office-365-customers/ - Passwörter: BSI verabschiedet sich vom
präventiven, regelmäßigen Passwort-Wechsel
https://www.heise.de/security/meldung/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html
Das Kennwort / Die Anmeldung
Noch immer werden zur Anmeldung an verschiedenen Daten normale Kennworte genutzt. Nur wenige Zugänge erfordern z.B. Zertifikate oder andere starke Authentifizierungen. Über Gruppenrichtlinien können Sie auch in ihrer Domäne so genannte "Komplexe Kennworte" fordern. So müssen Benutzer dann auch Sonderzeichen und Zahlen verwenden. Was der Sicherheit dient sorgt aber auch für ärger, wenn Sonderzeichen auf anderen Tastaturen nicht einfach erreichbar sind. Viele Anwender haben schon Probleme mit der Gross/Klein Schreibung (Caps Lock on) und haben Sie schon mal versucht ihr komplexes Kennwort im OWA-Anmeldebildschirm einzugeben, wenn Sie ein anderes Tastaturlayout vorgesetzt bekommen ? (z.B. im Urlaub)
Die "Cracker" haben mittlerweile aber auch nachgerüstet und dank moderner Grafikkarten GPU's können diese sogar noch ein vielfaches schneller die Hashwerte mit roher Gewalt (Brute Force Attacke) durchprobieren, als dies vor wenigen Jahren noch denkbar war. (Siehe auch http://www.heise.de/ct/inhalt/2009/06/204/). So kann ein normales Kennwort aus Buchstaben und Zahlen [a-zA-Z0-9] mit weniger als 7 Stellen schon in Minuten geknackt werden. Selbst komplexe Kennworte mit der Länge halten einem Angriff nicht länger als 30 Minuten Stand. Der Angreifer muss einfach nur das verschlüsselte Kennwort abgehört haben, was z.B. mit Cain&Abel im LAN gar kein Problem ist. Entsprechende auf Grafikkarten optimierte" Tools gibt es z.B. Unter http://3.14.by/en/md5 und anderen Quellen.
Erst mit zunehmender Länge eines Kennwort wird es für solche Angriffe immer schwerer, solche Attacken in vertretbarer Zeit erfolgreich zu fahren. Wenn Sie also ihr Kennwort entsprechend lange wählen und häufig genug (z.B. mindestens alle 60 Tage) ändern, dann ist das Risiko schon erheblich reduziert.
Ein weiterer Aspekt ist natürlich die Übertragung des Kennworts selbst. Wer heute noch per POP3, IMAP4, TELNET oder HTTP auf sensible Daten zugreift, ist selbst schuld, weil ich dann nicht mal das Kennwort knacken muss, sondern zumindest bei "Basic-Auth" direkt einsehen kann.
Neben einem "guten Kennwort" ist natürlich auch eine entsprechend gesicherte Übertragung per SSL (POP3S, IMAP4S, HTTPS, SSH etc.) oder eine starke Authentifizierung (Kerberos, Zertifikate) ratsam, so dass sich wenig Angriffsflächen für Mitleser oder Hash-Cracker bieten.
Leider wird genau das allzu oft vernachlässigt, da die Beantragung, Installation, Verlängerung und Konfiguration von z.B. SSL-Zertifikaten natürlich ein zusätzlicher Aufwand darstellt und auch die Clients entsprechend angepasst werden müssen.
Hinzu kommt auch, dass sie sicher alarmiert sind, wenn an ihrer Eingangstür seltsame Kratzspuren zu finden sind, aber fast niemand aktiv die fehlerhaften Anmeldungen an einem Netzwerk überwacht. Zwar hilft Windows hier mit einer "Lockout"-Strategie, dass nach zu vielen Fehlversuchen ein Konto temporär gesperrt wird, aber das funktioniert nicht bei "geknackten" Kennworten. Eine Überwachung der Anmeldungen kann aber wertvolle Hinweise auf Unregelmäßigkeiten liefern, da sich die meisten Anwender doch primäre an "ihrem" PC anmelden und Fremdanmeldungen daher einfach zu erkennen sind.
Wenn Sie nun die Übertragungswege weiter gesichert haben und auch lange Kennworte einsetzen, dann steigt der Aufwand für Angreifer natürlich sehr hoch an. Auf der anderen Seite belegen aber Projekte wie seti@home und andere, dass Millionen von PCs an einer gemeinsamen Rechenaufgabe arbeiten können. Andererseits gibt es auch immer wieder Viren und BOT-Netze, welche ferngesteuert werden können. Vielleicht erleben wir zukünftig Schadprogramme, die keinen direkten Schaden mehr auf ihrem Wirt verursachen, um möglichst lange unerkannt zu bleiben und statt dessen als verteilter Password-Knacker-Dienst arbeiten.
Kennwort Komplexität, Brute Force
Viel Wirbel wird auch um Kennworte und deren Komplexität gemacht. Es ist schon erschreckend, wie viele Dienste ein "komplexes" Kennwort (mit Zahlen, Gro/Kleinschrift, Sonderzeichen) erfordern aber bei der Länge passen. Auch Windows war früher mit LM-Hashwerte auf 14 Zeichen beschränkt, von denen sogar nur zwei Gruppen al 7 Zeichen "verhashed" wurden und ein Entwickler am Hashwert schon sehen konnte, ob das Kennwort 7 oder weniger Stelle hatten. Damit konnte der Aufwand zum "erraten" eines Kennworts natürlich reduziert werden.
Aber diese "Brute Force"-Attacken erfordern zwei Dinge:
- Schnelle Systeme
Hier haben aber nicht nur die Host-CPU's immer weiter zugelegt, sondern die Zweckentfremdung von Grafikkarten-CPUs (GPU) als Nummernknacker hat hier die Zeitdauer stark verkürzt, um auch lange Kennworte "durchzuproben" - Zugriff auf den CryptoKey
bzw. "dummes" System ohne
Sperren
Massentests sind aber nur möglich, wenn auch große Vergleiche möglich sind. Wer ein gutes System aufbaut, der sperrt ein Konto nach zu vielen Fehlversuchen. Dabei ist es relativ unwichtig, ob das nach 3, 5 oder auch 10 Versuchen passiert, solange dann für einige Minuten gesperrt wird. Das gesperrte Konto kann sogar nach wenigen Minuten (z.B.10) wieder entsperrt werden. mit 10 Versuchen und 10 Minuten funktioniert Brute-Force nicht mehr. Wohl aber das Erraten aus einer Liste von bekannten bzw. "wahrscheinlichen Kennworten.
Die Komplexität statt der Länge ist aber kein wirklich guter Ratgeber. Ein Kennwort mit 10 Zeichen aus einem Zeichensatz von [a-zA-Z0-1Sonderzeichen} ist weniger sicher als ein langes Kennwort aus [a-z]
Zeichensatzauswahl | Zeichenmenge | Stellen | Varianten (Menge hoch Stellen) |
---|---|---|---|
0-9 (z.B. PIN der EC-Karte oder SIM-Karte etc.) |
10 |
4 |
10000 |
a-z, A-Z, 0-9, Sonderzeichen |
ca. 80 |
8 |
1677721600000000 |
a-z |
26 |
11 |
3670344486987776 |
a-z, A-Z, 0-9, Sonderzeichen |
ca. 80 |
10 |
10737418240000000000 |
a-z |
26 |
14 |
64509974703297150976 |
Wer also ohne Zahlen, Sonderzeichen und Groß/Kleinschrift auskommt, muss nur 11 statt 8 oder 14 statt 10 Stellen fordern, um viel mehr Varianten zu haben. Oder es mit einem Comic zu sagen:
Quelle:
http://xkcd.com/936/
Hinweis: Das Comic beschreibt den Begriff "Entropie". Auch wenn ein Betriebssystem z.B. einen 128bit Hashwert hat, so muss ein BruteForce keine 2hoch128 Varianten prüfen. Denn mehrere Kennworte können durchaus zum selben Hashwert führen. Und dass auch ein komplexes Zeichen keine 8 Bit braucht, reduziert die Entropie weiter.
Interessant ist hier auch die Geschwindigkeit, mit der Brute-Force-Angriffe durch Grafikkarten beschleunigt werden: (Quelle: Cheap GPus are rendering strong passwords useless. http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125)
Passwortlänge | HostCPU 10 Mio try/Sek | GDu 3,3 Mrd try/Sek |
---|---|---|
4 Zeichen a-zA-Z0-9 |
24 Sek |
<1 Sek |
6 Zeichen a-zA-Z0-9 |
1h30min |
4 Sek |
7 Zeichen a-zA-Z0-9 |
4 Tage |
17 Min |
7 Zeichen komplex |
75 Tage |
7h |
9 Zeichen a-zA-Z0-9 |
43 Jahre |
48 Tage |
Und es gibt Berichte, dass Systeme mit 4x HD 5970 (8 GPUs) bis zu 33 Mrd Hashes/Sek durchtesten können. Von dem Einsatz von Rainbow-Tables gar nicht zu reden.
Die Lösung kann eigentlich nur sein, dass sehr sehr lange Kennworte verwendet werden oder das Kennwort auf einer Hardware (z.B. Smartcard) hinterlegt ist, welche die Entschlüsselung macht und falsche Versuche aussperren, oder der Schlüssel von einem Server/Service bereitgestellt wird. (wie z.B. TPM-Chip für Bitlocker)
- Zusammenhang von Brute-Force-Attacken
und Passwortlängen
https://www.1pw.de/brute-force.php - Cheap GPus are rendering
strong passwords useless
http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125 - IGHASHGPU – GPU Based Hash
Cracking – SHA1, MD5 & MD4
https://www.darknet.org.uk/2016/08/ighashgpu-gpu-based-hash-cracking-sha1-md5-md4/ - Enforcing Strong Password usage Throughout Your
Organization
http://technet.microsoft.com/en-us/library/cc875814.aspx -
PWExpire
Kennworte ausfindig machen, die schon lange unverändert sind und demnächst ablaufen. - Steve Riley and Jesper Johansson - Protect your Windows Network
http://www.amazon.com/Protect-Your-Windows-Network-Addison-Wesley/dp/0321336437 - http://diablohorn.wordpress.com/2009/01/01/truecrypt-variety-of-bruteforcing-options/
Empfehlung ?
Es ist sicher nicht einfach einen Ratschlag zu geben, aber ich bin dazu
übergegangen, meinen Anwendern keine "komplexen" Kennworte mehr
aufzuzwingen, aber die Mindestlänge entsprechend anzuheben, so dass auch
mit vielen Grafikkarten eine Attacke auf den Hashwert erst in Jahren und
nicht in Tagen erfolgreich ist. Dies wird kombiniert mit einem maximalen
Kennwortalter von z.B. 60 Tagen und die Vermeidung jeder Übertragung in unverschlüsselter (FTP, POP3) oder schwach versteckter (BASE64 bei HTTP)
Form.
Lockout Policies
Ein wirksames Mittel, gegen Brute Force aber noch mehr gegen Dictionary-Attacken ist natürlich das "Bremsen" der Versuche. Das funktioniert leider nicht, wenn der Angreifer eine Kopie der SAM, der PFX oder der verschlüsselten DOC-Datei etc. hat. Aber wenn er z.B. ein Anmeldkonten auf einem DC über das Netzwerk "probieren" will, dann sind die Lockout-Policies ein effektives Mittel. Allerdings muss man hier auch wieder die richtige Wahl zwischen Sicherheit und Nutzbarkeit finden.
Wer nach drei Fehlerversuchen ein Konto für eine Stunde "aussperrt" oder sogar eine manuelle Entsperrung erfordert, der macht es einem Angreifer zwar sehr schwer, das Kennwort zu "erraten", sofern er keinen deutlichen Hinweise auf das möglich Kennwort hat. Aber dann kann ein Angreifer eben "anders" stören, indem er eine Liste der Benutzer bösartig abläuft und in kurzer Zeit alle Konten "gesperrt" hat. Viel Spaß beim Lösen dieses Knotens. Und Webserver versuchen schon mal gerne zwei Anmeldeverfahren, so dass mit einem falschen Kennwort schon zwei Versuche weg sein können.
Wer aber z.B. ein Konto erst nach 5-8 Fehlversuchen sperrt und nach 1 Minute wieder automatisch entsperrt, der verhindert weiterhin recht effektiv "Brute Force"-Attacken. Mit 5-8 Versuchen pro Minute muss ein Angreifer nicht nur viel Geduld haben, sondern setzt sich durch die permanente Sperrung eines Kontos auch der Entdeckung aus. Wenn ein Angreifer aber einen überwiegenden Teil des Kennworts ausgespäht, hat, dann könnte er so an das Ziel kommen. Auf der Habenseite einer entspannter eingerichteten Richtlinie steht, dass der Anwender einfach kurz warten muss und der Helpdesk weniger zu tun hat.
Wer es etwas pfiffiger haben will, kann ja das Konto weiterhin nach 3-5 Versuchen für "immer" sperren aber die Freischaltung über eine eigene Logik realisieren, die dynamischer auf die Häufigkeit oder die Quelle der Sperrung eingeht. Es ist recht einfach, das Active Directory zeitnah dahingehend abzufragen, ob ein Konto gesperrt wurde und darauf zu reagieren (siehe auch Get-USNChanges). Auch das Eventlog ist eine gute Quelle um "getriggert" eine Sperrung zu erkennen und angepasst zu reagieren
Übrigens ist eine Lockout-Policy nur die halbe Miete. Es hilft ihnen nicht, wenn ein Anwender sich meldet, weil sein Konto immer wieder gesperrt wird und sie keine Hilfsmittel haben, um die Ursache der Sperrung zu ermitteln. Gerade wenn ein Konto immer wieder gesperrt wird, sollten Sie schnell heraus finden, ob es wirklich ein einfacher Benutzerfehler ist, z.B. ein PC der noch mit dem alten angemeldet ist, oder ob tatsächlich jemand "probt". Das Windows Security Eventlog der Domain Controller ist hier die erstelle Quelle.
Wenn die Kennwort ausreichend Lange sind und eine passende Sperr-Richtlinie etabliert ist, dann könnten Sie darüber nachdenken, den "Wechselzwang" alle 60 Tage ein neues Kennwort zu vergeben, zu lockern. Allerdings sollten Sie dann eine Lösung haben, die Anmeldungen der Anwender "protokolliert" und auswertet um Missbrauch zu erkennen. Aber so eine Protokollierung ist ja für die Analyse von "Lockout"-Vorgängen eh schon relevant.
AzureAD
Übrigens kann Office 365/AzureAD hier dabei helfen. Sie können mit AzureAD P1 und passender Einrichtung ihr Kennwort auch in der Cloud ändern und zurückschreiben lassen. AzureAD prüft dabei ihr Kennwort gegen viele andere bereits angegeben Kennworte und warnt vor schwachen Kennworten:
- Erzwingen des lokalen Azure AD-Kennwortschutzes für Active Directory Domain
Services
https://docs.microsoft.com/de-de/azure/active-directory/authentication/concept-password-ban-bad-On-Premises - Plan and deploy On-Premises Azure Active Directory Password Protection
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-On-Premises-deploy - Azure AD Password Protection is now generally available!
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-password-protection-is-now-generally-available/ba-p/377487
Weitere Links
- Fine-grained Password Policy
- 802.1x
- Verschlüsseln und Signieren
- Datenhaltung
- Gruppenrichtlinien
- CA installieren
- 823731 How to remove cached User credentials that are used für PEAP authentication in Windows XP
- Password policy recommendations
https://docs.microsoft.com/de-de/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide - Passwörter: BSI verabschiedet sich vom präventiven, regelmäßigen
Passwort-Wechsel
https://www.heise.de/security/meldung/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html - Microsoft IT Showcase: Improving Security with Domain Isolation:
Microsoft IT Implements IP Security (IPsec)
http://www.Microsoft.com/downloads/details.aspx?FamilyID=a97ddc48-a364-4756-bb3c-91da274118fe&DisplayLang=en - Setting up IPsec Domain and Server Isolation in a Test Lab
http://www.Microsoft.com/downloads/details.aspx?familyid=5ACF1C8F-7D7A-4955-A3F6-318FEE28D825&displaylang=en - Passfilt Pro von Altus Network Solutions, Inc.
Verbesserte Richtlinien für Komplexität von Kennworten
http://www.altusnet.com/
http://www.gruppenrichtlinien.de/index.html?/Tools/passfiltpro.htm - Zusammenhang von Brute-Force-Attacken und Passwortlängen
https://www.1pw.de/brute-force.php - IEEE 802.1X: EAP over LAN (EAPOL) für LAN/WLAN Authentication & Key
Management
http://www.javvin.com/protocol8021X.html - Port based Network Access Control
http://standards.ieee.org/getieee802/download/802.1X-2001.pdf - XTweak von Enterasys zum Debugging von 802.1x Anmeldeproblemen
http://www.enterasys.com/support/tools.html - Simple Certificate Enrollment Protocol (SCEP) Add-on für Certificate
Services
http://www.microsoft.com/Downloads/details.aspx?familyid=9F306763-D036-41D8-8860-1636411B2D01&displaylang=en - Wikipedia EFS
http://en.wikipedia.org/wiki/Encrypting_File_System