Cdkey sicher online speichern und dem Nutzer anzeigen?

[Suxxess]

Mal ein Beispiel, ein Softwareanbieter vertreibt seine Software online.
Er speichert das vom Kunden jeweilige gekaufte Produkt in seiner Datenbank + den dazugehörigen Cdkey.

Wie würdet ihr diesen Cdkey in einer Datenbank möglichst sicher verschlüsseln und speichern?
Hash + Salt bedeutet doch, dass man so einen Code oder Passwort nicht wieder zurückrechnen kann.
Wie würdet ihr das in PHP und Mysql lösen?

Würdet ihr z.B. den Namen und das gehashte Passwort vom jeweiligen Nutzer nehmen, daraus einen persönlichen Schlüssel bauen um das Passwort damit verschlüsseln? Was wäre dort der sicherste Weg? ( Für den Fall, dass die Datenbank mal gehackt werden könnte? )

 

[Janniboy]

Hey,

ich würde da so vorgehen:
- Serverbetriebssystem auf dem neuesten Stand halten
- Webserver (z.B. Apache, nginx, lighttpd etc.) auf dem neuesten Stand halten
- Seit bei PHP 5.5 gibt es eine eigene Passwort-Hashing-Funktion, mit der man Kennwörter verschlüsseln kann. Diese würde ich nutzen
- PHP und MySQL natürlich auch aktuell halten (momentan PHP 5.5 und MySQL 5.6)
- Auf PDO setzen mit Prepared Statement und eben die gängigen Sicherheitsstandards beachten (XSS, CSRF, RFI und LFI, SQL Injection usw.)

Dann muss natürlich auch der Programmierer Ahnung haben und die Logik im Hintergrund der Script ordentlich programmieren. Viele Faktoren spielen da eine Rolle aber so mal als grober Überblick.
Bei den aktuellen Version hat man da auch noch den netten Nebeneffekt, dass dort die Performance auch am besten ist.

Den CD-Key verschlüsseln?
Wenn man den auslesen will, und dem Kunden somit mal zeigen muss im Kundeninterface, würde ich nicht verschlüsseln. Wenn er für andere Zwecke gebraucht wird um etwas zu überprüfen, kann man ihn natürlich verschlüsseln, wenn man will. Kommt auf den Anwendungsfall drauf an.

 

[Visceroid]

Fängt der "Hacker" mit den CD-Keys etwas an? Wenn nicht, warum überhaupt verschlüsseln, nur der Key macht den Besitz der Software ja noch nicht legal?

Auch wenn du in deiner Datenbank den Key verschlüsselst, wie willst du dem Kunden dann jemals wieder sagen welchen Key er hat?

 

[yummycandy]

Ich würde den inhalt des CD-Key Feldes mit AES verschlüsseln. Das Passwort des Feldes bildet das eingegebene PW des Benutzers + einem statischen String. Man kann das ganze auch doppelt machen um noch sicherer zu sein.

 

[Suxxess]

Danke für die Vorschläge, wie gesagt es kommt darauf an, dass man den verschlüsselten CDKey auch wieder zurückrechnen kann um ihn dem Nutzer wieder in Klarsicht anzeigen zu können.

Wenn man die dann in Klarsicht in der Datenbank speichert, ist das dann nicht relativ verantwortungslos?
Daher meine Frage ob man das etwas sicherer lösen kann.

@yummycandy
Danke ein guter Vorschlag

@Visceroid
Wenn es Nutzer gibt die den jeweiligen Key noch nicht auf sich registriert haben, dann wäre das recht problematisch im Fall der Fälle.

 

[Daaron]

Wenn es PHP sein soll, heißt das Zauberwort wohl mcrypt. Da setzt du dann im Zweifel auf MCRYPT_RIJNDAEL_256 (aka. AES256) oder TripleDES.

Wenn du relativ faul bist, könntest du z.B. Contao als Basis einsetzen und für deine Spezialanforderungen ne Extension schreiben. Du hättest dann Zugriff auf die Contao Encryption API, die im Prinzip ne hübsch vereinfachte Kapselung für mcrypt ist.

 

[Freezedevil]

Wenn ein Angreifer Zugriff auf die Datenbank hat, kann er üblicherweise alles tun, was dein Server sonst automatisch erledigt. Eine Verschlüsselung ist also verschwendete Rechenzeit wenn du nicht irgendwie extern was mit einfließen lässt. Dafür kommt im Prinzip nur das Passwort des Nutzers (oder eine andere von ihm generierte Zeichenfolge die nur dafür da ist) in Frage. Damit hast du aber ein Problem wenn dieser sein PW mal vergessen hat, da die verschlüsselten Keys unbrauchbar werden wenn du alles richtig gemacht hast.

Oder hab ich da nen Denkfehler drin?

 

[Daaron]

Oder hab ich da nen Denkfehler drin?

Nö, hast du nicht. Genau das würde passieren, wenn das User-PW verloren geht.

Man muss aber unterscheiden zwischen einem Einbruch in die Datenbank und ins File System. Ein DB-Dump kommt schneller in falsche Hände als eine config.php. Bei dem Dump reicht schon ein schlecht konfiguriertes Autobackup-Tool im CMS, das den Dump in ein von außen per HTTP lesbares Verzeichnis legt.
Daher würde es z.B. funktionieren, einfach auf die Contao-Encryption-API zu vertrauen und keinen separaten Key pro Crypt zu übergeben. Dann wird der System-Key verwendet (der natürlich für alle identisch ist und in ner config.php steht).

Was du natürlich auch machen könntest: eine Art Key Sharing.
Du als Admin, lagerst einen oder mehrere Master-Keys an dezentralen sicheren Orten (CD im Safe, USB-Stick in der Hosentasche, Zettel in der Brieftasche,...). Sollte jetzt ein Kunde seinen Key verschlampen kannst du mit einem Master Key immer noch ran.
Wird nur abartig schwer, so etwas zu implementieren.

 

[Freezedevil]

Ok, dann habe ich falsch eingeschätzt, wie "leicht" man an die Datenbankinhalte kommt ohne Zugriff auf den Server/das FS zu haben.
Dann ist man natürlich mit einer Verschlüsselung schon deutlich besser dran als ohne.

 

[Daaron]

Na ja, das muss man alles etwas relativieren. Angenommen, du kommst als Angreifer an das Backup einer Webseite, so enthält dieses Backup natürlich den Datenbank-Dump sowie den Sourcecode -> den Key.
Is halt alles irgendwo Mist, aber man kommt eben tatsächlich leichter an n DB-Dump als an die Sources.