andreas: Was ist an .htaccess sicherer als an UserDB???

Hallo!
ich verstehe irgendwie nicht, was an htaccess sicherer ist, als an einer eigenen Konrtolle über eine MySQl DB. Problem ist ja schonmal, dass die meisten Webhoster es nicht ermöglichen (können), eine .htpassword Datei in einem nicht aus dem Web zugänglichen Verzeichnis zu speichern. Damit ist der Vorteil schonmal weg. (ich mache das dann so dass ich die htpassw. in dem Ordner mit htacces Schutz speichere, gibts da was besseres?)
Jedenfalls kann ich doch auch in einer MySQl DB die User speichern, ob jetzt über http Auth oder ein einfaches html-Formular, ich kann doch auf der Result-Seite ein php Script hinschreiben, welches die DB abfragt, wenn alles OK, sonst einen anderen header(location...) und exit;
Was ist daran unsicherer als .htaccess? Und wenn ich die Variabeln dann noch in eine SessionID schreibe, kann ich das auf jeder Seite automatsch machen, ohne dass eine erneute Eingabe nötig ist.
Was spricht dagegen? Denn in der DB kann ich die User und Rechte viel einfacher und flexibler handhaben, als über htaccess!
Oder habe ich was nicht bedacht? Hab mir gerade einiges über htaccess durchgelesen, aknn aber keine entscheidenden Vorteile feststellen!

Grüsse
  Andreas

  1. Hallo Andreas

    Der größte Vorteil von .htaccess gegenüber einer selbstgebauten Lösunsung mit PHP o.ä. ist, dass man selber keine Sicherheitslücken verursachen kann. So tauchen Sessionids in der Url eben in allen Proxylogs auf und werden, wenn man das nicht verhindert, im Referer an verlinke Server weitergegeben.
    Außerdem kann man mit PHP u.ä. auch keine ganzen Verzeichnisse schützen. Dazu müsste schon jede Seite ein Phpscript oder die Zugriffe nur über ein PHP-Script möglich sein.
    Die Userdaten kann Apache mit dem entsprechenden Modul übrigens auch in DBs speichern.

    Grüße

    Daniel

  2. Hi Andreas,

    ich verstehe irgendwie nicht, was an htaccess sicherer ist, als an einer
    eigenen Konrtolle über eine MySQl DB.

    Nichts.

    "Sicher" ist kein Attribut von .htaccess, sondern von der verwendeten
    Authentifizierungsmethode.
    Eine solche wäre im vorliegenden Falle "Basic" oder "Digest".

    Problem ist ja schonmal, dass die meisten Webhoster es nicht ermöglichen
    (können), eine .htpassword Datei in einem nicht aus dem Web zugänglichen
    Verzeichnis zu speichern.

    Der Pfadname der .htpasswd-Datei steht im Klartext in der .htaccess-Datei
    drin - diese kannst Du manuell erstellen und hochladen, genau wie Deine
    HTML-Seiten. Der Webhoster hat damit gar nichts zu tun.

    Es kann natürlich sein, daß der Webhoster irgend ein GUI anbietet, um die
    .htpasswd-Dateien im Dialog zu bearbeiten, und daß dieses GUI irgendwelche
    Einschränkungen aufweist. Wenn Dich diese stören, dann verwende es halt
    einfach nicht ...

    Damit ist der Vorteil schonmal weg. (ich mache das dann so dass ich die
    htpassw. in dem Ordner mit htacces Schutz speichere, gibts da was besseres?)

    Es gibt _keinen_ Grund, die Passworte innerhalb des URL-Raums zu speichern.
    Laß den Webmaster einen Fingerfehler in seine Konfiguration machen, und
    Deine Passworte sind plötzlich ungeschützt.

    Jedenfalls kann ich doch auch in einer MySQl DB die User speichern,
    ob jetzt über http Auth oder ein einfaches html-Formular,

    HTTP Authentication "Digest" würde Dir erlauben, die Kenndaten bereits in
    verschlüsselter Form (MD5) zu _übertragen_.

    "Basic" ebenso wie jede formularbasierte Methode sendet die Daten im
    Klartext (bzw. Base64-codiert) über die Leitung. (Es sei denn, Du legst
    eine SSL-Schale um die gesamte Kommunikation herum.)

    ich kann doch auf der Result-Seite ein php Script hinschreiben, welches
    die DB abfragt, wenn alles OK, sonst einen anderen header(location...)
    und exit;

    Ja. Du kannst auch einen ganzen Webserver nachprogrammieren, wenn Du gerade
    nichts zu tun hast und glaubst, das besser zu können als die existierenden
    Hersteller.

    Was ist daran unsicherer als .htaccess?

    Wie gesagt: Nichts, denn .htaccess ist kein Authentifizierungsprotokoll.

    Und wenn ich die Variabeln dann noch in eine SessionID schreibe, kann
    ich das auf jeder Seite automatsch machen, ohne dass eine erneute Ein-
    gabe nötig ist.

    Klar. Du mußt halt die Session-ID jedesmal wieder auseinanderpflücken und
    Benutzerkennung & Passwort immer wieder prüfen.
    Bei Server Authentication würde das der Webserver für Dich machen.

    Was spricht dagegen?

    Der Aufwand auf Deiner Seite.

    Denn in der DB kann ich die User und Rechte viel einfacher und flexibler
    handhaben, als über htaccess!

    Wieso das? Wenn Du ein GUI für die Datenbank schreiben kannst, dann kannst
    Du auch einen GUI-Editor für .htpasswd-Dateien schreiben (das ist m. E. sogar
    viel einfacher).

    Oder habe ich was nicht bedacht? Hab mir gerade einiges über htaccess
    durchgelesen, aknn aber keine entscheidenden Vorteile feststellen!

    Der Haupt-Vorteil ist, daß es ein etablierter Standard ist, den alle Browser
    (mehr oder weniger gut) unterstützen.

    Darüber hinaus wäre "Digest" wirklich sicherer als alles, was Du selbst
    bauen kannst.
    Zum jetzigen Stand der Browser-Entwicklung schließt Du damit allerdings
    sämtliche Netscape-Browser aus; Opera 4, M$IE 5, Mozilla 0.9.7 und Amaya
    (ich habe 5.3 probiert) spielen bereits mit.

    Viele Grüße
          Michael

    1. Hallo!

      Danke Euch allen für die Antworten!

      Der Pfadname der .htpasswd-Datei steht im Klartext in der .htaccess-Datei
      drin - diese kannst Du manuell erstellen und hochladen, genau wie Deine
      HTML-Seiten. Der Webhoster hat damit gar nichts zu tun.

      Es kann natürlich sein, daß der Webhoster irgend ein GUI anbietet, um die
      .htpasswd-Dateien im Dialog zu bearbeiten, und daß dieses GUI irgendwelche
      Einschränkungen aufweist. Wenn Dich diese stören, dann verwende es halt
      einfach nicht ...

      Nein, das meinte ich nicht. Ich meine dass ich bei machen Hostern nicht die Möglichkeit habe, auf andere Verzeichnisse zuzugreifen als die htdocs! Also _muss_ ich die .htpassw in einem für Browser erreichbares Verzeichnis ablegen. Und wenn ich die im .htaccess geschützen Bereich ablege wird es wohl OK sein, oder was ist besser?

      HTTP Authentication "Digest" würde Dir erlauben, die Kenndaten bereits in
      verschlüsselter Form (MD5) zu _übertragen_.

      "Basic" ebenso wie jede formularbasierte Methode sendet die Daten im
      Klartext (bzw. Base64-codiert) über die Leitung. (Es sei denn, Du legst
      eine SSL-Schale um die gesamte Kommunikation herum.)

      Gilt das auch für HTACCESS?

      Wieso das? Wenn Du ein GUI für die Datenbank schreiben kannst, dann kannst
      Du auch einen GUI-Editor für .htpasswd-Dateien schreiben (das ist m. E. sogar
      viel einfacher).

      Also einfach ein php Script, welches die .htpasswd öffnet und den Inhalt mit explode() aufschlüsselt, den Inhalt in einer Schleife ausgibt und dann mache ich hinter jede User-Pass kombination 2 Links, einmal bearbeiten und einmal löschen, der eine löscht die Zeile, der andere schreibt die Daten in ein Formuler, wo ich die Daten verändern kann, und dazu noch ein Formular welches eine neue Zeile einfügt, Passwörter mit crypt() verschüsselt. Ginge das so in etwa? Leider habe ich noch nie was in der Art versucht.

      Darüber hinaus wäre "Digest" wirklich sicherer als alles, was Du selbst
      bauen kannst.
      Zum jetzigen Stand der Browser-Entwicklung schließt Du damit allerdings
      sämtliche Netscape-Browser aus; Opera 4, M$IE 5, Mozilla 0.9.7 und Amaya
      (ich habe 5.3 probiert) spielen bereits mit.

      Also fürs erste lieber Basic mit SSL-Verschlüsselung.

      Gibt es eigentlich die Möglichkeit an Stelle des sich öffnenden Auth-Fensters eine .htaccess Authentifizierung in ein html-Formular einzubauen? Jetzt nur wegen der Optik!

      Grüsse
        Andreas

      1. Hi Andreas,

        Ich meine dass ich bei machen Hostern nicht die Möglichkeit habe,
        auf andere Verzeichnisse zuzugreifen als die htdocs!
        Also _muss_ ich die .htpassw in einem für Browser erreichbares
        Verzeichnis ablegen.

        Yep. Kein guter Provider, das.
        Ich habe beispielsweise mein eigenes access_log und error_log und
        möchte beide sicherlich nicht in den URL-Raum einblenden.

        Und wenn ich die im .htaccess geschützen Bereich ablege wird es
        wohl OK sein, oder was ist besser?

        In Deinem Falle geht es nicht wirklich zuverlässig. Du mußt darauf
        vertrauen, daß Dein Provider keinen Unfug treibt. (Das Self-Portal hat
        mit einem früheren Provider genau diesen Un-Fall schon erlebt.)

        "Basic" ebenso wie jede formularbasierte Methode sendet die Daten im
        Klartext (bzw. Base64-codiert) über die Leitung. (Es sei denn, Du
        legst eine SSL-Schale um die gesamte Kommunikation herum.)
        Gilt das auch für HTACCESS?

        Diese Frage verstehe ich nicht.
        .htaccess ist ein Mechanismus innerhalb der Webserver-Konfiguration;
        SSL ist eine Schale um den HTTP-Dialog zwischen Server und Browser.

        Falls Du meintest: "Kann man auch Server Authentication in SSL einschalen?",
        lautet meine Antwort: "Genau das hatte ich gerade vorgeschlagen, damit die
        in HTTP im Klartext gesendeten Passworte von SSL verschlüsselt werden".

        Also einfach ein php Script, welches die .htpasswd öffnet und den Inhalt mit
        explode() aufschlüsselt, den Inhalt in einer Schleife ausgibt und dann mache
        ich hinter jede User-Pass kombination 2 Links, einmal bearbeiten und einmal
        löschen, der eine löscht die Zeile, der andere schreibt die Daten in ein
        Formuler, wo ich die Daten verändern kann, und dazu noch ein Formular welches
        eine neue Zeile einfügt, Passwörter mit crypt() verschüsselt. Ginge das so in
        etwa?

        Völlig richtig. Vor allem ist der Ansatz gut, zuerst die möglichen Werte zu
        bestimmen und einen davon auszuwählen - viel schöner, als zuerst ein Eingabefeld
        anzubieten und dann eine Fehleingabe mit einer Fehlermeldung zurückzuweisen.

        Du kannst auch für die definierten Benutzer ein Dropdown-Menü erzeugen - so
        etwas habe ich hier im Büro als Oberfläche für die eingetragenen Benutzer eines
        Webhosting-Produkts mal gebaut.

        Leider habe ich noch nie was in der Art versucht.

        Aber es scheint genau Deine Kragenweite zu sein. Probiere das ruhig mal aus.
        Das Prinzip hast Du ja verstanden. Und da es wahrscheinlich nur Dich selbst
        als Benutzer geben wird, darfst Du die Synchronisation paralleler Schreib-
        zugriffe auf die Passwort-Datei in Version 1.0 erst mal ausklammern. ;-)

        Darüber hinaus wäre "Digest" wirklich sicherer als alles, was Du selbst
        bauen kannst.
        Zum jetzigen Stand der Browser-Entwicklung schließt Du damit allerdings
        sämtliche Netscape-Browser aus; Opera 4, M$IE 5, Mozilla 0.9.7 und Amaya
        (ich habe 5.3 probiert) spielen bereits mit.
        Also fürs erste lieber Basic mit SSL-Verschlüsselung.

        Je nachdem. Für SSL brauchst Du wiederum ein Zertifikat ... und SSL im Web-
        server, mit entsprechender Konfiguration.
        Digest Authentication käme mir wesentlich 'handlicher' vor. Und Mozilla 0.9.7
        kann es immerhin - mal sehen, wann der nächste Netscape heraus kommt ...

        Gibt es eigentlich die Möglichkeit an Stelle des sich öffnenden Auth-Fensters
        eine .htaccess Authentifizierung in ein html-Formular einzubauen?
        Jetzt nur wegen der Optik!

        Das ist eine oft gestellte Frage. ;-)

        Im Prinzip besteht die Frage aus zwei Teilen:
        a) Kann ich das Verhalten des Browser beim Eintreffen einer Authentifizie-
           rungs-Anforderung beeinflussen?
        Antwort: Nein, weil die Browser-Hersteller das nicht vorgesehen haben.

        b) Kann ich selbst präventiv eine Authentifizierung anhand von Formular-
           werten an den Server senden?
        Antwort: Im Prinzip würde das funktionieren. Von HTTP-Seite spricht jeden-
        falls nichts dagegen, schon beim ersten Zugriff auf eine geschützte Seite
        die "credentials" mitzusenden - Du mußt die Aufforderung zur Authentifi-
        zierung nicht erst provizieren.
        Das Problem ist aber, daß die Browserhersteller nicht wissen können, daß
        Du mit einem HTML-Formular etwas Anderes tun möchtest, als eine der Me-
        thoden zu verwenden, die es für Formulare nun mal gibt - also GET oder
        POST.
        Im Prinzip 'fehlt' hier ein Stückchen HTML-Definition, um dem Browser zu
        sagen, den Inhalt eines bestimmten Formular-Elements nicht in den Query-
        String oder den POST-Inhalt, sondern in den Authentication Header des
        HTTP-Requests zu stecken.

        Es ist nicht prinzipiell unmöglich - es gibt nur einfach keinen passenden
        HTML-Tag dafür, obwohl HTML mit seinen Formular-Tags über die Grenzen
        einer Dokumentstrukturbeschreibungssprache ansonsten weit hinaus geht
        und sich gerade mit den Formular-Methoden (ebenso wie mit den URLs) an
        die Vorgaben von HTTP bindet.
        HTML und HTTP sind in dieser Hinsicht nicht inhaltlich deckungsgleich.

        Viele Grüße
              Michael

        P.S.: Eigentlich wundert es den Betrachter, daß Micro$oft an dieser Stelle
              noch keine proprietäre Lösung erfunden hat.
              Andererseits: Micro$oft und Sicherheitsbewußtsein ... ;-)

        1. Hi!

          Danke für Deine ausführliche Antwort!

          Yep. Kein guter Provider, das.

          Sehe ich genau so! Aber kann ich mir nicht immer aussuchen!

          Und wenn ich die im .htaccess geschützen Bereich ablege wird es
          wohl OK sein, oder was ist besser?

          In Deinem Falle geht es nicht wirklich zuverlässig. Du mußt darauf
          vertrauen, daß Dein Provider keinen Unfug treibt. (Das Self-Portal hat
          mit einem früheren Provider genau diesen Un-Fall schon erlebt.)

          Aber das wäre ja noch einigermaßen sicher, da er ja da nur dran kommt, wenn htaccess eh nicht funktioniert, doch dann bringt es auch nichts die PW_File zu verstecken!

          Du kannst auch für die definierten Benutzer ein Dropdown-Menü erzeugen - so
          etwas habe ich hier im Büro als Oberfläche für die eingetragenen Benutzer eines
          Webhosting-Produkts mal gebaut.

          Dropdown menü??? Wie denn das???

          Also fürs erste lieber Basic mit SSL-Verschlüsselung.

          Je nachdem. Für SSL brauchst Du wiederum ein Zertifikat ... und SSL im Web-
          server, mit entsprechender Konfiguration.

          Ja, das habe ich aber inzwischen - zum Glück!

          Digest Authentication käme mir wesentlich 'handlicher' vor. Und Mozilla 0.9.7
          kann es immerhin - mal sehen, wann der nächste Netscape heraus kommt ...

          Naja, nur damit würde ich 99,96 % der User ausschließen, klar kann ich die beeinflussen, aber das wäre dann doch zu exotisch, da ich nícht all den Leuten zumuten möchte einen anderen Browser zu verwenden.

          Gibt es eigentlich die Möglichkeit an Stelle des sich öffnenden Auth-Fensters
          eine .htaccess Authentifizierung in ein html-Formular einzubauen?
          Jetzt nur wegen der Optik!

          Das ist eine oft gestellte Frage. ;-)

          Im Prinzip besteht die Frage aus zwei Teilen:
          a) Kann ich das Verhalten des Browser beim Eintreffen einer Authentifizie-
             rungs-Anforderung beeinflussen?

          Wieso, macht das htaccess etwa? Ich dachte das wäre auch mit den Headern, serverseitig!

          b) Kann ich selbst präventiv eine Authentifizierung anhand von Formular-
             werten an den Server senden?
          Antwort: Im Prinzip würde das funktionieren. Von HTTP-Seite spricht jeden-
          falls nichts dagegen, schon beim ersten Zugriff auf eine geschützte Seite
          die "credentials" mitzusenden - Du mußt die Aufforderung zur Authentifi-
          zierung nicht erst provizieren.
          Das Problem ist aber, daß die Browserhersteller nicht wissen können, daß
          Du mit einem HTML-Formular etwas Anderes tun möchtest, als eine der Me-
          thoden zu verwenden, die es für Formulare nun mal gibt - also GET oder
          POST.
          Im Prinzip 'fehlt' hier ein Stückchen HTML-Definition, um dem Browser zu
          sagen, den Inhalt eines bestimmten Formular-Elements nicht in den Query-
          String oder den POST-Inhalt, sondern in den Authentication Header des
          HTTP-Requests zu stecken.

          Es ist nicht prinzipiell unmöglich - es gibt nur einfach keinen passenden
          HTML-Tag dafür, obwohl HTML mit seinen Formular-Tags über die Grenzen
          einer Dokumentstrukturbeschreibungssprache ansonsten weit hinaus geht
          und sich gerade mit den Formular-Methoden (ebenso wie mit den URLs) an
          die Vorgaben von HTTP bindet.
          HTML und HTTP sind in dieser Hinsicht nicht inhaltlich deckungsgleich.

          Nun ja, war ja nur so eine Idee!
          Aber danke für die interessante Antwort!

          Grüsse
            Andreas

          1. Hi,

            Yep. Kein guter Provider, das.
            Sehe ich genau so! Aber kann ich mir nicht immer aussuchen!

            Mit 5 Euro oder so sind Sie dabei. (Echt!)

            Aber das wäre ja noch einigermaßen sicher, da er ja da nur dran
            kommt, wenn htaccess eh nicht funktioniert, doch dann bringt es
            auch nichts die PW_File zu verstecken!

            Wenn Deine Seiten ungeschützt sind und Du das sofort wieder zunagelst,
            sind später hochgeladene Seiten wieder geschützt.
            Hat aber jemand Deine Passwortdatei gesaugt und in monatelanger Rechner-
            Arbeit per brute force geknackt, kommt er auch an Deine neuen Seiten ran.

            Du kannst auch für die definierten Benutzer ein Dropdown-Menü erzeugen - so
            etwas habe ich hier im Büro als Oberfläche für die eingetragenen Benutzer eines
            Webhosting-Produkts mal gebaut.
            Dropdown menü??? Wie denn das???

            http://selfhtml.teamone.de/html/formulare/auswahl.htm#listen

            Digest Authentication käme mir wesentlich 'handlicher' vor. Und Mozilla 0.9.7
            kann es immerhin - mal sehen, wann der nächste Netscape heraus kommt ...
            Naja, nur damit würde ich 99,96 % der User ausschließen,

            Aber nicht doch!
            Ich meinte: Von der Mozilla-Linie kann es der 0.9.7 (endlich), aber es kann auch
            Opera 4 und M$IE5 und Amaya.
            Du schließt also etwa 5% der Leute aus (nämlich diejenigen, die einen bereits
            existierenden Browser mit dem Namen Netscape haben, plus ein paar ganz abenteuer-
            liche Exoten).

            (Ich glaube, ich muß das hier noch ein paar hundert mal posten ...)

            Im Prinzip besteht die Frage aus zwei Teilen:
            a) Kann ich das Verhalten des Browser beim Eintreffen einer Authentifizie-
               rungs-Anforderung beeinflussen?
            Wieso, macht das htaccess etwa?
            Ich dachte das wäre auch mit den Headern, serverseitig!

            .htaccess "macht" gar nichts. Der Webserver macht das, was in seiner Konfiguration
            (inklusive .htaccess!) beschrieben ist: Er fragt den Browser. Und der fragt
            den Benutzer.
            Letzteres ist bei aller mir geläufigen Browsern nicht konfigurierbar, und es gibt
            auch keine Tags, um es zu von Seitenanbieterseite zu beeinflussen.

            Viele Grüße
                  Michael

            1. Hi!

              Yep. Kein guter Provider, das.
              Sehe ich genau so! Aber kann ich mir nicht immer aussuchen!

              Mit 5 Euro oder so sind Sie dabei. (Echt!)

              Schön wärs, 20m EUR bei Strato *stöhn*
              Zum Glück habe ich bis auf diese Sache alles da weg, war der mit Abstand schlechteste Provider bis jetzt!

              Wenn Deine Seiten ungeschützt sind und Du das sofort wieder zunagelst,
              sind später hochgeladene Seiten wieder geschützt.
              Hat aber jemand Deine Passwortdatei gesaugt und in monatelanger Rechner-
              Arbeit per brute force geknackt, kommt er auch an Deine neuen Seiten ran.

              Ich meine, wenn ich erst die htaccess hochlade, kommt keiner mehr an das Verzeichnis, ind dieses Verzeichnis dann die htpasswd, dann kommt da auch keine dran. Wenn da doch jemand egal wie dran kommt, ist htaccess sowieso Quatsch auf diesem Server!

              Du kannst auch für die definierten Benutzer ein Dropdown-Menü erzeugen - so
              etwas habe ich hier im Büro als Oberfläche für die eingetragenen Benutzer eines
              Webhosting-Produkts mal gebaut.
              Dropdown menü??? Wie denn das???

              http://selfhtml.teamone.de/html/formulare/auswahl.htm#listen

              Ja, das kannte ich wohl, aber unter dropdown verstehe ich irgendwie was anderes:
              Auch so ein Select-Field, dazwischen 2 Buttons und rechts ein leeres Select-Field. der eine Butten heißt hinzufügen der andere entfernen. Wenn ich jetzt links was auswähle und auf hinzufügen klicke, kommt der Wert in das rechte Select menü. Bei entfernen umgekehrt. Wie macht man denn sowas? Sieht mir sehr nach Javascript aus, oder?

              Naja, nur damit würde ich 99,96 % der User ausschließen,

              Aber nicht doch!
              Ich meinte: Von der Mozilla-Linie kann es der 0.9.7 (endlich), aber es kann auch
              Opera 4 und M$IE5 und Amaya.
              Du schließt also etwa 5% der Leute aus (nämlich diejenigen, die einen bereits
              existierenden Browser mit dem Namen Netscape haben, plus ein paar ganz abenteuer-
              liche Exoten).

              (Ich glaube, ich muß das hier noch ein paar hundert mal posten ...)

              Ich hatte das anders verstanden, im nach hinein ist es klar!
              Nur Leider ist der netscape Anteil immer noch zu groß, finde ich! Aber vielleicht kann man dann verlangen IE zu nutzen.
              Was passiert nochmal, wenn Netscape das trotzdem probiert?

              .htaccess "macht" gar nichts. Der Webserver macht das, was in seiner Konfiguration
              (inklusive .htaccess!) beschrieben ist: Er fragt den Browser. Und der fragt
              den Benutzer.
              Letzteres ist bei aller mir geläufigen Browsern nicht konfigurierbar, und es gibt
              auch keine Tags, um es zu von Seitenanbieterseite zu beeinflussen.

              Somit wäre das klar.

              Vielen Dank!

              mfg
                Andreas

              1. Hi Andreas,

                Yep. Kein guter Provider, das.
                Sehe ich genau so! Aber kann ich mir nicht immer aussuchen!
                Mit 5 Euro oder so sind Sie dabei. (Echt!)
                Schön wärs, 20m EUR bei Strato *stöhn*

                Selber schuld, wenn Du nicht wechselst ...

                Ich meine, wenn ich erst die htaccess hochlade, kommt keiner mehr
                an das Verzeichnis, ind dieses Verzeichnis dann die htpasswd, dann
                kommt da auch keine dran. Wenn da doch jemand egal wie dran kommt,
                ist htaccess sowieso Quatsch auf diesem Server!

                Richtig. Es geht nur um die Höhe des Schadens in diesem Fall.

                Auch so ein Select-Field, dazwischen 2 Buttons und rechts ein
                leeres Select-Field. der eine Butten heißt hinzufügen der andere
                entfernen. Wenn ich jetzt links was auswähle und auf hinzufügen
                klicke, kommt der Wert in das rechte Select menü. Bei entfernen
                umgekehrt. Wie macht man denn sowas? Sieht mir sehr nach Javascript
                aus, oder?

                Richtig. Du kannst mit DHTML den Inhalt des <select> dynamisch umschreiben.

                Nur Leider ist der netscape Anteil immer noch zu groß, finde ich!

                Ich weiß. Deshalb warte ich auf Mozilla 1.0 und Netscape 6.4 (?) - dann
                kann man den Netscape-Benutzern wirklich raten, ihren 4er wegzuwerfen.

                Was passiert nochmal, wenn Netscape das trotzdem probiert?

                Netscape schickt unerschütterlich Authentifizierungen mit AuthType Basic.
                Er kommt gar nicht auf die Idee, zu lesen, was der Webserver ihn fragt.
                Der Benutzer wird also immer wieder aufgefordert, sich auszuweisen.

                M$IE 4 (glaube ich mich zu erinnern) schaut wenigstens nach, was er tun
                soll, und gibt sofort auf.

                Vielen Dank!

                Gern geschehen.
                     Michael

  3. Hallo,

    gut, die .htaccess-basic authentification ist schon ziemlich sicher, jedoch auf unserem System werden sämtliche Daten per SSL (128bit) an den Server übertragen und dort wiederum verschlüsselt. Nun wird das ganze von einem php-scripts aus einer mysql-datenbank gelesen wird. Diese steckt wiederum hinter einer firewall so dass der Zugriff nur über den localhost stattfinden kann. Andere Möglichkeit ist den User per Linux/Unix Benutzername zu identifizieren.

    Gruß!