wie sicher ist das jetzt nun ?
xNeTworKx
- perl
Hallo,
ich hab unlängst hier gefragt, wie sicher eine Passwortabfrage mit Perl ist. Nun wollt ich nochmal sicherstellen, ob so eine Passwortabfrage mit Perl nach dem Prinzip
my $passwort = $query->param('passwort');
if ($passwort eq 'passwort') {
#mach dies und das
}
wirklich 100 % sicher ist ?
Ich würd gern wissen, ob jemand da reinkommt.
hi!
ich hab unlängst hier gefragt, wie sicher eine Passwortabfrage mit
Perl ist. Nun wollt ich nochmal sicherstellen, ob so eine
Passwortabfrage mit Perl nach dem Prinzip
my $passwort = $query->param('passwort');
if ($passwort eq 'passwort') {
#mach dies und das
}
wirklich 100 % sicher ist ?
Nichts ist 100%-ig sicher! In deinem Fall wird sogar das Passwort im
Klartext über's Internet gejagt, kann also auf jedem Rechner, über den
das Paket mit dem Passwort läuft, abgefangen werden.
Falls dein Skript die GET-Methode statt der POST-Methode verwendet,
landet das Passwort zusätzlich noch im Logfile des Providers.
Und wenn du schonmal gefragt hast, wieso wiederholst du deine Frage
jetzt nochmal?
bye, Frank!
Hallo,
Klartext über's Internet gejagt, kann also auf jedem Rechner, über den
das Paket mit dem Passwort läuft, abgefangen werden.
Falls dein Skript die GET-Methode statt der POST-Methode verwendet,
landet das Passwort zusätzlich noch im Logfile des Providers.
Was is da gemeint mit kann uaf jedem Rechner abgefangen werden, und warum is es nicht dekodiert, ich verwende doch CGI.pm ?
Mein Script läuft mit 'post' .
Was ich noch dazu sagen möchte is, daß das Script sehr viele verschiedene Funktionen hat, also ich muss bei jedem Aufruf mit einer anderen Variable, das Passwort als Variable auch mitschicken, weil ich sonst bei jedem neuen Aufruf das Passwort eigeben müsste. landet es dadurch auch im Logfile des Providers ?
Mosche
Klartext über's Internet gejagt, kann also auf jedem Rechner, über den
das Paket mit dem Passwort läuft, abgefangen werden.
Was is da gemeint mit kann uaf jedem Rechner abgefangen werden, und warum is es nicht dekodiert, ich verwende doch CGI.pm ?
Dein Passwort wird im Klartext übertragen, weil du weder eine SSL-Verschlüsselung benutzt ("https") noch irgendwo selber dein Passwort verschlüsselst. Zu der Frage, warum das Paket abgefangen werden kann, solltest du dich mit den Grundlagen von TCP/IP beschäftigen. Der Client schickt es vielleicht an seinen Provider, der an den nächsten Router, der _vielleicht_ schon zu deinem Provider. Du weisst nicht, wie viele Rechner das Paket wirklich streift. Um einen Überblick zu bekommen, probier mal tracer (DOS) / traceroute (Linux, nur als root). Alle angegebenen Rechner können dein (unverschlüsseltes) Paket lesen.
Tschö Matti
Hallo,
ich hab jetzt rausgefunden, daß mein Provider doch .htaccess unterstützt. Nur bin ich grad am probieren, wie das funktioniert, bei SelfHTML is es zwar erklärt, und ich bekomme auch die Passwortabfrage, nur weis ich irgendwie nicht ganz, was da mit dem AuthName "blabla" in .htaccess gemeint is, weil da in SelfHTML steht nur das man es braucht, aber nicht wofür es steht.
Hallo nochmal.
Wie muss ich das benutzen ?
.htaccess ---------
AuthType Basic
AuthName "bereich"
AuthUserFile /usr/forum/messages/.htusers
require user anonym
.htusers---------
anonym:INnA1BztLIaac
muss das passwort (in dem fall 'test') verschlüsselt sein ?
Server = Apache/unix
Hallo
anonym:INnA1BztLIaac
muss das passwort (in dem fall 'test') verschlüsselt sein ?
Ja, aber warum probierst du es nicht einfach aus?
Tschö Matti
Hallo,
ich hab alles, ausser das Richtige schon probiert, verschlüsselt, unverschlüsselt usw. Ich komm leider nicht drauf, wo der Fehler sein könnte ?
Mosche nochmal,
ich hab alles, ausser das Richtige schon probiert, verschlüsselt, unverschlüsselt usw. Ich komm leider nicht drauf, wo der Fehler sein könnte ?
Eine etwas detailliertere Fehlerbeschreibung wäre sinnvoll. Mit "funktioniert nicht" kann hier (denke ich) niemand etwas anfangen. Was für eine Fehlermeldung kommt denn, was hast du probiert, zeige, was du bisher gemacht hast, ...
Tschö Matti
Hi,
naja, die 2 Files .htaccess und .htusers versuch ich die ganze Zeit zu modifizieren,
.htaccess-------
AuthName testzone
AuthUserFile /usr/forum/messages/.htusers
AuthType Basic
require anonym
.htusers--------
anonym:INnA1BztLIaac
#=passwort 'test' mit der von hierhttp://selfhtml.teamone.de/diverses/htaccess.htm#ip_bereiche_namen verwendeten Verschlüsselungsfunktion.
Wenn ich jetzt in das Verzeichnis gehe, wo .htaccess ist, kommt, so wie es sein soll die Eingabebox wo ich Passwort und Name eingeben muss, nur wenn ich name:anonym und pw:test eingebe, lässt er mich nicht rein ?
Moin
Wenn ich jetzt in das Verzeichnis gehe, wo .htaccess ist, kommt, so wie es sein soll die Eingabebox wo ich Passwort und Name eingeben muss, nur wenn ich name:anonym und pw:test eingebe, lässt er mich nicht rein ?
Dann mach es doch mal 'richtig' und erstell die Passwortdatei mit dem zum Apachen mitgelieferten htpasswd-Tool. Ausserdem wären Ausschnitte aus dem Errorlog hilfreich.
Hmm, jetzt wo ich genauer hinsehe: Du hast das user hinter require vergessen :)
--
Henryk Plötz
Grüße aus Berlin
Hi,
mit oder ohne user, es geht trotzdem nicht, auch wenn ich die Datei .htpasswd nenne, er lässt mich nie rein =((
Logdatei hab ich ausserdem leder keine.
Ich versteh einfach nicht was da falsch sein soll.
Hi,
Logdatei hab ich ausserdem leder keine.
Wie willst Du eine Server-Konfiguration vornehmen (.htaccess ist eine!),
ohne im Logfile Deine Fehler nachzulesen?
Offensichtlich bist Du beim falschen Provider.
Ich versteh einfach nicht was da falsch sein soll.
Wir ohne Diagnoseinformationen auch nicht. Genau dafür ist ein Logfile da!
Viele Grüße
Michael
hi!
Wenn ich jetzt in das Verzeichnis gehe, wo .htaccess ist, kommt, so
wie es sein soll die Eingabebox wo ich Passwort und Name eingeben
muss, nur wenn ich name:anonym und pw:test eingebe, lässt er mich
nicht rein?
Hier nachlesen und Schritt für Schritt befolgen:
http://aktuell.de.selfhtml.org/artikel/server/htaccess/index.htm
bye, Frank!
Hi,
das is eigentlich zimelich gleich mit dem anderen Artikel bei Selfhtml. Das was ich nicht versteh is, daß mir einmal gesagt wird .htpasswd, in selfhtml steht aber wiederum .htusers ?
Vielleicht stimmt auch der abasolute Pfad in .htaccess nicht, da weis ich leider auch nicht genau was da jetzt hingehört, entweder /usr/forum/users/.htusers oder /usr/bin/forum/users/.htusers
Vielleicht hilft es wenn ich ein paar Umgebungsvariablen herschreibe, bei denen ich finde , daß sie wichtig sind wegem dem Pfad :
[DOCUMENT_ROOT] [/home/home1/mein.name/meinedomain]
[PATH] [/sbin:/bin:/usr/sbin:/usr/bin]
es funktioniert!
AuthUserFile /home/home1/mein.name/meinedomain/.htpasswd #so muss es lauten
AuthType Basic
AuthName testbereich
require user anonym
Jetzt wollt ich noch fragen, wenn ich aussteige, den Browser nicht neu starte, und wieder einloggen will, kommt die Abfrage nicht, erst wieder wenn ich den Browser neu starte. Ist das normal so ?
Moin!
Jetzt wollt ich noch fragen, wenn ich aussteige, den Browser nicht neu starte, und wieder einloggen will, kommt die Abfrage nicht, erst wieder wenn ich den Browser neu starte. Ist das normal so ?
Ja, völlig normal. Der Browser kennt die Anmeldedaten solange, wie er läuft. Auch wenn er zwischenzeitlich andere Seiten abruft, vergißt er die Daten nicht.
- Sven Rautenberg
Hi,
ok danke, alles klar jetzt.
Hi,
AuthUserFile /home/home1/mein.name/meinedomain/.htpasswd #so muss es lauten
Der Name des AuthUserFile ist frei wählbar - Du selbst definierst ihn ja in dieser Anweisung!
Nur mußt Du halt auch einen Pfadnamen angeben, der existiert.
Eine exakte Beschreibung Deines Fehlers hätte übrigens im error_log gestanden.
Viele Grüße
Michael
Hallo,
ich hab jetzt rausgefunden, daß mein Provider doch .htaccess unterstützt.
Du solltest Dir aber dabei bewußt sein, daß es nicht viel sicherer ist, den AuthType basic zu verwenden. Bei dieser wird nämlich der Benutzername und das Passwort lediglich base64 encoded über das Netz gejagt, und kann daher von jedem, der 'mitlauscht' einfach ermittelt werden. Erst AuthType Digest bietet bessere, sprich sicherere, Benutzerauthorisierungen, da dabei das Passwort nicht im 'Klartext' übertragen wird.
Grüße
Klaus
Moin!
ich hab jetzt rausgefunden, daß mein Provider doch .htaccess unterstützt.
Du solltest Dir aber dabei bewußt sein, daß es nicht viel sicherer ist, den AuthType basic zu verwenden. Bei dieser wird nämlich der Benutzername und das Passwort lediglich base64 encoded über das Netz gejagt, und kann daher von jedem, der 'mitlauscht' einfach ermittelt werden. Erst AuthType Digest bietet bessere, sprich sicherere, Benutzerauthorisierungen, da dabei das Passwort nicht im 'Klartext' übertragen wird.
Wenn wir schon von Sicherheit reden: Wieviel Sinn macht es, ein Paßwort zu verschlüsseln, und dann aber die Daten wieder im Klartext zu übertragen, so daß jeder mitlesen kann.
"AuthType Basic" ist zwar simpel, aber eigentlich genau auf dem Level, den die Daten, die man durch die Authentifizierung erhält, auch haben: Unverschlüsselt.
"AuthType Digest" verschlüsselt das Paßwort. Sogar recht aufwändig mit Challenge-Response (ansonsten wäre das Verschlüsseln wertlos). Aber wer es drauf anlegt und ein Basic-Paßwort mitlesen kann, wird hier jetzt einfach das mitlesen, was der angemeldete User auch lesen kann. Und eventuell kann man mit den ausgetauschten Daten ja auch noch die eine oder andere Seite zusätzlich rauslocken, indem man den Datenverkehr umbiegt.
Wie schon die RFC 2617 sagt:
"Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs TLS or SHTTP are more appropriate protocols. In particular Digest authentication cannot be used for any transaction requiring confidentiality protection. Nevertheless many functions remain for which Digest authentication is both useful and appropriate. Any service in present use that uses Basic should be switched to Digest as soon as practical."
Also lieber HTTPS benutzen, wenns wirklich drauf ankommt. Digest schützt wirklich nur das Paßwort - toll für Leute, die ein- und dasselbe Paßwort überall benutzen, ansonsten aber ist wirkliche Sicherheit für vertrauliche Informationen durch Digest-Authentifikation nicht wirklich gegeben.
Und es beherrschen nicht alle Browser diesen Mechanismus. Netscape 4 kann's nicht, bei Mozilla mußte man auch eine zeitlang drauf warten (AFAIK), Opera kanns ab Version 4 (also schon laaange), und der IE ab Version 5. Wer noch hinreichend viele Besucher mit älteren Browsern zählt, kann nicht umstellen.
- Sven Rautenberg
Hi Sven,
bei Mozilla mußte man auch eine zeitlang drauf warten (AFAIK),
genau bis Version 0.9.7, die das als bisher einzige kann.
Netscape 6.2.1 ist also schon "veraltet".
Viele Grüße
Michael