Camping_RIDER: Frage zum Wiki-Artikel „Zugriffsschutz“

problematische Seite

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

--
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
# Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  1. problematische Seite

    Hallo Camping_RIDER,

    Soll ich das mal irgendwie ändern?

    Klar. 😉

    Bis demnächst
    Matthias

    --
    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    1. problematische Seite

      Aloha ;)

      Soll ich das mal irgendwie ändern?

      Klar. 😉

      Erledigt ☑️

      Hoffe, es gefällt 😉

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
      1. problematische Seite

        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

        1. problematische Seite

          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

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  2. problematische Seite

    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.

    1. problematische Seite

      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.

      1. problematische Seite

        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

        --
        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
        # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  3. problematische Seite

    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

    1. problematische Seite

      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

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
    2. problematische Seite

      Hallo Julius,

      • <bisheriger Absatz>, evtl. die Veranschaulichung von @Der Martin verlinken oder einbinden (Lizenz? Platz?)

      Wo siehst du da Probleme?

      Bis demnächst
      Matthias

      --
      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
      1. problematische Seite

        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

        1. problematische Seite

          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

          --
          Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.