Kontodaten verschlüsseln
- Ersteller Moritz K
- Erstellt am
Ronald Nickel
Legendäres Mitglied
...kommt darauf an, ob die sie nach dem Eintragen noch weiterverwerten willst oder nicht. Du kannst sie mit MD5 (HASH)verschlüsseln und schauen ob die bereits abgelegten Kontodaten mit der ebenfalls verschlüüslten Eingabe des Konden übereinstimmen. So sind die Kontodaten, sollte jemand mal die Datenbank knacken sehr schwer an die Kontodaten. Klar ist auch MD5 knackbar aber es ist mal ein Anfang
Gruß Ronny
Gruß Ronny
TSc
Legendäres Mitglied
Einwegverschlüsselung bei Kontodaten? Welchen Sinn soll das haben?
Kontodaten speicher ich aus zwei Gründen:
1) Weil ich Überweisungen oder Abbuchungen auf dieses Konto vornehmen muss.
2) Weil ich dem User die Neueingabe ersparen will.
Für beides muss ich wieder an den Reincode kommen, sprich es muss eine Zweiwegverschlüsselung her.
Über PHP bietet sich da base64_encode() bzw. base64_decode() an.
Ist knackbar aber besser als gespeicherter Klartext.
Kontodaten speicher ich aus zwei Gründen:
1) Weil ich Überweisungen oder Abbuchungen auf dieses Konto vornehmen muss.
2) Weil ich dem User die Neueingabe ersparen will.
Für beides muss ich wieder an den Reincode kommen, sprich es muss eine Zweiwegverschlüsselung her.
Über PHP bietet sich da base64_encode() bzw. base64_decode() an.
Ist knackbar aber besser als gespeicherter Klartext.
Jürgen Auer
Legendäres Mitglied
Für mich ist das eine Fragestellung an der Grenze der Unsinnigkeit.
Da die Daten weiterverwendet werden sollen, muß die Verschlüsselung reversibel sein. Kommt man an die Daten und gleichzeitig an den Verschlüsselungs-/Entschlüsselungscode, ist die Verschlüsselung geknackt.
Kommt man aber an die Daten, dann ist dies das große Problem - sprich: Es muß dafür gesorgt werden, daß dies nicht passiert - das betrifft die Architektur der gesamten Anwendung.
Die Verschlüsselung von Nutzerdaten in der Datenbank (die die Suchalgorithmen der Datenbank unterläuft) wirkt auf mich immer wie eine Scheinsicherheit, die an den eigentlichen Problemen vorbeigeht.
PS: Es gab mal im Xing (war schon vor zwei oder drei Jahren) eine Firma mit Webanwendungen. Die warben damit, daß sie die Daten verschlüsselt abspeichern würden, so daß nur die Besitzer da rankommen könnten. Sorry - das ist albern - wer in den Code eine Verschlüsselung einbauen kann, kann auch eine Backdoor für die Entschlüsselung einbauen. Umgekehrt gibt es bei mir wiederholt die Situation, daß Kunden irgendein Problem mit ihren tatsächlichen Daten haben. Da ist es entscheidend, daß ich schnell an die Klartextdaten rankomme - nicht, um sie zu mißbrauchen, sondern um das Problem des Kunden lösen zu können. Banales Beispiel: Externer gibt Termin ein, Termin fehlt in einer Monatsansicht, taucht aber woanders auf - Datum 05.2005 statt 05.2008 fehlt natürlich im Mai 2008, ein simpler Vertipper.
Da die Daten weiterverwendet werden sollen, muß die Verschlüsselung reversibel sein. Kommt man an die Daten und gleichzeitig an den Verschlüsselungs-/Entschlüsselungscode, ist die Verschlüsselung geknackt.
Kommt man aber an die Daten, dann ist dies das große Problem - sprich: Es muß dafür gesorgt werden, daß dies nicht passiert - das betrifft die Architektur der gesamten Anwendung.
Die Verschlüsselung von Nutzerdaten in der Datenbank (die die Suchalgorithmen der Datenbank unterläuft) wirkt auf mich immer wie eine Scheinsicherheit, die an den eigentlichen Problemen vorbeigeht.
PS: Es gab mal im Xing (war schon vor zwei oder drei Jahren) eine Firma mit Webanwendungen. Die warben damit, daß sie die Daten verschlüsselt abspeichern würden, so daß nur die Besitzer da rankommen könnten. Sorry - das ist albern - wer in den Code eine Verschlüsselung einbauen kann, kann auch eine Backdoor für die Entschlüsselung einbauen. Umgekehrt gibt es bei mir wiederholt die Situation, daß Kunden irgendein Problem mit ihren tatsächlichen Daten haben. Da ist es entscheidend, daß ich schnell an die Klartextdaten rankomme - nicht, um sie zu mißbrauchen, sondern um das Problem des Kunden lösen zu können. Banales Beispiel: Externer gibt Termin ein, Termin fehlt in einer Monatsansicht, taucht aber woanders auf - Datum 05.2005 statt 05.2008 fehlt natürlich im Mai 2008, ein simpler Vertipper.
TSc
Legendäres Mitglied
Na ja, natürlich sind die Daten niemals vor dem Betreiber sicher, schliesslich kann er nach der Eingabe so ziemlich alles mit ihnen machen was ihm beliebt, selbst wenn er sie danach codiert speichert.
Trotzdem halte ich eine codierte Speicherung bei sensiblen Daten (und hier rede ich nicht von Daten die über Suchfunktionen erreichbar sein sollen, denn dann können sie so sensibel nicht sein) für mehr als eine "Scheinsicherheit".
Denn nur weil ich über SQLinjection an Datenbestände gekommen bin heisst das noch lange nicht das ich auch die Serveradministration gehackt habe um an die Scripte zu kommen in denen der Schlüssel codiert ist.
Es ist eine Sicherheitsmassnahme für einen bestimmten Problemfall, aber ich bin durchaus ein Freund von multiblen Sicherheitsvorkehrungen statt mich darauf zu verlassen das ein Teilaspekt der Sicherheit wie meine Serverstruktur und die Scriptzuverlässigkeit schon alles abfangen.
Trotzdem halte ich eine codierte Speicherung bei sensiblen Daten (und hier rede ich nicht von Daten die über Suchfunktionen erreichbar sein sollen, denn dann können sie so sensibel nicht sein) für mehr als eine "Scheinsicherheit".
Denn nur weil ich über SQLinjection an Datenbestände gekommen bin heisst das noch lange nicht das ich auch die Serveradministration gehackt habe um an die Scripte zu kommen in denen der Schlüssel codiert ist.
Es ist eine Sicherheitsmassnahme für einen bestimmten Problemfall, aber ich bin durchaus ein Freund von multiblen Sicherheitsvorkehrungen statt mich darauf zu verlassen das ein Teilaspekt der Sicherheit wie meine Serverstruktur und die Scriptzuverlässigkeit schon alles abfangen.
Die Verschlüsselung ist wohl ein sehr geringer Teil der wirklichen Sicherheit. Die Verschlüsselung bildet mehr das i-Pünktchen. Im eigentlichen ist es wichtig, dass dem Nutzer viele Wege in die Datenbank zu gelangen erschwert werden. Natürlich ist die Verschlüsselung (und hier sollte eine Zweiwegverschlüsselung verwendet werden, macht ja ansonsten wenig Sinn) wichtig, aber ist die Datenbank erst einmal geknackt, bringt das nicht immer viel.
BTW: MD5 ist zwar gehackt, aber eh nur durch lange Brutforcing knackbar. Das heißt bei einer Kontonummer wird das relativ lange dauern, wobei wenn ich recht überlege, sind ja alle Buchstaben schon einmal gestrichen, das bedeutet es läuft auf 10-Abfragen hinaus. 10xAnzahl der Ziffernx Zeit
Aber eine Einwegverschlüsselung macht in dem Fall eh keinen Sinn.
BTW: MD5 ist zwar gehackt, aber eh nur durch lange Brutforcing knackbar. Das heißt bei einer Kontonummer wird das relativ lange dauern, wobei wenn ich recht überlege, sind ja alle Buchstaben schon einmal gestrichen, das bedeutet es läuft auf 10-Abfragen hinaus. 10xAnzahl der Ziffernx Zeit
Aber eine Einwegverschlüsselung macht in dem Fall eh keinen Sinn.
Michael Bieri
Angesehenes Mitglied
Mag sein dass die Frage etwas dumm ist - aber was kann man bei euch in DE mit einer nakten Kontonummer alles anstellen?
Hier (Schweiz) kann man damit relativ gar nix anfangen - ausser Geld einzahlen..
Hier (Schweiz) kann man damit relativ gar nix anfangen - ausser Geld einzahlen..
Michael Bieri
Angesehenes Mitglied
Das geht bei euch so einfach? Krass
Jürgen Auer
Legendäres Mitglied
QUOTE (Alonso @ Do 22.01.2009, 14:44)aber was kann man bei euch in DE mit einer nakten Kontonummer alles anstellen?
Mir ist da auch nichts bekannt - deshalb ist die Server-Daten - Geschäftskontonummer auch auf meiner Domain drauf.
Und das machen viele Firmen so, daß im Impressum die Bankverbindung steht.
Bei Geschäftsbeziehungen ist das für mich eher eine Selbstverständlichkeit, daß die Bankverbindung, die auf der Rechnung angegeben ist, ebenfalls auf der Domain auftaucht.
Thomas: Eigentlich bin ich auch ein großer Freund von mehrstufigen Strukturen. Aus diesem Grund nutzt bsp. Server-Daten eine Technik der verzögerten Erstellung über Jobs: Der Webserver kann Sql-Befehlssequenzen nur anstoßen, nicht Schritt für Schritt ausführen. Selbst wenn der Webserver komplett gehackt wäre und ein Hacker interaktiven Zugang vom Webserver auf den Datenbankserver hätte, kann er noch nicht einmal Tabellen auslesen - weil er keinerlei Select-Berechtigung hat.
Bloß: Angesichts des damaligen Xing-Erlebnisses sind für mich solche Argumentationen eher fragwürdig - vor allem bei Code, der Sql-Code dynamisch zusammensetzt und mit einer praktisch administrativen Verbindung zum Datenbankserver arbeitet. Und ein transaktionssicherer Code bzw. ein entsprechendes Backend kommt bei mir auch noch weit vor solchen Maßnahmen.
PS: Ich hatte bei mir ein einziges Mal eine unerwünschte Abbuchung - und da ist jemandem ein Zahlendreher unterlaufen. So einfach geht das mit Lastschriften nicht. Ich sehe da auch kein Mißbrauchspotential.
Mir ist da auch nichts bekannt - deshalb ist die Server-Daten - Geschäftskontonummer auch auf meiner Domain drauf.
Und das machen viele Firmen so, daß im Impressum die Bankverbindung steht.
Bei Geschäftsbeziehungen ist das für mich eher eine Selbstverständlichkeit, daß die Bankverbindung, die auf der Rechnung angegeben ist, ebenfalls auf der Domain auftaucht.
Thomas: Eigentlich bin ich auch ein großer Freund von mehrstufigen Strukturen. Aus diesem Grund nutzt bsp. Server-Daten eine Technik der verzögerten Erstellung über Jobs: Der Webserver kann Sql-Befehlssequenzen nur anstoßen, nicht Schritt für Schritt ausführen. Selbst wenn der Webserver komplett gehackt wäre und ein Hacker interaktiven Zugang vom Webserver auf den Datenbankserver hätte, kann er noch nicht einmal Tabellen auslesen - weil er keinerlei Select-Berechtigung hat.
Bloß: Angesichts des damaligen Xing-Erlebnisses sind für mich solche Argumentationen eher fragwürdig - vor allem bei Code, der Sql-Code dynamisch zusammensetzt und mit einer praktisch administrativen Verbindung zum Datenbankserver arbeitet. Und ein transaktionssicherer Code bzw. ein entsprechendes Backend kommt bei mir auch noch weit vor solchen Maßnahmen.
PS: Ich hatte bei mir ein einziges Mal eine unerwünschte Abbuchung - und da ist jemandem ein Zahlendreher unterlaufen. So einfach geht das mit Lastschriften nicht. Ich sehe da auch kein Mißbrauchspotential.
profo
Angesehenes Mitglied
In Deutschland kannst Du zwar abbuchen, aber nur auf Dein Konto. Natürlich gibt es trotzdem Missbrauchspotential; es gab ja in der Presse Fälle, bei denen Anbieter vortäuschten, einen Auftrag zu haben, und dann munter Geld abbuchten...
Ganz kurz zu den Verschlüsselungen. MD5 oder php's Crypt sind nur "Prüfsummen" (korrekt: Hashes); sie machen aus einem beliebig langen Text eine Zahl mit fester Länge. Base64 ist ebenfalls keine Verschlüsselelung: es braucht nämlich keinen Schlüssel. Leute vom Fach können base64 überspitzt gesagt mit bloßem Auge lesen.
Solange der Entschlüsselungs-Schlüssel auf der gleichen Kiste liegt, wie die Daten, würde so etwas nie einen Sicherheitsaudit bestehen. Aber natürlich ist trotzdem etwas dran, dass eine Verschlüsselung es den Angreifern nicht unnötig leicht macht. Für PHP am bestem mal mcrypt ansehen (http://www.php.net/mcrypt). Wichtig dann: überlegen, wie der Schlüssel so gehalten werden kann, dass die Angreifer ihn nicht im gleichen Zug wie die Daten erbeuten können.
Ganz kurz zu den Verschlüsselungen. MD5 oder php's Crypt sind nur "Prüfsummen" (korrekt: Hashes); sie machen aus einem beliebig langen Text eine Zahl mit fester Länge. Base64 ist ebenfalls keine Verschlüsselelung: es braucht nämlich keinen Schlüssel. Leute vom Fach können base64 überspitzt gesagt mit bloßem Auge lesen.
Solange der Entschlüsselungs-Schlüssel auf der gleichen Kiste liegt, wie die Daten, würde so etwas nie einen Sicherheitsaudit bestehen. Aber natürlich ist trotzdem etwas dran, dass eine Verschlüsselung es den Angreifern nicht unnötig leicht macht. Für PHP am bestem mal mcrypt ansehen (http://www.php.net/mcrypt). Wichtig dann: überlegen, wie der Schlüssel so gehalten werden kann, dass die Angreifer ihn nicht im gleichen Zug wie die Daten erbeuten können.
TSc
Legendäres Mitglied
Jürgen, ich kenne deine Sicherheitsansätze bei Server-Daten und würde es dort eine Verschlüsselung der Daten auch als eher unnötig betrachten.
Leider programmiert noch nicht jeder so restriktiv, weswegen ich bei solchen Fragen immer eher weitere Sicherheitsebenen befürworte.
Was die Missbrauchstmöglichkeiten von Kontodaten angeht - es kann auch in DE nichts wirklich schlimmes damit passieren. Wenn jemand von meinem Konto abbucht kann ich diese Buchung jederzeit rückgängi machen.
ABER ich als Serviceprovider möchte einfach nach Möglichkeit nicht der Buhman sein der dafür verantwortlich ist das Kontodaten und persönliche Kontaktmöglichkeit meiner Kunden im Internet verkauft werde weil ich nicht alle Register gezogen habe.
Auch wenn die Kontodaten ungefährlich sind möchte nicht ich der sein der sie unfreiwillig in Umlauf gebracht hat.
Leider programmiert noch nicht jeder so restriktiv, weswegen ich bei solchen Fragen immer eher weitere Sicherheitsebenen befürworte.
Was die Missbrauchstmöglichkeiten von Kontodaten angeht - es kann auch in DE nichts wirklich schlimmes damit passieren. Wenn jemand von meinem Konto abbucht kann ich diese Buchung jederzeit rückgängi machen.
ABER ich als Serviceprovider möchte einfach nach Möglichkeit nicht der Buhman sein der dafür verantwortlich ist das Kontodaten und persönliche Kontaktmöglichkeit meiner Kunden im Internet verkauft werde weil ich nicht alle Register gezogen habe.
Auch wenn die Kontodaten ungefährlich sind möchte nicht ich der sein der sie unfreiwillig in Umlauf gebracht hat.
Ich sehe gar nicht das Problem bei dieser Verschlüsselung.
Wir bauen uns eine Funktion die uns einen Unique-Hash generiert mit lauter Zahlen.
Dann bauen wir uns einen kleinen Algorithmus der natürlich auch reversibel sein muss, aber dieser ist ja nur auf dem Server, heißt, das Script bzw. der Apache oder was auch immer müsste neben der DB ebenfalls gehackt werden.
Dieser Algorithmus versetzt unsere Kontonummer: 12345678 in 13524431498512612756879
Was ein potentieller Angreifer nun mit dieser Kontonummer anfangen will ist fraglich. Ok, ja er könnte raten, aber das ist ja Nonsense, dann kann er sich auch ohne diese Nummer irgendwelche Kontodaten zusammenbasteln die stimmen könnten.
Natürlich ist der hier vorgeschlagene "Algorithmus" wenn man ganz genau hinschaut nicht sooo schwer und im Prinzip entschlüsselbar, aber es war nur ein Beispiel.
Ich liebe die Programmierung von Algorithmen und könnte wetten, dass ich einen programmieren kann, der Kontodaten in reiner MySQL-gespeicherter Form, nutzlos macht.
Grüße, David
Wir bauen uns eine Funktion die uns einen Unique-Hash generiert mit lauter Zahlen.
Dann bauen wir uns einen kleinen Algorithmus der natürlich auch reversibel sein muss, aber dieser ist ja nur auf dem Server, heißt, das Script bzw. der Apache oder was auch immer müsste neben der DB ebenfalls gehackt werden.
Dieser Algorithmus versetzt unsere Kontonummer: 12345678 in 13524431498512612756879
Was ein potentieller Angreifer nun mit dieser Kontonummer anfangen will ist fraglich. Ok, ja er könnte raten, aber das ist ja Nonsense, dann kann er sich auch ohne diese Nummer irgendwelche Kontodaten zusammenbasteln die stimmen könnten.
Natürlich ist der hier vorgeschlagene "Algorithmus" wenn man ganz genau hinschaut nicht sooo schwer und im Prinzip entschlüsselbar, aber es war nur ein Beispiel.
Ich liebe die Programmierung von Algorithmen und könnte wetten, dass ich einen programmieren kann, der Kontodaten in reiner MySQL-gespeicherter Form, nutzlos macht.
Grüße, David