Du bist nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: WebStyleBoard. Falls dies dein erster Besuch auf dieser Seite ist, lies bitte die Hilfe durch. Dort wird dir die Bedienung dieser Seite näher erläutert. Darüber hinaus solltest du dich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutze das Registrierungsformular, um dich zu registrieren oder informiere dich ausführlich über den Registrierungsvorgang. Falls du dich bereits zu einem früheren Zeitpunkt registriert hast, kannst du dich hier anmelden.

1

Dienstag, 25. Januar 2005, 21:42

htacess in ein Formular

Hallo mal wieder,
ihr kennt ja sicher diese netten htaccess Fenster für Benutzername und Passwort. Nu8n möchte ich diese in einem HTML-Formular umsetzen. Was muss ich dabei beachten, Wie lauten Variablen für die Formular-Felder etc.?

Vielen dank schon einmal!
Signatur von »ARESOL« wieder da

2

Dienstag, 25. Januar 2005, 22:12

Meinst Du damit, dass Du anstelle eines Popup-Fensters für die Eingabe von Benutzername und Passwort lieber ein HTML-Formular für das Login hättest?

Dann brauchst Du eine Benutzerverwaltung. Ein paar Zeilen in .htaccess reichen dafür nicht aus.

Ich empfehle Dir für die weitere Lektüre mr_happiness' Tutorial für eine Benutzerverwaltung aus der WSB.Beitragsreihe...
Signatur von »LapisInfernalis« Eine Milde Gabe...

Der Horizont vieler Menschen ist ein Kreis mit dem Radius Null - und das nennen sie ihren Standpunkt.

Albert Einstein (1879-1955)

A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
Douglas Adams (1952-2001)

3

Dienstag, 25. Januar 2005, 22:21

ja das meine ich, das Problem ist, das ich keine Benutzerverwaltung führen kann. Dieses Login-Formular soll für das Webinterface meines Providers sein, also für´s Webmail.
Signatur von »ARESOL« wieder da

4

Dienstag, 25. Januar 2005, 23:20

Du könntest per Java-Script die Benutzerdaten übermittelt..

2 Formulardaten und dann auf den Link umleiten

http://$benuzername:$passwort@deine-seite.de/ein/dir/

Tobias
Signatur von »t-ob-i« {SIGNATUR}

5

Mittwoch, 26. Januar 2005, 13:47

Zitat von »t-ob-i«

Du könntest per Java-Script die Benutzerdaten übermittelt..

2 Formulardaten und dann auf den Link umleiten

http://$benuzername:$passwort@deine-seite.de/ein/dir/

Tobias

Ach ja, kleiner Tipp: Das ist total unsicher... der Browser speichert das Passwort dann in der History und übermittelt es ohne jede Verschlüsselung...
Signatur von »Alex« Man muss nichts sehen, um zu sehen, dass man nichts sieht, aber man muss etwas sehen, um zu sehen, was man nicht sieht.

6

Mittwoch, 26. Januar 2005, 13:59

Zitat von »Alex«

Zitat von »t-ob-i«

Du könntest per Java-Script die Benutzerdaten übermittelt..

2 Formulardaten und dann auf den Link umleiten

http://$benuzername:$passwort@deine-seite.de/ein/dir/

Tobias

Ach ja, kleiner Tipp: Das ist total unsicher... der Browser speichert das Passwort dann in der History und übermittelt es ohne jede Verschlüsselung...


Icn wusste das ich etwas wichtiges vergessen hatte :)

Tobias
Signatur von »t-ob-i« {SIGNATUR}

7

Mittwoch, 26. Januar 2005, 14:00

Zitat von »Alex«

Das ist total unsicher... der Browser [...] übermittelt es ohne jede Verschlüsselung...
Macht er das nicht immer?
Oder kennst du Seiten, die nicht Basic sondern Digest verwenden und gefahr laufen, die Minderheit der IE-Nutzer auszugrenzen?
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

8

Donnerstag, 27. Januar 2005, 17:11

Zitat von »mr_happiness«

Zitat von »Alex«

Das ist total unsicher... der Browser [...] übermittelt es ohne jede Verschlüsselung...
Macht er das nicht immer?
Oder kennst du Seiten, die nicht Basic sondern Digest verwenden und gefahr laufen, die Minderheit der IE-Nutzer auszugrenzen?

Ich kenne z.B. den NetCologne OnlineService - der verwendet https und ASP...
Signatur von »Alex« Man muss nichts sehen, um zu sehen, dass man nichts sieht, aber man muss etwas sehen, um zu sehen, was man nicht sieht.

9

Donnerstag, 27. Januar 2005, 18:32

Der Unsicherheitsfaktor kommt im Wesentlichen durchs Speichern in der History zustande... sodass die neugierige Schwester evtl. auch mal diverse Dinge machen kann, die der große Bruder immer so treibt! ;)
Rest-Unsicherheiten bleiben immer solange man halt nicht auf ssl bzw. ipsec zurückgreift... und auch dort... nein ;) - dort gibt es bei der Verwendung der richtigen Verschlüsselungsalgorithmen keine Unsicherheit ;)
Signatur von »Snoop« The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 (11.05.1930 - 07.08.2002)

10

Donnerstag, 27. Januar 2005, 19:46

Zitat von »Snoop«

dort gibt es bei der Verwendung der richtigen Verschlüsselungsalgorithmen keine Unsicherheit ;)
Jep. Sicher wären wohl Quantenkryptographie und One-Time-Pad... :D
Signatur von »Alex« Man muss nichts sehen, um zu sehen, dass man nichts sieht, aber man muss etwas sehen, um zu sehen, was man nicht sieht.

11

Freitag, 28. Januar 2005, 08:14

Zitat von »Alex«

Zitat von »mr_happiness«

Zitat von »Alex«

Das ist total unsicher... der Browser [...] übermittelt es ohne jede Verschlüsselung...
Macht er das nicht immer?
Oder kennst du Seiten, die nicht Basic sondern Digest verwenden und gefahr laufen, die Minderheit der IE-Nutzer auszugrenzen?

Ich kenne z.B. den NetCologne OnlineService - der verwendet https und ASP...
Was beides nicht direkt mit .htaccess zu tun hat, ASP sogar noch nichtmal indirekt

Bei https wird das laut Einstellung in der .htaccess verlangte Passwort verschlüsselt übertragen, aber aufgrund des "s" in http"s"

Ich meinte, dass das Passwort auch ohne dieses "s" verschlüsselt übertragen wird, aber nur dann, wenn in der .htaccess als AuthType Digest und nicht Basic steht.
Basic ist Standard, Digest wird nicht von allen (IE kann's nicht afair) unterstützt.

https und Basic:
Aufgrund von https wird Passwort "test" zu "abc" (Client)
Aufgrund von https wird "abc" wieder zu "Test" (Server)

http und Digest:
Browser verschlüsselt Passwort "test" zu "xyz"
Server entschlüsselt der Webserver "xyz" zu "test"

Du hast 4 Kombinationsmöglichkeiten und nur bei einer einzigen, nämlich dem Standard, der in den meisten Fällen eingesetzt werden dürfte, da https Geld kostet und Digest von wichtigen Browsern nicht unterstützt wird, wird das Passwort immer, bei jeder Anfrage, als Klartext übermittelt
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

12

Freitag, 28. Januar 2005, 08:37

[ot]
Och ich würde sogar sagen, dass ohne mathematischen Durchbruch in der nächsten Zeit auch TripleDES noch gut 10 Jahre halten wird... man muss ja immer gucken was da praktisch machbar ist. Denn bei einem Webshop ist es sehr unwahrscheinlich, dass irgendjemand einen Krypto-Angriff startet, der erfordert, dass mehrere Millionen Rechner als Verteiltes System parallel den Schlüssel versuchen zu brechen ;)
Wenn das dann nicht mehr reicht, kann man ja auch noch auf AES zurückgreifen...
[/ot]
Signatur von »Snoop« The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 (11.05.1930 - 07.08.2002)

13

Freitag, 28. Januar 2005, 13:48

Dürfte man erfahren, warum https:// Geld kostet? Davon hab ich ja noch nie gehört...
Signatur von »Alex« Man muss nichts sehen, um zu sehen, dass man nichts sieht, aber man muss etwas sehen, um zu sehen, was man nicht sieht.

14

Freitag, 28. Januar 2005, 13:53

Das Zertifikat bekommst du nicht geschenkt und du musst es hin und wieder auch erneuern lassen.

Oder würdest du etwas bei einem Shop kaufen, dessel Zertifikat abgelaufen ist?
Ich nicht, und ich bekomme es mit, weil mein Browser mich darauf hinweist
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »mrhappiness« (28. Januar 2005, 13:54)


15

Freitag, 28. Januar 2005, 13:54

Authentifizierung über .htaccess mit HTTPS

Mich würde sehr interessieren, wie diese Authentifizierung per .htaccess technisch überhaupt abläuft. Ich habe da schon mal im Apache-Manual nachgeschlagen, aber nichts vernünftiges gefunden. :( Sendet der Browser bei jeder Anfrage an ein so geschütztes Verzeichnis das Passwort und den Benutzernamen erneut?
Wie und warum ist HTTPs sicherer? (ok, ich kann mir wohl vorstellen, dass das "s" für secure steht und irgendetwas mit SSL zu tun hat, aber wie geht das genau?)
Und zu guter letzt (schreibt man das so?): Wie muss eine .htaccess-Datei aussehen für eine Authentifizierung über HTTPs ?
Für Basic ist es ja klar, das steht u.a. bei SELFHTML.
Muss man einfach statt

Quellcode

1
AuthType Basic

Quellcode

1
AuthType SSL
schreiben?
Signatur von »MyWege« Achtung, Bildung!
Welch ein Meisterwerk ist der Mensch! Wie edel durch Vernunft! Wie unbegrenzt an Fähigkeiten! [...] Im Begreifen wie ähnlich einem Gott! Und doch, was ist mir diese Quintessenz von Staube? Ich habe keine Lust am Manne.
Hamlet

16

Freitag, 28. Januar 2005, 14:01

RE: Authentifizierung über .htaccess mit HTTPS

Zitat von »MyWege«

Sendet der Browser bei jeder Anfrage an ein so geschütztes Verzeichnis das Passwort und den Benutzernamen erneut?
Ja

Zitat

Wie und warum ist HTTPs sicherer? (ok, ich kann mir wohl vorstellen, dass das "s" für secure steht und irgendetwas mit SSL zu tun hat, aber wie geht das genau?)
https ist insofern sicherer, als die gesamte Kommunikation verschlüsselt abläuft.
Such mal bei wikipedia nach https und/oder iso-osi

Ganz kurz und knapp:
https ist http mit SSL verschlüsselt

Zitat

Und zu guter letzt (schreibt man das so?): Wie muss eine .htaccess-Datei aussehen für eine Authentifizierung über HTTPs ?
Für Basic ist es ja klar, das steht u.a. bei SELFHTML.
Muss man einfach statt

Quellcode

1
AuthType Basic

Quellcode

1
AuthType SSL
schreiben?
Nein, so geht das nicht

Die SSL-Verschlüsselung ist "tiefer" angesiedelt als das http, was in der .htaccess steht ist aber auf http bezogen. Da gibt es Basic und Digest, kein SSL.

Basic heißt, dass die Daten im Klartext übertragen werden
Digest heißt, dass die Daten verschlüsselt übertragen werden.
Das ist aber völlig unabhängig von einer eventuell erfolgten, transparenten Verschlüsselung mit SSL ein paar Ebenen tiefer.
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...