Verschlüsselung - wo Passwort speichern ?

[evilh]

Hi,

ich entwerfe gerade eine Anwendung (PhP/MySQL), die sensible Daten speichert.
Zur zusätzlihen Absicherung sind die Daten mit Blowfish verschlüsselt in der Datenbank gespeichert.

Die Daten können also nur rekonstruiert werden, wenn Zugang zu Datenbank und zum Filesystem besteht. (wo der Blowfish Key gespeichert ist)
Mein Problem ist nun, dass wenn ein Angreifer Zugang zum Filesystem hat, hat er ja ebenfalls die Zugangsdaten zur Datenbank, da diese ja Plain gespeichert sind, damit die Scripte darauf zugreifen können.

Habt Ihr eine Idee wie man die DB Anbindung auslagern könnte, dass ein Angreifer der kein Root ist, keinen Zugriff darauf hat, die Scripte aber gleichzeitig darauf zugreifen können ?

[jan10001]

Ganricht würde ich sagen, wenn er auf dem Server als Root rumgeistert ist es eh zu spät. Er hat ausreichend Möglichkeiten zur Verfügung um an die gewünschten Daten zu kommen.

[evilh]

ich meinte ja, solange er KEIN root ist.
Nehmen wir an, er kommt durch irgendwelche Umstände an das FTP Passwort des Web Users...

[Joe User]

Du kannst es nur erschweren, indem die Zugangsdaten ausserhalb des Userdirs abgelegt werden und von dort dann includen. Oder direkt in der php.ini hinterlegen. Problem ist halt, dass mindestens PHP auf die Zugangsdaten zugreifen können muss und der Angreifer nur ein Script mit vardump() oder phpinfo() anlegen braucht und somit an die Zugangsdaten kommt. Da man vardump() nicht unbedingt verbieten möchte (debugging), bleibt das Henne-Ei Problem...

[jan10001]

Wozu werden die Daten benötigt oder anderes müssen die User unbedingt darauf zugreifen?

[evilh]

Es geht im speziellen um "tokens", über die die PHP Anwendung im Namen des Users bei einem Auktionshaus handeln kann.
Sollten also diese Tokens oder die Userpasswörter nach außen dringen, könnte ein Angreifer extreme Schäden anrichten, an die ich gar nicht denken möchte...

Aus diesem Grund möchte ich alle Möglichkeiten ausschöpfen, das Ganze so sicher als möglich zu gestalten.

Die Tokens und Userpasswörter sind also verschlüsselt in der Datenbank gespeichert. Zum Entschlüsseln benötigt es einen Key, der ausserhalb des public_html liegt, auf den die Scripte jedoch zugreifen können.

Dieser Schutz funktioniert wunderbar, wenn z.B. die Datenbank durch SQL Injections ausgespäht werden würde, da dann der Blowfish Key fehlt.

Wenn aber wie erwähnt z.B. das FTP Passwort abhanden kommen würde, wären alle Daten zugänglich...
Hmmm, wie Joe User schon sagte scheint es wirklich ein Henne, Ei Problem zu sein...

[freddy36]

Unabhängig davon wäre es sowieso sinnvoll auf FTP zu verzichten ;).

[evilh]

@freddy... ja sicher, aber programmiere mal über die Shell...Da kommt freude auf ;-)
Und bei einem Projekt dieser Grösse sind ständige Änderungen/Erweiterungen leider an der Tagesordnung.

[suntzu]

@freddy... ja sicher, aber programmiere mal über die Shell...Da kommt freude auf ;-)
Und bei einem Projekt dieser Grösse sind ständige Änderungen/Erweiterungen leider an der Tagesordnung.

SSH/SFTP?!

Und entwickelt man nicht eh lokal/auf einem dedizierten Entwicklungs-Server?

[jan10001]

Ich würde in dem Fall hier 2 Server verwenden.
Server1 für DB und verarbeitende Anwendung die die Tokens (Benutzername, Versteigerungspasswort) verwaltet und bei den Versteigerungen bietet
Server2 für Verwaltung der Kunden und normalen Webzugriff

Auf Server1 sollten nur die nötigsten Dienste laufen, er muß entsprechend prof. konfiguiert werden. Du schränkst so zu sagen alles ein und legst genau fest was reinkommen darf und verarbeitet wird.
- Server2 sendet Server1 nur die Daten zur Versteigerung, Zugriffspaßwort + eine TAN (Die TAN Liste sendest du den Kunden per Post zu.)

Auf Server2 kannst du ganz normal die Kunden dann verwalten, möchte der Kunde an einer Auktion teilnehmen so muß er das mit einem extra Paßwort bestätigen das auch nicht auf Server2 gespeichert ist und zusätzlich eine TAN (wie beim Online Banking) übergeben.

Sollte Server2 gehackt werden, könnte der Angreifer nur eine Man-in-the-Middle Attacke durchführen um Schaden anzurichten. (Er kommt nur so an Passwort und die gerade gültige TAN.)


Vorteil des Ganzen Server1 ist max. abgesichert und die sensiblen Daten sind nur dort gelagert.

[evilh]

Die Idee mit den zwei Servern ist gar nicht schlecht...
Ich frage mich nur, ob man damit nicht das selbe Problem wieder hat.

Nehmen wir an, auf dem geschützten Server läuft ausschliesslich eine MySQL Datenbank, in der die Tokens gespeichert sind.
Wie spiele ich dort nun neue Tokens von z.B. neuen Usern ein ? Das kann ich ja nur machen, indem ich auf dem "öffentlichen" Server einen Zugang zur Datenbank des geschützen Servers speichere. Und bei einem Angriff auf den öffentlichen Server sind diese Daten dann eben auch verwundbar.

Anders wäre es, wenn der geschützte Server selbst per Polling Daten aus der Datenbank des öffentlichen Servers holt und diese verarbeitet. (Und der geschützte Server gar keine Verbindungen von aussen ausser SSH akzeptiert)
Damit könnte ein Zugriff nur von Seiten des geschützen Servers erfolgen, was perfekt wäre. Allerdings möchte ich aus Performancegründen ungern mehrmals pro Sekunde pollen...Und weniger häufiges Pollen führt dann wieder zu Problemen mit nicht aktuellen Daten...

Oder habe ich einen Denkfehler ?

[jan10001]

@matzewe01
Ich denke mal unter Token versteht er Benutzername/Paßwort, die braucht der Server um im Namen des Users zu bieten. z.B. Ebay Benutzername und Passwort

@evilh
Ähm auf MySQL würde ich bei solchen Geschichten verzichten da es um Datensicherheit und um Geld geht. (Stichwort: Transactionen)

[evilh]

was ist gegen MySQL zu sahen ? Neue Versionen bieten ebenfalls Rollback Funktionalitäten. Ich sehe da keine Nachteile zu kommerziellen Datenbanken.