Login-Server programmieren, Fragen zur Datenbankanbindung etc.

[Magogan]

Hi,

ich möchte einen Linux-Server mieten und dadrauf mehrere Programme laufen lassen. Unter anderem einen selbst geschriebenen Login-Server (in C++, mit SSL). Allerdings habe ich fast keine praktische Erfahrung damit. Wie zum Beispiel läuft das genau mit den SSL-Zertifikaten? Muss ich eines kaufen und gilt das dann für Login-Server und Webserver, wenn beide auf dem gleichen Server (gleiche IP, verschiedene Domains) laufen?

Es soll auch ein Datenbankserver (MySQL?) darauf laufen. Wie kann ich das Backup der Daten (es geht hier um sensible und wichtige Daten) automatisieren bzw. am besten umsetzen? Und wie kann ich sicherstellen, dass jemand, der über Paypal bezahlt hat, sein Produkt (ein Key, der dem Account zugewiesen wird) auch erhält, selbst bei einem Serverausfall oder -neustart? Vermutlich durch Redundanz, aber wie soll das funktionieren? Zwei Datenbankserver? Und wie hält man die am besten synchron? Und wie viele Ressourcen brauche ich? Reicht ein V-Server? Oder ein Dedicated Server?

Mir wäre es tatsächlich am liebsten, wenn sich jemand mit Erfahrung darum kümmert, aber meine finanziellen Mittel sind leider begrenzt. Also muss ich die Probleme selbst lösen und wäre für Hilfen und Tipps dankbar.

Grüße,
Magogan

PS: Ich hoffe, ich bin im richtigen Forum. Wenn nicht, dann bitte verschieben.

 

[moshimoshi]

(es geht hier um sensible und wichtige Daten)

Dann sollte das jemand machen der Kenntnisse hat.

 

[Magogan]

Dann sollte das jemand machen der Kenntnisse hat.

Das weiß ich auch. Aber wo soll ich jemanden finden, der sich damit auskennt? Und wie soll ich den bezahlen? xD

Ich bin ja jetzt nicht ganz blöd und würde bestimmt auch einiges selbst hinbekommen, nur ganz sicher bin ich mir nicht, wie das am besten umgesetzt werden sollte. Erfahrung mit SQL habe ich zumindest ein bisschen, aber da gab es doch noch Constraints für Datenbanken/Tabellen, ich weiß zum Beispiel nicht, ob ich die brauche.

Edit: https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication

Ich hab zum Beispiel dieses Tutorial gefunden. Aber was passiert, wenn ein Server offline ist, während der andere noch läuft und da was verändert wird?

 

[honky-tonk]

wenn jemand über paypal zahlen soll dann ist das garantiert eine art shop wo früher oder später geld rum kommt. so online shop systeme gibt es fertig zu kaufen.

lass es lieber professionell bzw. aus dem fertig baukasten machen...sonst gibt's nachher nur ärger!

vll beschreibst du auch nochmal genauer was du vor hast... bzw wo die daten herkommen etc.

 

[Magogan]

Ich entwickle gerade ein Spiel und möchte dafür einen Login-Server erstellen, sodass man sich im Spiel einloggen kann, nachdem man sich auf der Webseite registriert hat und einen Code aktiviert hat, den man wiederum bekommen soll, wenn man das Spiel über Paypal kauft.

Der Webserver soll also mit dem Datenbankserver kommunizieren, der Login-Server aber auch. Ich dachte mir, dass es am sinnvollsten wäre, das irgendwie redundant zu machen, also mehrere Datenbankserver, die redundant sind, und jeweils einer läuft auf dem Webserver und auf dem Login-Server.

Aber wie stelle ich sicher, dass die Spieler ihren Code auch bekommen, wenn der Webserver mal ausfallen sollte?

 

[Bisumaruku]

SSL Zertifikate gibt es in verschiedenen Ausführungen. Diese sind grundsätzlich nicht an die IP des Server gebunden, sondern an den Domainalias. Heißt du brauchst pro (Sub-)Domain ein Zertifikat oder ein Wildcard Zertifikat. Wildcard ist natürlich teurer.
Bsp.: 1 Zertifikat für shop.domain.de & 1 Zertifikat für www.domain.de oder 1 Zertifikat für *.domain.de

Automatische Backups der DB kannste via CronJob erledigen.
Bsp.: stündlich einen Dump erstellen und den via SFTP auf einen anderen Server verschieben.

Um die Einkäufe abzusichern kann man entweder mit Redundanz arbeiten oder halt z.B. die Dienste die laufen müssen überwachen. Nagios wäre da ein Stichwort.
Da du mit Paypal arbeiten willst: Gibt von Paypal einen Service wo die Bezahlvorgänge in einer XML hinterlegt werden die du dann regelmäßig überprüfen könntest.

 

[Magogan]

Kann ich bei Paypal auch eine eigene ID des Nutzers angeben, der das gerade kauft (also die ID aus der Datenbank)?

 

[Mojo1987]

Wie wärs wenn du dir die Paypal API einfach mal anschaust? Ist ja nicht so, das es die erst seit gestern gibt...

 

[Magogan]

Ok, ich schau nachher mal.

Anderes Problem: Wie kann ich in C++ und PHP einen Passwort-Hash erstellen? Also an sich kein Problem, nur muss der identisch sein, da das Passwort vom Webserver (PHP) und vom Login-Server überprüft werden soll. Und das geht nicht, wenn für das Passwort abc123 in PHP uegjhjjug57jh4eb herauskommt und in C++ 5ujgrzjgwzoknh562jn0.

Edit: Sollte ich zum Hashen ein C++-Programm schreiben und dieses aus PHP heraus ausführen? Das garantiert jedenfalls immer gleiche Hashes.

 

[westef]

Wenn du einen bekannten Algorithmus verwendest, dann kommt in C++ und in PHP dasselbe raus. Oder denkst du, dass PHP einen SHA-512 Hash anders berechnet als C++?

Ansonsten frage ich mich, wie du ein Game entwickeln willst, wenn du schon bei diesen (vergleichsweise einfachen) Tätigkeiten soviel nachfrägst. Ist jetzt nicht böse gemeint, aber ich gebe den Vorrednern recht: Wenn es um Zahlung und Datensicherheit geht, dann sollte das jemand machen, der sich damit auskennt und die Verantwortung trägt ...

 

[Magogan]

Das Problem ist, dass SHA-512 nicht sicher ist, da es zu schnell ist und ein Angreifer so das Passwort durch Brute-Force herausfinden kann, wenn er den Hash kennt. Man könnte den Algorithmus mehrmals laufen lassen, also den Hash nochmals hashen (10000 mal oder so), aber ob das dadurch sicherer wird, weiß ich nicht.

Und ja, die Fragen sind teilweise tatsächlich einfach zu beantworten, aber ich frage lieber nochmal nach, da ich auf dem Gebiet nicht so große Kenntnisse habe. Hab auch selbst nochmal gegoogelt und teilweise Ergebnisse gefunden, teilweise nicht. Jetzt habe ich dank eurer Antworten zumindest Anhaltspunkte und muss nicht mehr blind drauf los raten xD Ich hab's mir aber auch komplizierter vorgestellt als es ist.

Das mit den SSL-Zertifikaten verstehe ich trotzdem noch nicht ganz, die werden offenbar vom Browser überprüft, aber was ist dann, wenn ich für meinen Login-Server OpenSSL nutze? Ich übergebe ja im Client die URL gar nicht an OpenSSL, sondern nur den Socket (und damit höchstens IP-Adresse und Port). Muss ich dafür dann trotzdem ein SSL-Zertifikat kaufen?

Ich werde das erstmal alles auf einem Server laufen lassen (sollte nicht so kompliziert sein) und automatisch Backups der Datenbanken erstellen. Und wenn mehrere Server benötigt werden, hab ich hoffentlich genug Geld, um jemanden zu bezahlen, der sich darum kümmert

 

[asdfman]

Du musst kein Zertifikat kaufen. Du kannst dir auch selbst eins basteln, wenn du damit leben kannst, dass anfragende Browser ihren Usern falsche Sicherheitspanikmeldungen anzeigen.

 

[Kanibal]

Und auf einer Website mit ungültigen Sicherheitszertifikat werden die Nutzer dann eine PayPal-Transaktion starten? Wahrscheinlich eher nicht

@Megogan: Passworts Hashs zu übermitteln ist eine blöde Idee. Das bringt keine zusätzliche Sicherheit: Wenn ein Angreifer den Hash hat, kann er sich damit anmelden, es ist folglich kein Unterschied zu einem Passwort mehr.
Bessere Idee: Passwort verschlüsselt an Server senden (TLS), Server antwortet mit einem signierten Token, Client sendet für weitere Anfragen diesen Token mit. Stichwort: OAuth2 + JSON Web Tokens.

 

[asdfman]

Und auf einer Website mit ungültigen Sicherheitszertifikat

Ein Zertifikat ist nur ungültig, wenn es abgelaufen ist, oder keine gültige Signatur hat (€: Und wenn notwendige Angaben fehlen natürlich auch :E). Und eine Selbstsignatur ist selbstverständlich auch gültig. Immerhin endet jede Chain Of Trust in SSL zwangsläufig an einem selbstsignierten Zertifikat.
Daran, dass die Leute auf das Sicherheitstheater im Browser hereinfallen und dann nichts kaufen werden, ändert diese Tatsache aber natürlich nichts.

 

[Magogan]

@Megogan: Passworts Hashs zu übermitteln ist eine blöde Idee. Das bringt keine zusätzliche Sicherheit: Wenn ein Angreifer den Hash hat, kann er sich damit anmelden, es ist folglich kein Unterschied zu einem Passwort mehr.
Bessere Idee: Passwort verschlüsselt an Server senden (TLS), Server antwortet mit einem signierten Token, Client sendet für weitere Anfragen diesen Token mit. Stichwort: OAuth2 + JSON Web Tokens.

Das ist mir schon klar (hab auch nicht geschrieben, dass ich das vorhabe), aber falls der Angreifer Zugriff auf die Datenbank erlangen sollte, hätte er halt die Hashes und sollte daraus nicht so einfach das Passwort herausfinden können.

Das Geld für ein SSL-Zertifikat habe ich, das ist kein Problem.

 

[Kanibal]

Ein Zertifikat ist nur ungültig, wenn es abgelaufen ist, oder keine gültige Signatur hat (€: Und wenn notwendige Angaben fehlen natürlich auch :E). Und eine Selbstsignatur ist selbstverständlich auch gültig.

Oder wenn Die Certificate Chain unterbrochen ist. Und das ist sie bei selbstsignierten Zertifikaten. Ist aber wohl auch Definitionssache, ich bin davon ausgegangen, dass für die Definition von "Ungültig" das übliche "Browser wirft mit Fehlermeldungen um sich" gilt. Nächstes mal dann vielleicht mit Disclaimer.

@Magogan
Dass Du keine Passwörter in der Datenbank speichern solltest, versteht sich von selbst - aber, wie gesagt: Hashing auf Client-Seite bringt nix. Es reicht, das Passwort verschlüsselt zu übertragen und serverseitig die Hashs zu vergleichen.

 

[daemon777]

Sollte man nicht lieber den verschlüsselten Hash schicken? Schließlich finde ich es als User ganz angenehm, wenn mein PW nicht im Klartext auf dem Server landet.

 

[asdfman]

Wenn ein Hash zur Authentisierung übertragen wird, bedeutet das, dass man zur Anmeldung das Passwort nicht wissen muss. An sich nicht zwangsläufig katastrophal, aber warum absichtlich die Sicherheit schwächen?

 

[Kanibal]

@daemon777
Deswegen

Es reicht, das Passwort verschlüsselt zu übertragen

 

[daemon777]

Ich meinte ja auch nicht den Hash als Verschlüsselung, sondern das gehashte PW mit einer verschlüsselten Verbindung übertragen.