Mindestpasswortsicherheit gemäß der Serverrichtlinie

  • Hallo,
    ich bin gänzlich neu bei netcup und bin beim Anlegen von Mail-Postfächern darüber gestolpert, dass meine Passworte nicht akzeptiert wurde mit der Meldung:

    >>> Ihr Passwort ist nicht komplex genug. Mindestpasswortsicherheit gemäß der Serverrichtlinie: Stark (empfohlen).

    Wo bitte ist denn beschrieben wie die "Serverrichtlinie" aussieht (kann man das irgendwo abfragen),
    und welchen Regeln für die Passworte gelten denn hier?

    Grüße Lutz

    Einmal editiert, zuletzt von ek-bb (11. Oktober 2025 um 11:29) aus folgendem Grund: Präziser

  • thunfisChkleeblatt7stattzweiundzwanzig ist sicher und leicht zu merken. :)

    username max 10 und passwort min 32 wäre eine gute Server Richtlinie aber man sollte es Benutzern generell garnicht erlauben ihren Benutzernamen oder gar ihr Passwort selbst zu setzen.

    The universe tends toward maximum irony. Don't push it.

    4 Mal editiert, zuletzt von webdesignheld (14. Oktober 2025 um 17:59)

  • Die Richtlinien auf meinen Servern haben bei den Nutzern auch schon mal für leichten Unmut gesorgt: :)

  • ek-bb

    Wir werden dir die Frage vermutlich nicht beantworten können, da wir nicht die Administratoren der Systeme sind. Mein Tipp: Frage mal beim Support ob sie dir das sagen können (und Update danach gerne diesen Thread hier)

    Die Richtlinien auf meinen Servern haben bei den Nutzen auch schon mal für leichten Unmut gesorgt: :)

    Ist zwar OffTopic, aber gucke dir mal das Password Game an :)

    Kannst im Längsten Thread ja gerne auch schreiben bis wo du gekommen bist :D

    https://neal.fun/password-game/

  • eine gute Server Richtlinie ... sollte es Benutzern generell gar nicht erlauben ihren Benutzernamen ... selbst zu setzen.

    Warum?

    'root' ist zwar sicher keine gute Idee, aber welchen Sicherheitsgewinn bringt ein vorgegebener Benutzername?

    eine gute Server Richtlinie ... sollte es Benutzern generell gar nicht erlauben ... ihr Passwort selbst zu setzen.

    Es wäre bestimmt nicht sicherer lediglich systemseitig vorgegebene Passwörter zu erlauben.

    Außerdem ist das Tastaturlayout zu berücksichtigen: Es dürfte schwierig werden einem Franzosen das systemseitig german-engineered Passwort

    Ha8€diesePaßwörterÜb3lstSatt!elf11!!

    schmackhaft zu machen.

    Die Prüfung des eingegebenen Passworts auf bestimmte Eigenschaften und Angriffsvektoren ist sicher eine gute Praxis.

  • Passwort natürlich nur natürliche Wörter im us ascii Raum in verschiedenen sprachen.

    Ist auf jeden Fall durchgehend sicherer und bequemer Passwörter systemseitig zu vergeben.

    Vorgegebener Benutzername ist nur bequemer. Dein Passwort Beispiel ist eine Katastrophe - schwer zu merken. Sowas kommt mir nicht in die Datenbank. 🙂

    https://xkcd.com/936/

    The universe tends toward maximum irony. Don't push it.

    Einmal editiert, zuletzt von webdesignheld (22. Oktober 2025 um 07:26)

  • Ist auf jeden Fall durchgehend sicherer und bequemer Passwörter systemseitig zu vergeben

    Ich wollte keine Meinung hören, sondern habe nach einer Begründung für die Behauptung gefragt...

    Passwort natürlich nur natürliche Wörter im us ascii Raum in verschiedenen sprachen.

    Ah, ich verstehe: Die Einschränkung des Zeichenraums verringert die Entropie was das die Sicherheit erhöht, dass Brute-Forcler eine höhere Erfolgswahrscheinlichkeit haben... ;)

    Insbesondere wenn:

    natürlich nur natürliche Wörter

    ... verwendet werden.

    Dann reichen sogar reine #Wörterbuchangriffe. ^^

    Jetzt weiß ich was Du mit "sicherer" meinst. Es geht Dir wohl um die Sicherheit für Erfolg auf Angreiferseite.

  • Das serverseitige Setzen von Passwörtern kann zwar dafür sorgen, dass gewisse Richtlinien eingehalten werden, hat aber den eklatanten Nachteil, dass dieses Passwort auch wieder irgendwie zu dem Nutzer kommen muss. So viel Mühe man sich dann beim Erstellen gibt, beim Transportweg sind dann Richtlinien meist schon wieder egal und sie landen im Klartext in irgendwelchen E-Mails. SMS ist auch nicht besser. Prinzipiell ist es nie gut, wenn ein Passwort von mehr als einer Person gesehen wird. Das Passwort an sich ist in den wenigstens Fällen das Problem (Ausnahmen bestätigen bekanntlich die Regel). Je restriktiver der Admin die Passwort Erstellung macht - desto sorgloser ist meist der Umgang der User mit diesem - vor allem wenn es nicht einmal selbst gesetzt wurde.

  • Dann reichen sogar reine #Wörterbuchangriffe

    Absolut. Fr, it, de, en, da und sv - da sind ja nicht soviele 4 Worte Konstellationen möglich. Das haben die in 1 Stunde raus. Wollen wir noch 1 Nummer und einen großen Buchstaben dazu tun um 30 Minuten länger durchzuhalten?

    The universe tends toward maximum irony. Don't push it.

    Einmal editiert, zuletzt von webdesignheld (22. Oktober 2025 um 13:24)

  • Ich wollte keine Meinung hören, sondern habe nach einer Begründung für die Behauptung gefragt...

    Die Meinung dass 4 Wörter aus einem Pool von 120.000 sicher genug gegenüber brute force versuchen sind muss ich nicht begründen. Hast du das xkcd Comic mal angeschaut? Da sinds “nur” 44bit im englischsprachigen Raum … jetzt nimm die anderen Sprachen dazu, mach einen der Buchstaben groß und setz irgendwo eine 9 hin und dann brute force mal los.

    The universe tends toward maximum irony. Don't push it.

    Einmal editiert, zuletzt von webdesignheld (22. Oktober 2025 um 14:35)

  • [netcup] Sarah G. bitte leite die Eingangsfrage an die zuständigen Supportspezialisten weiter

    Fachgebiet Accountsicherheit / Passwortsicherheitsrichtlinie Webhosting / Anlage neuer Mailaccounts

    Sämtliche bisherigen Beiträge sind (bezogen auf die Eingangsfrage) Off-Topic und niemand im Forum kennt scheinbar das Regelwerk von netcup zur Mindestpasswortsicherheit.

    In älteren Treads gibt es auch nur "professionelle" Hinweise wie 'probier's halt aus bis es klappt ' :rolleyes:

  • Hallo zusammen,

    die Passwortsicherheit wird mit Hilfe der Open-Source-Library "zxcvbn-ts" validiert. Die Bibliothek bewertet Passwörter nicht nach festen Regeln (z. B. "mindestens ein Großbuchstabe und eine Zahl"), sondern danach, wie leicht ein Angreifer das Passwort erraten könnte. Dazu analysiert sie das Passwort und erkennt typische Muster, zum Beispiel:

    • Wörter aus Wörterbüchern oder Namen
    • Zahlenreihen (z. B. "12345") oder Tastaturmuster ("qwertz")
    • Wiederholungen ("aaaaaa")
    • Geburtsdaten oder Jahreszahlen

    Aus diesen Mustern schätzt zxcvbn-ts, wie viele Versuche ein Computer bräuchte, um das Passwort zu erraten. Je mehr Versuche nötig wären, desto stärker das Passwort.

    Weitere Informationen dazu finden sich z.B. auch hier:

    https://zxcvbn-ts.github.io/zxcvbn/guide/

    In folgendem Test (mit allen Haken aktiv) muss ein Score von "3" erreicht werden, damit wird die Richtlinie "stark" erfüllt:

    https://zxcvbn-ts.github.io/zxcvbn/demo/

  • (Lars war schneller.)

    Die Plesk Regeln zur Passwort Stärke sind praktisch nicht dokumentiert, aber es gibt einen Hinweis, was "stark" heißen könnte:

    The Plesk default password strength policy under Tools & Setting > Security Policy will be changed to Strong starting from Plesk Obsidian 18.0.25.

    This policy requires passwords to be at least 8 characters long and to have at least one occurrence of upper and lower-case characters, digits, and special characters, for example: P@ssw0rd12.

    (Das Beispiel erfüllt die genannten Kriterien formal, aber es ist veröffentlicht und damit unbrauchbar.)

    2022 wurde das aber anscheinend wieder geändert. Ein Algorithmus schätzt die nötigen Versuche, um das Passwort zu knacken, aber die Regeln sind wieder nur angedeutet:

    To comply with the current security standards (like 1Password generator), the password validation functionality in Plesk was revised and improved significantly. The new validation feature is enabled by default starting from July 5th, 2022 (Obsidian 18.0.45 release)

    Die verwendete Bibliothek beschreibt die Arbeitsweise so:

    zxcvbn is a password strength estimator inspired by password crackers. It recognizes and analyzes over 40 thousand common passwords using pattern matching and conservative estimation and filters out common first names, last names, popular words from Wikipedia and common words in many cultures, and recognizes common patterns like dates, repetitions (e.g. 'aaa'), sequences (e.g. 'abcd'), keyboard smashes (e.g. 'qwertyuiop'), and l33t speak.

    Consider using zxcvbn as an algorithmic alternative to password composition policy — it is more secure, flexible, and convenient in websites that require a minimal complexity score.

    Mit anderen Worten: Die konkrete Policy ist wahrscheinlich nicht leicht in Worte zu fassen. Es gibt nur ein Orakel, das den Daumen hoch oder runter für dein Passwort gibt.

    2 Mal editiert, zuletzt von NaN (22. Oktober 2025 um 15:11) aus folgendem Grund: Zu langsam...

  • M.E. sind Wörterkombinationen (Gerne auch mal mit absichtlichen Rechtschreibfehlern drin), garniert mit Sonderzeichen und Zahlen (nicht zu viele) sehr sinnvoll.

    Leicht zu merken (Man braucht sie nirgendwo aufzuschreiben und auch keinen Passwortmanager) und nicht in endlicher Zeit zu brute-forcen.

    Just#My5zents!