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

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

ichbinsisyphos hat geschrieben:Es wär überhaupt kein sicherheitstechnisches Fiasko, bestimmten usern Zugriff auf ausgewählte, eigene Passwörter zu geben.
Doch, Passwörter im Klartext speichern ist immer mit Risiken verbunden. Siehe die Hacks auf die ganzen Webseiten, die ihre Passwörter nicht Hashen sondern einfach so in die Datenbank speichen.

Bei GNOME-Keyring könnt mir vorstellen, dass die die Passwörter einfach verschlüsselt abspeichen, mit dem Login-Passwort verschlüsselt. Das ist schon wesentlich sicherer als das was du da planst.

Natürlich, man könnte so ein System auch auf die Konsole portieren und von GUI-Abhängigkeiten befreien, aber bisher hat das eben keiner gemacht.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
ichbinsisyphos
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

Leserechte? PAM liest Passwort aus root-lesbarer Datenbank und gibt es an Benutzer weiter, die nach eigener Konfiguration berechtigt sind?
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Das sinnvollste bei der ganzen Sache wäre wirklich die OS-eigenen Systeme zu verwenden, sprich Gnome Keyring, OSX Keychain, KWallet, Windows hat da hoffentlich auch was ähnliches. Zumindest bei GNOME und OSX gibt es dafür eine C-Api die man über ctypes ansprechen kann.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Nein, du hast einen Hintergrunddienst wie etwa der GNOME-Keyring und PAM gibt dem bei der Anmeldung das Userpasswort an den Dienst weiter (so ähnlich wie das pam-gnome-keyring das macht), der dann das Passwort hat, mit dem er die gespeicherten Passwörter des Users entschlüsseln kann. Diesen Dienst könnte man dann eben befragen, was das Passwort des Users für einen bestimmten Zweck ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
ichbinsisyphos
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

Sorry, das ich den thread nochmal hochhole, aber einen neuen aufmachen zahlt sich nicht aus.

Was würdet ihr empfehlen um Passwörter unkenntlich zu machen?

Ich hab jetzt base64 benutzt und glaub damit kann ich immerhin jemanden meine Skripte zeigen, ohne ihnen gleich mein Passwort ins Gesicht zu reiben.
Aber das sind zum Teil nur 15 Buchstaben, alle groß, das lässt sich trotzdem noch schnell merken.

Was hat python für schöne Module für solche Zwecke?
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Um das Grundproblem auszugraben: Da du in deinem Script das Passwort eben wieder entschlüsseln musst und daher den Algorithmus dazu im Code hast, hat ein Angreifer alles was er brauch um an den Klartext zu kommen.
ichbinsisyphos
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

cofi hat geschrieben:Um das Grundproblem auszugraben: Da du in deinem Script das Passwort eben wieder entschlüsseln musst und daher den Algorithmus dazu im Code hast, hat ein Angreifer alles was er brauch um an den Klartext zu kommen.
Ja, aber wir sind wirklich oft genug in dieser Sackgasse geendet in dem thread :-)

Du wirst sicher zustimmen, dass ein verschlüsseltes Passwort, zu lang und konfus um es sich zu merken inklusive Entschlüsselungsanweisung besser ist als das Klartext-Passwort. Ja?
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Und was nütz dieses unkenntlich machen?
Warum machst du den Leuten zugänglich, wenn sie diese Informationen nicht haben dürfte, bzw sie nicht benutzen sollen?

Ein verschlüsseltes Passwort, so lang und so konfus es auch ist, nützt nichts, wenn man dem Angreifer die Mittel liefern eben an das einfache Klartextpasswort zu kommen (bzw auch wieder an das verschlüsselte).

Der Grund warum wir immer wieder in dieser Sackgasse änden ist einfach, dass das ein konzeptionelles Problem ist: Was für einen Sinn machen Passwörter, mit denen man sich ja authentifiziert, wenn man sie speichert und damit jedem verfügbar macht, der Zugang hat?
ichbinsisyphos
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

Und welchen Sinn macht es, dass jetzt zum 20ten mal zu wiederholen?

Ich hab zum Beispiel ein Skript, dass meinem IMAP-Account regelmässig check und mir die Anzahl der ungelesen Emails mitteilt. Viele meiner Kollegen, die sonst nur die gebräuchlichen Clients benutzen, finden das nützlich und interessant und wollen wissen wie das funktioniert.
In dem Skript stand aber bis vor kurzem mein Passwort in Klartext. Wenn ich jemandem das Skript unverändert gezeigt hätte, wüssten die alle mein Passwort.

Solange niemand Zugriff auf das Skript selbst hat, muss das Passwort nicht unentschlüsselbar sein, es reicht, wenn es zu lange und konfus ist, um es sich zu merken.


Ich wiederhole die Frage:

Welche Möglichkeiten gibt es Passwörter unkenntlich zu machen?
Es wär schön einen Algorithmus zu haben, der mehr Zeichen benutzt als base64 und möglich lange, am besten sogar Ergebnisse mit konstanter Länge produziert.

Ich möchte ausdrücklich und wiederholt betonen, dass es keineswegs erforderlich ist, dass das Passwort unmöglich zu entschlüsseln ist.
lunar

ichbinsisyphos hat geschrieben:Und welchen Sinn macht es, dass jetzt zum 20ten mal zu wiederholen?
Er ergibt keinen Sinn, was mittlerweile jeder gemerkt hat ... nur dir scheint es irgendwie entgangen zu sein :roll:

Der Quellcode deiner Programme sollte keine vertraulichen Daten enthalten, wenn du sie weitergeben willst. Die zum Ablauf des Programms notwendigen vertraulichen Daten kann man in eine Konfigurationsdatei auslagern, dann besteht auch kein Grund mehr für unsinnige Verschleierungsmaßnahme, die nichts bringen.

Denk doch mal kurz nach: Wenn du deinem Kollegen das Skript mit dem verschleiterten Passwort gibst, enthält dieses Skript zwangsläufig auch die Umkehrfunktion der Verschleierung, der dem Kollegen somit auch zur Verfügung steht.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

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
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

lunar hat geschrieben:...
#21
ichbinsisyphos
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

jerch hat geschrieben: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
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

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

jerch hat geschrieben:(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
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

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
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

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
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@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
User
Beiträge: 120
Registriert: Montag 4. Juni 2007, 19:19

jerch hat geschrieben:@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...
Gesperrt