Kann mir einer noch erklären was da der Unterschied zur normalen Speicherung in den Sessions ist? In beiden Fällen werden doch die Daten gespeichert und können wieder abgerufen werden? Wo ist also der Vorteil da nun eine uuid zu vergeben? Ist die uuid dann pro Formularseite zu vergeben oder pro Formular?
Du hast eine UUID pro "Workflow". Dieser kann sich ja über mehrere Seiten / Formulare erstecken. Somit kann der Benutzer auch mit 2 Tabs zwei verschiedene Durchläufe machen, ohne dass sich die Daten vermischen.
Zurück zum regenerate_id: Ich rufe das also einfach immer auf beim Login? Weil dann würde im Fall das einer nicht eingeloggt ist eine SessionID vergeben werden und im Falle er ist schon drin wird diese einfach refreshed?
Genau, nach jedem erfolgreichen Login. Somit kann die SessionID nicht vom Benutzer kontrolliert werden, bzw. die Daten werden in die richtige Session geschrieben.
Wie prüfe ich denn ob es zwei verschiedene Sessions sind? Bei jedem Seitenaufruf innerhalb des Logins die aktuelle IP mit der in der Session vergleichen.
Wenn ungleich dann logout und account sperren?
Wenn ein angemeldeter Benutzer eine SessionID präsentiert, welche durch einen Login durch IP a.b.c.d erstellt wurde, dann kann er nicht plötzlich von der IP w.x.y.z kommen. Das bedeutet im Regelfall, dass die SessionID geklaut wurde. In dem Falle einfach die präsentierte SessionID löschen (session_destroy() oder noch besser: Eine spezielle Fehlermeldung drin speichern und diese dem legitimen Benutzer zeigen. Gleichzeitig natürlich dafür sorgen, dass dieser nicht mehr eingeloggt ist)
Hierbei aber nicht die komplette IP speichern (Datenschutz) und vergleichen, sondern nur die ersten 2 oder 3 Blöcke. Idealerweise sollte die Einstellung vom Benutzer festgelegt und auch komplett abschaltbar sein.
Achso und nochmal was zu den Cookies:
Ich habe bei einer Seite von mir mal Cookies ausgeschaltet. Ein Login ging dann nicht mehr. Ich habe die Tage gelesen, dass dann an die URL die SID angehängt wird.
Ja, das ist auch richtig so. Dass die SessionID an die URL angehängt wird, gab es meines Wissens nach mal. Da das aber nicht immer funktioniert hat wurde die Funktion wieder entfernt, bzw. per Standard abgeschaltet. Würde ich auch so belassen, denn dadurch funktionieren dann Lesezeichen nicht mehr korrekt und der Benutzer hat einfacher Kontrolle über die ID.
ch würde bei der Registrierung eines Users einen Salt in die User Datenbank schreiben, zufällig 20 Zeichen aus Buchstaben, Zahlen, Sonderzeichen. Diesen Salt würde ich dann beim hashen Mitnutzen und eventuell Später bei sensiblen Daten als Passwort zum ver- bzw. entschlüsseln über mcrypt nutzen. Meint Ihr das ist sicher?
Zum Salt: Sehr gut, jeder Benutzer sollte seinen eigenen haben, das ist wichtig. Gleichzeitig muss dieser nicht allzu geheim sein, in der Datenbank neben dem Passwort zu speichern ist OK. 20 Zeichen sind auch mehr als ausreichend, ob da jetzt aber unbedingt auch Sonderzeichen dabei sein müssen, darüber lässt sich streiten. Selbst wenn der Benutzer nur "a" als Passwort eingibt, so ist der Hash über effektiv 21 Zeichen erstellt. Und diese sind an sich schon quasi nicht zu knacken.
Wenn du den aber auch als Passwort zum ver- und entschlüsseln verwenden willst, dann wirds etwas tricky. Dann sollte dieser nicht so einfach in der Datenbank am Benutzer hängen sondern extra geschützt wo anders. Ausserdem sollte sich der Salt normalerweise bei jeder Passwortänderung auch ändern. Wenn du hiermit dann irgenwas verschlüsselt hast, dann kommst du da nicht mehr dran.
Extra Tabelle für die Verschlüsselungs-Schlüssel, mit extra Benutzer und Passwort. Am besten auch von einem extra Service aus anzusprechen, nicht von deiner Hauptanwendung aus drauf gehen. Der Extraservice bietet eine definierte Schnittstelle an und gibt die Schlüssel niemals raus. Zum Beispiel nur per REST ansprechbar, "verschlüssele Datei X für den Benutzer Y" oder "entschlüssele Datei Z für Benutzer X und liefere Daten".
Kann ich sowas direkt per SQL erzeugen? Ich würde die Spalte sonst noch auf Unique setzen. Aber was passiert denn wenn es dieses Zeichen schon mal gibt? Kriege ich dann eine Fehlermeldung?
Natürlich kannst du den Salt auch per SQL erzeugen lassen, dieser muss nicht kryptografisch sicher sein. Unique würde ich nicht nehmen, sollte ja quasi nie den selben Salt für zwei Benutzer erzeugen.
Wenn die Spalte auf Unique ist, dann gibt es einen Fehler, ja.
Würde mir in dem Zusammenhang übrigens auch noch Transaktionen in der Datenbank anschauen, diese helfen dir deine Daten konsistent und sauber zu halten. Vorallem wenn mal irgendwie was abbricht hast nicht nur die Hälfte der Änderungen drin.
Grüsse,
BK
