Entropie-Schätzung

(Javascript benötigt; bisher nur Firefox-getestet)

sichtbar:
verschleiert:
Länge: 0, Entropie: 0.0 (bei umgangssprachlicher Phrase etwa: 0.0)

(benutzt nur den Standard-Javascript-Zufallsgenerator)
alle ASCII-Codes über Alt-Nummerntasten-Kombinationen
alle üblichen Akzent-Vokale
alle üblichen Sonderzeichen
Satzzeichen und Grundrechnungs-Operatoren
Dezimalziffern
deutsches Alphabet (Großbuchstaben)
deutsches Alphabet (Kleinbuchstaben) und Leerzeichen

Debugging

Was soll das Ganze?

Dieses Modul liefert eine Entscheidungshilfe für die Definition von Passwörtern, um sie so stark zu machen, daß aus offen abgelegten Hashwerten der Passwörter nicht effektiv deren Klartext abgeleitet werden kann.

Die offene Ablage von Passdaten muß in aller Regel einkalkuliert werden. In der Regel verlangt die Betriebsorganisation eines Systems, daß zumindest für Kontrollzwecke lesender Zugriff auf Passdaten für Personen möglich ist, die trotz ihrer Funktion keinen Zugang zu den Klartexten erhalten sollen. Mitunter ist es im Interesse solcher Personen notwendig, daß diese beweisbar belegen können, trotz ihrer Funktion keinen Zugang zum Klartext zu haben. Mitunter läßt sich nicht vermeiden, daß Passdaten über offen lesbare Kanäle übertragen werden müssen.

Unter den dargelegten Bedingungen folgt, daß Passwörter zwingend verschlüsselt abgelegt werden müssen, wenn sie denn abgelegt werden müssen. Da auch eventuelle Passphrasen für die verschlüsselte Ablage den genannten Bedingungen unterliegen würden, bringt eine echte Verschlüsselung nur begrenzten Nutzen - wenn die Schlüsselablage von der Schlüsselberechnung getrennt ist und ein Angreifer dadurch eine zusätzliche Hürde zu nehmen hat. Der wesentliche Sicherungsbeitrag wird durch den Charakter einer Hashwertberechnung geleistet.

Hashwerte können trivial ausreichend breit angelegt werden, so daß ein Zurückberechnen des Klartextes aus dem Hashwert analytisch unmöglich ist. Das hindert jedoch nicht, Hashwerte für einige zig bit variante Passphrasen zu berechnen und mit gekaperten Hashwerten zu vergleichen:
Passwort-Cracker als Bezahldienst
Angriff auf Passwörter in Windows-Netzwerken

Für den Schutz gegen eben jenen Angriff dient dieses Modul. Es hilft, ein Passwort so stark zu machen, daß ein Angreifer zu viele Varianten von Passwörtern durchzuspielen hätte, um auf diese Weise effektiv an einen Treffer zu gelangen.
Es wird dabei berücksichtigt, daß in Botnetzen Datenbanken abgelegt werden können, die eine Hashwert-Identifizierung extrem billig über recht große Varianzbereiche realisieren können, sofern die Hashwerte nur in die Muster passen, die in die Datenbankerzeugung eingeflossen sind.
Die Variantenbreite, die damit abgedeckt werden kann, entwickelt sich fortlaufend proportional zum Stand der Technik, 2007 etwa 32 bit je Zombie-PC (Hashwerte nach SHA1: 128 bit alias 16 byte mal 4 Giga, entsprechend etwa 64 Gigabyte gekapertem Speicherplatz, was in der Welt der 500 Gigabyte Datenträger und zig bis hunderten Gigabyte gesammelten Mediendateien nicht auffällt) bei Botnetzen der Größenordnung von 10'000 Rechnern, entsprechend etwa 45 bit je Botnetzbetreiber, wachsend derzeit um etwa ein halbes bit pro Jahr, voraussichtlich also:

201047 bit
202052 bit
203057 bit
usw.

Ziel des Moduls ist es, einen Hinweis auf die Stärke eines Passwortes in Bezug auf solche Angriffe zu liefern, so daß der Benutzer es hinreichend komplex machen kann, als daß es in einer solchen Datenbank gefunden wird.

Ich orientiere darauf, Passworten für geringere Bedeutung (nur Zugang zu begrenzten Ressourcen, die keinen entscheidenden Einfluß auf den Betrieb des zu schützenden Systems haben können) eine Sicherheit von mindestens 1:1000 pro Jahr und gesamtes zu schützendes System mitzugeben. Wobei ich mit diesem Sicherheitsfaktor wohl kaum zu den Paranoiden gehören dürfte...

Diese Überlegung gründet sich darauf, daß die Benutzung einer verteilten Datenbank immer viel ökonomischer ist als ein erneutes Zusammenstellen von Hashwerten vor Ort (wobei solches nichtsdestotrotz ausgeführt werden kann und insbesondere dann wirksam sein kann, wenn das Einbruchsprogramm das Herauslassen der in der Datenbank enthaltenen Varianten bei gleichzeitigem Spezifizieren von örtlichen Besonderheiten unterstützt). Dadurch träte bei wiederholten Angriffen auf ein und dasselbe Passwort keine Erhöhung der Trefferwahrscheinlichkeit ein. Eine erneuter Versuch würde sich also erst lohnen, wenn das Passwort geändert oder die Hashwert-Datenbank neu angelegt wird. Beides nehme ich hier mal pauschal mit nicht viel öfter als einmal im Jahr an...

Dies reicht aus, um gezieltes Einbrechen hinreichend unattraktiv zu machen. Es KANN ausreichen, um Versicherungen zu befriedigen. Bei wichtigen Passworten, wertvollen Systemen, mit der Streubreite automatisierter Angriffe und wahrscheinlich aus Sicht von Versicherungen steigen die Anforderungen.
In das Sicherheitsverhältnis sollen ALLE im System verwendeten Passworte passen, da eine einzelne Einbruchstelle für einen erfolgreichen Einbruch ausreicht. Dementsprechend ist der Sicherheitsfaktor um die Menge der Mitarbeiter und der von ihnen pro Jahr verwendeten Passworte in Bezug auf das zu schützende System zu erweitern.

Die Orientierung für einfache Passworte bedeutet damit zur Zeit (2007) in einem kleinen Unternehmen (sagen wir - 8 Mitarbeiter) und bei einem Passwort pro Jahr und Mitarbeiter folgende Entropie-Forderung in Bits:

45 (Datenbank) + 10 (Sicherheit) + 3 (Mitarbeiter mal Passwortmenge) = 58 (aufgerundet zu 60)

Entropie - zur Erinnerung - ist das Maß der Ungewissheit eines Interpreters (!) eines Dingens über das Aussehen des Dingens. Ist also z.B. ein Dingens streng nach einer Regel aufgebaut und kennt der Interpreter diese Regel vorab, ist die Entropie gleich Null.
Die Regeln, auf die hier eingegangen wird, sind jene, die auch ein Passwort-Angreifer befolgen würde. Es sind "Gebrauchsregeln", welche am wahrscheinlichsten von Menschen beim Festlegen von Passwörtern angewendet werden.
Dies betrifft in erster Linie:
Dabei geht es um die Eingabe durch Menschen, die in der Regel Probleme damit haben, sich an Passworte zu erinnern und deshalb versuchen, diese so einfach wie möglich zu gestalten. Außerdem darum, daß der Zugriff auf größere Zeichenbereiche über die Tastatur stufenweise viel aufwendiger und deshalb gemieden wird.
Ich setze voraus, daß ein Angreifer nicht ohne weiteres in der Lage ist, zu einem konkreten Hashwert den konkret dafür verwendeten Zeichenbereich zu ermitteln (falls er das könnte, würde er eher wahrscheinlich das konkrete Passwort bereits wissen). Er hat also keine andere Wahl, als allgemeine Kriterien beim Durchtesten der Zeichenvarianten anzusetzen.
Dazu zählt, daß die Kleinbuchstaben auf den üblichen westlichen Tastaturen die bevorzugt für Worte bzw. Phrasen verwendeten sind und die Wahrscheinlichkeit der Verwendung anderer Zeichenbereiche mit der Schwierigkeit ihres Einsatzes schwindet. Ein Angreifer wird die am wahrscheinlichsten verwendeten Zeichenklassen zuerst probieren und dann den Variantenbereich immer weiter ausdehnen. Die angesetzten Beurteilungen orientieren sich an dieser Strategie.

Die Beurteilung umgangssprachlicher Silben ist noch nicht implementiert. Behelfsmäßig kann erstmal davon ausgegangen werden, daß die Entropie bei Verwendung solcher Silben um einen Faktor verringert wird (ich habe hier im Beipiel einen Faktor von 2 angesetzt, gehe aber davon aus, daß es eher in die Größenordnung von 3 geht). Der Benutzer muß momentan noch selbst die mentale Schwerarbeit aufbringen, zu entscheiden, ob er solche Silben verwendet.

Mangels Möglichkeiten ist dieses Modul zur Zeit auf westliche Tastaturen und ASCII-Zeichensatz beschränkt. Mir stehen eh keine anderen als die westlichen Tastaturen und Betriebssysteme zur Verfügung, und ich beherrsche eh keine Sprache, die über den ASCII-Zeichensatz hinausgeht. Ich könnte für weitergehende Zeichensätze also weder sinnvoll entwickeln noch irgendwas davon testen. Des weiteren besteht keinerleii derartige Anforderung.

Einige Betrachtungen zu konkreten Erscheinungen

Platzierungs-Gruppierung

Alias Berücksichtigung von Umgangssprache.
Noch nicht implementiert.

Dem zu erwartenden menschlichen Verhalten geschuldet: Neben der Bevorzugung von Zeichenwiederholungen tendieren Menschen auch dazu, sich die Arbeit durch Benutzung umgangssprachlicher Silben oder einfache Gruppierungschemas zu vereinfachen.

Ein Angreifer wird seine Testfolgen so gestalten, daß er die Anordnungen mit umgangssprachlichen Regelmäßigkeiten zuerst testet bzw. katalogisiert. Das Problem für Angreifer wie Verteidiger besteht darin, die möglichen Vereinfachungen zu kennen und zu berücksichtigen.

(in Arbeit...)