gabriel-b schrieb:

wird es bereits in Md5 verschlüsselt

Autsch. MD5 ist keine Verschlüsselung, sondern ein Hash. Heißt, Du kannst den nicht einfach in den Klartext zurück verwandeln, da Hashes Einwegfunktionen sind. Verschlüsselte Daten kann man entsprechend wieder entschlüsseln. Zwar gibt es sog. Rainbow Tables für sowas und zugegeben ist MD5 auch nicht mehr wirklich kollisionssicher, aber an sich ist es so gesehen erstmal nicht möglich. Wenn Du das schon hashst, dann solltest Du etwas aus der SHA-Familie nehmen (SHA256 bzw. 512 ist da wohl eine gute Wahl).

Grüße

Ich bin der Ansicht, dass das Benutzerpasswort dort ganz allgemein nicht gut aufgehoben ist. Wie sieht dieses System denn bisher aus?

Ich sehe keinen guten Grund, warum man Sicherheit gegen Performance so deutlich einbüßen lassen sollte. Was bringt dir der schnellste Dienst der Welt, wenn du ihn nicht sicher verwenden kannst? Wir sprechen hier über wenige Millisekunden um einen Cookie zu entschlüsseln, seinen Inhalt gegen den HMAC zu vergleichen und dann eventuell nochmal gegen die Datenbank zu checken.

Warum verwendest du nicht einfach ein Framework, das solche und andere Bereiche abdeckt? Laravel wäre da meine Wahl der Stunde.

Wenn du wirklich ein Problem mit der Performance haben solltest, dann analysiere das nachträglich. Behalte die Performance in Kopf, aber manche Operationen sind einfach nicht opferbar.

Passwörter speichert Laravel zum Beispiel als bcrypt, was auf solche Anwendungen spezialisiert ist.

Laravel kann als Backend zwar super verwendet werden, je nachdem was du machen möchtest könnte auch schon Lumen reichen.

Am einfachsten, denke ich, wäre es die Formdaten aus deiner Anwendung via POST über SSL an den Server zu versenden welcher mit einer als XML formatierten Antwort antwortet
und dir bei Erfolg einen Token zurückgibt welchen du bei jedem Request via Authorization-Header übergeben kannst um deinen Benutzer zu autorisieren.

Eventuell solltest du noch ein Ratelimit einbauen, besonders was den Login und ggf. die Anmeldung betrifft.

Nein. SSL ist beidseitig verschlüsselt. Wie genau das im Detail funktioniert, kann ich dir nicht erklären. Ich weiß wie man es nutzen kann. Das reicht mir
Soweit ich weiß gibts 2 Keys. Einen hat der Server und einen bekommt der Client. Den einen nutzt der Client um die Daten zu verschlüsseln und der
Server benutzt anschließend seinen um die Daten wieder zu entschlüsseln.

Ja so in etwa. Einem User sollte nicht die Möglichkeit gegeben werden tausend Login-Anfragen pro Minute senden zu können um in irgendwelche
Accounts rein zu kommen. Login-Throttling ist meiner Meinung nach Pflicht in sogut wie jeder (Web)Anwendung*. Wie du den User nun aussperrst obliegt dir.
Wenn ein User sich beispielsweise 3x falsch angemeldet hat, sollte er sich für z.B. 15 Minuten nicht anmelden können, auch wenn die Daten richtig sind.

Hast du eine Funktion wie beispielsweise das senden von privaten Nachrichten solltest du auch diese Funktion auf z.B. 20 Nachrichten pro Stunde begrenzen.
Sofern der User vernünftige Nachrichten sendet und keinen C&P Spam verschickt reicht das vollkommen aus.

* Nimm dir an meiner Website kein Beispiel denn dort wiederspreche ich mir selbst. Dass ich auf meiner Website noch kein Login-Throttling habe liegt
eher daran, dass ich noch keine Lust hatte das zu implementieren

Auch API / Login Throttling übernimmt Laravel durch eine Trait im Usermodel. (Weia.)
laravel.com/docs/master/authen…authentication-throttling
Die Sperren sind ein bisschen weniger drakonisch (5 Versuche, 1 Minute Sperre meine ich, lässt sich aber auch konfigurieren) - sollte für bcrypt aber ganz gut reichen denke ich.

Bei SSL/TLS kann man auch (unabsichtlich) Dinge kaputt machen (finde ich), "es ist SSL mit drinnen" könnte sich auch als gefährlicher Trugschluss herausstellen. Ordentlich konfiguriert, erste Sahne. Mit alten Ciphersuiten und Co, setzt du da auf ein falsches Pferd.

Let's Encrypt stellt kostenlose SSL Zertifikate aus und erneuert die auch regelmäßig. Da gibt es auch einen Setup "Wizard" für den Server, ehrlich gesagt weiß ich aber nicht, was der dir genau alles abnimmt. Automatische Konfiguration geht da momentan aber auch nur mit Apache, wobei das Tools schon ganz gut hilft.

Eventuell kannst du hier immer wieder den selben RSA Key verwenden und während die Zertifikate alle 90 Tage erneuert werden, könntest du so den Public Key in deinem Client "anpinnen" - das sollte ein sehr sicheres Sandwich darstellen. Sprich, der Client kennt den öffentlichen Teil des RSA Keys und kann diesen vergleichen. Abrunden könnte man es, indem du noch sicherstellst, dass de.wikipedia.org/wiki/Perfect_Forward_Secrecy eingehalten wird.
Vermutlich hab ich jetzt aber schon wieder 3-4 Sachen nicht bedacht, in dem Feld gibt es einfach sehr sehr viel zu verstehen.

Wichtig wäre an dieser Stelle: Ist es das wert?
Du schreibst, du möchtest einfach nur kurz was programmieren und es geht hier doch deutlich über "kurz und hackig" hinaus
Laravel ist natürlich schon ein Schlachtschiff, aber vielleicht kannst du das ja eh für dich verwenden.

BTW: Warum XML statt JSON? Einfacher zu parsen als xDocument? Newtonsoft geht mit JSON sehr gut um, aber wäre natürlich eine extra Dll. Würde mich persönlich aber nicht groß stören.

noBlubb schrieb:

BTW: Warum XML statt JSON? Einfacher zu parsen als xDocument? Newtonsoft geht mit JSON sehr gut um, aber wäre natürlich eine extra Dll. Würde mich persönlich aber nicht groß stören.

Aus genau diesem Grund habe ich XML vorgeschlagen. Je nachdem was er nach dem Login macht bzw. mit dem Login alles holen möchte wäre es nur eine Antwort die er verarbeiten müsste. Da denke ich wäre es Sinnvoller die Bordmittel zu verwenden.
Baut er nun jedoch jedes Formular / Fenster mit den Daten vom Server auf wäre es vermutlich einfacher Newtonsofts Json.NET zu verwenden.

@gabriel-b Ich möchte dich bitten, beim Zitieren vorher ein wenig nachzudenken, was wirklich nötig ist. Vollzitate, d. h. das Zitieren von vollständigen Postings, die noch dazu direkt über deinem stehen, sind nicht nur unnötig und unübersichtlich, sondern hier auch nicht erlaubt.

Sonderzeichen schrieb:

Zitat von noBlubb: „BTW: Warum XML statt JSON? Einfacher zu parsen als xDocument? Newtonsoft geht mit JSON sehr gut um, aber wäre natürlich eine extra Dll. Würde mich persönlich aber nicht groß stören.“
Aus genau diesem Grund habe ich XML…

Jap, guter Gedankengang. Laravel hat meines wissens nach viele praktische Methoden für JSON, aber nicht wirklich für XML. Jetzt ist mir gerade gekommen, dass man ja auch das Blade / Template - System mit Responses füllen könnte - das müsste doch eigentlich wunderbar funktionieren. Dann hat man weiter eine schöne Trennung von "View" (eher Response) und Controller. Das Templating könnte ja sogar für die diversen Token Sinn ergeben

Auch normale Webhosting Pakete sollten SSL anbieten. Gerade mit Let's Encrypt ist es nun wirklich kein großer Aufwand mehr und die Beta-Phase ist ja auch schon verlassen.
Wenn wordpress.com darauf setzt, ist das schon ein Zeichen, denke ich. Ist es denn ein Server in der Schweiz? Da sollte doch Sicherheit groß geschrieben werden

SSL / TLS wird gern für HTTP(S) Transfers eingesetzt, kann aber auch für Emails (SMTP / IMAP, vermutlich POP, ob das jemand nutzt...) verwendet werden. Es liegt auf einer tieferen Ebene (Transport Layer => TL), als etwa das HTTP Protokoll. (Das dadurch zu HTTPS wird). Der Wikipedia-Artikel liefert da eine gute Übersicht: de.wikipedia.org/wiki/Transport_Layer_Security
Da du an PHP gebunden bist und das ganze durch einen Webserver ausgeliefert wird, sind wir hier an HTTP (oder eben besser HTTPS) gebunden. HTTP kann HTML transportieren, auch das ist aber kein muss. Stichwort Content-Type.