• Über uns
    • Dominik Sauer
    • Patrick Sauer
  • Kategorien
    • binsec
    • Datenschutz
    • Informationssicherheit
    • IT-Forensik
    • IT-Sicherheit
    • Netzpolitik
    • PCI DSS
    • Pentest
    • Presse
    • Studium
    • Unkategorisiert
    • Vorlesung
      • HDA
      • THB
    • Vorträge
    • Zertifizierung
  • Lehrveranstaltungen
    • Hochschule Darmstadt (HDA)
      • Internet-Sicherheit
      • IT-Sicherheitsmanagement & Compliance
      • Penetration Testing
      • Security of Web Applications
    • Technische Hochschule Brandenburg (THB)
      • PCI DSS
    • Technische Hochschule Mittelhessen (THM)
      • WK_2620 Secure Coding
      • WK_2621 Penetration Testing
      • WK_2622 Digitale Forensik
  • Impressum / Datenschutzerklärung
InfoSec Blog | Patrick Sauer & Dominik Sauer

Blog - IT Security - Pentest - Fun

Passwörter

Regelmäßige Passwortänderungen alle 90 Tage – sinnvoll oder kontraproduktiv? Eine Kritik an der gängigen Praxis!

20. September 2016 by Patrick Sauer 2 Comments

Regelmäßige Passwortänderungen alle 90 Tage bzw. alle 3 Monate ist eine gängige Praxis in der IT-Sicherheit und wird auch von diversen Sicherheitsstandards wie zum Beispiel dem PCI DSS oder auch etwas allgemeiner von der ISO 27002 vorgeschrieben. Für diese Praxis sprechen zwei Gründe:

  1. Wird ein Passwort „geklaut“, d.h. ist ein Benutzeraccount kompromittiert worden und es wurde nicht gemerkt, kann ein Angreifer mit dem „geklauten“ Passwort nur einen überschaubaren Zeitraum lang etwas anfangen. Danach wird es ohnehin wieder geändert.
  2. Werden gehashte Passwörter von einem System abgezogen, kann es je nach verwendetem Hashalgorithmus und Passwort deutlich länger als 90 Tage dauern, bis ein Passwort rekonstruiert werden kann.

Die Vorteile einer Richtlinie zu regelmäßigen Passwortänderungen sind damit klar. Sie erhöhen das Sicherheitsniveau. Natürlich ist es für Nutzer etwas unbequem, regelmäßig die eigenen Passwörter zu ändern und vor allem neu zu merken, aber natürlich sind sie bereit ganz im Sinne der Sicherheit dieses zu tun und zeigen sogar Verständnis dafür. Diese spezielle Sicherheitsmaßnahme muss Nutzern zwar erklärt werden, aber sind die Einführungsschwierigkeiten erst einmal überwunden und wird das Thema regelmäßig über Security Awareness Kampagnen behandelt, ist alles kein Problem.

Blödsinn.

Die Wahrheit sie wie folgt aus: Ein Teil der IT-Nutzer ist grundsätzlich und stets mit der regelmäßigen Änderung überfordert und vergisst das Passwort in gewohnter Regelmäßigkeit. Und der Rest? Der hat die Intention dieser Richtlinie einfach dezent umgangen, z.B. mit „Buxtehude-2016Q1“. Es ist schon ein super Passwort: Groß- und Kleinschreibung, Sonderzeichen, Zahlen, in diesem Fall sogar 16 Zeichen lang. Top. Alternativ kann man auch das Passwort unter die Tastatur kleben – ein alter Witz aus der IT-Sicherheit: Woran merkt man, dass ein Password Change durchgesetzt wurde? Die Bestellungen für Post-its steigen rasant an! Natürlich gibt es ein paar Security-Enthusiasten, die eine solche Passwortrichtlinie ganz in dem eigentlichen Sinne umsetzen. Das sind aber nur Einzelfälle.

Wie geht man nun damit um? Sofern dem keine Compliancevorschriften o.ä. entgegenstehen, empfehle ich grundsätzlich auf häufige erzwungene Passwortänderungen zu verzichten. Sie sind kontraproduktiv und erfüllen in der Regel nicht den Zweck. Es macht viel mehr Sinn den Nutzern zu erklären, wie sie sich starke Passwörter ausdenken und merken kann. Eine jährliche Passwortänderung o.ä. kann man immer noch erzwingen, man sollte nur dafür sorgen, dass alle Nutzer ausreichend sensibilisiert sind und nicht wieder mit der Iteration von Passwörter beginnen.

Leider vertrete ich mit meiner Kritik an der gängigen Praxis immer noch eine Minderheit unter den Sicherheitsexperten, auch wenn sich die Situation langsam verbessert. So erscheinen zum Beispiel immer mehr Untersuchungen und Empfehlungen, die auch kritisch gegenüber regelmäßigen Passwortänderungen sind:

„Using this framework, we confirm previous conjectures
that the effectiveness of expiration in
meeting its intended goal is weak.“

The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis, University of North Carolina, https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf

„[..] the burden appears to shift to those who continue to
support password aging policies, to explain why, and in which
specific circumstances, a substantiating benefit is evident.“

Quantifying the Security Advantage of Password Expiration Policies, School of Computer Science, Carleton University, Canada, http://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf

„Regular password changing harms rather than improves security, so avoid placing this burden on users“

Communications-Electronics Security Group, a group within the UK Government Communications Headquarters (GCHQ), https://www.cesg.gov.uk/content/files/document_files/Password_guidance_-_simplifying_your_approach_back_cover.pdf

„Generally, password expiration periods are not of much help
in mitigating cracking because they have such a small effect on
the amount of effort an attacker would need to expend,
as compared to the effect of other password policy elements.“

NIST Special Publication (SP) 800-118 (DRAFT), http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf

Posted in: Informationssicherheit Tagged: Passwörter

OWASP Membership mit CVENT – Wie man es nicht macht: Passwörter & CVV

14. März 2014 by Patrick Sauer Leave a Comment

Ich habe mich heute dazu entschlossen dem Open Web Application Security Project (OWASP) beizutreten. Zur Anmeldung, Verwaltung und Zahlung des Eintritts wird auf die Dienstleistung von cvent.com zurückgegriffen.

Wie gewöhnlich generiere ich mit Keepass für die Registrierung ein Passwort: Lang + Komplex = Sicher. Man könnte meinen, bei einer Anmeldung bei dem internationalem Projekt für Webanwendungssicherheit sei das kein Problem. Ist es aber – keine Sonderzeichen und maximal 20 Zeichen.

password_policy_owasp_cvent

 

Dass die Webseite optisch nicht auf dem aktuellsten Stand ist, kann ich verschmerzen. Die Beschränkung der Passwortkomplexität aber nicht. Das lässt erahnen, welchen Sicherheitszustand die Anwendung dahinter besitzt.

Der Mitgliedsbeitrag kann nur mit Kreditkarte beglichen werden. Gut, kein Problem. Über das Passwort konnte ich noch schmunzeln, aber jetzt hört der Spaß auf. Der CVV meiner Kreditkarte wird nicht nur beim Eingeben angezeigt, sondern auch vom Browser gespeichert. In der Entwicklung von cvent war es anscheinend nicht nötig, die angemessenen HTML-Parameter beim Formular zu setzen. Hier hört der Spaß auf…

cvv_owasp_cvent
 

Die Registrierung und Zahlung bei OWASP hat, höflich ausgedrückt, noch Möglichkeiten sich an den ansonsten guten Veröffentlichungen von OWASP zu orientieren und zu verbessern…. peinlich ists trotzdem :-(.

Posted in: IT-Sicherheit Tagged: OWASP, Passwörter

Der sichere Umgang mit Passwörtern

24. Januar 2014 by Patrick Sauer Leave a Comment

Das Problem

Von vielen Menschen wird online gerne das gleiche Passwort für unterschiedliche Webseiten genutzt. Oftmals wird dann noch zur Anmeldung immer die gleiche E-Mail-Adresse verwendet. Wird dazu noch ein einfaches Passwort verwendet, erhöht sich die Gefahr eines Missbrauchs enorm.

Sobald das Passwort auch nur einmal gestohlen oder veröffentlicht wurde, ist das ein riesiges Problem.

Mit einem gestohlenen Passwort kann man – wenn man die E-Mailadresse kennt – mit etwas Glück bei Amazon und eBay einkaufen oder auch komplett das digitale Social Life auf Facebook und Google Plus kapern. Ich kann nur eindringlich davor warnen, für wichtige Dienste das gleiche Passwort zu verwenden.

Natürlich sollten Passwörter auch nicht aus einfachen Wörtern bestehen. Leider sehen Passwörter oftmals so aus: 123456, 12345678, qwertz, letmein, love, password, passwort usw. Das ist gefährlich, da Angreifer mit frei verfügbaren Listen von häufig genutzten Passwörtern sehr schnell in einen Account eindringen können.

Eine Lösung

Passwörter sollten um möglichst sicher zu sein, möglichst komplex sein. Aber wer kann sich  schon ein Passwort wie 64#sxB%pKk merken und dann für jeden Dienst ein anderes? Niemand – außer vielleicht Gedächtniskünstler. Ein möglicher Ansatz um das Problem zu lösen ist die Nutzung eines Passwortsafes. Es gibt verschiedene Alternativen, manche wie KeePass sind frei verfügbar und kostenlos (OpenSource), andere sind kommerzielle Produkte. Im Prinzip ist ein gutes kostenloses Tool ausreichend. Ich selbst nutze KeePass.

Etwas vereinfacht ausgedrückt, erstellt ein Passwortsafe mit einem Passwort bzw. Passphrase eine verschlüsselte Datenbank, in dieser die eigentlichen Passwörter für Amazon & Co gespeichert werden. Das geht auch etwas sicherer mit kryptographischen Schlüsseldateien, ist aber in der Benutzung etwas aufwendiger. Das Passwort zur Verschlüsselung der Datenbank sollte nun möglichst kompliziert und lange sein. Hier lohnt es sich etwas Hirnschmalz einzusetzen.

Ein einfacher Trick um sich ein sicheres, und komplexes Passwort zu erstellen ist die Ableitung aus einem Satz. Ein Beispiel: „Ich heiße Max Mustermann, habe 1 Ehefrau, 1 Freundin und mehrere Kinder.“ Aus dem Satz verwendet man nun die ersten Buchstaben eines Wortes, die Zahlen und Satzzeichen – man erhält

IhMM,h1E,1FumK.

Je länger der Satz und somit auch das Passwort wird, desto besser.

bsp-keepass-01

Hat man die Datenbank mit einem guten Passwort erstellt und gesichert, kann man sichere und äußerst komplexe Passwörter automatisch erstellen lassen. Die kann man dann bequem aus dem Passwordsafe in die Eingabemaske eines Logins im Browser kopieren. Problem gelöst.

bsp-keepass-02

Noch kurz der Hinweis: Das Passwort vom Passwordsafe kann man nicht zurücksetzen, wenn man es vergessen hat. Also im Zweifel lieber einmal ausdrucken und an einem sicheren(!) Ort aufbewahren. Eine regelmäßige Datensicherung (u.a. vom Passwordsafe bzw. seiner Datenbank) ist auch keine schlechte Idee ;-).

Posted in: Unkategorisiert Tagged: Keepass, Password-Safe, Passwörter

Erfahrungen zum OSCP: Teil 6 Manchmal kann es so simpel sein

16. November 2013 by Patrick Sauer Leave a Comment

Manchmal kann es so simpel sein. Ich hatte auf einem Linux-Host eine nicht-privilegierte Reverse-Shell per netcat erlangt. Neben root existierte noch ein weiterer User. Nachdem ich mehrere Stunden erfolglos Zeit in die Privilege Escalation über Exploits investiert hatte, war ich kurz vorm Aufgeben für diesen Tag.

Aus purer Verzweiflung wagte ich ein „su username“ und gab einfach als Passwort den Benutzernamen ein. Nicht nur hatte das Erfolg, der Benutzer hatte auch uneingeschränkte sudo-Rechte auf diesem Host. In weniger als einer Minute war ich root.

Wenn man selbst sehr sensibilisiert mit dem Umgang von Passwörtern ist und weiß, wie man sichere Passwörter benutzt und auch einen Passwortsafe verwendet, verschränkt es manchmal ungemein den eigenen Blickwinkel. Irgendwann kommt man nicht mehr intuitiv auf die Idee, dass trivialste Passwort zu versuchen. Manchmal ist es wirklich so simpel.

Posted in: Pentest Tagged: Erfahrungsbericht, netcat, OSCP, Passwörter

Passwortrichtlinien bei 1&1 VServer Initialisierung

18. Oktober 2013 by Patrick Sauer Leave a Comment

Ich habe einen VServer bei 1&1 geordert, der direkt mit Centos aufgesetzt wurde. Nachdem ich persönlich eine andere Distribution bevorzuge, wollte ich ihn neu initialisieren lassen. Vor der Initialisierung kann man ein neues Initialpasswort festlegen. Gesagt, getan:

1und1_pw1

Ja natürlich, wie kann ich nur auf die Idee kommen ein Passwort länger als 12 Zeichen zu benutzen. Wer macht das schon und warum auch? Also wieder zurück in den keepassx und ein neues Passwort generieren lassen. Dieses Mal mit 12 Zeichen. Sicher ist sicher.

1und1_pw2

Passwörter länger als 12 Zeichen sind böse, Passwörter mit Sonderzeichen erlaubt das System auch nicht. Das ist jetzt ein schlechter Scherz oder? Ich konnte dann gerade noch widerstehen als Passwort 123456 auszuprobieren.

Posted in: Unkategorisiert Tagged: Passwörter

PCI DSS Requirement 8.5.9 bei Endkundenzugängen

19. August 2013 by Patrick Sauer Leave a Comment

Die PCI DSS Anforderung 8.5.9 besagt, dass Benutzerpasswörter mindestens alle 90 Tage gewechselt werden müssen. Unter Requirement 8 existiert jedoch eine Notiz im Standard, die den Umfang der Anwendbarkeit präzisiert:

„Note: These requirements are applicable for all accounts, including point of sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point of sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).”

Hier wird u.a. die Anwendbarkeit der Anforderung 8.5.9 deutlich eingeschränkt. Exakt beschreibt der Hinweis im Standard dennoch nicht, wie mit Accounts von Endkunden verfahren werden soll. Hier hilft die zweite Testing Procedure zur Anforderung 8.5.9 etwas weiter:

„For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”

Hierdurch wird nun klar, dass sich die Prüfung der 90-Tage-Regelung primär an „non-consumer user passwords“ richtet. Kombiniert man die zuvor zitierte Notiz inhaltlich mit der zweiten Testprozedur der Anforderung 8.5.9, richtet sich der Zwang zur Änderung eines Passworts alle 90 Tage primär nicht an Benutzer-Accounts von Endkunden. Nachdem Endkunden keinen Zugang zu Kreditkatendaten besitzen (z.B. bei Amazon, Paypal), weder zu anderen noch zur eigenen, besteht kein Risiko für einen Diebstahl von Kreditkartendaten. Das PCI DSS Requirement 8.5.9 zum Wechsel des Passworts alle 90 Tage findet hier keine Anwendung.

Posted in: PCI DSS Tagged: Compliance, Passwörter, Requirement

Schlechtes Beispiel: Passwörter bei Meine Schufa

17. August 2013 by Patrick Sauer Leave a Comment

Ich wollte mich eben bei www.meineschufa.de registrieren.  Wie gewöhnlich hinterlege ich meine Zugangsdaten im Passwortsafe Keepass und lasse Keepass auch gleich ein ausreichend komplex Passwort generieren. Damit schlägt eine Anmeldung bei Meine Schufa leider fehl:

Man kann Nutzer natürlich auch zur Verwendung einfacherer Passwörter erziehen, indem man Sonderzeichen komplett ausschließt: Wer kommt auf so etwas?

Posted in: IT-Sicherheit Tagged: Passwörter

PCI DSS: Wie die Änderung der Benutzerpasswörter alle 90 Tage indirekt regelmäßig umgangen wird.

8. August 2013 by Patrick Sauer Leave a Comment

Der Payment Card Industry Data Security Standard 2.0 schreibt die Änderung von Benutzerpasswörtern alle 90 Tage vor: “8.5.9 Change user passwords at least every 90 days.” Meistens sehe ich in der Praxis folgende Typen von Nutzern:

  1. Der Nutzer benutzt einen Password-Safe wie z.B. Keepass und er generiert regelmäßig neue Passwörter.
  2. Der Nutzer muss sich das Password tatsächlich merken und iteriert Zahlen durch.

Nutzer von Password-Safes haben aber noch das Problem, dass die Nutzung erst nach der Anmeldung an einen Arbeitsplatz möglich ist. Somit fallen die meisten beim Passwort für den Login am Arbeitsplatz in die Kategorie 2 zurück: Passwörteränderungen werden so realisiert, dass sich der Nutzer ein Schema merkt. Damit ergeben sich sinnlose Passwortänderungen wie z.B.

  • Passwort-01, Passwort-02, Passwort-03, …
  • Passwort!2012-04, Passwort!2013-01, Passwort!2013-02, …

Damit wird in der Praxis die erzwungene Änderung von Passwörtern alle 90 Tage umgangen. „Compliant“ im Sinne von PCI DSS sind diese Passwörter und die damit verbundenen Änderungen dennoch. Ich finde es wäre hilfreich, wenn man die regelmäßige Änderung von Passwörtern beibehält, allerdings die Fristen risikogewichtet und damit flexibler gestaltet. Wenn eine Sicherheitsmaßnahme zu aufwendig ist (hier das Merken neuer Passwörter), und sie umgangen werden kann, wird sie auch umgangen werden.

Posted in: PCI DSS Tagged: Compliance, Passwörter, Requirement

Sprachen

  • Deutsch
    • English

Search

Categories

  • binsec
  • binsec.tools
  • blackhole pentesting
  • Datenschutz
  • Fragen und Antworten (Q & A)
  • Informationssicherheit
  • ISO27001
  • IT-Forensik
  • IT-Sicherheit
  • Lehraufträge
  • Netzpolitik
  • PCI DSS
  • Pentest
  • Presse
  • Regulatorik
  • Reuning
  • Studium
  • Unkategorisiert
  • Vorlesung
    • HDA
    • THB
    • THM
  • Vorträge
  • Zertifizierung

Copyright © 2025 InfoSec Blog | Patrick Sauer & Dominik Sauer.

Omega WordPress Theme by ThemeHall

  • Deutsch
  • English (Englisch)