Beat: Sessions vs htaccess / sicherheit? was meint ihr?

Beitrag lesen

Pauschal würde ich erstmal sagen, dass eine Verwaltung von Passwörtern über Datenbanken u.ä. in Verbindung mit Sessions flexibler ist.

Ja, aber...

Man kann Passwörter, Benutzergruppen, Berechtigungen usw. einfach besser handhaben, wenn sie nicht in irgendwelchen flachen Textdateien herumliegen.

Nein das hat primär mal nix mit dem Speicherformat zu tun. Und im Gegenteil. ein Flatfile ist unabhängiger als eine Datenbank.
Für mich ist das auch nicht das Thema den die Frage ist ja nicht, was weniger Programming Skill bedarf.

Der Vorteil eigener Sessions liegt darin, dass du nicht auf bestimmte Parameter Werte festgelegt bist, sondern diese selber definieren kannst.
Alle Komplexizität steht dir offen.

Einen Nachteil bei Sessions ohne Cookies sehe ich darin, dass URLs, in denen die Session-ID auftaucht, benutzt werden können, um die Session zu "hijacken".

Gilt auch bei Cookies. Das hat nichts damit zu tun.

Zudem: Poste hier doch mal, was dir Live Headers anzeigt? Das kam hier kürzlich vor. Der Betroffene wurde darauf hin aufgefordert sein passwort möglichst schnell zu ändern...

Der essentielle Unterschied zwischen einer URL Deponierten ID und einer Cookie ID ist:

Eine Cookie ID ist vollkommen Browser-orientiert.
Eine URL-ID ist Aktivitätsorientiert.

bei URL Sessions kann ich parallel mehrere Sessions haben. Das bekommst du mit Cookies nur in einer höchst blödsinnigen Weise hin.

Beispiel:

...

Dem kann man natürlich entgegenwirken, z.b. dadurch, dass besonders sicherheitskritische Funktionalitäten eben nochmal eine erneute Authentifzierung erfordern oder die Session nach ner Zeit abläuft (ist ja glaube ich sogar Standard). Trotzdem, das ist nicht ganz unproblematisch, und kann bei .htaccess-Schutz nicht passieren.

Du kannst eine Kombination verwenden.
BrowserID = deine Cookie ID
RequestID = einen vorherigen Zustand identifizierenden ID via URL/Formular.

In der Kombination kannst du daraus OneTime IDs basteln und somit im Zusammenhang mit einer "used" marke schon beinahe sichere IDs erzeugen, die bei Doppelverwendung die ganze Browser-ID Geschichte killen, also Schadensbegrenzend wirken.

Ein Nachteil widerrum bei .htaccess:
Es reicht eine kleine Unachtsamkeit bei der Serverkonfiguration (dass z.b. die .htaccess-Datei ungewollt beschreibbar durch einen Prozess wird), und das wars mit der Sicherheit.

Das ist ein Punkt. Aber .htaccess braucht nicht via ein gleichnamiges File implementiert zu sein.

mfg Beat

--
><o(((°>           ><o(((°>
   <°)))o><                     ><o(((°>o