Architektur review

Hallo zusammen

Ich arbeite an einer App und hätte gerne euer Feedback zur Architektur.
In meiner App sollte man folgendes können:
- Man kann sich registrieren
- Man kann sich anmelden
- Man kann Freundschaftsanfragen senden
- Man kann sie akzeptieren oder ignorieren
- Man kann die Freunde anzeigen
- Man kann an Freunden Bilder senden

Momentan sieht die Architektur so aus:
- Siehe Anhang

Ich habe einen Server darauf läuft ein PHP Skript. Die App würde immer das PHP Skript ansprechen via IPort und das PHP Skript würde alles aus der mySQL Datenbank (und/oder aus dem Image Folder) holen und dies als Antwort zurück geben das die App das kriegt und damit weiter arbeiten kann. Wäre diese Architektur für mein Vorhaben gut? Was habe ich gut gemacht, was sollte cih verbessern? Was wäre die Ideale Architektur für mein Vorhaben? Welche Datenbanken? Andere Vorschläge?

Ich Danke euch schonmal im Vorraus.

Ich würde das Ganze mit Websocket/Node,js/Deamon aufbauen ,eine ordentliche Verschlüsselung drauf .

Port 80 und nur ein PHP dahinter finde ich recht unsicher und recht unstabil

Websocket, Node.js und Deamon ist auch nicht besser (Wären nicht mal meine letzte Wahl ). Nicht das Framework, sondern die Fähigkeiten in einer Sprache sind entscheiden.

PHP ist schon gut, man muss nur alles sauber programmieren. Was auch für alle anderen Sprachen gilt. Als Datenbank würde ich MySQL oder PostgreSql benutzen.

Statt Port 80 (Http) würde ich lieber Port 8080 (Https) benutzen. Schon damit du die Passwörter nicht im Klartext überträgst.

Für den Rest gibt es viele Möglichkeiten. Als nächstes sollest du Dir überlegen, wie die Anwendungen aussehen sollen. Welcher Use-Case soll die App haben. Welche Daten werden ausgetauscht. Wie soll die GUI aussehen.

@markus.tullius Aktuell wird das Passwort schon Clientseitig (seitens der App) verschlüsselt und es wird dann verschlüsselt am Server übergeben. Spielt da trotzdem eine rolle ob ich HTTP oder HTTPS nehme? Ich werde glaube ich dann eh noch das PHP durch eine Spring Boot Applikation ersetzten.

Ja, es spielt eine elementare Rolle.

In deinen Fall wird das Passwort verschlüsselt. In Klartext an den Server gesendet. Und dort wird es wieder entschlüsselt.

In der Konstruktion ist ein großer Denkfehler. Internetverbindungen sind keine Point to Point Verbindungen, sondern die Daten wandert von Rechner zu Rechner bis bei dem Server ankommt. Jeder der Server kann die Kommunikation mitschneiden, wenn sie in Klartext erfolgt.

Dieser hat jetzt das verschlüsselte Passwort. Und genau dieses braucht man um den Server "aufzuschließen". (Das ist ungefähr so als würdest du ein Musikstück auf eine CD pressen, und diese versendest. Wenn das richtige Stück auf der CD ist, öffnet der CD-Player die Tür. Leider kann aber jeder die CD kopieren, und diese in den CD-Player stecken.)

Deshalb ist auch schwachsinnig Passwörter mit md5 zu haschen, und diese dann in Klartext zu übertragen (Alles schon erlebt )

@markus.tullius Mit was würdest du dann verschlüsseln wenn nicht mit md5? Ich weiss auch das es für md5 auch sogenannte Cracker gibt die standartpasswörter einer liste beinhaltet un diese somit die md5 verschlüsselten passwörter wieder entschlüsseln kann ...

Die einfachste - erst mal HTTPS zu benutzen. Neuerdings gibt es Zertifikate, die umsonst sind: Let's Encrypt: 1 Million Zertifikate ausgestellt
Und die Daten statt mit GET mit POST übertragen.
Damit umgehst du schon 99% der Probleme. Dann solltest du Passworte nicht fest im Code speichern.
Zusätzlich kannst du dir noch ein eigenen Handshake überlegen.

Die andere Schwachstelle ist die Datenbank. Dort muss Du die unbedingt die Eingaben überprüfen. Auch befugte Leute haben manchmal nicht so nette Motive.

PHP: SQL Injection - Manual
MySQL-Injection und Datenmanipulation verhindern - MySQL/PHP-Skripte absichern und schützen - PC-Erfahrung.de

Zum Schluss noch ein Tipp zur Datenbankstruktur:
Normalisierung (Datenbank) – Wikipedia
Primär- und Fremdschlüssel - PHP-Kurs.com - PHP programmieren lernen

Hier noch ein Link zu dem Thema, wieso PWs verschlüsseln (egal mit welchem Algorithmus) nicht reicht: Replay-Angriff – Wikipedia

Nachtrag:
Verschlüsselung: Mit AES zum Beispiel. Aber man sollte sich trotzdem Gedanken über den Mechanismus machen, mit der man die Passworte austauscht.

MD5: Es gibt nicht nur Listen mit md5 Hash und dazu gehörigen Passwörter. Es gibt auch eine Möglichkeit aus einem md5 hash ein neues Wort zu generieren, welches den gleichen md5 Hash erzeugt (Kollision).
Besonders genial ist dabei, wenn die e-mail Adresse der Benutzername ist. Da viele die e-mail Adresse als Benutzernamen benutzen, und daneben immer das gleiche Passwörter verwenden, lohnt es sich ein paar bekannte Webseiten auszuprobieren. Treffer garantiert.

Man braucht dafür noch nicht mal besondere Software. Einfach mal den md5 Hash bei Google eingeben, da bekommt man sofort ein Wort ausgespuckt.
Für die Übermittlung würde ich auch auf https setzen. Die Gründe wurden glaube ich schon hinreichend dar gelegt. Wichtig ist auch es auch, dass die Passwörter nicht im Klartext in der Datenbank gespeichert werden.

Noch was zu den Bildern, die könntest du auch als Blob in die DB legen.

markus.tullius schrieb:

Statt Port 80 (Http) würde ich lieber Port 8080 (Https) benutzen. Schon damit du die Passwörter nicht im Klartext überträgst.

Zum Vergrößern anklicken....

Ich muss hier mal noch reingrätschen, auch wenn ich mich an der restlichen Diskussion noch nicht beteiligt habe:

Erstmal ist der Port für das Protokoll ziemlich egal. Ich kann auch https über Port 80 laufen lassen, oder FTP, oder ssh. Es müssen sich nur beide Seiten einig darüber sein was worüber gesprochen wird. Wir reden hier also maximal über Standardports. (Also Ports auf denen es sich eingebürgert hat (bzw. bei der IANA registriert sind) dort ein bestimmtes Protokoll laufen zu lassen, wie eben http 80, ftp 21, ssh 22. Und der Standardport für https ist NICHT 8080. Der allseits verwendete Standardport für https ist 443. 8080 ist der alternative http Port, der fast immer auch für Java basierte Application Server verwendet wird. (Tomcat, Jetty, ...)

Hallo@Deek,

du hast natürlich recht, 443 ist der betreffende Port. Asche auf mein Haupt.
Port stammt noch aus der Zeit, wo Speicher extrem knapp war. Damit beide Rechner wissen, welches Protokoll benutzt wird, hat man Ports eingeführt. Diese brauchen viel weniger Platz als ein String.
Es gibt Ports, die für den freien Gebrauch zu Verfügung stehen. Und es gibt natürlich auch Idioten, die sich nicht an die Standardports halten, aber den Leuten kann man nicht mehr helfen.