Zugangsdaten auslagern

  • Moinsen,


    gibt es die Möglichkeit Zugangsdaten nicht direkt in einem Pythonskript zu benutzen, sondern in einer separaten Datei auszulagern? z.B. Benutzernamen und Passwörter für diverse Anmeldungen und Dienste.


    Das würde es vereinfachen seine Skripte online zu posten ohne Sorge haben zu müssen, vlt. irgendwo keinen Platzhalter eingetragen zu haben.

    Ärgerlich ist es auch, wenn man für irgendwo sein Passwort geändert hat und erstmal alle Skripte überprüfen muss, wo evtl. ein Zugriff erfolgt.


    Hatte mal irgendwo was von env-Dateien gelesen. Weiß aber nicht ob sowas wirklich Sinn macht oder wie soetwas umzusetzen wäre.


    Was meint ihr dazu?

  • Go to Best Answer
  • Hallo,


    spontan würde mir eine *.csv - Datei und den DictReader von Python einfallen:

    Code: Userdata.csv
    Username,Password
    FigUhr,1234

    und

    ergibt:

    Code
    FigUhr
    1234



    Grüße

    Dennis

    🎵🎸Die Nordsee schlägt dir ins Gesicht, trotzdem hast du verloren, du bist nicht weit gekommen, du läufst weiter nach vorn 🎵🎸

    • Best Answer

    gibt es die Möglichkeit Zugangsdaten nicht direkt in einem Pythonskript zu benutzen, sondern in einer separaten Datei auszulagern?

    Dafür gibt es u.a. toml. ;) Sieh mal hier unter "erste Schritte" Mein Weg zu einem Telegrambot mit Python wie das Hofei verwendet hat.

  • Im Übrigen sollte man ja auch nicht das Passwort abspeichern, sondern eine Einwegverschlüsselung (Hash) davon. Am Besten noch mit einem "Salt" verfälscht, damit im Zweifel keiner in Hashlisten bestehender Passwörter nachsehen kann, falls er das verschlüsselte Passwort mal in die Finger bekommt.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Im Übrigen sollte man ja auch nicht das Passwort abspeichern, sondern eine Einwegverschlüsselung (Hash) davon.


    Du beschreibst die Serverseite, ich glaube aber, dass er den Client meint.


    Üblicherweise werden für APIs wegwerf-Tokens generiert, die dann anstelle des Passworts verwendet werden.

    Würde man das eingegebene Passwort als Hash speichern und den Hash übermitteln, macht der Dienst ein Hash aus dem Hash.


    Man könnte die Logindaten mit symmetrischer/asymmetrischer Verschlüsselung auf dem lokalen Computer schützen.

    Beispiel: https://cryptography.io/en/lat…ing-passwords-with-fernet



    Die .env Lösung finde ich aus folgenden Gründen aber besser:

    • Es sind keine Umgebungsvariablen, die andere Prozesse einsehen können
    • Kann durch Berechtigungen im lokalen Dateisystem vor anderen Prozessen geschützt werden
    • liegt unverschlüsselt vor, d.h. man muss nichts entschlüsseln und sich auch keine Gedanken über die Krypto machen
    • wird von vielen Projekten bereits eingesetzt
    • einfach zu integrieren
    • Kann vor versehentlichem Hochladen auf github respositories durch .gitignore verhindert werden.
  • Ja, offenbar meint er Zugangsdaten für andere Dienste. Kann ja nicht so schwer sein, die in einer Umgebungsvariablen oder einer Datei/Datenbank abzuspeichern.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

    Edited once, last by Gnom ().

  • Umgebungsvariable == ganz schlecht, weil andere Prozesse automatisch Zugriff auf die Umgebungsvariablen haben.

    Das kann man mit systemd ggf. isolieren, sofern es sich um einen Dienst handeln soll, der im Hintergrund durch systemd gestartet wird.

    Wenn es aber eine Applikation ist und nicht durch systemd gestartet kann/soll, lassen sich die Umgebungsvariablen schlecht isolieren.


    python-dotenv liest die lokale .env Datei und überträgt das Mapping dem lokalen Environment des Programms. D.h. andere Programme können diese Variablen nicht sehen.

  • Mir scheint das .env ein nicht ganz passender, oder verwirrender Name ist. Mit Environment (env) hat das ja nicht wirklich was zu tun. Es ist, soweit ich es richtig verstanden habe, eine ganz normale Textdatei in der Variablen stehen mit Wert (Variable=<Wert>). Diese werden dann als Datenquelle benutzt (einlesen und verarbeiten). Eine Umgebungsvariable kann das zwar auch sein, ist aber wohl nicht gemeint.

  • Mir scheint das .env ein nicht ganz passender, oder verwirrender Name ist. Mit Environment (env) hat das ja nicht wirklich was zu tun.

    Nicht direkt, aber indirekt, da load_dotenv() die lokalen Umgebungsvariablen setzt, ohne sie zu exportieren

    Alternativ bekommt man mit dotenv_values() ein dict.


    Die Implementierungen für die anderen Sprachen machen das auch so.

  • daxb Die Datei enthält Definitionen für Umgebungsvariablen. Die kann man auch in einer Shell ”sourcen” dann sind es normale Umgebungsvariablen. Es gibt (gab?) auch Projekte die das machen, ist aber halt unsicherer wenn andere (Kind)Prozesse sich die Daten anschauen können.

    “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” — Edsger Dijkstra

  • Das Auslagern von Zugangsdaten scheint also gängige Praxis zu sein?

    Seitdem es Github gibt.


    Grund: Es sind zu viele Passwörter und Tokens geleakt worden.


    Ich glaub, der Solarwinds-Hack lief so ab. Das ist eben doof, wenn man seine Zugangsdaten von einem Dienst/API im Code hinterlässt und der Öffentlichkeit zugänglich macht. Außerdem ist es fast unmöglich nach so einem Unfall das wieder aus dem Repository zu bekommen. Dennoch sollte man vorher die .gitignore anfertigen, damit die .env Dateie oder auch die .toml Datei ignoriert wird.

  • Das ist eben doof, wenn man seine Zugangsdaten von einem Dienst/API im Code hinterlässt und der Öffentlichkeit zugänglich macht.

    Solange das Repo nur firmenintern zugreifbar ist ist es nicht so schlimm. Aber auch da muss das - nicht sollte das - nicht passieren. Bekanntermassen werden die meissten IT Schaeden in Unternehmen von intern vorgenommen ... Wenn es denn dann ein externes Repo ist ist das ein Gau :rip:

    Außerdem ist es fast unmöglich nach so einem Unfall das wieder aus dem Repository zu bekommen.

    100% sicher ist man wenn die Zugangscredentials geaendert werden.

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect."

    Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert =O Bei mir tut das raspiBackup automatisch ;)

  • Dafür gibt es u.a. toml. ;) Sieh mal hier unter "erste Schritte" Mein Weg zu einem Telegrambot mit Python wie das Hofei verwendet hat.

    toml 0.10.2 als aktuellste Version? Das klingt für mich nicht gerade "ausgereift" oder final.


    Außerdem werde ich ständig von neuen kreativen Fehlermeldungen bombardiert. Bei unverändertem Quellcode, versteht sich. Leider sind sie daher auch nicht reproduzierbar. Wie immer Hofei damals den Telegram-Bot bei diesem Code zum Laufen gebracht hat.

  • toml 0.10.2 als aktuellste Version? Das klingt für mich nicht gerade "ausgereift" oder final.

    Was erwartest Du? Sollte stable immer bei 1.0 beginnen? :lol: Sieh Dir die mal History https://pypi.org/project/toml/#history an!


    Außerdem werde ich ständig von neuen kreativen Fehlermeldungen bombardiert. Bei unverändertem Quellcode, versteht sich.

    Ohne konkretem Skript kann man dazu nichts sagen. Ich verwende toml auch und das funktioniert super bei mir.

  • FigUhr Die 10 nach der 0 klingt IMHO schon ausgereift. Nach *10* Versionen sollten die Kinderkrankheiten in der Regel alle auskuriert sein. Und es gibt bei OpenSource generell ziemlich viele Projekte/Bibliotheken die sich scheuen jemals die 1.0 zu erreichen, weil fertig ist man ja eigentlich nie. Oder wenn man dann fertig ist, hat man eine 0.42.23 und man hat keinen Anlass mehr eine neue Version raus zu bringen, weil die ist ja fertig, und nur um die Versionsnummer zu ändern, macht doch keiner ein *Major*-Release.

    “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” — Edsger Dijkstra

  • Oder wenn man dann fertig ist, hat man eine 0.42.23 und man hat keinen Anlass mehr eine neue Version raus zu bringen, weil die ist ja fertig, und nur um die Versionsnummer zu ändern, macht doch keiner ein *Major*-Release.

    Da merkt man die psychologischen Nebenwirkungen eines jahrelangen Microsoft-Nutzers.


    Hätte nicht gedacht, das ich mich jemals mit dem Thema Versionierung beschäftigen würde. Interessant was da zB bei Microsoft für eine Strategie praktiziert wird.

  • Bei Firmen, oder auch grösseren OpenSource-Anwendungen für Endanwender sieht das anders aus. Da gibt's dann auch Marketingabteilungen oder man schaut auf die Versionsnummern von Konkurrenzprodukten. 🙂

    “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” — Edsger Dijkstra