Selbstgewählte Passwörter für die Tür sollten genügend Entropie enthalten

[Felix Kästner]

Selbstgewählte Passwörter für die Tür sollten genügend Entropie enthalten

Die Vereinsmitglieder können sich ein Passwort für die Schließanlage selbst wählen (man erstellt ein Passwort, berechnet den Hash und nur dieser wird an die Schließanlagenverantwortlichen weiter gereicht). Es sollte aber sicher gestellt werden, dass die Passwörter ein gewisses Mindestmaß an Entropie enthalten.

Hier gibt es vermutlich diese Fragen zu klären:

1. Muss das Passwort vom Nutzer selbst generiert werden können?
2. Wie kann man (als Betreiber des Schließsystems) bei einem selbstgewählten Passwort ein Mindestmaß an Entropie sicher stellen?

Momentan besteht das Risiko, dass ein Nutzer aus Bequemlichkeit oder Unwissen ein sehr einfaches Passwort wählt und damit eine brute-force Attake auf die Schließanlage recht erfolgversprechend wird.

[Felix Kästner]

Noch ein paar Gedanken:

• Zu 1.: Wenn das Passwort nie den Hoheitsbereich des Besitzers verlässt, dann ist es besonders sicher. Wenn die Betrieber der Schließanlage das Passwort nicht kennen, dann können die Passwörter weiter benutzt werden, wenn die Betreiber wechseln.
• Zu 2.: Der Raspi bekommt bei einem Öffnungsversuch das Passwort im Klartext. Er könnte also folgendes prüfen: Mindestlänge, Mindestanzahl an unterschiedlichen Zeichen. Leider wird es bei allen Regeln weiterhin ein triviales Passwort geben, was den Regeln genügt, aber leicht erratbar ist. Das ist also keine Besonders gute Lösung.

Vielleicht ist es aber auch möglich, dass das Passwort generiert wird und dann kurz einem Verantwortlichen gezeigt wird. Man kann sich so das passwort nicht merken, aber man kann sehen, ob es "sicher aussieht".

Dann ist mir aufgefallen, dass vermutlich bei vielen Nutzern das Passwort vom Rechner aufs Smartphone übertragen werden muss. Das macht ja bei über 70 Zeichen kaum Spass. Vielleicht war daher die Idee, dass man ein Passwort wählen kann, was man sich merken oder es einfach übertragen kann. Dann muss man die Sache vermutlich nochmal übredenken.

[bernd]

Der qbi hat sich auch mal ein paar Gedanken gemacht:

1. Ich würde die Ursprungsfrage eher verneinen. Vielmehr sollte das Passwort vom Betreiber der Türanlage generiert werden und an die Nutzerin oder den Nutzer ausgehändigt werden. Auf die Art und Weise kann sichergestellt werden, dass das Passwort bestimmten Anforderungen genügt. Änderungen des Passwortes müssen dann ebenso von den Betreibern vorgenommen werden. Auf der anderen Seite hat man das Problem, dass die Betreiber das Passwort kennen. Aus meiner Sicht ist das Problem immer vorhanden. Denn die Betreiber können einfach den Traffic mitschneiden und die Passwörter abspeichern. Damit schafft man sich mit der Vorgehensweise keine neuen Probleme, löst aber das Problem eines eventuell schwachen Passworts.

2. siehe 1. :-)

[bernd]

Replying to fpunktk:

Dann ist mir aufgefallen, dass vermutlich bei vielen Nutzern das Passwort vom Rechner aufs Smartphone übertragen werden muss. Das macht ja bei über 70 Zeichen kaum Spass. Vielleicht war daher die Idee, dass man ein Passwort wählen kann, was man sich merken oder es einfach übertragen kann. Dann muss man die Sache vermutlich nochmal übredenken.

Ich halte die >70 Zeichen ebenfalls für Overkill und eine starke Beeinträchtigung bei der Usability. Mit dem derzeitigen Algorithmus stehen 37 Zeichen zur Verfügung. Unter der Annahme, dass die mit SHA1 oder SHA2 gespeichert werden, reichen mindestens 12 Zeichen für eine sichere Speicherung (Ermittlung eines Passworts dauert durchschnittlich 100 Jahre pro GPU). Mit einem der in #69 vorgeschlagenen Algorithmen könnte man sogar auf acht Zeichen heruntergehen und eine ähnliche Sicherheit erreichen. Obiges sind natürlich grobe Schätzungen.

[Felix Kästner]

Replying to bernd:

Der qbi hat sich auch mal ein paar Gedanken gemacht:

1. Ich würde die Ursprungsfrage eher verneinen. Vielmehr sollte das Passwort vom Betreiber der Türanlage generiert werden und an die Nutzerin oder den Nutzer ausgehändigt werden. Auf die Art und Weise kann sichergestellt werden, dass das Passwort bestimmten Anforderungen genügt. Änderungen des Passwortes müssen dann ebenso von den Betreibern vorgenommen werden. Auf der anderen Seite hat man das Problem, dass die Betreiber das Passwort kennen. Aus meiner Sicht ist das Problem immer vorhanden. Denn die Betreiber können einfach den Traffic mitschneiden und die Passwörter abspeichern. Damit schafft man sich mit der Vorgehensweise keine neuen Probleme, löst aber das Problem eines eventuell schwachen Passworts.

So war es vorher. Das hat aber entscheidende Nachteile:

• wenn ein Betreiber den Verein verlässt, dann müssen alle Passwörter gewechselt werden
• die Passwortvergabe ist recht kompliziert, weil man einen guten verschlüsselten Kanal oder ein persönliches Treffen braucht. Den Hash kann man wohl auch unverschlüsselt übertragen und muss nur sicher stellen, dass er von der korrekten Person kommt. (Keine Ahnung, ob das so viel besser ist.)

Da ich den Betreibern so weit verrtauen würde, dass sie keine Hintertür einbauen (dann müsste man bei einem Betreiberwechsel ja den Router neu aufsetzen), bin ich weiterhin für die Lösung, dass man das generierte Passwort einfach kurz vorzeigt. Das macht die Passwortvergabe natürlich wieder komplizierter :-/

Replying to bernd:

Ich halte die >70 Zeichen ebenfalls für Overkill und eine starke Beeinträchtigung bei der Usability. Mit dem derzeitigen Algorithmus stehen 37 Zeichen zur Verfügung. Unter der Annahme, dass die mit SHA1 oder SHA2 gespeichert werden, reichen mindestens 12 Zeichen für eine sichere Speicherung (Ermittlung eines Passworts dauert durchschnittlich 100 Jahre pro GPU). Mit einem der in #69 vorgeschlagenen Algorithmen könnte man sogar auf acht Zeichen heruntergehen und eine ähnliche Sicherheit erreichen. Obiges sind natürlich grobe Schätzungen.

Hier gehe ich mit. Ich würde 20 bis 25 zufällige Zeichen vorschalgen.

Was aber noch gar nicht betrachtet wurde ist die Idee hinter der initialen Entscheidung die Passwörter vom Nutzer generieren zu lassen.

[helix]

Entsprechende Checks sind/wurden eingebaut. Die aktuelle Implementierung entspricht in erweiterter Form der alten Lösung und hat so deren Vor- und Nachteile, ist aber sicher genug.
Dieses Ticket entspricht von den Voraussetzungen nicht den Gegebenheiten.

[Jens Kubieziel]

Die »Lösung« ist nicht sinnvoll und muss auf einen funktionierenden Stand zurückgesetz werden.