nicht angemeldet
Provider unterstützt .htaccess nicht, wer kennt Alternative?
Hallo,
ich habe versucht per .htaccess einen Passwortschutz zu realisieren, sodass ich einen Teil meiner Seiten per Passwortschutz sichern kann. Leider konnte mein Provider (T-Online Business HP) mir nicht den erforderlichen Pfad nennen sondern eröffnete mir, dass .htaccess noch nicht unterstützt wird.
Nun die Frage: Gibt es eine andere einigermaßen zuverlässige Alternative bestimmte Bereiche per Passworteingabe zu schützen?
Javascript wäre denkbar, da die Inhalte nicht hochbrisant sind!
Ich dachte hier vielleicht an einen Zugangsschutz per JScript und gekoppelt an diesen eine Sperrung der rechten Maustaste um den Quelltext zu sperren?!
Habe ich dank SelfHTML auch schon ein wenig hingekriegt, habe aber hier noch das Problem, dass bei fehlerhafte Eingabe des Passwortes keine erneute Eingabeaufforderung erscheint!
Hier der Quelltext:
<html>
<head>
<script language="JavaScript">
<!--
var Passwort = "test";
var Eingabe = window.prompt("Bitte geben Sie das Passwort ein","");
if(Eingabe != Passwort)
{alert("Falsches Passwort!");
}
else
{
document.location.href="geheim.htm";
}
// -->
</script>
</head>
</html>
CGI wird vom Provider unterstützt! Leider kenne ich mich da wenig aus.
Kann mir jemand helfen, ich bin für jede alternative Abfrageform dankbar!
Viele Grüße, Jens.
-
Hi,
Nun die Frage: Gibt es eine andere einigermaßen zuverlässige Alternative bestimmte Bereiche per Passworteingabe zu schützen?
aber sicher doch. Die Zahl der alternativen Provider ist immens, such Dir einfach einen aus, der Deinen Ansprüchen genügt.
Javascript wäre denkbar,
Nein. Eine Alternative zu einem serverseitigen Schutzmechanismus (ob noch Basic/Digest Authentication oder ein gutes CGI-, PHP- oder ähnliches Script) existiert nicht.
da die Inhalte nicht hochbrisant sind!
Ein schwacher Schutz ist identisch mit gar keinem Schutz. Wenn es nicht wirklich drauf ankommt, dann lass es einfach bleiben.
Ich dachte hier vielleicht an einen Zugangsschutz per JScript und gekoppelt an diesen eine Sperrung der rechten Maustaste um den Quelltext zu sperren?!
Beides kann von Anfängern leicht umgangen werden.
var Passwort = "test";
Das ist für _jeden_ im Klartext lesbar.
document.location.href="geheim.htm";
location ist ein Unterobjekt von window, nicht von document.
CGI wird vom Provider unterstützt! Leider kenne ich mich da wenig aus.
Dann kommt ein CGI-basierter Schutzmechanismus für Dich nicht in Frage. Wenn die Implementierung (wie bei Authentication) nicht klar und sicher ist, ist sie nutzfrei, solange der Nutzer (also Du) nicht hinreichende Kenntnisse sowohl über die Implementierung an sich als auch über Sicherheit hat.
Suche Dir einen Provider, der Deine Wünsche erfüllt.
Cheatah
-
Hallo Jens!
Nun die Frage: Gibt es eine andere einigermaßen zuverlässige Alternative bestimmte Bereiche per Passworteingabe zu schützen?
aber sicher doch. Die Zahl der alternativen Provider ist immens, such Dir einfach einen aus, der Deinen Ansprüchen genügt.
Dem kann ich nur zustimmen. Die paar Euro pro Monat sollte einem die Verfügbarmachung der eigenen Arbeit schon wert sein - oder hältst du so wenig von deinen Seiten?
Javascript wäre denkbar,
Nein. Eine Alternative zu einem serverseitigen Schutzmechanismus (ob noch Basic/Digest Authentication oder ein gutes CGI-, PHP- oder ähnliches Script) existiert nicht.
Das ist, im Wortlaut der Frage sicher richtig, im Sinne der Anwendung geht das mit Javascript IMHO aber dennoch:
Die Seite wird verschlüsselt in einem String gespeichert, mit dem Passwort als Schlüssel entschlüsselt und dann per document.write ausgegeben.Das schützt natürlich keine Bereiche sondern genau eine Seite und dort auch nur den (HTML)Text, setzt JavaScript vorraus, wenn man mehrere Seiten so schützen muss man das Passwort pfrimelig über Frame-Konstrukte oder window.name durchreichen etc.
Aber für Mitglieder/Telefonlisten von Vereinen oder vergleichbares sollte das IMHO eine akzeptable Lösung sein.Gruss,
Carsten-
Hi,
Das schützt natürlich keine Bereiche sondern genau eine Seite und dort auch nur den (HTML)Text, setzt JavaScript vorraus, wenn man mehrere Seiten so schützen muss man das Passwort pfrimelig über Frame-Konstrukte oder window.name durchreichen etc.
und vor allem hat es mit einem Schutz nichts zu tun, sondern höchstens mit einer Erschwernis.
Aber für Mitglieder/Telefonlisten von Vereinen oder vergleichbares sollte das IMHO eine akzeptable Lösung sein.
Nur dann, wenn es nichts ausmacht, den vermuteten Schutz auch völlig wegzulassen. Ein schwacher Schutz ist kein Schutz.
Cheatah
-
Hi Cheatah,
Das schützt natürlich keine Bereiche sondern genau eine Seite und dort auch nur den (HTML)Text, setzt JavaScript vorraus, wenn man mehrere Seiten so schützen muss man das Passwort pfrimelig über Frame-Konstrukte oder window.name durchreichen etc.
und vor allem hat es mit einem Schutz nichts zu tun, sondern höchstens mit einer Erschwernis.
Wenn du z.b. Blowfish mit 120bit Schlüssel als Erschwernis bezeichnen möchtest dann ja.
Aber für Mitglieder/Telefonlisten von Vereinen oder vergleichbares sollte das IMHO eine akzeptable Lösung sein.
Nur dann, wenn es nichts ausmacht, den vermuteten Schutz auch völlig wegzulassen. Ein schwacher Schutz ist kein Schutz.
Sorry, aber ich denke du hast das Verfahren nicht verstanden:
Symmetrische Verschlüsselung nach Wahl, Decoder in Javascript implementiert, zusammen mit dem verschlüsselten Inhalt ausgeliefert. Der Schlüssel wird per Hashverfahren aus dem Passwort generiert. Bei 20 Zeichen langen Passwörtern bekommt man etwa 120 (brauchbare) bit lange Schlüssel, die noch nicht mal übers Netz gesendet werden.
Gruss,
Carsten-
Hi,
und vor allem hat es mit einem Schutz nichts zu tun, sondern höchstens mit einer Erschwernis.
Wenn du z.b. Blowfish mit 120bit Schlüssel als Erschwernis bezeichnen möchtest dann ja.wenn es sich um eine clientseitige Verschlüsselung handelt, wird der Dekodierungs-Algorithmus mitgeliefert. Ergo ist es nicht das geringste Problem, den unkodierten Code zu erhalten.
Zudem haben solche Verfahren _immer_ den Nachteil, dass sie bei bis zu ca. 20% der User (je nach Komplexität sogar mehr, weil neueste JavaScript-Versionen vorausgesetzt werden) nicht funktionieren, weil diese kein JavaScript aktiviert haben wollen, dürfen oder können. Welchen Sinn hat das?
Cheatah
-
Hallo Cheatah!
und vor allem hat es mit einem Schutz nichts zu tun, sondern höchstens mit einer Erschwernis.
Wenn du z.b. Blowfish mit 120bit Schlüssel als Erschwernis bezeichnen möchtest dann ja.wenn es sich um eine clientseitige Verschlüsselung handelt, wird der Dekodierungs-Algorithmus mitgeliefert. Ergo ist es nicht das geringste Problem, den unkodierten Code zu erhalten.
Falsch.
Ohne Kenntnisss des Schlüssels ist es ein Problem den Inhalt der Seite zu erhalten.Und der wird bei dem von mir beschriebenen Verfahren niemals übers Netz übertragen.
Zudem haben solche Verfahren _immer_ den Nachteil,
Ich weiss das du die Methode nicht magst. Ich habe in meinem Posting
</?m=135206&t=24550> auch ausdrücklich auf die notwendigen Vorraussetzungen hingewiesen. Das hat aber nichts mit der Sicherheit des Verfahrens zu tun.Gruss,
CarstenP.S.
Kurzes Beispiel:<script>
cipher="hh{,qfk+bkt*gl{~$id!ezi%cagie*ml`ij,rl}o"
key = prompt("Geben Sie Ihr Passwort fuer diese Seite ein","");
res="";
for(i=0;i<cipher.length;i++)
res+=String.fromCharCode((key.charCodeAt(i)&0x3f)^cipher.charCodeAt(i));
document.write(res);
</script>Den ganzen Schnickschnack mit krypto Verfahren und dem Hash habe ich aus Längengründen mal weggelassen, das ändert aber nichts am Prinzip: Ohne Passwort kommst du nicht an den Inhalt!
-
-
-
-
-
-
Hallo,
ich habe versucht per .htaccess einen Passwortschutz zu realisieren, sodass ich einen Teil meiner Seiten per Passwortschutz sichern kann. Leider konnte mein Provider (T-Online Business HP) mir nicht den erforderlichen Pfad nennen sondern eröffnete mir, dass .htaccess noch nicht unterstützt wird.
Nun die Frage: Gibt es eine andere einigermaßen zuverlässige Alternative bestimmte Bereiche per Passworteingabe zu schützen?
Ja - es gibt zig Provider, die das anbieten.
Also wechsle den Provider!Andreas
-
Hi Jens,
sondern eröffnete mir, dass .htaccess noch nicht
unterstützt wird.streiche "noch". Ich bezweifele, daß ein Massen-Provider wie T-Offline so etwas jemals freischalten wird.
Von "Unterstützen" kann ja nur insofern die Rede sein, als daß das Verbot der Verwendung aus der Webserver-Konfiguration entfernt würde ... das aber würde bedeuten, daß der Provider
a) begreifen müßte, was er da tut,
b) den Rest seines Servers so konfigurieren müßte, daß er keine Sicherheitslücken öffnet, wenn er Anwendern wie Dir erlaubt, die Server-Konfiguration zu beeinflussen (denn _das_ ist die Funktion von .htaccess) und
c) gewillt sein muß, damit zu leben, daß sein Server dadurch langsamer wird, weil er bei jedem Zugriff die gesamte Dateisystem-Hierarchie von Deinem Dokument-Ablageort bis zur Wurzel nach .htaccess-Dateien durchsuchen, diese einlesen und ihren Inhalt semantisch überlagern müßte.T-Offline-Webspace ist m. E. kostenlos - und Du weißt doch: You get what you pay for.
Viele Grüße
Michael