Passwort während der Laufzeit sicher aufbewahren

[Sophus]

Hallo Leute,

ich möchte ein Passwort während der Laufzeit sicher aufbewahren. Folgende Situation: Ich habe auf meinem WebServer eine .htaccess-Datei, dort sind verschlüsselte Passwörter. Mein Programm loggt sich zum Beispiel via mechanize auf ein Portal ein und holt sich das Passwort, um über .htaccess Zugang zu bekommen. Und jetzt kommt der Punkt. Das Passwort wird dann temporär im Quelltext in eine Variable gespeichert, damit das Programm mit dieser Information weiterarbeiten kann. Selbst wenn ich das geholte Passwort in eine Klasse speichere, ist es möglich, dass man von außen mit einem anderen Programm an das Passwort kommen kann, richtig? Schließlich wird ja alles in den Arbeitsspeicher temporär gespeichert. Das heißt also, ich möchte das eben geholte Passwort sicher in meinem Quelltext zur Laufzeit aufbewahren. Sobald das Programm beendet wird, wird alles "zerstört". Ich möchte also kein Passwort irgendwo in eine Datei speichern. Dabei habe ich mir die Standard-Bibliothek base64 angeschaut.

Hier ein Beispiel:

Code: Alles auswählen

import base64

pwd = raw_input("Enter your password here: ")

encoded_pwd = base64.b64encode(pwd)

print "encoded_pwd", encoded_pwd

decoded_pwd = base64.b64decode(encoded_pwd)

print "decoded_pwd", decoded_pwd

Aber ich weiß nicht, ob ich mich mit dieser Methode auf der sicheren Seite befinde. Allerdings zeigt die Vorgehensweise, was ich meine. Ich nehme das geholte Passwort entgegen, verschleiere das geholte Passwort, und speichere das verschleierte Passwort in eine Klasse. Und sobald mein Programm dazu übergeht, Zugang über .htaccess zu verschaffen, wird das verschleierte Passwort geholt, dekodiert, und kann sich dann in den gesicherten Bereich der WebSeite "arbeiten" - zum Beispiel Informationen holen, die im gesicherten Web-Bereich hinterlegt wurden.

Nun die Frage an euch. Ist dies sicher? Oder gibt es bessere Vorgehensweisen?

[__deets__]

Das ist grosser Unfug. Jenseits aller kryptographischen Ueberlegungen (base64 ist ja nicht wirklich irgendwie schwierig, das dekodiert so mancher im Kopf) - ein Programm, dass ein solches Passwort bestaendig braucht, und das ich angreifen will - bei dem haenge ich mich als Angreifer halt an die Stelle, an der es das Passwort entschluesselt, um damit dann wiederum ein Request zu erzeugen.

Anders gesagt: wenn ich den Speicher deines Programmes abgreifen kann, kann ich auch alle Logik zum entschluesseln des Passwortes abgreifen. Ist also vergebliche Muehe, da zu investieren.

Aus Gruenden der Sicherheit ein Passwort bei Programmstart eingeben zu lassen, statt es irgendwo auf dem Filesystem zu speichern - *das* hat schon durchaus seine Berechtigung. Denn sonst ist das Geheimnis auch ohne Programmlauf angreifbar, und auf Dateien zuzugreifen ist ueblicherweise mehr Leuten gestattet, als auf den Programmspeicher - ist also einfach gefaehlicher.

[Sophus]

Ich habe keineswegs vor ein Passwort in eine Datei abzulegen. Denn rein von der Überlegung her braucht mein Programm das Passwort nur, um ein Requests zu erzeugen. Meine Überlegung geht also dahin, dass ich mich fragen, wie ich ein Passwort zur Laufzeit sicher aufbewahren kann, wenn ein Benutzer sein Passwort eingegeben hat. Wenn ein Angreifer generell Zugriff auf den Rechner des Benutzers hat, dann wird sich der Angreifer sich andere Mühe auf sich nehmen, anstatt sich mit dem Programm auseinander zu setzen. Jedoch hätte ich eine gewisse Sicherheit dabei, während mein Programm mit dem Passwort weiterarbeitet. Ich möchte es eben nicht als Klartext haben. Zum Thema Decoding und Encoding von Texten habe ich mir eben diese Seite angeschaut.

[BlackJack]

@Sophus: Du musst es ja als Klartext haben wenn Du dir Abfragen machst, also muss es auch unverschlüsselt vorliegen. Wenn der Angreifer keinen Zugriff auf den Rechner hat, dann sehe ich kein Problem, und falls er Zugriff auf Deinen Rechner hat, und zwar so viel das er auf den Arbeitsspeicher Deines Programms zugreifen kann, kann er auch sehr viel mehr andere Sachen veranstalten die dieses Problem in den Schatten stellen. Wie so oft scheinst Du Dir hier wieder Gedanken um etwas zu machen was kein reales Problem darstellt.

Die Problembeschreibung ist auch äusserst irreführend gewesen, denn etwas im Quelltext zu speichern bedeutet ja gerade nicht das der Benutzer es zur Laufzeit eingibt, sondern das es, nun ja, im Quelltext gespeichert ist. Und was eine Klasse damit zu haben soll erschliesst sich mir auch nicht. Ob das Passwort nun an einfache Namen oder an Attribute gebunden wird, hat mit der Fragestellung ja nichts zu tun.

[Sophus]

@BlackJack: Das mit der Klasse war eher eine Randbemerkung. Wenn der Benutzer zu einem späteren Zeitpunkt noch einmal auf eine geschützte Seite zugreifen will, dann nimmt mein Programm das zuvor geholte Passwort und arbeitet weiter. Mehr wollte ich hier nicht andeuten. Aber du hast Recht, dies tut nichts zur Sache.

Vielleicht mache ich mir um ungelegte Eier Gedanken. Nur ging ich davon aus, dass man in Puncto Passwort Sicherheit bewahren sollte. Ich dachte mir einfach, dass das temporär gespeicherte Passwort, welches zur Laufzeit existiert, irgendwie gesichert werden soll - ganz gleich, ob der Angreifer Zugriff auf den Rechner hat. Ich ging davon aus, dass andere Programme, die das Passwort von Benutzer entgegennehmen, diese Informationen sichern. Ist es denn wirklich gängige Praxis, dass Passwörter zur Laufzeit unverschlüsselt rumgereicht werden? Wenn ja, dann wusste ich das nicht.

[BlackJack]

@Sophus: Ausser in einer Anwendung die sich dediziert um Passwörter oder Sicherheit kümmert, also so etwas wie Keepass/KeepassX oder Verschlüsselungssoftware würde ich da keine weiteren besonderen Massnahmen erwarten. Wogegen willst Du Dich denn auch absichern? Dafür das man nicht an den Arbeitsspeicher des Programms heran kommt, ist das Betriebssystem und dessen Rechteverwaltung zuständig. Eine Schwachstelle ist die Auslagerungsdatei/Swap-Partition, aber darum sollten sich nicht einzelne Programme kümmern müssen, das löst man einmal für alle Programme in dem man diese Daten verschlüsseln lässt.

[Sophus]

@BlackJack: Danke. Das wusste ich nicht. Ich hatte bei meiner Überlegung so mehr an Filzilla, Thunderbird etc gedacht, die womöglich dein Passwort während der Laufzeit sichern. Gut, diese und ähnliche Programme bieten einem ja auch an, das Passwort auf die Festplatte zu speichern. Aber wenn ich dich richtig verstanden habe, hausieren auch diese Programme zur Laufzeit mit dem Passwort im Klartext.

[DasIch]

Was theoretisch sinnvoll sein könnte wäre den Speicher in dem das Passwort steht nach dem Gebrauch zu überschreiben. Wenn du dies nicht tust und du den Speicher einfach freigibst, könnte jemand mit einer späteren Allokation an Speicher kommen dass das Passwort enthält. Auf die Weise war es möglich den Private Key über Heartbleed zu kommen.

Das ist bei C ein Problem weil man dadurch wie Memory Management funktioniert eine gute Chance hat an wiederverwendeten Speicher zu kommen. Im Python Kontext ist dies glaub ich weit weniger problematisch, schliesslich bräuchte man eine Lücke im Interpreter, einer C Extension oder Code der mit ctypes/cffi hantiert. Das cryptography Projekt stimmt mir da ebenfalls zu.