Warnung bei impliziter Zustimmung

In Python 3.6 gibt die implizite Zustimmung zur Verwendung des deterministischen PRNG eine Deprecation-Warnung aus, die folgende Prüfung verwendet.

if not isinstance(_inst, Random):
    warnings.warn(DeprecationWarning,
                  "Implicitly ensuring repeatability. "
                  "See help(random.ensure_repeatable) for details")
    ensure_repeatable()

Der genaue Wortlaut der Warnung sollte mit einer geeigneten Antwort auf Stack Overflow versehen werden, so wie es für die benutzerdefinierte Fehlermeldung beim Aufruf von print ohne Klammern geschehen ist [10].

In der ersten Python 3-Version, nachdem Python 2.7 in den reinen Sicherheitsfix-Modus wechselt, wird die Deprecation-Warnung zu einer RuntimeWarning hochgestuft, damit sie standardmäßig sichtbar ist.

Diese PEP schlägt nicht vor, die Möglichkeit abzuschaffen, sicherzustellen, dass der standardmäßig verwendete RNG prozessweit ein deterministischer PRNG ist, der bei gegebenem Seed die gleiche Ausgabereihe erzeugt. Diese Funktionalität wird in Modellierungs- und Simulationsszenarien häufig verwendet, und die Anforderung, dass ensure_repeatable() entweder direkt oder indirekt aufgerufen wird, ist eine ausreichende Verbesserung, um die Fälle zu lösen, in denen die Modul-Level-Random-API in Webanwendungen für sicherheitsrelevante Aufgaben ohne angemessene Berücksichtigung der potenziellen Sicherheitsimplikationen der Verwendung eines deterministischen PRNG verwendet wird.

Performance-Auswirkungen

Aufgrund des großen Leistungsunterschieds zwischen random.Random und random.SystemRandom werden Anwendungen, die auf Python 3.6 portiert werden, in Fällen, in denen

• die Anwendung die Modul-Level-Random-API verwendet
• kryptografische Qualität der Zufälligkeit nicht benötigt wird
• die Anwendung nicht bereits implizit durch Aufruf von random.seed, random.getstate oder random.setstate auf den deterministischen PRNG zurückschaltet
• die Anwendung nicht aktualisiert wird, um explizit random.ensure_repeatable aufzurufen

eine erhebliche Leistungsregression erfahren. Dies würde im Abschnitt "Porting" des Python 3.6 "What's New"-Leitfadens vermerkt werden, mit der Empfehlung, den folgenden Code im __main__-Modul betroffener Anwendungen aufzunehmen.

if hasattr(random, "ensure_repeatable"):
    random.ensure_repeatable()

Anwendungen, die kryptografisch hochwertige Zufälligkeit benötigen, sollten unabhängig von Geschwindigkeitsüberlegungen den System-Zufallszahlengenerator verwenden. In diesen Fällen behebt die in dieser PEP vorgeschlagene Änderung einen zuvor latenten Sicherheitsfehler.

Änderungen an der Dokumentation

Die Dokumentation des random-Moduls würde aktualisiert werden, um die Dokumentation der Schnittstellen seed, getstate und setstate weiter unten im Modul zu verschieben, zusammen mit der Dokumentation der neuen Funktion ensure_repeatable und der zugehörigen Sicherheitswarnung.

Dieser Abschnitt der Moduldokumentation würde auch eine Diskussion der jeweiligen Anwendungsfälle für den deterministischen PRNG, der durch ensure_repeatable ermöglicht wird (Spiele, Modellierung und Simulation, Softwaretests) und den System-RNG, der standardmäßig verwendet wird (Kryptografie, Generierung von Sicherheitstokens), enthalten. Diese Diskussion würde auch die Verwendung von Drittanbieter-Sicherheitsbibliotheken für letztere Aufgabe empfehlen.

Warum "ensure_repeatable" statt "ensure_deterministic"?

Dies ist ein Fall, in dem die Bedeutung eines Wortes als Fachjargon mit der typischen Bedeutung des Wortes kollidiert, obwohl es *technisch* dasselbe ist.

Aus technischer Sicht bedeutet ein "deterministischer RNG", dass man bei Kenntnis des Algorithmus und des aktuellen Zustands zuverlässig beliebige zukünftige Zustände berechnen kann.

Das Problem ist, dass "deterministisch" allein diese Qualifikationen nicht vermittelt, so dass es wahrscheinlich stattdessen von Leuten, die die konventionelle Bedeutung kennen, aber nicht mit den zusätzlichen Qualifikationen der technischen Bedeutung vertraut sind, als "vorhersehbar" oder "nicht zufällig" interpretiert wird.

Ein zweites Problem mit "deterministisch" als Beschreibung für den traditionellen RNG ist, dass es nicht wirklich angibt, was man mit dem traditionellen RNG tun kann, was man nicht mit dem System-RNG tun kann.

"ensure_repeatable" zielt darauf ab, beide Probleme zu lösen, da seine gebräuchliche Bedeutung den Hauptgrund für die Bevorzugung des deterministischen PRNG gegenüber dem System-RNG genau beschreibt: die Sicherstellung, dass dieselbe Reihe von Ausgaben durch Angabe desselben Seed-Werts oder durch Wiederherstellung eines zuvor gespeicherten PRNG-Zustands wiederholt werden kann.

Nur Änderung des Standardwerts für Python 3.6+

Einige andere neuere Sicherheitsänderungen, wie die Verbesserung der Fähigkeiten des ssl-Moduls und die standardmäßige Umstellung auf die korrekte Überprüfung von HTTPS-Zertifikaten, wurden als so kritisch erachtet, dass die Änderung in alle derzeit unterstützten Python-Versionen zurückportiert wurde.

Der Unterschied in diesem Fall liegt im Grad – die zusätzlichen Vorteile, diese Änderung ein oder zwei Jahre früher als ohnehin schon auszurollen, rechtfertigen weder den zusätzlichen Aufwand noch die Stabilitätsrisiken, die mit einer so invasiven Änderung in einer Wartungsversion verbunden sind.

Beibehaltung der Modul-Level-Funktionen

Neben allgemeinen Überlegungen zur Abwärtskompatibilität wird Python häufig zu Bildungszwecken verwendet, und wir möchten insbesondere nicht die Vielzahl von Lehrmaterialien ungültig machen, die die Verfügbarkeit der aktuellen random-Modul-API voraussetzen. Daher stellt dieser Vorschlag sicher, dass die meisten öffentlichen APIs nicht nur ohne Änderungen, sondern auch ohne neue Warnungen weiterverwendet werden können.

Warnung bei impliziter Zustimmung zum deterministischen RNG

Es ist notwendig, sich implizit für den deterministischen PRNG zu entscheiden, da Python häufig für Modellierungs- und Simulationszwecke verwendet wird, wo dies das Richtige ist, und in vielen Fällen werden diese Softwaremodelle kein dediziertes Wartungsteam haben, das dafür zuständig ist, sicherzustellen, dass sie mit den neuesten Python-Versionen kompatibel bleiben.

Leider erscheint die explizite Übergabe von random.seed mit Daten aus os.urandom ebenfalls als Fehler in einer Reihe von fehlerhaften Anleitungen zum "Erzeugen eines Sicherheitstokens in Python", die online leicht verfügbar sind.

Die Verwendung von zunächst einer DeprecationWarning und später einer RuntimeWarning, um von der impliziten Umstellung auf den deterministischen PRNG abzuraten, zielt darauf ab, zukünftige Benutzer, die einen kryptografisch sicheren RNG benötigen, vom Aufruf von random.seed() wegzulenken, und diejenigen, die tatsächlich einen deterministischen Generator benötigen, dazu anzuleiten, explizit random.ensure_repeatable() aufzurufen.

Vermeidung der Einführung eines User-Space-CSPRNG

Die ursprüngliche Diskussion dieses Vorschlags auf python-ideas[#csprng]_ schlug die Einführung eines kryptografisch sicheren Pseudo-Zufallszahlengenerators vor und dessen Verwendung als Standard, anstatt standardmäßig den relativ langsamen System-Zufallszahlengenerator zu verwenden.

Das Problem [7] bei diesem Ansatz ist, dass er einen zusätzlichen Fehlerpunkt in sicherheitsrelevanten Situationen einführt, für Anwendungen, bei denen die Zufallszahlengenerierung möglicherweise nicht einmal auf einem kritischen Leistungspfad liegt.

Anwendungen, die kryptografisch hochwertige Zufälligkeit benötigen, sollten unabhängig von Geschwindigkeitsüberlegungen den System-Zufallszahlengenerator verwenden. In diesen Fällen.

Ist der deterministische PRNG "sicher genug"?

Mit einem Wort: "Nein" – deshalb gibt es in der Moduldokumentation eine Warnung, die besagt, dass sie nicht für sicherheitsrelevante Zwecke verwendet werden sollte. Obwohl wir derzeit keine Studien zur Python-Zufallszahlengenerierung speziell kennen, haben Studien zur PHP-Zufallszahlengenerierung [3] gezeigt, dass Schwächen in diesem Subsystem zur Erleichterung eines praktischen Angriffs auf Passwort-Wiederherstellungstokens in beliebten PHP-Webanwendungen ausgenutzt werden können.

Allerdings lautet eine der Regeln für die sichere Softwareentwicklung: "Angriffe werden nur besser, niemals schlechter", so dass es sein kann, dass bis zur Veröffentlichung von Python 3.6 tatsächlich ein praktischer Angriff auf Pythons deterministischen PRNG öffentlich dokumentiert wird.

Sicherheitsermüdung im Python-Ökosystem

In den letzten Jahren hat die gesamte Computerbranche concerted effort unternommen, die gemeinsame Netzwerkinfrastruktur, auf die wir alle angewiesen sind, auf einen "sicher per Standard"-Ansatz aufzurüsten. Als eine der am weitesten verbreiteten Programmiersprachen für die Entwicklung von Netzwerkdiensten (einschließlich der OpenStack Infrastructure-as-a-Service-Plattform) und für die Systemadministration auf Linux-Systemen im Allgemeinen ist ein gerechter Anteil dieser Last auf das Python-Ökosystem gefallen, was für Pythonistas, die Python in anderen Kontexten verwenden, wo diese Probleme nicht so sehr ins Gewicht fallen, verständlicherweise frustrierend ist.

Diese Überlegung ist einer der Hauptfaktoren, die die substanziellen Verbesserungen der Abwärtskompatibilität in diesem Vorschlag im Vergleich zum ursprünglichen Entwurfskonzept, das auf python-ideas veröffentlicht wurde [6], antreiben.