Prüfen ob Anforderung an ein neues Passwort erfüllt wurden

[Jumpy]

Hallo,

für eine Anwendung mit separater Benutzerverwaltung, die ich für einen Kunden erstellen soll, sollen auch dessen generelle Anforderungen an Passwörter erfüllt werden, z.B. Mind. 3 der 4 Zeichentypen (Großbuchstaben, Kleinbuchstaben, Sonderzeichen, Zahlen)müssen enthalten sein, Mindestlänge usw.

Will also ein Nutzer sich ein neues Passwort geben, sollen diese Kriterien geprüft werden. Das meiste davon ist ja nicht wirklich schwierig, aber es gibt da noch den Punkt: Darf nicht mit den letzten x Passworten übereinstimmen oder Ähnlichkeiten zu diesen enthalten.

Das mit dem Übersinstimmen krieg ich ja noch hin, aber wie testet man das mit diesen Ähnlichkeiten? Oder muss ich da erst warten bis ich genaueres weiß, wie die Ähnlichkeit definieren? Was sind da übliche (falls es das gibt) definitionen bzw. vorgehensweisen?

[Sir Rufo]

Ja warten bis die Ähnlichkeiten definiert sind, sonst programmierst du dich zu Tode ;)

Als Vorschlag könntest du die Levensthein-Distanz unterbreiten oder du schaust dich hier mal um

[Der schöne Günther]

Großer Gott, wie ich diese Passwort-Anforderungen hasse. Dieser XKCD-Comic bringt es wirklich auf den Punkt.

Die Anforderungen hätte ich mittels regulären Ausdrücken überprüft. Die kann der Kunde eigentlich sogar selber liefern.

Ähnlichkeit finde ich wirklich sehr vage, das muss der Kunde wirklich selber definieren, das kann doch alles sein, das sieht jeder anders!

[mkinzler]

Hier würden sich reguläre Ausdrücke anbieten

[Sherlock]

Schließe mich dem Günther vorbehaltlos an und schicke noch folgende Weisheit hinterher:
Wenn man die Anwender dazu zwingt sich regelmäßig neue Passwörter auszudenken, werden diese über kurz oder lang auf einem Zettelchen am Monitor kleben. Das ist der feuchte Traum eines jeden "Datendiebs".

Sherlock

[Neutral General]

Ich finde es auch ehrlich gesagt bescheuert wenn dem User vorgeschrieben wird wie sein Passwort aussehen muss. Wenn da so ein "Komplex-o-Meter" angezeigt wird anhand dem der Benutzer ungefähr erkennen kann wie sicher sein Kennwort ist, dann ist das super. Aber wenn er dann trotzdem "123" als Kennwort setzen will, dann soll er halt.

[Klaus01]

.. es soll ja auch Firmen geben - die gewisse Rchtlinien haben bzgl. der Eigenschaft des Passworts.
z.B. bestimmte Mindestlänge, Sonderzeiche, Groß- Kleinschreibung, Ziffern.

Grüße
Klaus

[Neutral General]

Zitat:

Zitat von Klaus01 (Beitrag 1213847)

.. es soll ja auch Firmen geben - die gewisse Rchtlinien haben bzgl. der Eigenschaft des Passworts.
z.B. bestimmte Mindestlänge, Sonderzeiche, Groß- Kleinschreibung, Ziffern.

Grüße
Klaus

Ist das mittlerweile nicht quasi Standard?

[Luckie]

Des weiteren erhöht es nicht die Sicherheit, wenn man den Benutzer zwingt alle vier Wochen sein Passwort zu ändern. Ich baue ja auch nicht alle vier Wochen ein neues Schloss in meine Wohnungstür ein. Man erreicht eher das Gegenteil. Entweder werden die Passwörter immer einfache und mit leichter zu knacken oder sie werden irgendwo notiert.

[Jumpy]

Bzgl. der Passworte-Regelungen ist halt der Kunde König und da es sich in dem Fall um Banker handelt, die eh etwas paranoider sind als andere, ist dat halt so. Auch wenn mein Progrämmelchen mit deren eigentlichen Bankdaten gar nichts zu tun haben wird. Das geht bei denen sogar soweit, dass jeder bei uns im Haus deren Datenschutz Lehrgang mitmachen muss, für den Fall, das man mal an einem Projekt für die arbeitet.

Bzgl. der Ähnlichkeit harre ich mal der Dinge, die da kommen werden. Bis dahin ist der Link mit der Levensthein-Distanz und ähnlichen Geschichten schon mal sehr spannend, danke.

[BUG]

Zitat:

Zitat von Jumpy (Beitrag 1213801)

Darf nicht mit den letzten x Passworten übereinstimmen oder Ähnlichkeiten zu diesen enthalten.

Die erste Anforderung finde ich vernünftig, die zweite erscheint mir in manchen Umgebungen bedenklich: Es wäre nötig, Passwörtern im Klartext / ungehasht zu speichern und das wird eigentlich als Bad Practice angesehen. Das gilt insbesondere bei vielen "anonymen" Usern der Fall, weil die dazu neigen, Passwörter anderer Dienste/Anwendungen wiederzuverwenden.
Wenn die User bekannt sind, könntest du alternativ das Vorkommen von speziellen Zeichenketten testen (Geburtsdatum, Name des Kunden, Namen der Anwendung, Namen der Firma, Variationen davon).

Zitat:

Zitat von Neutral General (Beitrag 1213841)

Aber wenn er dann trotzdem "123" als Kennwort setzen will, dann soll er halt.

Wenn das Passwort den Wartungszugang eines Atomkraftwerk sichert, sehe ich das anders :wink:

[Namenloser]

Man könnte automatisch Variationen eines Passworts erstellen (z.B. eine im Passwort vorkommende 1 durch eine 2,3,4,5, usw. ersetzen) und diese hashen und dann vergleichen. Problem ist natürlich nur, dass, bei einer vernünftigen Passwortlänge, das extrem viele Kombinationen wären, wenn man genügend Fälle abdecken will.

Aber anders geht es imo eigentlich nicht... man könnte zwar stattdessen das Passworts irgendwie komprimieren in der Art „abc-123456-def“ → „abc-<ZAHLEN>-def“ (so SoundEx-mäßig) und dann den komprimierten String hashen und vergleichen, aber da der komprimierte String deutlich kürzer als das Passwort sein müsste, könnte ein Angreifer das Muster relativ leicht bruteforcen und so Informationen über die Struktur des Passworts erhalten, was kontraproduktiv für die Sicherheit wäre.

[sx2008]

Also ich würde so vorgehen:
Schritt 1:
Eine Klasse schreiben, die ein Passwort bewertet und dafür Punkte vergibt.
Als Vorlage was man wie bewertet kann man z.B. http://www.passwordmeter.com/ verwenden.
Es gibt da viele verschiedene Algorithmen; hier ein Beispielcode (PHP): http://www.sikosoft.com/item/writing...ngth_algorithm
Schritt 2:
Die Punkte werden dem Benutzer als farbigen (rot, gelb, grün) Balken oder als Ampel dargestellt.
Dafür gibt es eine eigene Klasse, die die Punktzahl als Input bekommt und als Output auf einem Canvas zeichnet.
Schritt 3:
Optional kann der Admin eine Mindestpunktzahl vorgeben.
Falls die geforderte Punktzahl nicht erreicht wird, wird das PW als zu schwach abgelehnt.
Schritt 4:
die letzten 5 Passwörter werden als Hash gespeichert.
So kann überprüft werden ob ein altes PW neu verwendet wird.
Wenn das neue PW dem alten PW nur ähnlich ist, würde ich das nicht als negativ bewerten.
Ein Ähnlichkeitsanalyse halte ich nicht für sinnvoll.
Vorallem müsste man für einen Vergleich der Ähnlichkeit die Passwörter selbst speichern (und nicht nur den Hash).
Das stellt aber einen eheblichen Schwachpunkt dar, weil ein Hacker so an jede Menge alter Passwörter kommen könnte, die der Benutzer auf anderen System evtl. noch im Einsatz hat.

[BUG]

Eigentlich hat Jumpy ja schon ausgeschlossen, das an der Passwortbewertung etwas geändert wird:

Zitat:

Zitat von Jumpy (Beitrag 1213850)

Bzgl. der Passworte-Regelungen ist halt der Kunde König und da es sich in dem Fall um Banker handelt, die eh etwas paranoider sind als andere, ist dat halt so.

Die Erarbeitung des Sicherheitskonzept kostete die Bank eventuell mehr als das Programm :wink:


@Jumpy: Wenn du da nicht zu Verschwiegenheit verpflichtest bist: Es würde mich schon interessieren, wie die Ähnlichkeit dann letztendlich festgestellt wird.

[p80286]

Wie wäre es die Kölner Phonetik zu nutzen ist einfach zu implementieren und kann gut an die eigenen Bedürfnisse angepasst werden. (0-O, E-3, etc.)

Gruß
K-H

[blablab]

OT:

Zitat:

Zitat von Der schöne Günther (Beitrag 1213803)

Großer Gott, wie ich diese Passwort-Anforderungen hasse. Dieser XKCD-Comic bringt es wirklich auf den Punkt.

Und am schlimmsten sind Einschränkungen wie keine Leerzeichen, Umlaute usw. Mein Onlinebanking z.B. erlaubt nur A-Z und _ und es wird nichtmal zwischen Groß- und Kleinschreibung unterschieden. Und warum, WARUM gibt es oft eine Maximallänge für Passwörter? Hab zuletzt sogar eine Maximallänge von 8 Zeichen gesehen! Ich kanns ja verstehen dass es ab 50 Zeichen etwas merkwürdig wird, aber wen juckt's?

Und wirklich leicht zu merkende aber sichere Passwörter wie aus dem Comic werden zum Großteil alle verboten durch die "tollen" Anforderungen wie Groß- und Kleinbuchstaben und Zahlen und Sonderzeichen und und und...

Ich würde zwar auch eine Meldung bringen wenn ein Passwort schlecht zu sein scheint, aber man muss es dann ja nicht immer gleich verbieten.