Seite 1 von 2

Config-Datei verschlüsseln

Verfasst: Freitag 20. April 2007, 08:42
von droptix
Ein Programm braucht eine Config-Datei (INI). Weil Passwörter drin stehen möchte ich die gern verschlüsselt ablegen. Eigentlich macht es Sinn, gleich die gesamte INI-Datei zu verschlüsseln.

Welchen Algo sollte man wählen? Ich denke mit AES fährt man ganz gut, oder? Dafür gäbe es ja pycrypto.

Verfasst: Freitag 20. April 2007, 12:16
von lunar
Ich würde dir außerdem nicht zu pycrypto raten... Das ist zwar ein gutes Modul, was Umfang und Implementation der Algorithmen angeht, aber es ist sehr grundlegend.

Es bietet iirc keine Funktionen zum Ableiten von Schlüsseln aus Passwörtern, kein Padding, etc. Um eine Konfigurationsdatei zu Verschlüsseln, muss man einiges drumrum programmieren, was die ganze Sache potentiell angreifbar macht. Außerdem musst du dich um das Speichern oder das Abfragen des Schlüssels selbst kümmern.

Ich an deiner Stelle würde auf etwas Etabliertes zurückgreifen. Du könntest z.B. gnupg zum Verschlüsseln der Passwörter nehmen.

Außerdem würde ich die Passwörter unbedingt in einer separaten Datei ablegen. Dann musst du die Passwörter nämlich erst dann entschlüsseln wenn du sie wirklich benötigst. Speicherst du dagegen alles in einer Konfigurationsdatei und verschlüsselst diese, so musst die alles (auch die Passwörter) entschlüsseln, nur um z.B. die Option für einen Download-Ordner oder die Verbosity auszulesen.

Verfasst: Freitag 20. April 2007, 13:43
von droptix
Ich muss sowieso die ganze Config einlesen, weil ich alle Angaben gleichzeitig brauche. Es ist nur eine Hilfe, dass der arme Anwender nicht jedesmal alles neu eingeben muss. Ich würde die Passwörter aber ungern unverschlüsselt rumliegen lassen... Prinzipsache. Es geht mir nicht um maximalen Schutz.

Was ist mit ezPyCrypto und yawPyCrypto?
Auszug aus [url=http://www.freenet.org.nz/ezPyCrypto/detail/public/ezPyCrypto.key-class.html#encString]ezPyCrypto[/url] hat geschrieben:encString(self, raw)

Encrypt a string of data

High-level func. encrypts an entire string of data, returning the encrypted string as binary.
Arguments:

* raw string to encrypt

Returns:

* encrypted string as binary

Note - the encrypted string can be stored in files, but I'd suggest not emailing them - use encStringToAscii instead. The sole advantage of this method is that it produces more compact data, and works a bit faster.
Tja, wie und mit welchem Algo wird denn da encryptet? Kann ich da keinen Key festlegen? Dann kann ja sicher jeder der Python hat den encrypteten Binary-String wieder decrypten...

Verfasst: Freitag 20. April 2007, 14:24
von lunar
droptix hat geschrieben:Ich muss sowieso die ganze Config einlesen, weil ich alle Angaben gleichzeitig brauche.
In diesem Fall würde ich dir wirklich zu gnupg raten, da man das über subprocess recht komfortabel steuern kann:

Code: Alles auswählen

# verschlüsseln
data = "In diesem String steht die Konfiguration"
process = subprocess.Popen(['gpg', '-o', 'configfile', '-c'],
                                         stdin=subprocess.PIPE)
process.communicate(data)
# entschlüsseln
process = subprocess.Popen(['gpg', '-d', 'configfile'],
                                         stdout=subprocess.PIPE)
# die Konfiguration landet auf stdout
data = process.communicate()[0]
Um z.B. ConfigParser in einer String schreiben zu lassen, kannst du StringIO nehmen, und denn erzeugten String dann auf die Pipe weiterleiten. Da bei dieser Methode keine temporären Dateien erzeugt werden, ist die Sache relativ sicher. Die Passwortabfrage geschieht automatisch, sofern die richtigen pinetry-Frontends installiert sind.

Getestet habe ich das nicht, es sollte aber so ähnlich unter Linux laufen, von Windows weiß ich das nicht.

Verfasst: Freitag 20. April 2007, 17:15
von droptix
Ich möchte eine Python-Anwendung bauen, weil ich nicht von externen Programmen abhängig sein will. Daher finde ich ist das zu weit ausgeholt.

Wie gesagt: es muss nicht bombensicher sein. Ich will einfach nur keine Klartextpasswörter. Wäre nett, wenn das trotzdem relativ sicher ist, aber es muss halt nicht sein.

Gibt's keine simple Möglichkeit dafür? Mir reicht theoretisch auch ein ROT13... wehe jetzt lacht einer :twisted:

Verfasst: Freitag 20. April 2007, 17:25
von Mephisto
Also wenn dir echt rot13 reicht, dann geht das ziemlich einfach:

Code: Alles auswählen

In [6]: "abcd".encode('rot13')
Out[6]: 'nopq'

In [7]: "nopq".decode('rot13')
Out[7]: u'abcd'
:)

greets meph

Verfasst: Freitag 20. April 2007, 17:48
von droptix
Cool! Was kann ich denn alternativ zu "rot13" angeben? Finde mal wieder nichts dazu in der Python-Doku. Die Funktion wird zwar aufgeführt, aber die Argumente nicht... nervt manchmal ganz schön.

Verfasst: Freitag 20. April 2007, 17:54
von Leonidas
droptix hat geschrieben:Cool! Was kann ich denn alternativ zu "rot13" angeben?
Alle in Python registrierten Codecs. Du kannst auch eigene Codecs registrieren, womit man ganz lustige Sachen machen kann.
droptix hat geschrieben:Finde mal wieder nichts dazu in der Python-Doku. Die Funktion wird zwar aufgeführt, aber die Argumente nicht... nervt manchmal ganz schön.
Also ich sehe in der Python Doku durchaus eine lange Liste mit eingebauten Codecs ;) Da sind neben den "normalen" Encodings wie Latin-1 (ISO-8859-1) auch eben auch UUEncode, Base64 und auch noch weitere.

Verfasst: Freitag 20. April 2007, 17:56
von Mephisto
Wo das in der Doku steht weis ich leider auch nicht genau, aber in encodings.aliases.aliases ist ein Dictionary mit allen Encodings.
Alternativ zu rot13 würde sich vielleicht base64 eignen.

Hm, da war einer schneller, naja schadet auch nicht :)

greets meph

Verfasst: Freitag 20. April 2007, 18:15
von droptix
Leonidas hat geschrieben:Also ich sehe in der Python Doku durchaus eine lange Liste mit eingebauten Codecs
Ohoooo, aber diese Liste hätte man mal bei String.encode() verlinken können. Muss man ja erstmal wissen, dass alle Codecs gehen.

Das ist ja ne ziemlich lange Liste. Welcher Codec eignet sich eurer Meinung nach am besten, um den String so gut wie möglich zu verschleiern? Wie wär's mit "macturkish"? :D meph meinte dazu schonmal:
Mephisto hat geschrieben:Alternativ zu rot13 würde sich vielleicht base64 eignen.
Immer dran denken: ich will damit nur das Maximum rausholen und keine 100%-ige Sicherheit. Danke!

Verfasst: Freitag 20. April 2007, 18:15
von darkfrog
Man könnte auch einfach nur einen Hash (z.B. md5) des Passwortes in der Datei abspeichern und diesen dann mit der Eingabe vergleichen.

Verfasst: Freitag 20. April 2007, 19:33
von EyDu
darkfrog hat geschrieben:Man könnte auch einfach nur einen Hash (z.B. md5) des Passwortes in der Datei abspeichern und diesen dann mit der Eingabe vergleichen.
Dann sollte man das Passwort aber noch so verändern, dass daraus nicht direkt der MD5-Wert gebildet wird. Sonst könnte jeder die Config-Datei nach seinen "Bedürfnissen" anpassen, indem er selber einen Wert einträgt.

Außerdem nützt das nichts, wenn man beispielsweise zu einer Datebank eine Verbindung aufbauen möchte, oder seine E-Mails abrufen will.

Verfasst: Freitag 20. April 2007, 19:34
von Leonidas
darkfrog hat geschrieben:Man könnte auch einfach nur einen Hash (z.B. md5) des Passwortes in der Datei abspeichern und diesen dann mit der Eingabe vergleichen.
Ja, das ist eine Idee, am besten mit Salt. Aber nicht immer sind Hashes eine gute Idee. So ist es nicht möglich Passwörter zu speichern, die später im Klartext noch verfügabr sein müssen.

Eine der normalen Datei-Encodings würde ich nciht nehmen. Denn UTF-8 oder Latin-1 oder Latin-9 unterscheiden sich bei ASCII-Zeichen nicht, und Türkisch hat auch nicht so viele Sonderzeichen, somit ist es gut möglich, dass es auch als Macturkish kodiert noch problemlos lesbar ist: siehe ``'abc'.encode('macturgish')``.

Verfasst: Freitag 20. April 2007, 19:47
von EnTeQuAk
Also ich hatte vor langer Zeit mal die gleiche Problematik ;)
Ich habe für das Problem einfach base64.base16 genommen. Das sieht genial aus, keiner kanns mehr lesen und es ist extrem leicht zu verarbeiten *grinz*
(um vllt. noch ein wenig mehr Sicherheit hinzuzubringen, kann man ja einfach automatisch zwei Buchstaben an den Anfang und das Ende hängen. Damit ist das ganze auch nicht gleich automatisch für Leute lesbar, die `base16` erkennen und es knacken wollen.

Ist ne sehr easy Lösung finde ich. ;)

MfG EnTeQuAk

Verfasst: Samstag 21. April 2007, 11:04
von droptix
Ich brauche die Passwörter im Klartext, muss sie also wieder decodieren können. Daher kein Hash wie MD5.

Die Variante von EnTeQuAk gefällt mir und ist für meine Zwecke völlig ausreichend. Ich denke ich werde einfach "base64" und "rot13" kombinieren.

Thanks a lot! :D

ConfigParser() readstring möglich?

Verfasst: Samstag 21. April 2007, 11:20
von droptix
Da wir anfangs mal den `ConfigParser` angeschnitten hatten: Der soll mir meine INI ja einlesen. Zuvor muss ich sie eben nur decodieren.

Das Problem was ich grad entdeckt hab: `ConfigParser` kann nur von einem Fileobject lesen. Ich kann keinen String übergeben. Wie löst man dieses Problem? Kann ich eine Art virtuelles Fileobject erstellen, welches nicht erst auf Platte geschrieben werden muss?

Verfasst: Samstag 21. April 2007, 11:26
von rayo
Hi

Schau das Modul StringIO an.

Gruss

Verfasst: Samstag 21. April 2007, 11:41
von droptix
rayo hat geschrieben:Schau das Modul StringIO an.
Na wunderbar. Hat geklappt, danke!

Verfasst: Sonntag 22. April 2007, 09:33
von jens
"suche pure Python crypt Algo...": http://www.python-forum.de/topic-8075.html

btw. Um es wirklich sicher zu machen, müßte man IMHO ein Master-Passwort nehmen, welches der User eingeben muß, um die anderen Passwörter "freizuschalten"... Ohne so etwas ist das ganze nur ein leicht zu durchschauendes durcheinander würfeln...

Verfasst: Sonntag 22. April 2007, 11:37
von droptix
Danke. Ich denke aber es reicht mit dem durcheinander würfeln. Ist nichts sicherheitskritisches. Die INI Datei wird eigentlich auch nur auf einem Rechner abgelegt, auf den nur ich Zugriff habe. Die Verschlüsselung ist nur für alle Fälle...