Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Passwortregeln

2 views
Skip to first unread message

Helmut Richter

unread,
Mar 11, 2023, 1:32:45 PM3/11/23
to
Jeder, der Dienste anbietet, die er mit Passwörtern schützen will, erfindet
Regeln, die die Benutzer dabei einhalten sollen. Das dümmste mir bis jetzt
begegnete Schema ist:

1. mindestens 8, jedoch nicht mehr als 20 Zeichen

2. mindestens einen Klein- und Großbuchstaben

3. mindestens zwei der folgenden Zeichen: 1,2,3,4,5,6,7,8,9,0,_,-,#,(,),@,§,!
(andere Zeichen sind nicht zugelassen)

4. keine Verkettung identischer 4er-Gruppen (z.B. "aB11aB11"), wobei dies
nur für die direkte Aneinanderreihung gilt

5. nicht mehr als zwei aufeinanderfolgende gleiche Zeichen (z.B. "aB111222")

6. keine Umlaute

Warum finde ich das dumm?

(1) ist vernünftig, (2) auch, (3) soweit es um Nicht-Buchstaben geht auch.

Die in (3) willkürlich ausgeschlossenen ASCII-Zeichen
Komma,$,%,&,*,+,.,/,:,;,<,=,>,[,\,],{,|,} (um mal solche zu nennen, die sich
nicht als Diakritika komisch verhalten könnten) haben überhaupt keinen Grund
– sie kommen bei mir durchaus auch in Passwörtern vor. Hier wird also die
mögliche Komplexität unnötig verringert, bis es schwierig wird, merkbare
Passwörter einer bestimmten Bauart zu generieren. Ebenso willkürlich sind die
Regeln (4) und (5), die nur wenige schlechte Passwörter ausschließen, daneben
aber auch viele mögliche gute. Dagegen wird genau *ein* Nicht-ASCII-Zeichen
zugelassen, nämlich §.

Schließlich sind (4) und (5) so willkürlich, dass sie vermutlich ebensoviele
gute Passwörter ausschließen wie schlechte ermöglichen.

Aber das sollte nur ein Beispiel sein, was man sich alles ausdenken kann.
Jetzt meine Frage: wie verhalten sich Programme, die neue, sichere Passwörter
generieren und speichern, gegenüber solcher Forderungen? Gibt es einen aus
der Erfahrung (nicht durch ein Normungsgremium) etablierten Mindeststandard,
wie zufällig ein Passwort mindestens sein muss und höchstens sein kann?
Vermutlich nicht. Aber ohne das kann man keine Regeln festlegen, die dann
auch von den Passwortspeichern eingehalten werden können.

--
Helmut Richter

Arno Welzel

unread,
Mar 12, 2023, 3:04:34 PM3/12/23
to
Helmut Richter, 2023-03-11 19:32:

> Jeder, der Dienste anbietet, die er mit Passwörtern schützen will, erfindet
> Regeln, die die Benutzer dabei einhalten sollen. Das dümmste mir bis jetzt
> begegnete Schema ist:
>
> 1. mindestens 8, jedoch nicht mehr als 20 Zeichen
>
> 2. mindestens einen Klein- und Großbuchstaben
>
> 3. mindestens zwei der folgenden Zeichen: 1,2,3,4,5,6,7,8,9,0,_,-,#,(,),@,§,!
> (andere Zeichen sind nicht zugelassen)
>
> 4. keine Verkettung identischer 4er-Gruppen (z.B. "aB11aB11"), wobei dies
> nur für die direkte Aneinanderreihung gilt
>
> 5. nicht mehr als zwei aufeinanderfolgende gleiche Zeichen (z.B. "aB111222")
>
> 6. keine Umlaute

[...]

> Aber das sollte nur ein Beispiel sein, was man sich alles ausdenken kann.
> Jetzt meine Frage: wie verhalten sich Programme, die neue, sichere Passwörter
> generieren und speichern, gegenüber solcher Forderungen? Gibt es einen aus
> der Erfahrung (nicht durch ein Normungsgremium) etablierten Mindeststandard,
> wie zufällig ein Passwort mindestens sein muss und höchstens sein kann?
> Vermutlich nicht. Aber ohne das kann man keine Regeln festlegen, die dann
> auch von den Passwortspeichern eingehalten werden können.

Und was hat das mit de.comm.infosystems.www.authoring.misc zu tun?

Mir ist auf Anhieb kein Standard bekannt, der Regeln für sichere
Passwörter definiert. Aber vielleicht wissen Andere da noch mehr.

X'Post und F'up nach de.comp.security.misc.


--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

unread,
Mar 12, 2023, 3:32:36 PM3/12/23
to
On 2023-03-11 18:32, Helmut Richter <hr.u...@email.de> wrote:
> Jeder, der Dienste anbietet, die er mit Passwörtern schützen will, erfindet
> Regeln, die die Benutzer dabei einhalten sollen. Das dümmste mir bis jetzt
> begegnete Schema ist:

...

> Aber das sollte nur ein Beispiel sein, was man sich alles ausdenken kann.
> Jetzt meine Frage: wie verhalten sich Programme, die neue, sichere Passwörter
> generieren und speichern, gegenüber solcher Forderungen? Gibt es einen aus
> der Erfahrung (nicht durch ein Normungsgremium) etablierten Mindeststandard,
> wie zufällig ein Passwort mindestens sein muss und höchstens sein kann?
> Vermutlich nicht. Aber ohne das kann man keine Regeln festlegen, die dann
> auch von den Passwortspeichern eingehalten werden können.

HTML kennt drei Attribute, mit denen Anforderungen an das Passwort dem
User-Agent (und damit auch einem Passwort-Manager) mitgeteilt werden
können:

minlength
maxlength
pattern

Die ersten beiden sollten selbsterklärend sein.
Der dritte spezifiziert eine Regular Expression, der das Passwort
genügen muss. Einschränkungen im Character-Set sind damit trivial
möglich (für Dein Beispiel pattern="[-_#()@§!0-9A-Za-z]+"), aber Regeln
wie "mindestens 2 aus dieser Klasse" oder "keine Wiederholungen"
brauchen schon ein bisschen Hirnschmalz, wenn sie in JavaScript-REs
überhaupt ausdrückbar sind (ich bin da Perl-REs gewohnt, und dagegen
fühlt sich JavaScript immer so ... unfertig ... an).

Ob Passwort-Generatoren diese Attribute auswerten, weiß ich nicht.
minlength und maxlength wären wohl trivial möglich, beim pattern ist es
etwas schwieriger: Man kann nicht einfach solange zufällige Passwörter erzeugen
bis das Pattern matcht (das würde nicht in brauchbar kurzer Zeit
terminieren), man müsste einen Generator schreiben, der aus einer RE
zufällige Strings generiert. Für echte Regular Expressions keine
Hexerei, bei JavaScript-kompatiblen möglicherweise nicht ganz trivial.

hp

Helmut Richter

unread,
Mar 14, 2023, 6:04:19 AM3/14/23
to
[ Xpost weil Vorposter da gepostet hat, und weil in de.comp.security.misc
öfters wochenlang tote Hose ist ]
Meine Frage war weniger technisch gemeint (wie setze ich meine Regeln
durch?), sondern eher praktisch (was für Regeln kann ich sinnvollerweise
verwenden?): ich kann als Betreiber von passwortgeschützten Diensten nicht
von meinen Benutzern verlangen, dass sie mindestens eine Ziffer oder ein
Sonderzeichen im Passwort haben, und dann kriegen sie von einem
Passwortspeicher, z.B. einem Browser, ein „sicheres“ Passwort
vorgeschlagen, das diese Bedingung nicht erfüllt und deswegen von meinem
Dienst nicht akzeptiert wird.

Ich kann also sehr wenig verlangen (höchstens: nicht alles Groß- und nicht
alles Kleinbuchstaben, aber sonst nichts) und auch sehr wenig verbieten
(z.B. Nicht-ASCII-Zeichen), weil ich nicht sicher sein kann, dass der
Passwortspeicher sich an meine Regeln hält. Eine vernünftige Mindestlänge
(irgendwo um 8 bis 10) werde ich wohl durchsetzen können.

Ich habe auch beim Testen des Formulars die Erfahrung gemacht, dass
zumindest Firefox nicht in jedem generierten Passwort eine Ziffer hat, und
anscheinend gibt es überhaupt keine Passwörter jenseits von [0-9A-Za-z]*.
Außerdem war ich verwundert, öfters dasselbe „sichere“ Passwort angeboten
bekommen zu haben. Das wäre eine böse Sicherheitslücke, wenn unter
denselben Bedingungen (gleiches altes Passwort, gleiches Zielsystem)
tatsächlich vorhersagbare Passwörter generiert würden, aber ich will das
nicht behaupten, ohne es systematisch getestet zu haben – bis jetzt ist
das nur eine zufällige Beobachtung.

--
Helmut Richter

Lars Gebauer

unread,
Mar 14, 2023, 6:47:07 AM3/14/23
to
Am 14.03.2023 um 11:04 schrieb Helmut Richter:
> Ich kann also sehr wenig verlangen (höchstens: nicht alles Groß- und nicht
> alles Kleinbuchstaben, aber sonst nichts) und auch sehr wenig verbieten
> (z.B. Nicht-ASCII-Zeichen), weil ich nicht sicher sein kann, dass der
> Passwortspeicher sich an meine Regeln hält. Eine vernünftige Mindestlänge
> (irgendwo um 8 bis 10) werde ich wohl durchsetzen können.

Ich würde ja 12, besser noch 14 oder mehr, Zeichen durchsetzen und den
Rest dem Benutzer überlassen. Länge schlägt Komplexizität und
Komplexizität hat immer die Tendenz, geradenwegs in die Esoterik zu führen.

--
| Die Drachenschlucht ist ein Ort voller Magie
| Wo einst ein Lindwurm hauste und schrie
--ChatGPT versuchte sich an einem Gedicht über die Drachenschlucht bei
Eisenach

Peter J. Holzer

unread,
Mar 14, 2023, 3:25:29 PM3/14/23
to
On 2023-03-14 10:04, Helmut Richter <hr.u...@email.de> wrote:
> On Sun, 12 Mar 2023, Peter J. Holzer wrote:
>
>> On 2023-03-11 18:32, Helmut Richter <hr.u...@email.de> wrote:
>> > Jeder, der Dienste anbietet, die er mit Passwörtern schützen will, erfindet
>> > Regeln, die die Benutzer dabei einhalten sollen. Das dümmste mir bis jetzt
>> > begegnete Schema ist:
>>
>> ...
>>
>> > Aber das sollte nur ein Beispiel sein, was man sich alles ausdenken kann.
>> > Jetzt meine Frage: wie verhalten sich Programme, die neue, sichere Passwörter
>> > generieren und speichern, gegenüber solcher Forderungen? Gibt es einen aus
>> > der Erfahrung (nicht durch ein Normungsgremium) etablierten Mindeststandard,
>> > wie zufällig ein Passwort mindestens sein muss und höchstens sein kann?
>> > Vermutlich nicht. Aber ohne das kann man keine Regeln festlegen, die dann
>> > auch von den Passwortspeichern eingehalten werden können.
>>
>> HTML kennt drei Attribute, mit denen Anforderungen an das Passwort dem
>> User-Agent (und damit auch einem Passwort-Manager) mitgeteilt werden
>> können:
>>
>> minlength
>> maxlength
>> pattern
[...]
> Meine Frage war weniger technisch gemeint (wie setze ich meine Regeln
> durch?), sondern eher praktisch (was für Regeln kann ich sinnvollerweise
> verwenden?): ich kann als Betreiber von passwortgeschützten Diensten nicht
> von meinen Benutzern verlangen, dass sie mindestens eine Ziffer oder ein
> Sonderzeichen im Passwort haben, und dann kriegen sie von einem
> Passwortspeicher, z.B. einem Browser, ein „sicheres“ Passwort
> vorgeschlagen, das diese Bedingung nicht erfüllt und deswegen von meinem
> Dienst nicht akzeptiert wird.

Ich würde außer der Länge nichts vorschreiben. Diese
"Komplexitätsregeln" verhindern schlechte Passwörter nicht aber
verhindern oft gute ("Passwort1" wäre nach unseren Regeln zulässig,
"6fw6ykqndh67cj0" nicht).

Etwas, was ich seit längerem vorhabe, aber noch nie umgesetzt habe, ist
Passwörter gegen die Liste von haveibeenpwned abzugleichen. Wenn ein
Passwort darin vorkommt, sollte man es nicht verwenden.


> Ich habe auch beim Testen des Formulars die Erfahrung gemacht, dass
> zumindest Firefox nicht in jedem generierten Passwort eine Ziffer hat, und
> anscheinend gibt es überhaupt keine Passwörter jenseits von [0-9A-Za-z]*.

Interessant. Ich habe Passwörter im Passwort-Manager, die sicher von
Firefox generiert wurden und Interpunktionszeichen enthalten. Beim
aktuellen Firefox bekomme ich aber auch nur Buchstaben und Ziffern.
Offenbar wurde das vor nicht allzulanger Zeit geändert.

> Außerdem war ich verwundert, öfters dasselbe „sichere“ Passwort angeboten
> bekommen zu haben.
> Das wäre eine böse Sicherheitslücke, wenn unter
> denselben Bedingungen (gleiches altes Passwort, gleiches Zielsystem)
> tatsächlich vorhersagbare Passwörter generiert würden, aber ich will das
> nicht behaupten, ohne es systematisch getestet zu haben – bis jetzt ist
> das nur eine zufällige Beobachtung.o

Hmm. Ich bekomme ein anderes Passwort, wenn ich einen neuen Tab öffne
oder deb Browser neu starte und auch wenn ich im gleichen Tab auf eine
andere Domain wechsle. Wenn ich hingegen im gleichen Formular
hintereinander mehrere Passwörter generieren lasse (auch mit anderen
Usernamen) bekomme ich immer das gleiche Passwort. Offenbar merkt sich
Firefox das Passwort und schlägt es wieder vor, wenn er der Meinung ist,
dass es das gleiche sein sollte. Ich sehe da definitiv Situationen, wo
das nach hinten los gehen könnte.

hp
0 new messages