Abmelden bei Seiten mit BasicAuth (.htaccess-Passwort-Schutz)

[Tom]

Hello,

wie zuverlässig ist es eigentlich, ein "Logout" bei einem .htaccess-Passwort-Schutz (BaiscAuth) durch einen Link der Form

http://[e-mail]/protected_dir

vorzunehmen?

Wobei "logout" hier ein Username ist, den es in der Berechtigungsdatei nicht gibt.

Das Passwort wird hier ausdrücklich nicht mit übermittelt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

wie zuverlässig ist es eigentlich, ein "Logout" bei einem .htaccess-Passwort-Schutz (BaiscAuth) durch einen Link der Form

kleiner Nachtrag:

gemeint ist, wie zuverlässig vergessen die Browser das letzte eingebene erfolgreiche "User:Password"?

http://[e-mail]/protected_dir

vorzunehmen?

Wobei "logout" hier ein Username ist, den es in der Berechtigungsdatei nicht gibt.

Das Passwort wird hier ausdrücklich nicht mit übermittelt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[MudGuard]

Hi,

wie zuverlässig ist es eigentlich, ein "Logout" bei einem .htaccess-Passwort-Schutz (BaiscAuth) durch einen Link der Form http://[e-mail]/protected_dir vorzunehmen?

Ziemlich un-.

Es gibt Browser, die warnen bei derartig ungültigen URLs.
Und das dürfte einige User abhalten, weiterzumachen.

Und es gibt Browser, die ignorieren das in der Url befindliche Login-Zeug, und schlagen weiterhin die gespeicherten Auth-Daten vor.

Und Logout ist eh nicht möglich, da ja kein Login stattfindet.

cu,
Andreas

[Fred Furunkelstein 2011]

Ziemlich un-.

Ja.

Es gibt Browser, die warnen bei derartig ungültigen URL.

"Ungültig" im Sinne der RFC 2396 sind diese nicht. Viele Browser warnen aber weil Benutzerdaten übergeben werden. Da war ja mal die Geschichte von den Typen, die auf dem Wege Ihre Zugangsdaten mit Copy & Paste veröffentlichten: Ups.

Und das dürfte einige User abhalten, weiterzumachen.

Ja. Hoffentlich.

Und es gibt Browser, die ignorieren das in der Url befindliche Login-Zeug, und schlagen weiterhin die gespeicherten Auth-Daten vor.

Oder machen, vor allem in Zukunft alles Mögliche (un-)denkbare.

Fred

[MudGuard]

Hi,

Es gibt Browser, die warnen bei derartig ungültigen URL.

"Ungültig" im Sinne der RFC 2396 sind diese nicht.

2396 ist generisch, nicht http-spezifisch, und beschreibt alle Möglichkeiten, auch wenn diese in einzelnen Protokollen nicht möglich sind.

1738 sagt:
   An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.

2616 (also neuer als 1738/2396) sagt:

The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Da kommt kein <userinfo>@ drin vor.

cu,
Andreas

[Gunnar Bittersmann]

@@MudGuard:

nuqneH

2396 ist […]

vor allem: obsolet, Mr. MuseumGuard!

Qapla'

[A.]

Hi,

wie zuverlässig ist es eigentlich, ein "Logout" bei einem .htaccess-Passwort-Schutz (BaiscAuth) durch einen Link der Form

http://[e-mail]/protected_dir

leider nicht zuverlässig, da es Browser gibt (z.B. den Internet Explorer) die damit nicht umgehen wollen/können. Mit der Thematik habe ich mich auch lange Zeit befasst, bin aber noch zu keinem zufriedenstellenden Ergebnis gelangt. Ein recht interessanter Diskussionsbeitrag, der das Thema behandelt und auch eine Lösungsmöglichkeit aufzeigt, findet sich hier:

http://www.berenddeboer.net/rest/authentication.html

A.

[Tom]

Hello,

wie zuverlässig ist es eigentlich, ein "Logout" bei einem .htaccess-Passwort-Schutz (BaiscAuth) durch einen Link der Form

http://[e-mail]/protected_dir

leider nicht zuverlässig, da es Browser gibt (z.B. den Internet Explorer) die damit nicht umgehen wollen/können.

Ja, das habe ich heute Nacht leider auch noch festgestellt, nachdem ich wieder einen IE8 installiert hatte. Der Firefox macht es.

Mit der Thematik habe ich mich auch lange Zeit befasst, bin aber noch zu keinem zufriedenstellenden Ergebnis gelangt. Ein recht interessanter Diskussionsbeitrag, der das Thema behandelt und auch eine Lösungsmöglichkeit aufzeigt, findet sich hier:

http://www.berenddeboer.net/rest/authentication.html

Danke.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

http://[e-mail]/protected_dir
leider nicht zuverlässig, da es Browser gibt (z.B. den Internet Explorer) die damit nicht umgehen wollen/können.
Ja, das habe ich heute Nacht leider auch noch festgestellt, nachdem ich wieder einen IE8 installiert hatte. Der Firefox macht es.

dem Internet Explorer kann man es aber erlauben, wenn man das ausdrücklich möchte. Und das kann wünschenswert sein, um beispielsweise URLs mitsamt Anmeldedaten als Bookmark (aka Favoriten) zu hinterlegen.

Ciao,
 Martin

[Harlequin]

Yerf!

dem Internet Explorer kann man es aber erlauben, wenn man das ausdrücklich möchte. Und das kann wünschenswert sein, um beispielsweise URLs mitsamt Anmeldedaten als Bookmark (aka Favoriten) zu hinterlegen.

Öffnet das aber nicht wieder die Sicherheitslücke des IE zur Manipulation der URL-Anzeige? (oder ist das mittlerweile doch behoben?)

Gruß,

Harlequin

[Der Martin]

Hallo,

dem Internet Explorer kann man es aber erlauben, wenn man das ausdrücklich möchte. Und das kann wünschenswert sein, um beispielsweise URLs mitsamt Anmeldedaten als Bookmark (aka Favoriten) zu hinterlegen.
Öffnet das aber nicht wieder die Sicherheitslücke des IE zur Manipulation der URL-Anzeige? (oder ist das mittlerweile doch behoben?)

mir ist nicht klar, was für eine Manipulation du meinst. Beschreib mal genauer!

Ciao,
 Martin

[Harlequin]

Yerf!

mir ist nicht klar, was für eine Manipulation du meinst. Beschreib mal genauer!

Es gab da mal einen Bug mittels dessen es möglich war die URL-Anzeige zu beeinflussen. Das System war etwa so:

http://[e-mail]/evil.php

Durch bestimmte Steuerzeichen (chr(1) glaub ich) wurde die Anzeige ab diesem Zeichen unterdrückt, man hat nur den Anfang gesehen. Den Bug gab es in mehreren Browsern (FF und Opera waren auch betroffen) aber in allen außer dem IE wurde er gefixt. Beim IE hat man einfach die Übergabe von Benutzernamen deaktiviert...

Muss mal den Link noch raussuchen. Vor allem auch, welche IE Versionen jetzt alles betroffen sind.

Gruß,

Harlequin

[Der Martin]

Hallo,

mir ist nicht klar, was für eine Manipulation du meinst. Beschreib mal genauer!

Es gab da mal einen Bug mittels dessen es möglich war die URL-Anzeige zu beeinflussen. Das System war etwa so:
http://[e-mail]/evil.php
Durch bestimmte Steuerzeichen (chr(1) glaub ich) wurde die Anzeige ab diesem Zeichen unterdrückt, man hat nur den Anfang gesehen.

ah, ich erinnere mich dunkel. Stimmt, da war mal was.

Den Bug gab es in mehreren Browsern (FF und Opera waren auch betroffen) aber in allen außer dem IE wurde er gefixt.

Tatsächlich? Ich meine mich zu erinnern, dass er im IE auch repariert wurde. Ich sitze aber gerade am PC mit den Alt-Browsern (IE5.5, Opera8, FF3) und kann das Verhalten nur für diese Veteranen verifizieren.
In einem Testdokument habe ich diesen Link:

<a href="http://example.org/\x01@localhost">Follow me</a>

Dabei soll \x01 das Steuerzeichen mit dem Code 1 in C-Notation darstellen. Opera und Firefox zeigen das Linkziel beim Draufzeigen als "http://example.org/%01@localhost" in der Statuszeile an, IE als "http://example.org/ @localhost". Okay, im IE sieht das Steuerzeichen wie Whitespace aus, davon abgesehen ist bis hierher aber noch alles okay.
Klicke ich diesen Link nun an, versuchen alle drei Testbrowser, http://example.org/ anzuzeigen, scheinen also alles nach dem \x01 zu ignorieren. Ich finde, das ist zwar ein falsches, aber absolut gutmütiges Verhalten, denn es wird genau das Ziel aufgerufen, das der flüchtige Beobachter auch zu sehen glaubt.

Beim IE hat man einfach die Übergabe von Benutzernamen deaktiviert...

Und ich meinte "repariert", nicht "unterdrückt". ;-)

Muss mal den Link noch raussuchen. Vor allem auch, welche IE Versionen jetzt alles betroffen sind.

Ja, würde mich auch nochmal interessieren.

Ciao,
 Martin

[Harlequin]

Yerf!

Muss mal den Link noch raussuchen. Vor allem auch, welche IE Versionen jetzt alles betroffen sind.

Ja, würde mich auch nochmal interessieren.

Ich hab bisher nur das gefunden: http://www.heise.de/newsticker/meldung/Gefaelschte-URLs-im-Internet-Explorer-Update-90003.html

Demnach waren nur IE6 und "manche" 5er betroffen.

Gruß,

Harlequin

[Tom]

Hello,

Mit der Thematik habe ich mich auch lange Zeit befasst, bin aber noch zu keinem zufriedenstellenden Ergebnis gelangt. Ein recht interessanter Diskussionsbeitrag, der das Thema behandelt und auch eine Lösungsmöglichkeit aufzeigt, findet sich hier:

http://www.berenddeboer.net/rest/authentication.html

Dann ist es doch eigentlich immer noch ein Manquo der Browser. Man müsste also die Anforderungen an die Browser neu definieren. Die müssen einen Button bekommen "Diese Seite ohne Authentifizierung aufrufen", der erscheint, wenn man eine Authentifizierung eingegeben hat und der Browser meint, diese nun mitsenden zu müssen.

Ich habe sonst immer zwangsweise einen 401 geschickt auf

http://example.com/?logout

Funktioniert aber auch nicht sicher
Das ist ja auch so ähnlich in dem Beitrag beshrieben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

noch eine Frage zu Auth-Basic und den Passwortfiles dafür:

Kann mir jemand sagen, ob ich die Passwordfiles wie nachfolgend gezeigt verändern darf?

tom:S4ga/NwOmS2U2:20111121-1226:master
heinz:QZdYu3Ui0Tycc:20111120-1200
markus:qTeSHT0OsSxXs:20111120-1200
regina:Y4pNW6dTxPM5E:20111120-1200
silvia:2qxB3.yhqsNRE:20111120-1200
jens:4ui9KVIpwK6Kk:20111120-1200
reiner:GSWjW2oRh9fgk:20111119-1000:trustie:tom

Es funktioniert auf einem Debian-Linux 5 einwandfrei. Ein anderes habe ich im Moment zum Spielen  nicht zur Verfügung...

Aber wo kann ich darüber nachlesen, ob die Routinen von htaccess das verkraften?

Außerdem habe ich noch nicht ausprobiert, was htpasswd dazu sagt und wie das File aussieht, wenn man mit htpasswd Änderungen/Ergänzungen durchführt...

Ich bearbeite die Files mit einem PHP-Script und dafür könnte ich gut noch die zusätzlichen Daten gebrauchen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Es funktioniert auf einem Debian-Linux 5 einwandfrei. Ein anderes habe ich im Moment zum Spielen  nicht zur Verfügung...

alle ausprobierten Änderungen/Ergänzungen mit htpasswd lassen die ergänzten Zeilen auch vollständig erhalten, mit Ausnahme der Löschung eines Users selbstverständlich...

Wo ich etwas über Aufbau, Verhalten und Vorgaben zur Funktionsgruppe nachlesen kann, habe ich leider immer noch nicht gefunden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

tom:S4ga/NwOmS2U2:20111121-1226:master
heinz:QZdYu3Ui0Tycc:20111120-1200
markus:qTeSHT0OsSxXs:20111120-1200
regina:Y4pNW6dTxPM5E:20111120-1200
silvia:2qxB3.yhqsNRE:20111120-1200
jens:4ui9KVIpwK6Kk:20111120-1200
reiner:GSWjW2oRh9fgk:20111119-1000:trustie:tom

Gibts einen Grund dafür, dass du noch das alte crypt() für die Passworte verwendest? Das schneidet das Passwort nach 8 Zeichen ab, alle weiteren sind irrelevant - das ist unsicher. MD5 ist auf allen Plattformen der Standard für Passworte, wenn man htpasswd verwendet - crypt-Hashes zu erzeugen wäre extra-aufwendig.

Abgesehen davon wäre zu eruieren, was diese Zusatzangaben denn bedeuten sollen, und ob es dafür nicht einen besseren Platz gibt. Eine Textdatei ist ja nicht das einzige Format, was der Apache als Userdatenbank erlaubt.

- Sven Rautenberg

[Tom]

Hello,

tom:S4ga/NwOmS2U2:20111121-1226:master
heinz:QZdYu3Ui0Tycc:20111120-1200
markus:qTeSHT0OsSxXs:20111120-1200
regina:Y4pNW6dTxPM5E:20111120-1200
silvia:2qxB3.yhqsNRE:20111120-1200
jens:4ui9KVIpwK6Kk:20111120-1200
reiner:GSWjW2oRh9fgk:20111119-1000:trustie:tom

Gibts einen Grund dafür, dass du noch das alte crypt() für die Passworte verwendest? Das schneidet das Passwort nach 8 Zeichen ab, alle weiteren sind irrelevant - das ist unsicher. MD5 ist auf allen Plattformen der Standard für Passworte, wenn man htpasswd verwendet - crypt-Hashes zu erzeugen wäre extra-aufwendig.

Abgesehen davon wäre zu eruieren, was diese Zusatzangaben denn bedeuten sollen, und ob es dafür nicht einen besseren Platz gibt. Eine Textdatei ist ja nicht das einzige Format, was der Apache als Userdatenbank erlaubt.

Das wäre für meine persönlichen Anwendungsfälle sicherlich eine überlegenswerte Alternative.

Ich suche allerdings nach einer Möglichkeit, das allgemein nutzbar zu machen und bisher ist mir noch kein Server untergekommen, der etwas anderes als Crypt einsetzt. Seit wann und bei welchen Providern sind denn andere (bessere) Methoden im Einsatz?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Das wäre für meine persönlichen Anwendungsfälle sicherlich eine überlegenswerte Alternative.

Ich suche allerdings nach einer Möglichkeit, das allgemein nutzbar zu machen und bisher ist mir noch kein Server untergekommen, der etwas anderes als Crypt einsetzt. Seit wann und bei welchen Providern sind denn andere (bessere) Methoden im Einsatz?

MD5 ist allgemein einsetzbar. SHA1 ist allgemein einsetzbar.

Crypt ist NICHT allgemein einsetzbar. Windows-Apaches unterstützen das nicht.

- Sven Rautenberg

[Tom]

Hello Chris, hallo Sven,

Ich suche allerdings nach einer Möglichkeit, das allgemein nutzbar zu machen und bisher ist mir noch kein Server untergekommen, der etwas anderes als Crypt einsetzt. Seit wann und bei welchen Providern sind denn andere (bessere) Methoden im Einsatz?

MD5 ist allgemein einsetzbar. SHA1 ist allgemein einsetzbar.

Crypt ist NICHT allgemein einsetzbar. Windows-Apaches unterstützen das nicht.

Danke für die Info. Dann muss ich da auf jeden Fall nochmal ran.

Kann man denn irgendwie (möglichst mit dem PHP-Programm) abfragen, mit welcher Methode der Apache gerade arbeitet?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

MD5 ist allgemein einsetzbar. SHA1 ist allgemein einsetzbar.
Crypt ist NICHT allgemein einsetzbar. Windows-Apaches unterstützen das nicht.
Kann man denn irgendwie (möglichst mit dem PHP-Programm) abfragen, mit welcher Methode der Apache gerade arbeitet?

Nimm einfach SHA1 oder MD5, der Apache erkennt das von selbst.

htpasswd encrypts passwords using either a version of MD5 modified for Apache, or the system's crypt() routine. Files managed by htpasswd may contain both types of passwords; some user records may have MD5-encrypted passwords while others in the same file may have passwords encrypted with crypt().

dedlfix.

[Tom]

Hello Hi Lo,

MD5 ist allgemein einsetzbar. SHA1 ist allgemein einsetzbar.
Crypt ist NICHT allgemein einsetzbar. Windows-Apaches unterstützen das nicht.
Kann man denn irgendwie (möglichst mit dem PHP-Programm) abfragen, mit welcher Methode der Apache gerade arbeitet?

Nimm einfach SHA1 oder MD5, der Apache erkennt das von selbst.

Interessanter Aspekt. Das muss ich doch näher untersuchen...

htpasswd encrypts passwords using either a version of MD5 modified for Apache, or the system's crypt() routine. Files managed by htpasswd may contain both types of passwords; some user records may have MD5-encrypted passwords while others in the same file may have passwords encrypted with crypt().

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Nimm einfach SHA1 oder MD5, der Apache erkennt das von selbst.
Interessanter Aspekt. Das muss ich doch näher untersuchen...

Ist ja nicht schwer, man kann das (nebst Crypt) an der Länge unterscheiden.

dedlfix.

[ChrisB]

Hi,

Ich suche allerdings nach einer Möglichkeit, das allgemein nutzbar zu machen und bisher ist mir noch kein Server untergekommen, der etwas anderes als Crypt einsetzt. Seit wann und bei welchen Providern sind denn andere (bessere) Methoden im Einsatz?

http://httpd.apache.org/docs/2.2/en/programs/htpasswd.html, Options:
-m
    Use MD5 encryption for passwords. This is the default.

Unter 2.0 sah das noch anders aus, siehe http://httpd.apache.org/docs/2.0/en/programs/htpasswd.html

MfG ChrisB