Passwörter in Pythoncode Verschlüsseln und zur Laufzeit ents

[jerch]

Wie wärs mit Steganographie? Aber auch hiermit bleibt das Grundproblem bestehen, solange Du einfachen Zugang zur "Umkehrfunktion" bietest, ist das alles für die Katz. Ein kompilierende Sprache erzeugt hier immerhin den Mehraufwand des Dekompilierens, damit wären unmovitierte Skriptkiddies wohl abzuschrecken, mit Python wird Dir aber alles auf dem Tablett serviert.

Und mit base64 errät man die Umkehrfunktion wohl auch, ohne überhaupt den Quelltext gesehen zu haben.

Wie mans dreht und wendet, wenn alle nötigen Informationen vorliegen, ist die Sicherheit dahin und jeglicher Verschleierungsversuch ist im Quelltext gut nachvollziehbar. Wie gesagt, bei kompilierenden Sprachen könnte man auf security by obsurity spekulieren, was aber keinen echten Sicherheitsgewinn darstellt.

[ichbinsisyphos]

...

#21

[ichbinsisyphos]

Wie wärs mit Steganographie? Aber auch hiermit bleibt das Grundproblem bestehen, solange Du einfachen Zugang zur "Umkehrfunktion" bietest, ist das alles für die Katz. Ein kompilierende Sprache erzeugt hier immerhin den Mehraufwand des Dekompilierens, damit wären unmovitierte Skriptkiddies wohl abzuschrecken, mit Python wird Dir aber alles auf dem Tablett serviert.

Und mit base64 errät man die Umkehrfunktion wohl auch, ohne überhaupt den Quelltext gesehen zu haben.

Wie mans dreht und wendet, wenn alle nötigen Informationen vorliegen, ist die Sicherheit dahin und jeglicher Verschleierungsversuch ist im Quelltext gut nachvollziehbar. Wie gesagt, bei kompilierenden Sprachen könnte man auf security by obsurity spekulieren, was aber keinen echten Sicherheitsgewinn darstellt.

Angenommen du hast zwei Skripte vor dir, die sind gleich, mit nur einem Unterschied:

* Skript A hat das Passwort in Klartext.

* Skript B hat ein obskur verschlüsseltes Passwort - verschlüsselt mit einem Algorithmus, den zu finden der Sinn meines postings war (du siehst die Funktionennamen und verstehst, wie man aus dem elendslangem String das Passwort wiederherstellen kann, aber leider hast du keinen Zugriff auf den Rechner, weil der Besitzer ihn belegt und dein Gedächnis ist nicht gut genug um sich den langen, verschlüsselten String so lange zu merken, bis du zu Hause vor deinem eigenen Rechner sitzt.

Aus welchem der beide Skripte (A oder B) kriegst du das Passwort leichter raus?

Wenn der böse Mensch das Skript selbst in die Hände kriegt, dann ist es natürlich gelaufen, aber mit Klartext-Passwort kann ich niemanden auch nur einen Blick auf das Skript werfen lassen.

Ich hoffe, dass damit die Meta-Diskussion beendet ist. Natürlich ist niemand gezwungen Antworten zu geben, ich wär aber trotzdem an Ideen und Meinungen interessiert.

Eine kompilierende Sprache ist sicher genug um das Passwort vor einem Großteil aller normalsterblichen Menschen zu verbergen (obwohl ich mit "strings" Textteile sofort aus jeder Binärdatei ausgeben kann), aber wenn du jemanden den Quelltext zeigen willst, stehst wieder genau vor dem selben Problem.

[lunar]

Wieso willst du das Passwort unbedingt im Skript selbst speichern? Es aus einer Konfigurationsdatei zu lesen, ist die offensichtlichste Lösung dieses Problems.

[jerch]

Aus welchem der beide Skripte (A oder B) kriegst du das Passwort leichter raus?

Mit Interpreter zur Hand aus beiden gleich schwer/einfach. Ich muß im Falle des Skriptes mit dem verschleierten Passwort nicht mal selbst mein Hirn anstrengen, um es zu entschlüsseln, da Du ja irgendwo auf das entschlüsselte Passwort zugreifst. Da würde ich mich einfach einklinken und mitlesen. (Ich hatte unter dem 2.4er Linuxkernel mal ein Modul geschrieben, das auf diese Weise alle systemweiten Passwortaktionen protokolliert konnte. Mit ein wenig Vertrauensbildung dem root untergeschoben, gehört Dir so das ganze System. Zum Glück wurden die system call hooks als Sicherheitsrisiko erkannt und sind weit schwieriger unter 2.6)

Wenn der böse Mensch das Skript selbst in die Hände kriegt, dann ist es natürlich gelaufen, aber mit Klartext-Passwort kann ich niemanden auch nur einen Blick auf das Skript werfen lassen.

Wenn es Dir nur um den Blick auf das Skript geht, ist doch einfacher, das Passwort rauszunehmen. Bzw. könntest Du das Skript so anpassen, daß ein potentieller Nutzer da seine Daten bereitstellt und es selber testen kann. Z.B per Konfigurationsdatei, wie Lunar schon bemerkte, oder testweise als globale Variablen im Skript selbst.

[lunar]

(Ich hatte unter dem 2.4er Linuxkernel mal ein Modul geschrieben, das auf diese Weise alle systemweiten Passwortaktionen protokolliert konnte. Mit ein wenig Vertrauensbildung dem root untergeschoben, gehört Dir so das ganze System. Zum Glück wurden die system call hooks als Sicherheitsrisiko erkannt und sind weit schwieriger unter 2.6)

So was wie "system call hooks" gibt es als Konzept im Kernel doch gar nicht. Man kann allenfalls die Funktionszeiger in der syscall-Tabelle umbiegen. Da die Syscall-Tabelle in 2.4 als Symbol exportiert wurde, war das damals ziemlich einfach. In 2.6 ist das zwar nicht mehr der Fall, allerdings kann ein Modul immer noch den Kernelspeicher nach der Syscall-Tabelle durchsuchen.

Btw, mich würde interessieren, wie du auf Kernel-Ebene "Passwortaktionen" mitgelesen hast. Authentifizierung ist nicht Kernel-Sache, sondern geschieht im Userspace durch privilegierte Programme, die bei Erfolg die effektive und tatsächliche UID ändern und anschließend Unterprozesse starten.

[ichbinsisyphos]

ok, vergesst es.

Wenn der Angreifer eine Zeitmaschine zur Hand hat, dann ist sowieso alles umsonst. Er könnte zu dem Zeitpunkt zurückgehen, an dem ich das Passwort in die Konfuriationsdatei geschrieben habe und mir über die Schulter blicken. Er kann das mehrfach wiederholen, bis es einmal klappt.

Die einzige Lösung ist völlig auf Computer zu verzichten und ein einfaches Leben am Land zu führen. Ich empfehle Ziegen für Milch und ein paar Schweine (Ziegen sind einfacher in der Haltung als Kühe). Dann noch eines kleines Maisfeld und eine vollbusige Bäuerin und man kann trotzdem ein ein erfülltes Leben führen, meine ich.

Das ist natürlich schwachsinning, aber die einzig wirklich orginelle von inzwischen 3 Seiten voll mit Themenverfehlungen.

[jerch]

Ok, mir fällt da jetzt doch eine Mgl. ein, es zumindest schwieriger zu machen:
- alle Passwort-bezogenen Skriptteile in eine separate Datei packen
- von Python kompilieren lassen
- in eigentlichem Skript auf gültige md5-Summe der Datei prüfen

In der Python-Bytecode-Datei kannst Du Dir alle möglichen Verrenkungen überlegen, um das Passwort zu verschleiern. Wiederum nur security by obscurity, zumal die Python-Kompilate immernoch gut lesbar sind. Damit fällt aber auch der einfache Blick auf den Quelltext weg...

[jerch]

@ichbinsisyphos:
Wir drehen uns auch im Kreis, da Du offensichtlich nicht einsehen willst, das eine maschinengesteuerte vollautomatische Authenifizierung bei Zugriff auf die Ressourcen keine Sicherheit bietet. Ist halt so.

@lunar:
Puh, müßte ich mal in den alten Codedateien rumwühlen, wie ich das genau gemacht habe. Schematisch wars nicht viel mehr als:
- read umbiegen auf eigene
- wenn read auf etc/shadow, dann lies irgendeinen buffer (da stand dann das passwort drin)
- passwort an device /dev/password schreiben
- read aufrufen
Das ganze funktionierte nur mit shadow, aber von allem mgl. login-Szenarien aus (konsole, ssh, su usw.)

Edit: Falls Dich der Code interessiert, kann ich den mal raussuchen, wirklich erschreckend war nur die Einfachheit, mit der das damals mgl. war.

[ichbinsisyphos]

@ichbinsisyphos:
Wir drehen uns auch im Kreis, da Du offensichtlich nicht einsehen willst, das eine maschinengesteuerte vollautomatische Authenifizierung bei Zugriff auf die Ressourcen keine Sicherheit bietet. Ist halt so.

hahahaha, heilige Sch...

[lunar]

Puh, müßte ich mal in den alten Codedateien rumwühlen, wie ich das genau gemacht habe. Schematisch wars nicht viel mehr als:
- read umbiegen auf eigene
- wenn read auf etc/shadow, dann lies irgendeinen buffer (da stand dann das passwort drin)
- passwort an device /dev/password schreiben
- read aufrufen

Ok, das dachte ich mir schon

Edit: Falls Dich der Code interessiert, kann ich den mal raussuchen, wirklich erschreckend war nur die Einfachheit, mit der das damals mgl. war.

Keine Umstände ... ich kanns mir vorstellen.

[Hyperion]

@ichbinsisyphos:
Wir drehen uns auch im Kreis, da Du offensichtlich nicht einsehen willst, das eine maschinengesteuerte vollautomatische Authenifizierung bei Zugriff auf die Ressourcen keine Sicherheit bietet. Ist halt so.

hahahaha, heilige Sch...

Anstatt hier sinnfrei prollige Kommentare abzugeben wäre es doch schön, wenn Du einfach mal auf den Hinweis mit einer externen Konfigurationsdatei eingehen würdest! Natürlich hast Du etwas anderes gefragt, aber was ist daran so schlimm, wenn man anstatt eines einfachen "geht nicht" sogar eine gute Alternative aufgezeigt bekommt?

[ichbinsisyphos]

@ichbinsisyphos:
Wir drehen uns auch im Kreis, da Du offensichtlich nicht einsehen willst, das eine maschinengesteuerte vollautomatische Authenifizierung bei Zugriff auf die Ressourcen keine Sicherheit bietet. Ist halt so.

hahahaha, heilige Sch...

Anstatt hier sinnfrei prollige Kommentare abzugeben wäre es doch schön, wenn Du einfach mal auf den Hinweis mit einer externen Konfigurationsdatei eingehen würdest! Natürlich hast Du etwas anderes gefragt, aber was ist daran so schlimm, wenn man anstatt eines einfachen "geht nicht" sogar eine gute Alternative aufgezeigt bekommt?

Ist dir aufgefallen, dass er wieder von "ich will nicht einsehen, dass blah blah keine Sicherheit bietet" geschrieben hat? Oder liest du auch die postings nicht, die du quotest?

[jerch]

@ichbinsisyphos:
Dann laß es uns lieber sachlich diskutieren und nicht mit emotional aufgeladenen Vorwürfen jonglieren. An welcher Stelle fühlst Du Dich mißverstanden?

[Hyperion]

Ist dir aufgefallen, dass er wieder von "ich will nicht einsehen, dass blah blah keine Sicherheit bietet" geschrieben hat? Oder liest du auch die postings nicht, die du quotest?

Dazu fällt mir nur noch *plonk* ein!

[Leonidas]

Wenn der Angreifer eine Zeitmaschine zur Hand hat, dann ist sowieso alles umsonst. Er könnte zu dem Zeitpunkt zurückgehen, an dem ich das Passwort in die Konfuriationsdatei geschrieben habe und mir über die Schulter blicken. Er kann das mehrfach wiederholen, bis es einmal klappt.

Oder er könnte den von mit mitgelieferten Entschlüsselungsalgorithmus aufrufen, ihm als Eingabe dein verschlüsseltes Passwort eingeben und als Ausgabe dein Klartextpasswort bekommen.

[HWK]

@ichbinsisyphos: Auch wenn ich mir hier den Unmut sehr vieler auf mich ziehe, schau Dir mal die Codecs für encode() an, z.B. bz2_codec oder zlib_codec.
MfG
HWK

[ichbinsisyphos]

@ichbinsisyphos: Auch wenn ich mir hier den Unmut sehr vieler auf mich ziehe, schau Dir mal die Codecs für encode() an, z.B. bz2_codec oder zlib_codec.
MfG
HWK

Ja, danke, bz2 erzeugt interessante Resultate: Ich lass' dabei, damit dieser Irrsinn ein Ende hat.

[snafu]

Natürlich hast Du etwas anderes gefragt, aber was ist daran so schlimm, wenn man anstatt eines einfachen "geht nicht" sogar eine gute Alternative aufgezeigt bekommt?

Ihm das zu vermitteln, scheint eine wahre Sisyphosarbeit zu sein. *schenkelklopf*

[Hyperion]

Natürlich hast Du etwas anderes gefragt, aber was ist daran so schlimm, wenn man anstatt eines einfachen "geht nicht" sogar eine gute Alternative aufgezeigt bekommt?

Ihm das zu vermitteln, scheint eine wahre Sisyphosarbeit zu sein. *schenkelklopf*

Tja... vor allem wieso äußert er sich dazu nicht? Dann wüßten wir ja, wieso ihm das als keine akzeptable Lösung erscheint...

Aber das wäre ja zu einfach