Frage zum Wiki-Artikel „Zugriffsschutz“
Camping_RIDER
0 
Matthias Apsel
0 Camping_RIDER
0 
Rolf b
0 
dedlfix
0 
Julius
Frage zum Wiki-Artikel „Zugriffsschutz“
Camping_RIDER
Aloha ;)
Bin ich schief gewickelt oder muss das
„Benutzerspezifische Passwörter sind nicht möglich.“
eigentlich an der Stelle raus?
Gerade wenn ich ein Formular hernehme hält mich ja nichts davon ab, zum Passwort noch einen Benutzernamen abzufragen und nur gültige Kombinationen zu akzeptieren.
Das macht den „Passwortschutz“ dann natürlich auch noch nicht zum Passwortschutz, aber zumindest sachlich sollte die Kritik ja schon korrekt sein.
Auch die Formulierung beim darauffolgenden Unterpunkt ist irgendwie nicht perfekt, weil der Grund dafür, dass es ein Negativbeispiel ist, nur in der Überschrift erwähnt ist.
Soll ich das mal irgendwie ändern?
Grüße,
RIDER
-
Hallo Camping_RIDER,
Soll ich das mal irgendwie ändern?
Klar. 😉
Bis demnächst
Matthias-
-
Sind die Backticks Absicht? Oder sollte es 'kursiv' oder ''fett'' sein?
Mir gefällt vor allem die Liste an möglichen Fehlern bei der serverseitigen Implementierung. Mit kleinen Anmerkungen:
- Punkt 3 ist eher eine Folge von Punkt 2 und kein Fehler der Implementierung.
- Eine weitere Schwachstelle kann die billige Vergabe von Session-IDs sein (fortlaufende Nummer) statt einer kryptographisch gesicherten Zufallsfolge, so dass man die Session-IDs anderer Anwender erraten kann
- Ein letzter Punkt "Diese Liste erhebt keinen Anspruch auf Vollständigkeit" würde nochmal unterstreichen, dass man hier keine Checkliste hat, die man erledigen und sich dann entspannt zurücklehnen kann.
Rolf
-
Aloha ;)
Danke für die Anregungen. 😀
Sind die Backticks Absicht? Oder sollte es 'kursiv' oder ''fett'' sein?
Ah, selbstverständlich. So ist das, wenn man an zu vielen Syntaxen gleichzeitig sitzt 😂 Es ist im Wiki sogar ''kursiv'' bzw. '''fett''' xD
Mir gefällt vor allem die Liste an möglichen Fehlern bei der serverseitigen Implementierung. Mit kleinen Anmerkungen:
- Punkt 3 ist eher eine Folge von Punkt 2 und kein Fehler der Implementierung.
Teils-teils. Wenn die Verbindung unverschlüsselt ist kann das Passwort immer noch clientseitig gehasht sein (in Javascript) und damit das aufs gleiche Passwort hörende E-Mail-Konto schützen - deshalb habe ich explizit darauf abgestellt in diesem Punkt. Optimalerweise wird das Passwort zweimal gehasht - einmal beim Client, bevor es dessen Einflussbereich verlässt, und einmal beim Server, zum Speichern. Über die Sinnhaftigkeit des ersten Hashen lässt sich streiten und insbesondere macht das die verschlüsselte Verbindung nicht überflüssig, aber es kann helfen, beispielsweise um noch größeren Schaden zu verhindern wenn die Verbindung irgendwie kompromittiert ist, wie im Beispiel mit dem E-Mail-Konto.
- Eine weitere Schwachstelle kann die billige Vergabe von Session-IDs sein (fortlaufende Nummer) statt einer kryptographisch gesicherten Zufallsfolge, so dass man die Session-IDs anderer Anwender erraten kann
Richtig, guter Punkt. Aus der Liste würde ich es allerdings draußen lassen, weil der Standardfall (zumindest bei Verwendung von PHP) ist, dass die Session-ID nicht manuell vergeben wird.
- Ein letzter Punkt "Diese Liste erhebt keinen Anspruch auf Vollständigkeit" würde nochmal unterstreichen, dass man hier keine Checkliste hat, die man erledigen und sich dann entspannt zurücklehnen kann.
Stimmt. Danke. Habe ich ergänzt.
Grüße,
RIDER
-
-
-
Tach!
Bin ich schief gewickelt oder muss das
„Benutzerspezifische Passwörter sind nicht möglich.“
eigentlich an der Stelle raus?
Gerade wenn ich ein Formular hernehme hält mich ja nichts davon ab, zum Passwort noch einen Benutzernamen abzufragen und nur gültige Kombinationen zu akzeptieren.
Theoretisch (und praktisch) kann man. Aber dann muss man alle Nutzer-Passwort-Kombinationen im Code stehen haben. Die Idee ist gleich noch schlechter, als nur ein einzelnes Passwort dort zu verstecken.
dedlfix.
-
Dann wäre noch das hier:
Die zu schützende Seite wird ohne Links ins Netz gestellt und den Suchmaschinen mittels meta-Element oder robots.txt empfohlen, die jeweilige Seite nicht in den Index aufzunehmen.
Es ist ganz gewiss eine nur auf ganz besondere Weise "gute" Idee, die zu schützende Seite in der für jedermann abrufbaren robots.txt zu listen.
Ich würde mich aber nicht auf die Aussage versteifen, dass der Satz weg kann.
-
Aloha ;)
Dann wäre noch das hier:
Die zu schützende Seite wird ohne Links ins Netz gestellt und den Suchmaschinen mittels meta-Element oder robots.txt empfohlen, die jeweilige Seite nicht in den Index aufzunehmen.
Es ist ganz gewiss eine nur auf ganz besondere Weise "gute" Idee, die zu schützende Seite in der für jedermann abrufbaren robots.txt zu listen.
Ich würde mich aber nicht auf die Aussage versteifen, dass der Satz weg kann.
Hm? Genau deshalb hatte ich doch schon heute Mittag ergänzt:
„Es ist außerdem nicht ausgeschlossen, dass diese Angaben dazu führen, dass böswillige Webcrawler, die gezielt nach solchen Dateien suchen, bei denen die Indizierung unerwünscht ist, der geheimen Seite dadurch zusätzliche Aufmerksamkeit widmen.“
Dem Aspekt sollte damit ausreichend Rechnung getragen sein.
Grüße,
RIDER
-
-
-
Hallo RIDER,
ich häng mich mal dran, weil ich auch zwei Dinge suboptimal finde und fragen wollte, was andere dazu sagen:
Im Abschnitt HTTP-Authentication heißt es:
Ein weiteres mögliches Problem ist, dass die Zugriffsregelung sehr allgemein gehalten ist. Die Konfiguration kann nur regeln, mit welchen Zugangsdaten man welche Dateien (einzeln oder verzeichnisweit) abrufen kann. Auf den Benutzer maßgeschneiderte Inhalte zusammen zu stellen, wie etwa in einem Forum oder web-basierten E-Mail-Programm, ist damit nicht möglich.
Grundsätzlich ist es doch möglich, per HTTP-Authentication benutzer-spezifische Inhalte auszuliefern – wurde das hier nicht in im CForum < 4 mit der Ansicht unter forum.de.selfhtml.org/my/ genauso gehandhabt?
Ich denke, das Problem des Artikels ist der Vergleich von „HTTP-Authentication“ mit „Passwortschutz mit serverseitiger Programmiersprache“, denn eigentlich müsste man „HTTP-Authentication“ mit „Cookie-basierter Passwortschutz“ vergleichen:
- HTTP-Authentication: Arbeitet direkt auf HTTP-Ebene mit den passenden Statuscodes und Headern
- Server implementieren einfache Varianten direkt <jetziger Abschnitt über .htaccess>
- kann auch mit einer serverseitigen-Programmiersprache ausgewertet werden → mehr Möglichkeiten
- Einschränkungen: Ausloggen nicht so einfach möglich
- evtl. Vorteil: Benutzer- und Passwort können in die URL gepackt werden: https://name:pass@example.org
- Cookie-basierte Authentification: Benutzt Cookie(s)
- <bisheriger Absatz>, evtl. die Veranschaulichung von @Der Martin verlinken oder einbinden (Lizenz? Platz?)
Im Abschnitt Passwortschutz mit serverseitiger Programmiersprache heißt es (Hervorhebung durch mich):
Wenn eine Website mittels einer serverseitigen Script-Sprache (ist im Prinzip eine Programmiersprache) wie z.B. Perl, PHP oder andere ausgeliefert wird, dann lässt sich mittels dieser Script-Sprache ein wesentlich leistungsfähigeres Konzept der Zugangsbeschränkung realisieren.
Ist die Betonung auf Scriptsprachen hier nötig? Reicht nicht einfach „serverseitige Programmiersprache“?
Gruß
Julius-
Aloha ;)
Grundsätzlich ist es doch möglich, per HTTP-Authentication benutzer-spezifische Inhalte auszuliefern
Richtig. Das ist eine Fehldarstellung.
Wenn eine Website mittels einer serverseitigen Script-Sprache (ist im Prinzip eine Programmiersprache) wie z.B. Perl, PHP oder andere ausgeliefert wird, dann lässt sich mittels dieser Script-Sprache ein wesentlich leistungsfähigeres Konzept der Zugangsbeschränkung realisieren.
Ist die Betonung auf Scriptsprachen hier nötig? Reicht nicht einfach „serverseitige Programmiersprache“?
Ich bin da bei dir; „serverseitige Programmiersprache“ würde mir auch genügen. Auf die Unterschiede zwischen Scriptsprache und Nicht-Scriptsprache will man hier ja auch gar nicht abstellen - es macht auch keinen Unterschied an der Stelle.
Grüße,
RIDER
-
Hallo Julius,
- <bisheriger Absatz>, evtl. die Veranschaulichung von @Der Martin verlinken oder einbinden (Lizenz? Platz?)
Wo siehst du da Probleme?
Bis demnächst
Matthias-
Hallo Matthias,
- <bisheriger Absatz>, evtl. die Veranschaulichung von @Der Martin verlinken oder einbinden (Lizenz? Platz?)
Wo siehst du da Probleme?
- Platz
- Sprengt diese relativ umfangreiche Veranschaulichung den Rahmen des Artikels? Ich meine nein, weil sie die Thematik sehr gut vor Augen führt. Aber ich wollte wissen, wie das andere sehen.
- Lizenz
- Der Eintrag kommt aus dem Forum, unter welcher Lizenz steht er dann? Sie müsste kompatibel zur CC-BY-SA des Wikis sein.
Einfügen wäre halt auffälliger als bloß verlinken.
Gruß
Julius-
Hallo Julius,
- Lizenz
- Der Eintrag kommt aus dem Forum, unter welcher Lizenz steht er dann? Sie müsste kompatibel zur CC-BY-SA des Wikis sein.
Einfügen wäre halt auffälliger als bloß verlinken.
Wenn das eindeutig als Zitat gekennzeichnet ist, dann muss es auch in allen Folgewerken so gekennzeichnet sein. Ich sehe da keine Probleme.
Bis demnächst
Matthias
- HTTP-Authentication: Arbeitet direkt auf HTTP-Ebene mit den passenden Statuscodes und Headern