Dmitri Rettig: Passwörter lokal verschlüsselt speichern

Hallo,

Ein Programm soll einige Benutzereinstellungen und -Daten speichern (XML), unter anderem auch Passwörter. XML-Dateien kann man einfach lesen, deswegen müssen die Passwörter irgendwie verschlüsselt gespeichert werden. Nun will ich aber den Quelltext des Programms frei zugänglich machen (erstmal Open Source ohne Lizens). Wie soll das mit der Verschlüsselung gehen?

Mit freundlichen Grüßen
   Dmitri Rettig

--
--------------------------------------
Diejenigen, die immer nur das Mögliche fordern, erreichen gar nichts. Diejenigen, die das Unmögliche fordern, erreichen wenigstens das Mögliche.
  -- M. Bakunin, da Sprüche grad' so inn sind.
  1. Hallo,

    Ein Programm soll einige Benutzereinstellungen und -Daten speichern (XML), unter anderem auch Passwörter. XML-Dateien kann man einfach lesen, deswegen müssen die Passwörter irgendwie verschlüsselt gespeichert werden. Nun will ich aber den Quelltext des Programms frei zugänglich machen (erstmal Open Source ohne Lizens). Wie soll das mit der Verschlüsselung gehen?

    Vielleicht hilft http://www.w3.org/Encryption/2001/ weiter.

    MfG, Thomas

  2. Moin Moin !

    Nun will ich aber den Quelltext des Programms frei zugänglich machen (erstmal Open Source ohne Lizens).

    Ohne Lizenz ?

    OK, ich nehm' den Quelltext, verändere ihn wie ich will, und verklage Dich anschließend bis auf den letzten Cent, weil Deine Software meine Oma aufgefordert hat, aus dem Fenster zu springen. Den Prozess könnte ich sogar gewinnen. Auf jeden Fall in den USA. ;-)

    Such Dir eine der gängigen Lizenzen aus, und achte auf einen Haftungsausschluß! GPL, BSD, LGPL, Perl Artistic License, ...

    Alexander

    --
    <!--#include file="signature.html" -->
    1. Hi,

      Nun will ich aber den Quelltext des Programms frei zugänglich machen (erstmal Open Source ohne Lizens).

      Ohne Lizenz ?

      OK, ich nehm' den Quelltext, verändere ihn wie ich will, und verklage Dich anschließend bis auf den letzten Cent, weil Deine Software meine Oma aufgefordert hat, aus dem Fenster zu springen. Den Prozess könnte ich sogar gewinnen. Auf jeden Fall in den USA. ;-)

      Such Dir eine der gängigen Lizenzen aus, und achte auf einen Haftungsausschluß! GPL, BSD, LGPL, Perl Artistic License, ...

      Das, was ich hier als Programm bezeichnet habe, ist ein kleines Progrämmchen um Java-Erfahrung zu sammeln und Kenntnisse aufzufrischen bzw. Unkenntnisse zu erkennen. Und "Open Source" nur für den eher unwarscheinlichn Fall, dass jemand ebenfalls Java-Erfahrungen auf einem bestimmten Gebiet sammeln und vielleicht seine Resultate in ein mehr oder weniger sinnvolles Programm implementieren will.

      Soll ja nichts kommerzielles werden. Und wenn ich nur meinen Code zum Download anbiete, dann erkennt man leicht, ob es mein Original, oder eine Veränderung des Originals ist.

      Mit freundlichen Grüßen
         Dmitri Rettig

      --
      --------------------------------------
      Diejenigen, die immer nur das Mögliche fordern, erreichen gar nichts. Diejenigen, die das Unmögliche fordern, erreichen wenigstens das Mögliche.
        -- M. Bakunin, da Sprüche grad' so inn sind.
  3. Moin!

    Hallo,

    Ein Programm soll einige Benutzereinstellungen und -Daten speichern (XML), unter anderem auch Passwörter. XML-Dateien kann man einfach lesen, deswegen müssen die Passwörter irgendwie verschlüsselt gespeichert werden. Nun will ich aber den Quelltext des Programms frei zugänglich machen (erstmal Open Source ohne Lizens). Wie soll das mit der Verschlüsselung gehen?

    Zunächst mal: Kein Mechanismus in XML hindert dich daran, die Daten verschlüsselt in XML abzulegen. XML ist ja nur der Container.

    Dann: Logischerweise kann man deinen Mechanismus der Verschlüsselung nachvollziehen, wenn du deinen Quelltext offenlegst. Entsprechend kann man also die Daten entschlüsseln, wenn du dich beim Verschlüsseln dumm anstellst. ;) Deshalb: Benutze eines der altbekannten, lange erprobten und als sicher betrachteten Verfahren und erfinde kein neues Verfahren. Dann ist sichergestellt, dass du keine dummen Hintertüren in ein selbst ausgedachtes Verfahren einbaust.

    Dann: Kläre, ob du Einwegverschlüsselung benutzen willst. Crypt (nicht empfehlenswert) oder MD5 bieten sich an. Du mußt nur den Mechanismus implementieren bzw. kannst möglicherweise externe Funktionen bzw. Bibliotheken einbinden und mußt dich ansonsten um nichts weiter kümmern.

    Wenn du die Daten aus irgendeinem Grund wiederherstellen mußt: Nimm ein symmetrisches Verfahren wie 3DES oder Blowfish. Zum Verschlüsseln benötigst du dann einen Schlüssel, der unter allen Umständen geheim bleiben muss. Aus diesem Grund kannst du dann durchaus dein Programm selbst veröffentlichen - solange der Schlüssel geheim bleibt, sind auch deine verschlüsselten Daten unzugänglich. Der kritische Punkt ist hierbei, den geheimen Schlüssel wirklich geheim zu halten. Je nach Systemarchitektur ist das mehr oder weniger einfach bis hin zu unmöglich - und auch der Komfort der Lösung (Lesen aus einer Datei oder Eingabe über die Tastatur und Bereithalten im RAM) ist variabel.

    Entsprechend kannst du natürlich auch asymmetrische Verfahren wie PGP verwenden. Dann kannst du jederzeit über den öffentlichen Schlüssel verschlüsselte Daten generieren, und den Zugriff auf die verschlüsselten Daten erfolgen über den privaten Schlüssel - dieser ist natürlich wieder geheim zu halten, ansonsten sind die verschlüsselten Daten nicht geheim.

    Das Problem bei umkehrbaren Verschlüsselungen ist immer die Geheimhaltung des Schlüssels. Deshalb hängt die zu wählende Lösung auch ganz stark davon ab, welche Datenströme vorliegen bzw. welche Zugriffe auf die Daten von wem erfolgen sollen.

    Für Passworte empfiehlt sich ein Hash-Verfahren wie MD5. Ein später eingegebenes Passwort wird einfach auch MD5-codiert, das Ergebnis mit dem gespeicherten Wert verglichen. Wird ein Passwort vergessen, generiert man einfach ein neues (anderes), teilt es einmal im Klartext dem Benutzer mit und speichert es gleich MD5-codiert ab.

    Für Daten, die nur in eine Richtung durch einen unsicheren Übertragungskanal übertragen werden müssen, ist ein Asymmetrisches Verfahren geeignet. Wenn beispielsweise persönliche Daten erfasst und per SSL zum Server gesendet werden, dort aber nur ein Formmailer eingesetzt werden soll, ist es ratsam, die Mail mit PGP verschlüsselt abzusenden. Auf die eingegebenen Daten wird der Server nicht wieder zurückgreifen.

    Wenn hohe Sicherheit mit ständigem Zugriff gefordert ist, ist sehr zu prüfen, wo man mit dem Sicherheitsmechanismus ansetzt. Denn wenn der geheime Schlüssel z.B. einem CGI-Skript bekannt ist, d.h. von ihm gelesen werden kann, wäre es grundsätzlich möglich, ihn eventuell vom Server auslesen zu lassen. Außerdem besteht bei Multi-Host-Servern das Problem, dass vermutlich auch Skripte von anderen Usern Lesezugriff haben, wenn der Schlüssel in einer Datei steht. In diesem Fall ist es angebracht, den Schlüssel von einer weiteren, unabhängigen Instanz, z.B. einem Crypto-Deamon, verwalten zu lassen, der unter der eigenen oder einer separaten User-ID läuft und als einziger Lesezugriff auf die Schlüsseldaten hat.

    Bedenke aber, dass auch dann Root vermutlich immer feststellen kann, wie dein Schlüssel lautet. Wenn du aktiv wieder an die Daten ran willst und nicht selbst Root auf dem System bist, kannst du symmetrische Verschlüsselung deshalb eigentlich vergessen. Sorge dafür, dass kein Mitbenutzer die Daten lesen kann (der systemeigene Zugriffsschutz sollte das erledigen können), und gut ist. Alternativ ist eine asymmetrische Verschlüsselung geeignet, um Daten erstmal zu sichern und dann auf ein vertrauenswürdiges eigenes System zu transferieren, um sie dort wieder zu entschlüsseln.

    Ach ja: Wenn die Daten bei der Erfassung unverschlüsselt über das Internet übertragen werden, brauchst du sie hinterher auch nicht mehr intensiv zu verschlüsseln. Der schwächste Punkt bzw. die schlechteste Verschlüsselung der Transferkette entscheidet über die Sicherheit - unverschlüsselt ist daher immer schlecht und macht jede weitere Verschlüsselung im Prinzip sinnlos.

    Informiere dich, falls du Root auf deinem eigenen System bist, auch über die Möglichkeiten, verschlüsselte Dateisysteme zu benutzen. Dann mußt du nicht mehr deine einzelnen Dateien verschlüsseln, sondern lagerst diese Problematik auf dein Betriebssystem aus. In der Regel muss man beim Systemstart ein Passwort eingeben, um auf das verschlüsselte Dateisystem Zugriff zu erlangen - damit sind die Daten geschützt, wenn der Rechner von unautorisierten Personen gestartet wird. Wenn er beispielsweise aus dem Serverraum geklaut wird, wird man ihn in der Regel herunterfahren müssen, kriegt beim erneuten Hochfahren dann aber keinen Zugriff auf sensible Daten mehr.

    - Sven Rautenberg

    --
    Diese Signatur gilt nur am Freitag.
    1. Möp!

      Ein Programm soll einige Benutzereinstellungen und -Daten speichern (XML), unter anderem auch Passwörter. XML-Dateien kann man einfach lesen, deswegen müssen die Passwörter irgendwie verschlüsselt gespeichert werden. Nun will ich aber den Quelltext des Programms frei zugänglich machen (erstmal Open Source ohne Lizens). Wie soll das mit der Verschlüsselung gehen?

      Soo ... nun bin ich fertig mit durchgoogeln nach Farchbegriffen und ich glaube, ich verstehe jetzt, was du in diesem riesigen Beitrag geschrieben hast.

      Zunächst mal: Kein Mechanismus in XML hindert dich daran, die Daten verschlüsselt in XML abzulegen. XML ist ja nur der Container.

      Das ist mir klar.

      Dann: Logischerweise kann man deinen Mechanismus der Verschlüsselung nachvollziehen, wenn du deinen Quelltext offenlegst.

      Das ist eben mein Problem. Angenommen ich habe einen Browser programmiert. Der Benutzer geht auf http://forum.de.selfhtml.org/my/, wird nach dem Usernamen und dem Passwort gefragt und der Browser soll das Passwort irgendwie abspeichern. Die XML-Datei könnte dann aussehen:

      <seite url="http://forum.de.selfhtml.org/my/" username="drettig" passwort="asjdj2309uklckjaöwuoudjcn">SELFFORUM - da poste ich rein, da bin ich ein Mensch (oder so)</seite>

      Das Passwort sei muroffles (selfforum rückwärts), und verschlüsselt asjdj2309uklckjaöwuoudjcn. An den Server muss ich die Zeichenkette muroffles übergeben (natürlich verschlüsselte Übertragung), dazu muss ich aus asjdj2309uklckjaöwuoudjcn muroffles machen. Und das ist eben mein Problem. Das muss irgendwie schon beim Anwedner geschehen. Und da das Programm Open Source ist ...

      Wie hat man es beim Mozilla gemacht? Da kann man doch auch Passwörter speichern.

      Mit freundlichen Grüßen
         Dmitri Rettig

      --
      --------------------------------------
      Diejenigen, die immer nur das Mögliche fordern, erreichen gar nichts. Diejenigen, die das Unmögliche fordern, erreichen wenigstens das Mögliche.
        -- M. Bakunin, da Sprüche grad' so inn sind.
      1. Moin!

        Das Passwort sei muroffles (selfforum rückwärts), und verschlüsselt asjdj2309uklckjaöwuoudjcn. An den Server muss ich die Zeichenkette muroffles übergeben (natürlich verschlüsselte Übertragung), dazu muss ich aus asjdj2309uklckjaöwuoudjcn muroffles machen. Und das ist eben mein Problem. Das muss irgendwie schon beim Anwedner geschehen. Und da das Programm Open Source ist ...

        Nein, du mußt nicht das gespeicherte, codierte Passwort wiederherstellen, sondern du mußt das von Benutzer übermittelte Passwort ebenfalls codieren und gucken, ob es mit dem gespeicherten, codierten Passwort übereinstimmt. :)

        Wenn der Benutzer sich erstmals ein Passwort wählt, codierst du es mit MD5. Der MD5-Algorithmus kann nicht rückgängig gemacht werden, also kommt keiner an das Passwort ran, auch wenn er den verschlüsselten Text kennt.

        Wenn später das Passwort verifiziert werden soll, codierst du es einfach nochmal und vergleichst. Gleiche Passworte führen zu gleichen Ergebnissen der MD5-Codierung, unterschiedliche Passworte führen zu unterschiedlichen Ergebnissen.

        Man kann ein MD5-codiertes Passwort nur durch Ausprobieren aller möglichen Buchstabenkombinationen wiederherstellen - was eine gewisse Zeit dauert. Allerdings gibt es einen ganz winzigen Nachteil: MD5-codierte Strings sind immer gleich lang. Der Input dafür kann aber unterschiedlich lang sein, und auch wesentlich länger, als der MD5-String. Das bedeutet: Irgendwelche zwei Inputs haben als Ergebnis den gleichen Output. Zwei Tatsachen machen das aber vernachlässigbar: 1. Eine winzige Änderung im Input sorgt für große Veränderungen im Output. Man kann sich also nicht durch Raten dem Passwort annähern. 2. Der Output ist eine 128-Bit-Zahl. Es gibt also 2^128 (bzw. 3,4*10^38) verschiedene Outputs - aber es gibt nur 6*10^9 Menschen auf der Welt, also kann sich jeder Mensch 5*10^28 verschiedene Passwörter ausdenken - das sollte ausreichen.

        Wie hat man es beim Mozilla gemacht? Da kann man doch auch Passwörter speichern.

        Simpel: Die Passwörter wandern vermutlich im Klartext irgendwo auf die Festplatte. Und selbst wenn es verschlüsselt gespeichert würde, würde das ja nichts helfen: Es muß zur Übermittlung wieder im Klartext vorliegen. Deshalb ist eines der grundlegenden Prinzipien, wenn man seine Passwörter sicher aufbewahren will: Niemals "Passwort speichern" wählen, wenn der Rechner grundsätzlich auch von anderen genutzt werden kann.

        Allerdings ist das Risiko bei einem Client-Rechner auch ein viel geringeres. Normalerweise laufen auf ihm keine Serverdienste, also ist er von außen nicht erreichbar (ok, die Windows-Laufwerksfreigabe ist ein Serverdienst, der häufig läuft - aber das ist Sache des Computerbesitzers, den fürs Internet abzuschalten oder mit Passwort zu sichern). Insofern gibt es fast keine Ansatzpunkte, dass ein Fremder von außen die Passwortdatei in die Finger kriegt . Bei einem Server ist das etwas ganz anderes: Der muß erreichbar sein und wird manchmal fehlerhaft konfiguriert oder programmiert. Also ist es besser, wenn niemand mit einer Passwortdatei was anfangen kann - deshalb MD5-codieren, denn das kann niemand decodieren.

        Beachte, dass ich (hoffentlich überall) nicht von MD5-_Verschlüsselung_ spreche - eine Verschlüsselung kann man wieder entschlüsseln. Auch "MD5-Codierung" ist im strengen Sinne falsch - was man codieren kann, kann man auch decodieren. MD5 ist ein Prüfsummenverfahren, und als solches ist es für die Kontrolle von "korrekten Inhalten" wie Passwörtern prima geeignet. Aber ich kenne kein Verb für "Prüfsumme erstellen", welches sich flüssig in einen Satz einfügt. "Passwort MD5-codieren" ist irgendwie deutlich (insbesondere zeigt es, dass nichts _verschlüsselt_ wird), "Passwort md5-prüfsummieren" klingt blöd. :)

        - Sven Rautenberg

        --
        Diese Signatur gilt nur am Freitag.
        1. Hi,

          vielen Dank, ich werde mich wohl mit der Materie etwas auseinandersetzen müssen. Scheint aber gar nicht mal so schwer zu sein, zumal, der MD5-Algorithmus in Java geschrieben wurde (es heisst doch, einen Algorithmus in einer Programmiersprache schreiben, oder implimentieren?)

          Mit freundlichen Grüßen
             Dmitri Rettig

          --
          ##############################################################################################
          Diejenigen, die immer nur das Mögliche fordern, erreichen gar nichts. Diejenigen, die das Unmögliche fordern, erreichen wenigstens das Mögliche.
            -- M. Bakunin, da Sprüche grad' so inn sind.