PHP Login Password in Cookie sicher speichern

  • PHP

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von gabriel-b.

    PHP Login Password in Cookie sicher speichern

    Hallo,

    Da ich wieder einmal etwas programmieren wollte, hab ich mich mal rangesetzt. Da es aber das erste mal ist dass ich etwas mit Login mache habe ich mir mal überlegt, wie mach ich das jetzt sicher? Bevor ich das Password bei einem User in ein Cookie speichere, wird es bereits in Md5 verschlüsselt. Reicht dies oder muss ich da noch etwas komplexeres machen?
    Ich danke euch bereits im voraus für eure Antworten :D

    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
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    Ich bin der Ansicht, dass das Benutzerpasswort dort ganz allgemein nicht gut aufgehoben ist. Wie sieht dieses System denn bisher aus?
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.

    Trade schrieb:

    Wenn Du das schon hashst, dann solltest Du etwas aus der SHA-Familie nehmen (SHA256 bzw. 512 ist da wohl eine gute Wahl).
    Ich hab mich ein wenig schlau gegooglet. Auf dieser Seite(ganz unten) sind weitere Typen aufgelistet. Spielt da die Länge auch noch eine Rolle? Würde das ganze noch einmal sicherer wenn man irgend eine Geheime Zeichenkette vor das Password beim umwandeln tun würde?
    edit: Fast denn Link vergessen XD rither.de/a/informatik/php-bei…ash-eines-strings-bilden/

    Lukas schrieb:

    Wie sieht dieses System denn bisher aus?
    Bis jetzt sind es noch einzelne Scripte und schon die MySql Datenbank. Das ganze soll in Zukunft dann mal so funktionieren: Man gibt sein Nutzername und Password ein, einen Schritt weiter wird das dann überprüft und die Informationen sollten in ein Cookie (hoffentlich sicher) geladen werden. Beim aufrufen jeder Seite wird am Anfang geprüft ob die Daten korrekt sind.

    Man könnte natürlich auch eine Eintrag erstellen mit einer ID. Dann wäre das Password sicher in diesem Eintrag und man müsste Theoretisch nur noch ID und Username im Cookie speichern. Da habe ich aber ein wenig bedenken bezüglich der Effizienz.
    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.
    ...aber gut, dass wir darüber gesprochen haben!

    noBlubb schrieb:


    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.

    Ok... Sicher ist sicher ^^

    Sonderzeichen schrieb:

    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.

    Ist es über SSL möglich mit einem Programm wie WireShark das Password auszulesen?? Mit Ratelimit meinst du das eine IP in Z.B in 5 Min nur 3 versuche hat die Daten einzugeben? Oder wie?
    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 ;)
    ...aber gut, dass wir darüber gesprochen haben!
    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.
    ...aber gut, dass wir darüber gesprochen haben!
    Ähm... Also geht es hier bei diesem API's, Frameworks Tools usw. die ihr mir vorschlägt um die Verschlüsselungen eines HTML (Oder was auch immer) Formular? Dass Login an sich hab ich ja (soeben) fertig gestellt. Es geht auch nur um einen einmaligen Passwort austausch, der sicher sein sollte.

    noBlubb schrieb:


    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.
    Aber der Server ist nicht mir. Ich kann also nix dort installieren. Ist einfach ein normales Webhosting Paket. Sobald MySql und PHP dabei sind kann ich gut damit arbeiten.

    noBlubb schrieb:


    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 :)

    Also kurz sind bei mir wirklich große Dimensionen muss ich dazu noch sagen (Sollte man besser nicht zweideutig verstehen). Ich hab halt NOCH viel Zeit und dazu mach ich es gerne, irgendwelche Web Apps zu schreiben ^^

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „gabriel-b“ ()

    @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.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    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 8o

    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.
    @noBlubb
    Ja, die zwei grössten(Hostpoint, metanet) in der Schweiz bieten SSL an. Aber ich greife viel auch noch auf Ausländische Hoster zurück. Auch bei meiner Privaten Website habe ich einfach ein Deutscher(Oder österreichischen) Free hoster genommen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „gabriel-b“ ()