Hallo Zusammen,
es geht um das Thema Sicherheit beim Userlogin auf Websites, Stichwort md5 und Salt.
Bei Benutzerlogins via PHP in Verbindung mit MySQL sind wir uns alle einig, dass die Kennwörter verschlüsselt werden müssen. Nun ist md5 ja nicht gerade effektiv (selbst ich habe im Selbstversuch, da ich mich ja gerade damit befasse, eine Routine programmieren können, die die Kennwörter "ausliest", bzw. Strings mit dem selben Hash-Wert generiert).
Bei meinen Recherchen bin ich dann auf "Salt" gestoßen, was ich logischerweise irgendwo nachvollziehen kann. Nur die praktische Umsetzung verstehe ich noch nicht. Daher bitte ich die erfahrenen Leute hier, mir ein paar Denkanstöße zu geben, um ein möglichst sicheres Login für Benutzer zur Verfügung zu stellen.
Mein Lösungsansatz, wenn ich das alles Richtig verstanden habe, sieht in etwa so aus:
1. In der PHP-selber existiert bereits ein Pre-String in Sinne von "5gHH/u8$]a.Zas", der dem Kennwort vorne angehangen wird. Frage dazu: sollte dieser String auch verschlüsselt werden?
2. Das Benutzerkennwort wird mit md5 und sha verschlüsselt
3. Dann würde ich eine Zufallszahl erstellen (1-100), die einer ID in einer anderen Datenbank entspricht in der dann weitere Strings beinhaltet sind, die dem ganzen "hinten" angehangen werden. Bei dem Punkt bin ich mir aber nicht sicher, ob ich das richtig verstanden habe. Sollte Der String dann beim Login oder bei der Registrierung erfolgen? Ich denke mal eher beim letzteren und die Zufallszahl/ID wird ebenfalls in der Login-Datenbank gespeichert?!
Inwieweit bin ich da auf dem richtigen Weg, bzw. bringt dieser Ansatz überhaupt etwas? Welche Möglichkeiten hätte ich denn noch das ganze etwas sicherer zu machen? Natürlich wird es immer 'irgendwie' Möglich sein da reinzukommen :-( [lol, musste gerade an mein altes Dreamweaver denken, dass 'ganz einfach' einen Login ermöglicht und die Kennwörter im Klartext abspeichert ^^]
Existieren irgendwo im Netz bereits vorgefertigte Module/Scripte mit einer vernünftigen Verschlüsselung? Oder wäre generell davon abzuraten sowas zu nutzen, weil die 'Vorgehensweise' ja bekannt ist?!
Informatives zum Thema wäre willkommen, vielleicht auch für andere User hier interessant, weil es ja doch ein heikles Thema ist und immernoch viel zu viele Leute 'nur' md5 verwenden....
Danke im Voraus für Eure Mühen,
Innu
Programmieren - alles kontrollieren 4.934 Themen, 20.613 Beiträge
Der Salt darf einem möglichen Angreifer nicht bekannt sein, und dazu zählt auch der Nutzer selbst.
Ja gut, das kann man nicht verhindern denn:
Es geht darum Passwörter nicht im Klartext in die Nutzertabelle zu schreiben.
Richtig ist das Passwort einmal zu hashen - kryptographish sicher also MD5 oder SHA2-Familie,
hingegen sind MD4 und SHA1 so gut wie geknackt und CRC32 ist als kryptographisch sichere Funktion garnicht gedacht.
Nun geben Benutzer gern leichte Passwörter wie "123" ein. Vom Hash lässt sich der Inhalt zwar nicht zurückberechnen, aber es gibt Gigabytegroße Übersetzungstabellen die solche einfachen Spielereien im Standartrepertoire haben.
Klaut dir nun jemand deine Nutzertabelle vom SQL Server sind viele Nutzer offen.
Dagegen wirkt ein Salt. Davon braucht man auch nur eins. Ein globales für alle Nutzer "5gHH/u8$]a.Zas" ist aber auch nicht das gelbe vom Ei.
Als sicher gilt das Konzept jedem User ein neues (gutes) Salt zu generieren, dieses mit dem Klartext-Password zu hashen und dann Hash und Salt in die Nutzertabelle zu speichern.
Ein Angreifer hat nun statt 100 Nutzern mit 1 Salt für die er 1 Übersetzungstabelle berechnen muss, 100 Salts für die er 100 Übersetzungstabellen berechnen muss, und eine gute Tabelle dauert schon verdammt lang.
Als Salt kann man zum Beispiel die aktuelle Systemzeit mit microsekunden hashen.
Ja gut, das kann man nicht verhindern denn:
Es geht darum Passwörter nicht im Klartext in die Nutzertabelle zu schreiben.
Richtig ist das Passwort einmal zu hashen - kryptographish sicher also MD5 oder SHA2-Familie,
hingegen sind MD4 und SHA1 so gut wie geknackt und CRC32 ist als kryptographisch sichere Funktion garnicht gedacht.
Nun geben Benutzer gern leichte Passwörter wie "123" ein. Vom Hash lässt sich der Inhalt zwar nicht zurückberechnen, aber es gibt Gigabytegroße Übersetzungstabellen die solche einfachen Spielereien im Standartrepertoire haben.
Klaut dir nun jemand deine Nutzertabelle vom SQL Server sind viele Nutzer offen.
Dagegen wirkt ein Salt. Davon braucht man auch nur eins. Ein globales für alle Nutzer "5gHH/u8$]a.Zas" ist aber auch nicht das gelbe vom Ei.
Als sicher gilt das Konzept jedem User ein neues (gutes) Salt zu generieren, dieses mit dem Klartext-Password zu hashen und dann Hash und Salt in die Nutzertabelle zu speichern.
Ein Angreifer hat nun statt 100 Nutzern mit 1 Salt für die er 1 Übersetzungstabelle berechnen muss, 100 Salts für die er 100 Übersetzungstabellen berechnen muss, und eine gute Tabelle dauert schon verdammt lang.
Als Salt kann man zum Beispiel die aktuelle Systemzeit mit microsekunden hashen.