Naps: Tipps, Literatur Verschlüsselung

Hi,

kann mir vielleicht jemand ein paar Ansätze für folgendes liefern?

Ich möchte Nachrichten, die über eine Web-App versendet werden verschlüsselt in einer DB abspeichern.
Es handelt sich dabei, um ein "ganz normales" Nachrichtensystem, wie man es in fast jedem Forum findet.

Ich weiß, dass Verschlüsselung eine Sache ist, bei der man viel falsch machen kann. Gibt es gute Literatur darüber? Welche Ansätze gibt es?

Die Nachrichten werden prinzipiell nur zwischen 2 Personen hin und her versendet und nicht an mehrere. Lesbar sollen sie nur für diese beiden Personen sein.

Wäre Dankbar für jede Hilfe :)

MfG Naps

  1. Ich weiß, dass Verschlüsselung eine Sache ist, bei der man viel falsch machen kann. Gibt es gute Literatur darüber? Welche Ansätze gibt es?

    Literatur? viel falsch machen? Willst du etwa selber eine Verschlüsselung umsetzen? Vergiß es, nimm was fertiges.

    Ich möchte Nachrichten, die über eine Web-App versendet werden verschlüsselt in einer DB abspeichern.

    Genau genommen steht da nicht, daß sie auch in verschlüsseltem Zustand versendet werden sollen. Sollen sie aber, oder?

    Hilft Dir Pretty good privacy weiter?

    Es handelt sich dabei, um ein "ganz normales" Nachrichtensystem, wie man es in fast jedem Forum findet.

    Die Nachrichten sollen also nicht wie Emails versendet werden, sondern sie werden vom "Versender" in der Datenbank gespeichert und vom "Empfänger" aus der Datenbank gelesen? Warum auch immer. Aber ansich ändert das nichts, die Ver- und Entschlüsselung muß außerhalb der Vorgangs stattfinden, also lokal. Für den Rest könnte man beliebige filehoster verwenden.

    Die Nachrichten werden prinzipiell nur zwischen 2 Personen hin und her versendet und nicht an mehrere. Lesbar sollen sie nur für diese beiden Personen sein.

    Also würde auch eine Verschlüsselung mit einem Paßwort für beide ausreichen. Was gefällt Dir denn nicht an den Möglichkeiten die Du recherchiert hast?

    1. Literatur? viel falsch machen? Willst du etwa selber eine Verschlüsselung umsetzen? Vergiß es, nimm was fertiges.

      Nein natürlich will ich keine selber umsetzen.

      Ich möchte Nachrichten, die über eine Web-App versendet werden verschlüsselt in einer DB abspeichern.

      Genau genommen steht da nicht, daß sie auch in verschlüsseltem Zustand versendet werden sollen. Sollen sie aber, oder?

      Nein, sie werden ja auch nicht "versendet" sondern nur gespeichert.

      Hilft Dir Pretty good privacy weiter?

      Muss ich mir anschauen :)

      Die Nachrichten sollen also nicht wie Emails versendet werden, sondern sie werden vom "Versender" in der Datenbank gespeichert und vom "Empfänger" aus der Datenbank gelesen? Warum auch immer. Aber ansich ändert das nichts, die Ver- und Entschlüsselung muß außerhalb der Vorgangs stattfinden, also lokal. Für den Rest könnte man beliebige filehoster verwenden.

      Natürlich werden sie nicht versendet. Ich kann mir auch nicht vorstellen, dass bei anderen Nachrichtensystemen in Foren, die Nachrichten versendet werden!? Die werden doch auch nur in einer DB gespeichert.

      Also würde auch eine Verschlüsselung mit einem Paßwort für beide ausreichen. Was gefällt Dir denn nicht an den Möglichkeiten die Du recherchiert hast?

      Ja schon, aber der User soll so wenig wie möglich davon mitbekommen. Er soll sich nicht um die Verschlüsselung kümmern müssen. Da der user eingeloggt sein muss, kann ich ihn jederzeit identifizieren. Aber wie und wo speichert man das Passwort? Liegt hier nicht genau die Schwachstelle?

      MfG Naps

      1. Genau genommen steht da nicht, daß sie auch in verschlüsseltem Zustand versendet werden sollen. Sollen sie aber, oder?
        Nein, sie werden ja auch nicht "versendet" sondern nur gespeichert.

        Und wie kommen die Nachrichten auf den Server und wie sollen die auf dem Server liegenden Nachrichten gelesen werden? Sie werden vom Versender an den Server gesendet und auf Abfrage vom Server an den Empfänger. Soll das wirklich unverschlüsselt erfolgen? Geht es wirklich nur um den Spezialfall, daß irgendein Angriff auf die Datenbank erfolgen könnte ohne dabei den Server selbst zu kompromittieren?

        Wogengen willst Du die Nachricht schützen?

        Also würde auch eine Verschlüsselung mit einem Paßwort für beide ausreichen. Was gefällt Dir denn nicht an den Möglichkeiten die Du recherchiert hast?

        Ja schon, aber der User soll so wenig wie möglich davon mitbekommen. Er soll sich nicht um die Verschlüsselung kümmern müssen. Da der user eingeloggt sein muss, kann ich ihn jederzeit identifizieren. Aber wie und wo speichert man das Passwort? Liegt hier nicht genau die Schwachstelle?

        Ja und nein. Die Schwachstelle ist egal. Selbst wenn das Paßwort sicher verwart ist, wenn der Server kompromittiert ist, kann der Angreifer warten, bis der Server die Nachricht mit dem sicher verwarten Paßwort für den Empfänger entschlüsselt hat.

        1. Selbst wenn das Paßwort sicher verwart ist, wenn der Server kompromittiert ist, kann der Angreifer warten, bis der Server die Nachricht mit dem sicher verwarten Paßwort für den Empfänger entschlüsselt hat.

          Für eingehende Nachrichten gilt das natürlich auch, die greift der Angreifer ab, bevor sie verschlüsselt werden.

        2. Und wie kommen die Nachrichten auf den Server und wie sollen die auf dem Server liegenden Nachrichten gelesen werden? Sie werden vom Versender an den Server gesendet und auf Abfrage vom Server an den Empfänger. Soll das wirklich unverschlüsselt erfolgen? Geht es wirklich nur um den Spezialfall, daß irgendein Angriff auf die Datenbank erfolgen könnte ohne dabei den Server selbst zu kompromittieren?

          Jein, ich dachte, dass es keine vernünftige Lösung gibt, die Nachrichten direkt beim Client zu ver- und Entschlüsseln.

          Wogengen willst Du die Nachricht schützen?

          Gegen unerlaubten Zugriff ;)

          1. Hello,

            Jein, ich dachte, dass es keine vernünftige Lösung gibt, die Nachrichten direkt beim Client zu ver- und Entschlüsseln.

            Es gibt Software, die den ein- und den ausgehenden Datenverkehr deines Client behandeln kann. Die nennt man "Application Fire Wall". Die guckt in die Pakete rein, die rein und rausgehen und ist auch in der Lage, die Payload zu ver- und zu entschlüsseln, je nach Protokoll. Sinnvollerweise sollte die auch nicht auf demselben Host laufen. Und viel Geld kostet sie auch. Ob man ihr noch trauen kann, weiß ich auch nicht.

            Nun kann man sich angesichts der Snowden-Aussagen ff. mal fragen, wer wohl die "Clouds" so sehr propagiert hat. Allerdings ist es da wohl in den leztzten Wochen ziemlich still geworden um die Cloud-Werbung, oder?

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bikers-lodge.com
          2. Geht es wirklich nur um den Spezialfall, daß irgendein Angriff auf die Datenbank erfolgen könnte ohne dabei den Server selbst zu kompromittieren?

            Jein, ich dachte, dass es keine vernünftige Lösung gibt, die Nachrichten direkt beim Client zu ver- und Entschlüsseln.

            Es ist die *einzig vernünftige* Lösung, die Nachrichten direkt beim Client zu ver- und entschlüsseln.

            In der Tat ist das im Web nicht ohne weiteres möglich, wie ich bereits schrieb.

            Mathias

      2. Hello,

        Die Nachrichten sollen also nicht wie Emails versendet werden, sondern sie werden vom "Versender" in der Datenbank gespeichert und vom "Empfänger" aus der Datenbank gelesen? Warum auch immer. Aber ansich ändert das nichts, die Ver- und Entschlüsselung muß außerhalb der Vorgangs stattfinden, also lokal. Für den Rest könnte man beliebige filehoster verwenden.
        Natürlich werden sie nicht versendet. Ich kann mir auch nicht vorstellen, dass bei anderen Nachrichtensystemen in Foren, die Nachrichten versendet werden!? Die werden doch auch nur in einer DB gespeichert.

        Klar, und dazu müssen sie einen Weg von Deinem Client zur Datenbank zurücklegen.

        Also z.B. Browser -> Übertragung -> Webserver -> Übertragung -> Datenbankserver

        Wenn es wirklich vernünftig sein soll, muss bereits der Client verschlüsseln.
        Die Datenbankfunktionen (hier von MySQL)
        http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-decrypt
        http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-encrypt

        helfen Dir da wahrscheinlich gar nicht.

        Du müsstest erst einmal definieren, welche Komponenten deines Konstruktes "sicher" sind und welche unsicher, also
        Client: sicher (sicher?)
        Leitung zum Hub: unsicher
        Leitung durchs Haus: unsicher
        Router: ?
        Leitung zum Anschlaltepunkt des Netzproviders: unsicher
        usw.

        Dann kannst Du dir anschließend Gedanken über Verschlüsselung machen

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bikers-lodge.com
        1. Klar, und dazu müssen sie einen Weg von Deinem Client zur Datenbank zurücklegen.

          Ok, so hatte ich das nicht bedacht :)

          Also z.B. Browser -> Übertragung -> Webserver -> Übertragung -> Datenbankserver

          Wenn es wirklich vernünftig sein soll, muss bereits der Client verschlüsseln.
          Die Datenbankfunktionen (hier von MySQL)
          http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-decrypt
          http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-encrypt

          helfen Dir da wahrscheinlich gar nicht.

          Aber wie bereits gesagt, beim Client ist es in diesem Fall nicht wirklich möglich !?

          Du müsstest erst einmal definieren, welche Komponenten deines Konstruktes "sicher" sind und welche unsicher, also
          Client: sicher (sicher?)
          Leitung zum Hub: unsicher
          Leitung durchs Haus: unsicher
          Router: ?
          Leitung zum Anschlaltepunkt des Netzproviders: unsicher
          usw.

          Client kann ich in diesem Fall als sicher definieren.

          Wichtig für mich ist, dass die Daten verschlüsselt abgespeichert sind und nicht "offen" in einer DB liegen.

          1. Hello,

            Du müsstest erst einmal definieren, welche Komponenten deines Konstruktes "sicher" sind und welche unsicher, also
            Client: sicher (sicher?)
            Leitung zum Hub: unsicher
            Leitung durchs Haus: unsicher
            Router: ?
            Leitung zum Anschlaltepunkt des Netzproviders: unsicher
            usw.

            Client kann ich in diesem Fall als sicher definieren.

            Der Client ist nur solange "sicher", wie man keine fremde Software einsetzt und Geräte benutzt, die von vor 1999 stammen. Die haben vermutlich noch kein "Chiptuning" erhalten damals.

            Das ist aber in der Praxis gar nicht möglich. Du kannst ja nicht alles selber schreiben. Da müsstest Du zurück zum guten alten DOS, davon gabs noch Clones (PTS) usw.

            Browser sind mir schon von Haus aus suspekt. Wenn dann auch noch solche Klamotten, wie Adobe-Reader, Flash, usw. hinzu kommen, ist der Ofen ganz aus. Und wieviel Prozent der "Virenschutzsoftware" SIND in Wirklichkeit der Virus?

            Nach der SSl/TLS-Schlappe, die angeblich schon seit 2006 existiert hat, kann man ja auch der Open-Source-Gmeinde nicht mehr trauen. Wir sind auch alle zu bequem geworden! Warum noch nachdenken, es "funzt" doch?

            Und was in den Chips drinsteckt, weißt Du auch nicht mehr.

            Nachdem jetzt mal wieder bekannt wurde, dass der NSA 1000de von Cisco-Routern auf dem Postweg abgefangen, und manipuliert hat, kann man doch gar nichts mehr glauben.

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bikers-lodge.com
          2. Wichtig für mich ist, dass die Daten verschlüsselt abgespeichert sind und nicht "offen" in einer DB liegen.

            Das ist für sich genommen nicht wichtig. Es schützt dich nicht zuverlässig vor Angriffen auf deine Infrastruktur, es schützt nicht die User vor Abhören ihrer Kommunikation.

            Nützlich für die User wäre, dass nichts und niemand zwischen Alice und Bob den Klartext der Nachrichten lesen kann.

            Mathias

      3. Hello,

        hier könntest Du mal anfangen zu lesen
        http://webmagazin.de/web/security/PRISM-Co-Selbstverteidigung-fuer-Nerds-168223

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bikers-lodge.com
      4. Hallo,

        aber der User soll so wenig wie möglich davon mitbekommen. Er soll sich nicht um die Verschlüsselung kümmern müssen.

        Dann hat sie für die User auch keinerlei Nutzen und schützt die Daten auch nicht, wenn dein Server oder irgendeine Stelle in der Kommunikation kompromittiert wird.

        Da der user eingeloggt sein muss, kann ich ihn jederzeit identifizieren. Aber wie und wo speichert man das Passwort? Liegt hier nicht genau die Schwachstelle?

        Wenn man anfängt, Nachrichten zur Speichern in der Datenbank mit Schlüsseln zu verschlüsseln, die auf den eigenen Servern liegen oder auch nur irgendwann temporär im Speicher vorliegen, kann man das ganze Verschlüsseln gleich sein lassen. Wovor schützt die Verschlüsselung dann noch? Nicht vor Angriffen auf Server bzw. Datenbank.

        Mathias

  2. Hallo,

    Die Nachrichten werden prinzipiell nur zwischen 2 Personen hin und her versendet und nicht an mehrere. Lesbar sollen sie nur für diese beiden Personen sein.

    Die brauchbaren Ansätze arbeiten damit, dass die Kommunikationsteilnehmer ein Schlüsselpaar besitzen und also einen privaten Schlüssel besitzen, den alle Stationen dazwischen nicht kennen. Nur so ist eine Ende-zu-Ende-Verschlüsselung möglich.

    Bekannte Implementierungen sind OpenPGP und OTR.

    So etwas in einer Web-Apps zu implementieren ist konzeptionell problematisch, um nicht zu sagen unmöglich, weil der Browser keine sichere Programmierumgebung ist und die privaten Schlüssel nicht hinreichend sicher gespeichert werden können. Es gibt Versuche, diese Probleme zu umgehen.

    Mathias

    1. hi molily,

      So etwas in einer Web-Apps zu implementieren ist konzeptionell problematisch, um nicht zu sagen unmöglich, weil der Browser keine sichere Programmierumgebung ist und die privaten Schlüssel nicht hinreichend sicher gespeichert werden können. Es gibt Versuche, diese Probleme zu umgehen.

      Wo ist denn da die Unsicherheit? Das träfe ja dann auch auf Mobile-Apps zu, die mit Phonegap gebaut sind, weil man da auf einer Browserengine aufbaut?

      Und was heißt "Sicherheit" oder "unmöglich". Redest Du von NSA, sonstigen, vielleicht minder bemittelten nationalen Sicherheitsorganen oder Hackern/Viren/Malware?

      mfg

      tami

        1. hi molily,

          Grundlagen:
          http://tonyarcieri.com/whats-wrong-with-webcrypto

          Finde ich gleich:

          "If ample precautions are taken (which includes a large laundry list of things like TLS, CSP, CORS, proper HTTP headers, JS strict mode, and more), this can allow for the successful development of cryptographic applications that attempt to enforce the interests of the web application creator.
          [...]
          Before I keep talking about where in-browser cryptography is inappropriate, let me talk about where I think it might work: I think it has great potential uses for encrypting messages sent between a user and the web site they are accessing. For example, my former employer LivingSocial used in-browser crypto to encrypt credit card numbers in-browser with their payment processor’s public key before sending them over the wire (via an HTTPS connection which effectively double-encrypted them). This provided end-to-end encryption between a user’s browser and the LivingSocial’s upstream payment gateway, even after HTTPS has been terminated by LivingSocial (i.e. all cardholder data seen by LivingSocial was encrypted).

          In this approach, there’s an implicit trust relationship between the user and the site they’re accessing. What we see happening here is cryptography being used to protect the web site’s interests, not the user’s. For this purpose, in-browser crypto is great!"

          Das lese ich so, dass kryptografische Übertragung von Textnachrichten eigentlich prima möglich ist? Wenn es dem Webseiteninteresse dient, sei Browser-Crypto großartig.

          mfg

          tami

          1. Hallo,

            »… my former employer LivingSocial used in-browser crypto to encrypt credit card numbers in-browser with their payment processor’s public key«
            »In this approach, there’s an implicit trust relationship between the user and the site they’re accessing. What we see happening here is cryptography being used to protect the web site’s interests, not the user’s. For this purpose, in-browser crypto is great!«

            Das lese ich so, dass kryptografische Übertragung von Textnachrichten eigentlich prima möglich ist?

            Das lese ich anders. Wichtig ist hier »protect the web site’s interests, not the user’s«. Das Übertragen von verschlüsselten Textnachrichten zwischen Usern wäre eine »user’s interest«.

            Was der Text als Beispiel bringt, hat damit wenig zu tun: Kreditkartendaten werden clientseitig mit einem Public-Key des Payment-Providers verschlüsselt. Das bieten verschiedene Payment-Provider an und das haben wir auch schon einmal für Kunden implementiert.

            Es gibt nur einen Grund, warum man das tut: Datenschutzgesetze. Wenn man Zahlungsdaten auf den eigenen Servern speichert oder sie auch nur kurzzeitig im Speicher hält, muss man gewissen Sicherheits- und Datenschutzrichtlinien genügen. Das ist ein teurer Zertifizierungsprozess, den man sich nicht unterziehen will, wenn man die Daten nicht im Klartext braucht, sondern sie direkt synchron an einen externen Payment-Provider weitergibt.

            Wichtig ist hier: Es bietet für die User wenig zusätzliche Sicherheit. Es besteht immer das Problem, Daten direkt beim Client abzugreifen, z.B. durch XSS. Clientseitige Verschlüsselung ändert daran nichts. (Daher ist die »large laundry list« nötig, um das möglichst zu verhindern.) Die JavaScript-Verschlüsselung soll hier nur dem Anbieter das Leben vereinfachen.

            Mathias

            1. Kreditkartendaten werden clientseitig mit einem Public-Key des Payment-Providers verschlüsselt. Das bieten verschiedene Payment-Provider an und das haben wir auch schon einmal für Kunden implementiert.

              Als Hintergrundinfo: Payment-Provider bieten m.W. grob drei Möglichkeiten an.

              • Link bzw. Submit-Button, der zum Payment-Provider weiterleitet und nach erfolgter Zahlung wieder zurück leitet mit einer Transaktions-ID o.ä. als Query-Parameter
              • Einbindung der Seite des Providers mit einem IFRAME
              • Zahlungsdaten werden per JavaScript clientseitig verschlüsselt und erst einmal zum Server des Website-Betreibers geschickt, von dort aus zum Payment-Provider

              Soweit ich weiß, ist das erste Verfahren das sicherste und das letzte das problematischste. Es ist beim ersten natürlich möglich, den Nutzer per XSS auf eine gefälschte Seite https://paypaal.com zu leiten, aber dies fällt schneller auf.

              Die beiden letzten Möglichkeiten werden aus Gründen des Komforts und der nahtlosen Einbettung genutzt, weniger aus Sicherheitsgründen.

              Mathias

            2. hi molily,

              Hallo,

              »… my former employer LivingSocial used in-browser crypto to encrypt credit card numbers in-browser with their payment processor’s public key«
              »In this approach, there’s an implicit trust relationship between the user and the site they’re accessing. What we see happening here is cryptography being used to protect the web site’s interests, not the user’s. For this purpose, in-browser crypto is great!«

              Das lese ich so, dass kryptografische Übertragung von Textnachrichten eigentlich prima möglich ist?

              Das lese ich anders. Wichtig ist hier »protect the web site’s interests, not the user’s«. Das Übertragen von verschlüsselten Textnachrichten zwischen Usern wäre eine »user’s interest«.

              Was der Text als Beispiel bringt, hat damit wenig zu tun: Kreditkartendaten werden clientseitig mit einem Public-Key des Payment-Providers verschlüsselt. Das bieten verschiedene Payment-Provider an und das haben wir auch schon einmal für Kunden implementiert.

              Meine Frage ist im Grunde auch nicht allgemeiner Natur, ob irgendwas sicher "ist", sondern zielt eher danach, ob sich hier user und "web-sites" interest in Einklang bringen lassen, technisch. Also wenn es auch im Sinne des Anbieters ist, weil er zB. verschlüsselte Kommunikation ermöglichen will! Als Dienstleistung. Die Frage ist dann ja - für mich - ob und wenn ja wie das technisch umsetzbar ist (_wenn_ "man" das _will_!).

              Den Crockford-Vortrag habe ich mir angesehen, spaßig und lehrreich wie immer. Den dort verwiesenen Vortrag von Marc Stielger zu lazy programming habe ich noch nicht ganz geschafft. Da geht es ja wohl eher um allgemeine Prinzipien.

              Frage für mich wäre auch, in einer App, die zwar Javascript (s. Phonegap) benutzen würde, aber _keine_ externen JS-Quellen einbindet, wie das XSS überhaupt möglich wäre. Wenn die Kommunikation mit einem Server "lediglich" im Austausch von JSON-Objekten zB. bestünde. Also kein auszuführender oder ausführbarere JS-Code vom Server geholt wird.

              Eine Verschlüsselung von Dateninhalten (die ja nicht für den Server sondern für einen anderen Client bestimmt wären), muss den Server in dem Sinne ja garnicht interessieren, die kann ja (s. Phongap) vielleicht auch über ein Addon/Extension/Plugin realisiert werden?

              Bliebe dann noch die sichere Kommunikation mit dem Server bezüglich login, damit der Server weiß, wem er welche bereits verschlüsselten Nachrichten ausliefern darf/kann.

              Den verlinkten Artikel verstehe ich immer noch so, dass es möglich wäre, wenn man es wollte, auch wenn es vielleicht eben nicht ganz trivial ist, selbst wenn man es will:

              "For additional examples of the challenges of building a secure client-side JavaScript crypto application, check out Krzysztof Kotowicz’s “Keys to a Kingdom” challenge. It’s a great illustration of the sorts of problems that can arise when buiding web-based encryption applications. "

              mfg

              tami

              1. Hallo,

                Frage für mich wäre auch, in einer App, die zwar Javascript (s. Phonegap) benutzen würde, aber _keine_ externen JS-Quellen einbindet, wie das XSS überhaupt möglich wäre.

                Dazu kenne ich die Interna von PhoneGap zu wenig. Aber du arbeitest immer noch im Browser. Der Browser ist eine Programmierumgebung, die erst einmal Code aus sämtlichen Quellen ausführt. Einschränkungen wie Content Security Policy sind auf PhoneGap meines Wissens nicht anwendbar. Prinzipiell kann also Code von außen hineinkommen, behaupte ich mal. Das kann durch Templates und fehlendes Escaping schnell passieren, wie Crockford auch anmerkt. Auch eine PhoneGap-Anwendung lädt externe Daten, hat Eingaben und Schnittstellen, wenn auch andere als eine öffentliche Website.

                Eine Verschlüsselung von Dateninhalten (die ja nicht für den Server sondern für einen anderen Client bestimmt wären), muss den Server in dem Sinne ja garnicht interessieren, die kann ja (s. Phongap) vielleicht auch über ein Addon/Extension/Plugin realisiert werden?

                Wenn man eine entsprechende Schnittstelle baut, kann die App sogar auf native Crypto-Funktionen zugreifen.

                Mathias

                1. hi molily,

                  Frage für mich wäre auch, in einer App, die zwar Javascript (s. Phonegap) benutzen würde, aber _keine_ externen JS-Quellen einbindet, wie das XSS überhaupt möglich wäre.

                  Dazu kenne ich die Interna von PhoneGap zu wenig. Aber du arbeitest immer noch im Browser. Der Browser ist eine Programmierumgebung, die erst einmal Code aus sämtlichen Quellen ausführt. Einschränkungen wie Content Security Policy sind auf PhoneGap meines Wissens nicht anwendbar. Prinzipiell kann also Code von außen hineinkommen, behaupte ich mal. Das kann durch Templates und fehlendes Escaping schnell passieren, wie Crockford auch anmerkt. Auch eine PhoneGap-Anwendung lädt externe Daten, hat Eingaben und Schnittstellen, wenn auch andere als eine öffentliche Website.

                  Ja, meine Frage bleibt, ob man das sicher ausschalten kann in einer App, zB. in dem man einfach keine externen Quellen einbindet.

                  Eine Verschlüsselung von Dateninhalten (die ja nicht für den Server sondern für einen anderen Client bestimmt wären), muss den Server in dem Sinne ja garnicht interessieren, die kann ja (s. Phongap) vielleicht auch über ein Addon/Extension/Plugin realisiert werden?

                  Wenn man eine entsprechende Schnittstelle baut, kann die App sogar auf native Crypto-Funktionen zugreifen.

                  Und das wäre dann "gut" oder "sehr gut" ;-)??? Trotz Smiley und Formulierung ernst gemeinte Frage dem Sinn nach ...;
                  mfg

                  tami

                  1. Mahlzeit,

                    Ja, meine Frage bleibt, ob man das sicher ausschalten kann in einer App, zB. in dem man einfach keine externen Quellen einbindet.

                    Was willst du denn abschalten? Es wird geladen, was du einbindest und deine App muss die Berechtigungen erbitten, die du benötigst.

                    Externer Code kann nur in die App kommen, wenn du ihn anforderst. Damit sollte klar, sein, wie du das unterbindest.

                    --
                    42
                    1. hi M.,

                      Ja, meine Frage bleibt, ob man das sicher ausschalten kann in einer App, zB. in dem man einfach keine externen Quellen einbindet.

                      Was willst du denn abschalten? Es wird geladen, was du einbindest und deine App muss die Berechtigungen erbitten, die du benötigst.

                      Externer Code kann nur in die App kommen, wenn du ihn anforderst. Damit sollte klar, sein, wie du das unterbindest.

                      Jo. So dachte ich auch.

                      mfg

                      tami

        2. hi molily,

          Dank für die Link-Liste.

          Wo ist denn da die Unsicherheit?

          Grundlagen:
          http://tonyarcieri.com/whats-wrong-with-webcrypto

          s. erste Antwort.

          http://www.matasano.com/articles/javascript-cryptography/

          "What systems programming functionality does Javascript lack? Here's a starting point: a secure random number generator."

          Und:

          "SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
          The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser."

          https://www.youtube.com/watch?v=zKuFu19LgZA

          Crockford zeigt anschaulich das Problem, wenn ein Key nicht wirklich zufällig ist. Er verweist hier auch auf: Marc Stiegler.

          Den Stiegler-Vortrag finde ich grundsätzlich interessant, weil es hier um einen Programmierstil geht, der meinem Verständnis Zuständigkeiten und Sicherheit verknüpft.

          Was ich nicht ganz kapiert habe, das geht aber weg von der eigentlich Kryptografie, ist um 37:30  herum (bzw. dann die Nachfrage bei 38:45) seine Autentifizierungsmethode wo man selbst signierte Zertifikate nutzen kann, wobei im (Sub-)Domain-Namen der „fingerprint of the public-and-private-key-pair, that is being held by the Service/Website" untergebracht ist. Waterken-Sever spielt dabei eine oder die zentrale Rolle. Das habe ich auf die Schnelle nicht verstanden (auch nicht nach einem Besuch von waterken.com bzw. der sourcefourge-seite).

          Generell die Diskussion um Crypto.cat:

          Ist jetzt ein, oder "das" Beispiel für (angeblich) sichere/kryptografierte Kommunikation als Web-App?

          http://www.wired.com/2012/08/wired_opinion_patrick_ball/all/

          "My concerns stem from a sharp debate over software called CryptoCat – a debate spurred largely by an admiring profile at Wired. CryptoCat is a web-based chat application which uses encryption to scramble the contents of a conversation, in theory resisting electronic snooping. The interesting twist is that CryptoCat does the crypto without using the easily-thwarted security built into browsers (called SSL), and without requiring the user to download and install additional software (like Pidgin and OffTheRecord).
          Seems great, right?
          Well, not so great. CryptoCat is one of a whole class of applications that rely on what’s called “host-based security”. The most famous tool in this group is Hushmail, an encrypted e-mail service that takes the same approach.

          Any host-based system that delivers the encryption engine to you each time you log in, and in which your keys reside on the server, you are never secure against the host (there’s new research on this called “host-proof hosting,” but it’s a long way from being ready to use in real applications). That means that if the host attacks you, or they fail to protect themselves, your encrypted data will be available to them.”

          Heißt vereinfacht: SSL ist "shit" und host-based-encryption auch? Marc Stiegler aber nutzt https um mit seinem Server zu kommunizieren in dem Beispiel und im oben verlinkten matasano-Artikel heißt es: "But I can get random numbers over the Internet and use them for my crypto! How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." Ist SSL nun "gut" oder "schlecht"? Es steht dort ja auch: "The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography". ??? Vielleicht steht ich da auch grade auf dem Schlauch.

          https://blog.crypto.cat/2012/08/moving-to-a-browser-app-model/

          "As a project, Cryptocat’s mission is to find the very best, most functional balance between security and accessibility. In this scenario, after considering the advice of the security community, we have decided that the security benefits of moving towards a local browser plugin only model outweigh the accessibility concerns."

          Klare Aussage: Plugin funktioniert!

          Generell die Diskussion um Mega.co.nz:
          https://www.schneier.com/blog/archives/2013/01/the_security_of_6.html

          Wie du jetzt auf Mega.co.nz kommst, kapiere ich nicht ganz. Ich finde:

          a) auf der Seite als Kommentar: "i don't think so they care about security of files , its just to by pass laws as people just upload movie files on it like megaupload ..." - klingt logisch, wenn ich nicht weiß, was da drinne ist, kann ich auch nicht haftbar gemacht werden, "echte" encryption ist also zweitrangig

          b) der erste von den "this"-links auf schneiers seite: http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ - "The biggest problem with Mega's methods is the lack of entropy gathered in the generation of the RSA key pair. An encryption key needs to be difficult to guess, and so typically when one is generated it is created randomly by an algorithm. Computers, though, are notoriously non-random, and so the "random" numbers generated by their random number generation routines need to be supplemented by a factor called entropy. Entropy is "true" randomness, gathered by the computer from various sources—keypresses and mouse movements, or sound from a microphone, or any number of other things. Some modern CPUs even contain "true random number generators," which use random atomic vibrations in the CPU as entropy sources." bezieht sich wieder auf die schon erwähnte Notwendigkeit von echten Zufallszahlen, die u.a. auch im Crockfordvortrag anschaulich demonstriert werden.

          Fazit(?):
          1. man braucht echte Zufallszahlen, zB. über ein Plugin, nicht über Javascript
          2. der Server muss "dumm" bleiben, darf keine Schlüssel speichern
          3. Frage: SSL/TSL - https ist sicher oder nicht?
          4. Als Schlussforlgerung aus dem Stiegler-Vortrag: self-signed certificates sind ein praktikabler weg, weil sonst Zertifikate (zu) teuer sind?

          mfg

          tami

  3. Vielleicht ein dumme Frage aber:

    Der User muss sich jedes Mal einloggen um überhaupt die Möglichkeit zu haben, eine Nachricht zu senden und zu lesen.

    Wo liegen überall die Schwachpunkte wenn ich z.B. einen Hash dieses Passwortes, dass ja beim Login eingegeben wurde, in der Session Speichere und dieses dann als Passwort zum ver- und entschlüsseln verwende?

    Sobald die Session beendet ist, ist das "Passwort" weg und ich müsste es nirgends abspeichern.

    1. Hallo,

      Wo liegen überall die Schwachpunkte wenn ich z.B. einen Hash dieses Passwortes, dass ja beim Login eingegeben wurde, in der Session Speichere und dieses dann als Passwort zum ver- und entschlüsseln verwende?

      Wo liegen denn die Stärken? Mir fallen keine ein.

      Das hoffentlich gesalzene und gehashte Login-Passwort steht üblicherweise in der User-Tabelle. Sonst wäre es dir ja unmöglich, eine Authentifizierung umzusetzen.

      Das als Schlüssel oder nur als Ausgangsbasis für einen Schlüssel zu verwenden, ist schon einmal Quatsch.

      Sobald die Session beendet ist, ist das "Passwort" weg und ich müsste es nirgends abspeichern.

      Das Login-Passwort muss (wenn auch gesalzen und gehasht) abgespeichert werden, sonst gäbe es keinen passwortbasierten Login.

      Daraus einen weiteren Hash zu berechnen, macht diesen Wert nicht brauchbarer im Hinblick auf eine Verwendung für eine symmetrischen Verschlüsselung.

      Du musst damit rechnen, dass ein Angreifer das Login-Passwort herausbekommen kann und auch auf das Verfahren kommt, mit dem du daraus einen Schlüssel berechnest.

      Selbst wenn nicht: Du willst doch eine Kommunikation zwischen zwei Usern verschlüsseln und niemand dazwischen soll mithören können, soweit ich das verstanden habe. Also ist die Frage, wie entschlüsselt der Empfänger die Nachricht, wenn du den Schlüssel weggeworfen hast?

      Wenn du jetzt sagst, du kannst ihn aus dem Passwort des Absenders erschließen, dann sollte hoffentlich klar geworden sein, wie sinnlos diese Verschlüsselung ist.

      Mach dir einmal klar, was du genau vorhast, was für Verschlüsselungstechniken und was für Angriffsszenarien es gibt. Dazu wurden dir schon einige Links gegeben. Du tappst gerade ziemlich im Dunkeln, scheint mir. Nicht böse gemeint.

      Grüße
      Mathias

    2. Wo liegen überall die Schwachpunkte wenn ich z.B. einen Hash dieses Passwortes, dass ja beim Login eingegeben wurde, in der Session Speichere

      Wenn sich ein User mit seinem Passwort ausgewiesen hat, gibt es keinen Grund, das Passwort in der Session zu speichern. Was Du in der Session speicherst, sind Dinge, die später mal gebraucht werden, z.B. user-id, user-name, user-group und evntl. den Zeitpunkt der Anmeldung.

      und dieses dann als Passwort zum ver- und entschlüsseln verwende?

      Nein, nicht mit dem Passwort, zum Entschlüsseln von Nachrichten wird ein Schlüssel benötigt, den jeder, der Lesen will, kennen muss und das kann nicht das Passwort eines Benutzers sein.

      Es gibt ein Buch von Manfred Lipp, da ist das Diffie-Hellmann-Verfahren für den Schlüssel-Tausch beschrieben.

    3. Tach!

      Der User muss sich jedes Mal einloggen um überhaupt die Möglichkeit zu haben, eine Nachricht zu senden und zu lesen.
      Wo liegen überall die Schwachpunkte wenn ich z.B. einen Hash dieses Passwortes, dass ja beim Login eingegeben wurde, in der Session Speichere und dieses dann als Passwort zum ver- und entschlüsseln verwende?

      Mal angenommen, das wäre brauchbar (sicher ist es ja nicht), hast du da ein zeitliches Problem. In einem Fall ist der Sender online und der Empfänger nicht. Wessen Passwort willst du dann als Schlüssel verwenden? Diese Methode würde nur dann funktionieren, wenn der Empfänger ebenfalls online ist, der sein Passwort dann zum Verschlüsseln geben könnte. Wie sonst sollte der Empfänger die Nachricht entschlüsseln. Das Passwort vom Sender steht dazu nicht zur Verfügung.

      Das einzige was du serverseitig machen kannst, ist eine Verschlüsslung mit einem im Code oder der Konfiguration abgelegtem Schlüssel, um damit ein zufälliges Lesen beim Warten des Datenbestand zu verhindern. Das ist aber nicht mehr als ein Verschleiern, dazu reicht im Prinzip auch schon Base64 oder Rot-13.

      dedlfix.

    4. Wo liegen überall die Schwachpunkte ...?

      eine Nachricht zu senden

      Die kann auf dem kompromittierten Server abgefangen werden, wie ich schon schrieb.

      und zu lesen.

      Die kann auf dem kompromittierten Server abgefangen werden, wie ich schon schreib.

      Man man man, wenn der Angreifer völlig bekloppt ist, dann wirft er den Ausgabepuffer an und greift das Ergebnis ab, bevor er es ausliefern läßt. Von ausgeklügelt bis plump, das ist nicht das geringste Problem, wenn er erst mal auf dem Server ist. Ist er nicht auf dem Server, muß die Nachricht auch nicht verschlüsselt sein.

      einen Hash dieses Passwortes, dass ja beim Login eingegeben wurde,

      und damit auf dem kompromittierten Server abgefangen werden kann.

      Auf Paßwortsicherheit kommt es gar nicht erst an, wie ich schon schrieb.

      Beantworte meine Frage, wogegen Du die Nachrichten schützen willst, vernünftig. Beantworte Sie Dir vor allem erst mal selbst, dann sehen wir weiter.

      Sobald die Session beendet ist, ist das "Passwort" weg und ich müsste es nirgends abspeichern.

      Vor dem Angriff verschlüsselte Nachrichten könnte der Angreifer nicht lesen (zumindest bis sich der Absender das nächste mal anmeldet). Das könnte er erst, wenn sie für den Empfänger entschlüsselt werden (wobei der das Paßwort dafür nicht generieren lassen kann). Demnach wäre das Verfahren sinnloser als sicher, die Nachricht gelangt, wenn überhaupt, nur zum Angreifer.

  4. Hi,
    danke erstmals für die vielen Antworten zum Thema :)

    Mir ist klar, dass eine 100% sichere Lösung nicht möglich ist. Sonst hätten wir das ganze NSA-Dilemma ja nicht.

    Ich will die Daten auch nicht vor der NSA schützen sondern einfach den bestmöglichen Schutz ermöglichen. Und ich denke immer noch, dass es (in diesem Fall) besser ist die Daten verschlüsselt in der DB abzulegen, als gar nicht. Auch wenn sie am Weg dort hin und zurück mitgelesen werden könnten.

    Was ist daher, auch wenn jetzt einige sagen werden, dass es sinnlos ist, die beste Lösung um das umzusetzen. Welche PHP Bibliotheken könnt ihr mir empfehlen?

    Und wo ist der "sicherste" Platz für den Schlüssel?

    Danke, MfG Naps

    1. Hello,

      Mir ist klar, dass eine 100% sichere Lösung nicht möglich ist. Sonst hätten wir das ganze NSA-Dilemma ja nicht.

      Ich will die Daten auch nicht vor der NSA schützen sondern einfach den bestmöglichen Schutz ermöglichen. Und ich denke immer noch, dass es (in diesem Fall) besser ist die Daten verschlüsselt in der DB abzulegen, als gar nicht. Auch wenn sie am Weg dort hin und zurück mitgelesen werden könnten.

      Wir sollten das mögliche Modell aber ruhig mal zuende diskutieren.

      Du willst also Daten in der Datanbank verschlüsselt ablegen. Dann wäre erstmal das Datenmodell zu überdenken. Die Datenbank wird sich schwer tun, mit verschlüsselten Schlüsseln die Datenintegrität / referenzielle Integrität zu wahren. Da muss man sich also schon mal etwas ausdenken.

      Ein Teil der Daten darf also vermutlich nicht verschlüsselt sein.
      Das Gleiche gilt vermutlich auch für die Requests. Spätestens außerhalb der VPN-Strecke müssen zumindest die Verwaltungsdaten wieder unverschlüsselt vorliegen.

      Welchen Teil willst Du nun verschlüsseln?

      Und wo ist der "sicherste" Platz für den Schlüssel?

      Im Kopf des jeweiligen Dateneigentümers?

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bikers-lodge.com
      1. Wir sollten das mögliche Modell aber ruhig mal zuende diskutieren.

        Du willst also Daten in der Datanbank verschlüsselt ablegen. Dann wäre erstmal das Datenmodell zu überdenken. Die Datenbank wird sich schwer tun, mit verschlüsselten Schlüsseln die Datenintegrität / referenzielle Integrität zu wahren. Da muss man sich also schon mal etwas ausdenken.

        Ein Teil der Daten darf also vermutlich nicht verschlüsselt sein.
        Das Gleiche gilt vermutlich auch für die Requests. Spätestens außerhalb der VPN-Strecke müssen zumindest die Verwaltungsdaten wieder unverschlüsselt vorliegen.

        Welchen Teil willst Du nun verschlüsseln?

        Den Inhalt der Nachricht. Die Metadaten nicht. Aktuelle wären die Nachrichten den UserIds zugeordnet.

        Und wo ist der "sicherste" Platz für den Schlüssel?
        Im Kopf des jeweiligen Dateneigentümers?

        Schon klar, die sollen davon aber, wie schon gesagt, nichts mitbekommen.

        MfG Naps

    2. Tach!

      Ich will die Daten auch nicht vor der NSA schützen sondern einfach den bestmöglichen Schutz ermöglichen.

      Bestmöglich bedeutet nach aktuellem Stand der Technik. Das ist aber bei deinen Anforderungen nicht möglich. Du musst deshalb definieren, was deine (restlichen geringen) Sicherheitsanforderungen sind, welche Szenarien nicht möglich sein sollen. Und du musst dir im Klaren sein, was alles an Angriffen möglich ist.

      Und ich denke immer noch, dass es (in diesem Fall) besser ist die Daten verschlüsselt in der DB abzulegen, als gar nicht. Auch wenn sie am Weg dort hin und zurück mitgelesen werden könnten.

      Das hilft nur gegen ein ungewolltes Auslesen des Datenbankinhalts. Der Angreifer darf dabei aber keinen Zugriff auf deinen Code haben. Die Verschlüsslung muss ja auf deinem Server erfolgen, also müssen da auch die Schlüssel liegen.

      Was ist daher, auch wenn jetzt einige sagen werden, dass es sinnlos ist, die beste Lösung um das umzusetzen. Welche PHP Bibliotheken könnt ihr mir empfehlen?

      Darüber musst du dir keine großen Gedanken mehr machen. Wenn die Verschlüsslung nun drei Stufen schwerer zu knacken ist, als mit einem anderen Verfahren, dann knackt man eben deinen Server und kommt so an den Schlüssel.

      Und wo ist der "sicherste" Platz für den Schlüssel?

      Unter den gegebenen Umständen reicht es aus, wenn er außerhalb des DocumentRoots zu liegen kommt. Alle Plätze sind dann einigermaßen gleich (un)sicher.

      dedlfix.

      1. Bestmöglich bedeutet nach aktuellem Stand der Technik. Das ist aber bei deinen Anforderungen nicht möglich. Du musst deshalb definieren, was deine (restlichen geringen) Sicherheitsanforderungen sind, welche Szenarien nicht möglich sein sollen. Und du musst dir im Klaren sein, was alles an Angriffen möglich ist.

        Auch aus versicherungstechnischen gründen wäre die Verschlüsselung "besser". So blöd das klingen mag, aber viele Versicherungen unterscheiden hier nicht.

        Wenn z.B. jemand an die Daten in der DB ran kommt, macht es für die Versicherung einen riesen Unterschied ob die Daten "einfach so" dort abgespeichert werden oder verschlüsselt. Denen zu erklären, dass man die Daten nicht verschlüsselt weil es auch nicht sicherer wäre kann man vergessen.

        MfG Naps

        1. Auch aus versicherungstechnischen gründen wäre die Verschlüsselung "besser".

          Versicherungsgutachter: Wie sind die Angreifer an die Daten gekommen, wenn sie doch verschlüsselt waren?
          Du: Der Schlüssel liegt im Dateisystem.
          Versicherungsgutachter: *facepalm*

          Analog:

          Versicherungsgutachter: Wie konnten die Einbrecher ins Haus kommen, sie haben doch vergitterte Türen und Fenster?
          Du: Der Schlüssel lag unter Fußmatte.
          Versicherungsgutachter: *facepalm*

          Mathias

          1. Analog:

            Versicherungsgutachter: Wie konnten die Einbrecher ins Haus kommen, sie haben doch vergitterte Türen und Fenster?
            Du: Der Schlüssel lag unter Fußmatte.
            Versicherungsgutachter: *facepalm*

            Versicherungsgutachter: Wie konnten die Einbrecher ins Haus kommen, sie haben doch vergitterte Türen und Fenster?
            Du: Die Schlösser waren nicht versperrt
            Versicherungsgutachter: *double facepalm*

            1. Hallo

              Versicherungsgutachter: Wie konnten die Einbrecher ins Haus kommen, sie haben doch vergitterte Türen und Fenster?
              Du: Der Schlüssel lag unter Fußmatte.
              Versicherungsgutachter: *facepalm*

              Versicherungsgutachter: Wie konnten die Einbrecher ins Haus kommen, sie haben doch vergitterte Türen und Fenster?
              Du: Die Schlösser waren nicht versperrt
              Versicherungsgutachter: *double facepalm*

              Du redest die ganze Zeit davon, den Einbrecher zwar reinzulassen (was deine Analogie auch aussagt), dann aber verhindern zu wollen, dass er mit den aufgefundenen Dingen etwas anfangen kann. Es sollte dein Ziel sein, bestmöglich dafür zu sorgen, dass der Einbrecher erst garnicht rein kommt (abschließen und den Schlüssel eben nicht unter den Fußabtreter legen).

              Tschö, Auge

              --
              Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
              Terry Pratchett, "Wachen! Wachen!"
              ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
              Veranstaltungsdatenbank Vdb 0.3
            2. Mahlzeit,

              Du: Die Schlösser waren nicht versperrt

              Das passt aber nicht zu deinen Ausführungen.
              Du lässt zwar die Vorhängeschlösser zuschnappen, verteilst sie aber nur auf dem Fussboden.

              Sinnvoll ist, mit den Vorhängeschlössern die Tür zu sichern, aber das verweigerst du ja konsequent.

              --
              42
    3. Hallo,

      Ich will die Daten auch nicht vor der NSA schützen sondern einfach den bestmöglichen Schutz ermöglichen.

      Sorry, aber deine Antwort zeigt, dass du nichts von dem, was hier geschrieben wurde, dir wirklich zur Gemüte geführt hast.

      Wie ein »bestmöglicher« Schutz aussieht, wurde bereits beschrieben. Alles andere ist Augenwischerei und verbessert die Sicherheit nicht. Hier geht es nicht um Schutz vor der NSA, sondern um *realistische* Angriffsszenarien auf deine Server durch Kriminelle und Hacker.

      Und ich denke immer noch, dass es (in diesem Fall) besser ist die Daten verschlüsselt in der DB abzulegen, als gar nicht.

      Nein, ist es nicht. »No security is better than false security« (Douglas Crockford, Vortrag wurde hier verlinkt, siehe auch die Slides).

      Auch wenn sie am Weg dort hin und zurück mitgelesen werden könnten.

      Eben. Wenn ich an deine Daten will, dann attackiere ich nicht deine Datenbank, sondern deinen Application-Server. Der ist ohnehin viel einfacher anzugreifen und einfacher zu knacken. Irgendein PHP-Script wird mir die Türen weit öffnen, während der Datenbank-Daemon meist nicht öffentlich erreichbar ist und seltener remote-exploitable ist. Wenn ich mich auf dem App-Server eingenistet habe, dann ist sämtliche Verschlüsselung in der Datenbank hinfällig.

      Was ist daher, auch wenn jetzt einige sagen werden, dass es sinnlos ist, die beste Lösung um das umzusetzen.

      Ernst und freundliche gemeinter Rat: Lass es bleiben.

      Wenn du deine Sicherheit verbessern willst, dann lass sich von einer Sicherheitsfirma beraten. Dann lass das Verschlüsselungskonzept von einer Firma entwickeln, die auf solche Lösungen spezialisiert ist. Dann lass deinen Code von einer externen Firma auditieren. Lass deine Server gezielt von einer Sicherheitsfirma angreifen (Penetration Test). Und so weiter.

      *So* verbesserst du Sicherheit und Datenschutz für deine User. Nicht indem du fragwürdige Verschlüsselung mit Keys implementierst, die auf deinem Rechner liegen.

      Welche PHP Bibliotheken könnt ihr mir empfehlen?

      *kopfschüttel*

      Grüße,
      Mathias

      1. Sorry, aber deine Antwort zeigt, dass du nichts von dem, was hier geschrieben wurde, dir wirklich zur Gemüte geführt hast.

        Doch, sicher habe ich das.

        Und ich denke immer noch, dass es (in diesem Fall) besser ist die Daten verschlüsselt in der DB abzulegen, als gar nicht.

        Nein, ist es nicht. »No security is better than false security« (Douglas Crockford, Vortrag wurde hier verlinkt, siehe auch die Slides).

        Auch wenn sie am Weg dort hin und zurück mitgelesen werden könnten.

        Eben. Wenn ich an deine Daten will, dann attackiere ich nicht deine Datenbank, sondern deinen Application-Server. Der ist ohnehin viel einfacher anzugreifen und einfacher zu knacken. Irgendein PHP-Script wird mir die Türen weit öffnen, während der Datenbank-Daemon meist nicht öffentlich erreichbar ist und seltener remote-exploitable ist. Wenn ich mich auf dem App-Server eingenistet habe, dann ist sämtliche Verschlüsselung in der Datenbank hinfällig.

        D.h. du speicherst Passwörter auch ungehasht in deiner DB weil man ja sowieso einfach nur den Application Server angreifen muss? :S

        Wenn du deine Sicherheit verbessern willst, dann lass sich von einer Sicherheitsfirma beraten. Dann lass das Verschlüsselungskonzept von einer Firma entwickeln, die auf solche Lösungen spezialisiert ist. Dann lass deinen Code von einer externen Firma auditieren. Lass deine Server gezielt von einer Sicherheitsfirma angreifen (Penetration Test). Und so weiter.

        Penetration Tests werden regelmäßig durch eine externe Firma durchgeführt.

        Es ist doch schon oft genug vorgekommen,dass "nur" die Datenbank angegriffen wurde oder? Hört man fast wöchentlich, dass von einer der größeren Websites Datensätze aufgetaucht sind. D.h. da wäre wahrscheinlich sogar eine 0815 Verschlüsselung besser als gar keine oder?

        Auf was ich hinaus möchte ist, dass ein "bisschen" mehr Sicherheit immer noch besser ist als gar keine. Meiner Meinung nach, natürlich.

        MfG Naps

        1. Hallo

          Eben. Wenn ich an deine Daten will, dann attackiere ich nicht deine Datenbank, sondern deinen Application-Server. Der ist ohnehin viel einfacher anzugreifen und einfacher zu knacken. Irgendein PHP-Script wird mir die Türen weit öffnen, während der Datenbank-Daemon meist nicht öffentlich erreichbar ist und seltener remote-exploitable ist. Wenn ich mich auf dem App-Server eingenistet habe, dann ist sämtliche Verschlüsselung in der Datenbank hinfällig.

          D.h. du speicherst Passwörter auch ungehasht in deiner DB weil man ja sowieso einfach nur den Application Server angreifen muss? :S

          Hash != Verschlüsselung

          Ein gehashtes Passwort kann – einen zum Zeitpunkt des Angriffs sicheren Algorithmus vorausgesetzt – nicht entschlüsselt werden. Verschlüsselte inhalte sollen demgegenüber wieder entschlüsselt werden können.

          Es ist doch schon oft genug vorgekommen,dass "nur" die Datenbank angegriffen wurde oder? Hört man fast wöchentlich, dass von einer der größeren Websites Datensätze aufgetaucht sind.

          Steht, wenn man das hört oder liest, auch dabei, ob in diesen Fällen die Datenbank oder der Webserver angegriffen wurde? Im Normalfall steht es nicht dabei, womit *das* kein Argument für oder gegen die Verschlüsselung auf DB-Ebene ist.

          Tschö, Auge

          --
          Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
          Terry Pratchett, "Wachen! Wachen!"
          ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
          Veranstaltungsdatenbank Vdb 0.3
          1. hi Auge,

            Hallo

            Eben. Wenn ich an deine Daten will, dann attackiere ich nicht deine Datenbank, sondern deinen Application-Server. Der ist ohnehin viel einfacher anzugreifen und einfacher zu knacken. Irgendein PHP-Script wird mir die Türen weit öffnen, während der Datenbank-Daemon meist nicht öffentlich erreichbar ist und seltener remote-exploitable ist. Wenn ich mich auf dem App-Server eingenistet habe, dann ist sämtliche Verschlüsselung in der Datenbank hinfällig.

            D.h. du speicherst Passwörter auch ungehasht in deiner DB weil man ja sowieso einfach nur den Application Server angreifen muss? :S

            Hash != Verschlüsselung

            Ein gehashtes Passwort kann – einen zum Zeitpunkt des Angriffs sicheren Algorithmus vorausgesetzt – nicht entschlüsselt werden. Verschlüsselte inhalte sollen demgegenüber wieder entschlüsselt werden können.

            Es ist doch schon oft genug vorgekommen,dass "nur" die Datenbank angegriffen wurde oder? Hört man fast wöchentlich, dass von einer der größeren Websites Datensätze aufgetaucht sind.

            Steht, wenn man das hört oder liest, auch dabei, ob in diesen Fällen die Datenbank oder der Webserver angegriffen wurde? Im Normalfall steht es nicht dabei, womit *das* kein Argument für oder gegen die Verschlüsselung auf DB-Ebene ist.

            "Die bequemsten Angriffe erfolgen aber gemäß des minimalen Aufwands meist direkt auf den privaten Schlüssel, wenn er nicht sicher genug gespeichert ist, oder eben auf dessen Absicherung, beispielsweise durch einen einfachen Key-Logger."

            http://www.all-about-security.de/kolumnen/database-protection-integralis/artikel/12406-datenbank-verschluesselung/

            "Fazit

            In diesem Rahmen können nur sehr wenige Hinweise zur Datenbank-Verschlüsselung gegeben werden. Datenbank-Verschlüsselung bedarf der gründlichen Konzipierung, Planung und der sorgfältigen Durchführung. Das Key-Management ist Kern-Bestandteil der Datenbank-Verschlüsselung. Sorgfalt ist bei jeder Verschlüsselung zu empfehlen, sowohl hinsichtlich der Prozesse als auch ganz einfach beim Aufräumen von unverschlüsselten Datenkopien und -resten.

            Datenbanken, für welche die Datenbanken-Verschlüsselung eingesetzt werden soll, sind mit geeigneten Maßnahmen abzusichern. Es ist ein fachlicher Fehler, einzelne Sicherheitsmaßnahmen isoliert einzusetzen oder gar als Begründung zu verwenden, um auf weitere Maßnahmen zu verzichten. Insbesondere ist dafür zu sorgen, dass die verschlüsselten Datenbanken laufend aktualisiert werden, da immer noch Verbesserungen am Einsatz der Datenbank-Verschlüsselung entwickelt werden."

            mfg

            tami

            1. hi tami,

              https://www.google.de/?q=datenbank+verschl�sseln#q=datenbank+verschlüsseln

              zB. der erste Eintrag gleich, ähnelt irgendwie der "Diskussion" hier ...;

              mfg

              tami

          2. Hallo

            Eben. Wenn ich an deine Daten will, dann attackiere ich nicht deine Datenbank, sondern deinen Application-Server. Der ist ohnehin viel einfacher anzugreifen und einfacher zu knacken. Irgendein PHP-Script wird mir die Türen weit öffnen, während der Datenbank-Daemon meist nicht öffentlich erreichbar ist und seltener remote-exploitable ist. Wenn ich mich auf dem App-Server eingenistet habe, dann ist sämtliche Verschlüsselung in der Datenbank hinfällig.

            D.h. du speicherst Passwörter auch ungehasht in deiner DB weil man ja sowieso einfach nur den Application Server angreifen muss? :S

            Hash != Verschlüsselung

            Das ist mir klar. Im System ist man dann aber trotzdem bereits, und man braucht kein Passwort mehr.

            Steht, wenn man das hört oder liest, auch dabei, ob in diesen Fällen die Datenbank oder der Webserver angegriffen wurde? Im Normalfall steht es nicht dabei, womit *das* kein Argument für oder gegen die Verschlüsselung auf DB-Ebene ist.

            Nein steht nicht dabei. Aber wie im Fall von Adobe, waren dann die Datensätze auf zig Websites zum Download verfügbar. Da macht es auch keinen Unterschied mehr, wie die Daten gestohlen worden sind.

            Und nochmal, mir ist klar, dass ein Hash keine Verschlüsselung ist.

            MfG Naps

            1. Hallo

              … Im System ist man dann aber trotzdem bereits, und man braucht kein Passwort mehr.

              Steht, wenn man das hört oder liest, auch dabei, ob in diesen Fällen die Datenbank oder der Webserver angegriffen wurde? Im Normalfall steht es nicht dabei, womit *das* kein Argument für oder gegen die Verschlüsselung auf DB-Ebene ist.

              Nein steht nicht dabei. Aber wie im Fall von Adobe, waren dann die Datensätze auf zig Websites zum Download verfügbar. Da macht es auch keinen Unterschied mehr, wie die Daten gestohlen worden sind.

              Ah, Zaumzeug am Pferdearsch. Wenn die Daten in der freien Wildbahn sind, ist es selbstverständlich zu spät. Deine (oder wessen auch immer) Aufgabe sollte es aber sein, es garnicht erst dazu kommen zu lassen. Das heißt zuvörderst: Verhindere den Einbruch.

              Tschö, Auge

              --
              Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
              Terry Pratchett, "Wachen! Wachen!"
              ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
              Veranstaltungsdatenbank Vdb 0.3
        2. Es ist doch schon oft genug vorgekommen,dass "nur" die Datenbank angegriffen wurde oder?

          Wie gesagt: Datenbanken stehen i.d.R. hinter den Application-Servern in geschützten, internen Netzwerken. Sie direkt anzugreifen ist tausendmal schwieriger als einen Fehler in der öffentlich zugänglichen Webanwendung zu finden.

          Hört man fast wöchentlich, dass von einer der größeren Websites Datensätze aufgetaucht sind.

          Höchstwahrscheinlich nicht weil die Datenbank als solche angegriffen wurde. Da hat jemand einen leicht erreichbaren Server geknackt, der autorisierten Zugriff auf die Datenbank hat. Ein Server, auf dem du Zugangsdaten und Schlüssel für die Datenbank speichern willst.

          Auf was ich hinaus möchte ist, dass ein "bisschen" mehr Sicherheit immer noch besser ist als gar keine.

          An der richtigen Stelle ist wirksame Sicherheit ein Gewinn. An der falschen Stelle ist unwirksame Sicherheit Zeitverschwendung und lenkt von anderen Problemen ab.

          Natürlich kann man sich irgendwelche unwahrscheinlichen Angriffsfälle konstruieren und »Sicherheitsmaßnahmen« dagegen ergreifen. Das gibt einem ein gutes Gefühl, hat aber keinen signifikanten Einfluss auf die Sicherheit.

          Noch einmal Crockford:

          »… related to that is the idea that you shouldn’t be trying to do things that are not going to be effective. Sometimes there’s the idea, well, we can’t stop them but we sure as heck can slow them down. We’ll put some speed bumps in the information super highway and that’ll keep us safe for a little while. That turns out not to work at all. If what you’re doing is not effective then it’s ineffective, and you’re wasting your time. In putting together these speed bumps, you’re using resources that could have been used to do something that was more effective. Don’t prohibit what you can’t prevent. The corollary is that the bad guys will exploit whatever you cannot prevent.

          False security is worse than no security. If you know that you have no security then at least you’ll be smart about risk taking. If you think you are secure and you’re not, you’re going to make really bad judgments. Also, it turns out that false security has a cost, and by pursuing false security you’re not pursuing better forms of security.«

          http://www.youtube.com/watch?v=zKuFu19LgZA%23t=27m35s
          http://transcriptvids.com/v2/zKuFu19LgZA.html

          Mathias

          1. hi molily,

            An der richtigen Stelle ist wirksame Sicherheit ein Gewinn. An der falschen Stelle ist unwirksame Sicherheit Zeitverschwendung und lenkt von anderen Problemen ab.

            Schade, dass keiner mehr hierzu was zu sagen hat. App-Programmierung ist vermutlich erst im Kommen ... ;-)

            mfg

            tami