# Kontodaten verschlüsselt abspeichern



## TribunM (24. August 2010)

Hallihallo,

also ein Bekannter möchte für ein Classified Projekt Bankdaten in eine Datenbank speichern, damit die Zahlungsabwicklung unter den Mitgliedern einfacher funktioniert.
Das ganze wird sowieso per SSL verschlüssselt, aber gibt es noch zusätzliche Richtlinien, wie man diese Daten speichern darf, z.B. zusätzliche md5 Verschlüsselung oder etwas Ähnliches?

Ich bin für jeden hiflreichen Tipp dankbar.


----------



## Bratkartoffel (24. August 2010)

Hallo,

<offtopic>
Nichts gegen dich, aber...
Ich weiß nicht, wie oft ich es schon betont habe, aber md5 IST KEINE VERSCHLÜSSELUNG! 
</offtopic>

MD5, SHA1, Whirlpool, CRC32 und diverse andere nennen sich Hashing-Algorithmen und können nicht zweifelsfrei zurückgerechnet werden. Das heißt sie funktionieren nur in eine Richtung.

Somit fallen diese für dich weg. Ich würde dir eher empfehlen, die Daten für die Datenbank mit einem Algorithmus wie AES, Blowfish, Twofish, Serpent oder so zu verschlüsseln, diese bieten bei einem geeigneten Passwort genügend Sicherheit.

Das Problem bei einer solchen Verschlüsselung ist jedoch, dass dem PHP-Script der Schlüssel bekannt sein muss. Daher ist es jetzt relativ gleich, ob du die Daten unverschlüsselt in der Datenbank speicherst oder in deinem PHP-Script eine Variable mit dem Passwort hast.

Ein weiteres Problem der zusätzlichen Verschlüsselung ist die Last, die bei jedem Lesevorgang auftritt. Die Daten müssen ja nicht nur vom Datenbankserver geholt werden, sondern anschließend auch noch entschlüsselt werden. Dieser Aufwand ist zwar abhängig vom Algorithmus, aber je nach Stärke der CPU des Servers sollte man diesen Aufwand auf alle Fälle beachten.

Gruß
BK


----------



## TribunM (24. August 2010)

Oh Schande über mich, natürlich ist md5 keine Verschlüsselung. Aber ich vertue mich auch immer mit If Schleifen 

Also ist md5 hierfür nicht zu gebrauchen? Hm, ich dachte da dieses Verfahren standardmäßig bei Passwörtern verwendet wird, könnte man das an anderer Stelle genau so verwenden.

Das mit der zusätzlichen Rechenzeit lässt sich dann wohl oder übel nicht vermeiden.
Vielleicht noch andere Tipps?


----------



## Bratkartoffel (24. August 2010)

Hallo,

bei Passwörtern ist es möglich, weil:

Du hasht das Passwort des Benutzers, z.B.:
test -> 098f6bcd4621d373cade4e832627b4f6
Den Hash kannst du abspeichern, du musst es ja nicht mehr zurückrechnen. Das Passwort des Users ist vollkommen egal, wichtig ist der Hash.

Wenn der Benutzer sich anmelden will, hasht du seine Eingabe und vergleichst den Hash mit dem aus der Datenbank. Wenn beide Hashes gleich sind, dann ist alles OK, ansonsten hat er ein falsches Passwort eingegeben.

Bei Bankdaten gibt der Benutzer diese ja nur idealerweise einmal ein und müssen dann in Rohform später zur Verfügung stehen.

Gruß
BK


----------



## Sprint (24. August 2010)

Hi,
wie du die Daten verschlüsseln kannst, hat Bratkartoffel ja schon geschrieben. Zur einigermaßen sicheren Ablage des Kennwortes würde ich es nicht in das Script integrieren, sondern per include einfügen. Diese Datei kannst du dann entweder parallel zum Standardverzeichnis (htdocs o.ä.) in einem der anderen Verzeichnisse ablegen, oder falls das nicht geht, in ein htaccess geschütztes Verzeichnis ohne Benutzer oder mit einem tanz-auf-der-tastatur-namen und Kennwort. Damit hat jemand nur darauf Zugriff, wenn er den FTP Zugang hat.


----------



## Bratkartoffel (24. August 2010)

Hallo,

nicht unbedingt. Wenn er PHP-Code einfügen kann, so kann er sich jede Datei auf dem Server runterladen, auf die auch der Webserver Zugriff hat. Neben den Konfigurationsdateien mit den Kennwörtern somit auch den Aufbau der Seite und das Ding mit dem FTP-Server.

Des übrigen laufen viele Webserver in einem chroot (von mir alle), da lässt sich Verzeichnis-mäßig nicht allzu viel machen.

Gruß
BK


----------



## Sven Mintel (24. August 2010)

Moin,

das eine ist ja der Zugriff auf die DB, und das andere der Zugriff auf den Webserver.

Wer das eine hat, muss nicht gezwungenermaßen das andere haben.
Ich würde daher eine Verschlüsselung mit bspw. AES_ENCRYPT()  nicht unbedingt für schlecht halten.

Wenn jemand Zugriff auf den Webserver erlangt, ist das wie erwähnt eh alles Wurscht(es sei denn, du verschlüsselst auch deine beteiligten PHP-Skripte ).

Wenn er aber nur durch ein Sicherheitsleck an Daten aus der DB gelangt(was IMO der wahrscheinlichere Fall ist), dann könnte er damit nichts anfangen...was die Sache sicherer macht als ohne Verschlüsselung.


----------



## TribunM (24. August 2010)

Hm hat wer von euch Erfahrung damit? Sprich welche Verschlüsselung bietet das beste Verhältnis zwischen Sicherheit, Aufwand und Geschwindigkeit? Es gibt ja zig verschiedene. AES_ENCRYPT() soll wohl recht langsam sein?


----------



## Sven Mintel (24. August 2010)

TribunM hat gesagt.:


> Es gibt ja zig verschiedene. AES_ENCRYPT() soll wohl recht langsam sein?


 
Mmmh, der Begriff langsam ist wohl recht frei auslegbar 

Wieviel Kontobewegungen erwartest du denn am Tag 

Hier hat das jemand getestet:
http://forums.mysql.com/read.php?24,38114,38244

...das hat er vor 5 Jahren getan und hat für 100.000 Vorgänge ca. 10 Sekunden benötigt.
(Mittlerweile dürfte die Server-Hardware etwas aufgerüstet worden sein)

AES_DECRYPT war von den 3 getesteten Methoden dabei die schnellste.


----------



## TribunM (24. August 2010)

ah danke für den Link. Ja das teste ich dann einmal. Ich könnte mir auch vorstellen, dass die heutige Serverhardware das ein wenig schneller erledigen kann.


----------



## Killerkarte (24. August 2010)

Hey,
ich schreibe gerade an der Uni an einer Seminararbeit über das Thema Sicherheitskonzepte im eBusiness. Kurz gesagt: SSL (bzw. TLS) übernimmt schon komplett alles was Verschlüsselung etc angeht. Es wird zufällig ein Algorithmus und Schlüssel zwischen Browser und Client ausgewählt. Wo du drauf achten solltest ist natürlich die Speicherung. Schließlich willst du ja nicht die Kontodaten im Klartext speichern ;-) Und achte dadrauf, dass du verschlüsselst und nicht hasht, denn Hashfunktionen sind streng genommen Einwegfunktionen


----------



## Bratkartoffel (24. August 2010)

Hallo,

<klugscheiss>
wenn du eine Seminararbeit schreibst, dann achte bitte auf deine Wortwahl. Der Algorithmus wird nicht zufällig ausgewählt:
Im Handshake sendet der Client (je nach Einstellung) eine Nachricht mit dem Algorithmus die der Server versucht zu entschlüsseln. Wenn der Algorithmus für den Server OK ist, dann wird der Handshake weitergemacht.
Quelle u.a.: http://en.wikipedia.org/wiki/Transport_Layer_Security#Simple_TLS_handshake

Und die stärkste Verschlüsselung hilft nichts, wenn einer der Endpunkte kompromittiert ist.
</klugscheiss>

Ansonsten viel Glück bei der Arbeit, das Thema ist ja sehr weitreichend.

Gruß
BK


----------



## TribunM (24. August 2010)

Ja es geht im Thread auch primär um die verschlüsselte Abspeicherung in der Datenbank und welche Mechanismen dahingehend von Vorteil sind. Das Klartext allgemein zur Speicherung von sensiblen Daten nicht so dolle ist, sollte mittlerweile klar sein .


----------



## Killerkarte (24. August 2010)

Ja da hast du recht. Zufällig ist vielleicht etwas falsch gewählt. ABER ich muss dich auch korrigieren, denn der Server/Client tauschen priorisierte Listen mit unterstützen Algorithmen aus, und der Algo mit gleichhoher Priorität wird dann verwendet.


----------

