[HaBo]
| (Web-) Design und webbasierte Sprachen Tipps & Tricks, Designabgleich, HTML & Javascript, Flash, ASP, PHP, Perl/CGI... |
Passwort-Abfrage über clientseitiges JavaScript nicht sicher. Weshalb?
Diskussion: Passwort-Abfrage über clientseitiges JavaScript nicht sicher. Weshalb? im Forum (Web-) Design und webbasierte Sprachen, in der Kategorie Web, Network & Multimedia Palace; Anzeige Hallo zusammen ich möchte gerne meine Seite mit einem einfachen Dialog schützen, htaccess möchte ich aber nicht brauchen. Ich ...
 |
15.06.05, 22:29
| #1 (permalink) |
| Registriert seit: 20.05.05  Likes: 0 |  Passwort-Abfrage über clientseitiges JavaScript nicht sicher. Weshalb? Anzeige Hallo zusammen ich möchte gerne meine Seite mit einem einfachen Dialog schützen, htaccess möchte ich aber nicht brauchen. Ich lese auf diversen Seiten im Netz immer wieder, dass eine Passwort-Abfrage über ein clientseitiges Javascript nicht sicher sei. Habe deshalb mal ein Script im Internet runtergeladen, aber dieses ist offenbar anders aufgebaut, als diese, die ich gefunden habe: Code: <script language='JavaScript'>
var time= '09.03.05 20:06:41' ;
var i=0;
var UserID='';
passwort = window.prompt('Passwort:','');
if((passwort != null)&&(passwort != "")){
passwort = passwort.toLowerCase();
while (passwort.length < time.length){passwort=passwort+passwort;}
for (i=0;i<time.length;i++){UserID=UserID+(100+passwort.charCodeAt(i)+time.charCodeAt(i))}
link = window.location.href.split('?');
window.location.href =link[0] + '?UserID=' + UserID;
}//if
else window.location.href='http://www.your-homepage.com'
</script> Code: <SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
<!--
var kennwort = "geheim"
function go(knw)
{
if(knw == kennwort)
location.href = "dokument.htm"
else
alert("Geben Sie bitte das richtige Kennwort ein.")
}
// Nur fuer Alternative:
function wechsel_mit_kennwort()
{
go(prompt("Kennwort:", ""))
}
// -->
</SCRIPT> Daniel 8) |
|  |
|
16.06.05, 17:18
| #2 (permalink) |
| Moderator   Registriert seit: 30.03.04  Likes: 14 | Hallo, also das Obere ist kein wirklicher Passwortschutz. Und zwar wird aus dem eingebenen Passwort ein Code errechnet. Der User wird dann an: seite_12345.html weitergesendet. Sofern man nicht den richtigen Code hat, wird man an eine andere Seite weitergeleitet. Das wäre aber das Gleiche Prinzip, als wenn du deinen Freunden den Link: http://seite.de/ganz_geheime_seite_n...ter_sagen.html sendest, und nicht den Passwortcode. Sofern jmd. die URL der geheimen Seite herrausfindet, dann kann er auch ohne PW diese Aufrufen. Bei der zweiten Lösung kann man das PW einfach ablesen, oder man geht gleich auch dokument.htm Die einzig sichere Lösung ist recht kompliziert. Und zwar gab/gibt es bei PGP und auch anderen Tools eine Möglichkeit, Texte zu verschlüsseln. Diese Texte werden als HTML Datei abgespeichert. Wenn man diese Datei aufruft, ist dort ein Formular. Wenn man dann wieder das Passwort eingibt, und auf Entschlüsseln klickt, bekommt man den Klartext. Dies könnte man so umändern, dass beim Aufruf der Webseite ein JS-Popup Eingabefenster erscheint. Dort gibt man dann den Key/Passwort ein. Dann wird dieser Key benutzt um den Text zu entschlüsseln. Dieser Text enthält die Informationen der Seite ink. Formatierung. Der entschlüsselte Text wird dann zurück gegeben und sofern der Key richtig war, auch richtig dargestellt. Wie du siehst, ist das gar nicht so leicht, und Änderungen am Quellcode sind auch nur kompliziert möglich. P.S. Programme die eine Source verschlüsselt abspeichern, aber so dass der Browser _ohne_ Key Eingabe die Seite darstellen können, sind _nicht_ sicher. |
|
| |
| HaBOT | - Anzeige - |
|
|
16.06.05, 17:31
| #3 (permalink) |
| Themenstarter Registriert seit: 20.05.05 Likes: 0 | Und welche Seite wäre das im oberen Fall? Ich möchte das gerne mal auf meinem Server testen und einen Skriptkiddie, ein Kolleg von mir, draufloslassen und dann eine Seite machen, auf der seine "Leistung" bekannt gegeben wird. Weil wenn ja ein Code erstellt wird, muss die Seite dazu ja auch vorhanden sein. Daniel  |
|
| |
|
16.06.05, 17:53
| #4 (permalink) |
| Member of Honour   Registriert seit: 28.05.03 Likes: 1 | relativ sichere und einfachere variante ist, wenn sich aus dem passwort die weiterleitungs url ergibt. so kommt man mit richtigen pw auf die seite und bei falschen pw gibts ein 404 (seite nicht gefunden). am besten packt man noch ne hashfunktion dazwischen. also zB: passwort = "LetMeIn1337"; md5("LetMeIn1337") = 51711599afd6251394b1ef644661eab0 -> weiterleitung auf die seite 51711599afd6251394b1ef644661eab0.html directory listing sollte natürlich deaktiviert sein.
__________________ http://livehabo.hackerboard.de | http://livebb.sourceforge.net |
|
| |
|
16.06.05, 17:56
| #5 (permalink) | |
| Themenstarter Registriert seit: 20.05.05 Likes: 0 | Zitat:
Daniel | |
|
| |
|
16.06.05, 21:20
| #6 (permalink) |
| Registriert seit: 19.03.05 Likes: 1 | Ich finde die Lösung von ivegotmail ist gut, wenn dein Kollege an nem anderen PC sitzt und das ganze über nen Webserver läuft, geht das. Aber n Apache (oder ähnliches  ) ist halt nicht für jede Firma Standart. (vor allem nicht wenn se nichts mit Webdesign zu tun haben  ) Weiß nicht, wie du das machen wolltest.Wenn du aber (ich geh mal (weils in "der Firma" ist) von Win aus) den Explorer öffnest und deinem Kollegen von den beiden Datein (index.html und 51711599afd6251394b1ef644661eab0.html) index.html öffnest, ist das keine wirkliche Herausforderung mehr. (Ich denke nicht, das du sowas tust, ich sachs halt nur mal )Außerdem würde eine Brute-Force Attacke mit beliebigen Seitetiteln die lösung innerhalb des nächsten Jahrtausends ermitteln  .Wenns wirklich lokal ist, ist nur Elderans Methode sicher. Also, die ganze Seite verschlüsseln (so, wie sichere Datenübertragung übers Web halt funktioniert, nur ohne die automatische Umwandlung am Client). Für "normal sterbliche" mit Webserver würd ich aber ivegotmails Methode vorschlagen, oder wenigstens das Passwort nur als Hash speichern, auch wenn der Quellcode dann ablesbar ist. (is dann aber nur gegen Eintastenmäuse sicher ) |
|
| |
|
16.06.05, 23:16
| #7 (permalink) |
| Registriert seit: 06.04.05 Likes: 0 | Ich würd das ganze mit PHP machen, das ist wirklich nicht schwer. |
|
| |
|
17.06.05, 10:31
| #8 (permalink) | |
| Member of Honour  Registriert seit: 04.09.04 Likes: 0 | Zitat:
root | |
|
| |
|
17.06.05, 12:44
| #9 (permalink) | ||
| Member of Honour Registriert seit: 28.05.03 Likes: 1 | Zitat:
Zitat:
__________________ http://livehabo.hackerboard.de | http://livebb.sourceforge.net | ||
|
| |
|
17.06.05, 13:17
| #10 (permalink) |
| Registriert seit: 06.04.05 Likes: 0 | Es gibt sicher ein programm, dass mit Bruteforce verschiedene Kombinationen von Zeichen auf einen 404-Fehler prüft. |
|
| |
|
17.06.05, 13:20
| #11 (permalink) | ||
| Moderator Registriert seit: 30.03.04 Likes: 14 | Hallo, Zitat:
Zitat:
Diese Software/Browser kann aber nichts anderes als dein Firefox, Opera, IE... Sprich der Browser fragt den Server: Sende mir mal die Datei abc.html zu. Server: Ok, hier ist sie Browser: Danke. [Speichern|Anzeigen?] Sofern jetzt in dem Ordner eine index Datei vorhanden ist, oder directory listin auf OFF steht, ist der Browser "blind". Sprich dieser kann nur den Links der Dateien folgen. Und der Dateiname besteht aus 128 Bit, also gibt es 2^128 = 10^38 Möglichkeiten. Dass das Programm alle austesten.... unwahrscheinlich. Man hat nur ein sehr großes Problem, wenn jmd. an deinen PC geht, und in deinem Verlauf den Pfad zum "geheimen Dokument" findet. Denn dann kann er ohne Passwort dieses Dokument aufrufen. | ||
|
| |
|
17.06.05, 23:09
| #12 (permalink) |
| Registriert seit: 17.06.05    Likes: 0 | hm Hi, Was hast du gegen die .htpasswd ??? 1. Die legst du in das Verzeichnis was eine Ebene höher liegt und gibst das der .htaccess bekannt. ich meine da kommt man nicht so ohne weiteres ran wenn der Webserver einigermaßen durchschnittlich aufgebaut ist und die oberen Verzeichnisse nicht im Web veröffentlicht :- ). Passwörter können durch diverse Tools natürlich mit so einer 0-9 A-Z etc... Variante durchprobiert werden. Daher mußt du hier auch ein wenig kreativ mit der Paßwortvergabe sein. Sätze haben viele Zeichen und erschweren dieses wahnsinnig. Da würde es schon mal nen paar Tage brauchen wenn der Username bekannt wäre. Die HP zu der es am Ende gehen sollt am besten in einem komplett anderen Unterverzeichnis hosten als wo die .htaccess liegt. Zudem lohnt es immer eine .swf Flashdatei davor zu bauen die nicht sofort den Link anzeigt wo es zur .htaccess geht. Ist nochmal nen kleiner Schutz zusätzlich den Versuch alleine schon mal etwas zu erschweren. (wenn auch lächerlich). SYD |
|
| |
|
18.06.05, 14:17
| #13 (permalink) |
| Moderator Registriert seit: 30.03.04 Likes: 14 | Hallo, also die .htaccess hat _nichts_ mit dem Schutz zu tun. Die kann jeder einsehen und es wäre kaum ein Sicherheitsrisiko. Dort steht dann nur drin, wo es zur .htpasswd geht, gut dadurch könnte man den Dateipfad herrausfinden, aber das geht auch anders. Und noch dass der Ordner per PW geschützt ist. Was geheim gehalten werden muss ist die .htpasswd. Dort sind _verschlüsselt_ die Passwörter gespeichert. Und wenn man ein gutes Passwort hat, dann kann man dieses mit uns bekannten Angriffen und Technologie nicht innerhalb eines Menschenlebens knacken. Allerdings kann man auf beide Dateien _nicht_ per Browser zugreifen, sofern man dieses in der Config nicht deaktiviert hat. Und wenn jmd. FTP Zugriff hat, dann könnte er die geheimen Dateien auch ohne den Umweg über .htpasswd => PW entschlüsseln an die Daten kommen. Aber wie gesagt, es gibt viele Anbieter, vorallem kostenlose, die weder Serverseitigesprachen nocht .htaccess oder ähnliches unterstützen. |
|
| |
|
18.06.05, 20:13
| #14 (permalink) | |
| Registriert seit: 19.03.05 Likes: 1 | Zitat:
(Was für ein Satzmonster Hoffe, was ich aussagen wollte ist an gekommen) | |
|
| |
|
23.06.05, 10:43
| #15 (permalink) |
| Registriert seit: 27.01.05 Likes: 0 | Hi! Ich empfehle dir auf jeden Fall .htaccess (oder die Serverkonfiguration) zu verwenden. .htaccess finde ich die beste Möglichkeit für Passwortabfragen und geschützte Bereiche! Ich hab ein kleines Tutorial geschrieben, kannst es dir ja mal durchlesen: ----------------------------------------------------------- .htaccess - Einführung Was ist eine .htaccess-Datei? Die .htaccess-Datei ist eine Konfigurationsdatei, mit der man die Standardkonfiguration des Webservers (Apache) für bestimmte Verzeichnisse ändern kann. Man speichert eine Datei names .htaccess in dem Verzeichnis, in dem man die Konfiguartionsänderungen machen möchte. Sie gilt für dieses Verzeichnis und alle Unterhalbliegenden. Den Namen der .htaccess-Datei kann man mit folgendem Befehl in der Server-Konfigurationsdatei ändern: /etc/httpd.conf .................................... AccessFileName .conf .................................... Welche Befehle gibt es? Welche Befehle in einer .htaccess-Datei akzeptiert werden, wird durch 'AllowOverride' gesteuert. Ob es überhaupt möglich ist, diese Directive in einer .htaccess-Datei zu verwenden, steht in der Dokumentation. Um herauszufinden welches 'AllowOverride' man einfügen muss und ob es möglich ist, diese Directive zu verwenden, genügt ein Blick auf die Homepage von Apache. Hier ein Beispiel mit 'Require': In der Dokumentation von Apache (unter Directives => Require) steht folgendes: Apache-Manual .................................... [...] Context: directory, .htaccess Override: AuthConfig [...] .................................... Das heisst, dass man diese Directive in einer .htaccess-Datei verwenden darf und dass man vorher Require mit 'AllowOverride' in der Serverkonfiguration erlauben muss, damit 'Require' funktioniert: /etc/httpd.conf .................................... AllowOverride AuthConfig .................................... Was ist, wenn ich in tieferen Verzeichnissen Optionen wieder verbieten will? Wieder ein Beispiel: /usr/var/www/htdocs/board/.htaccess .................................... Options +ExecCGI .................................... /usr/var/www/htdocs/board/admin/.htaccess .................................... Options Includes .................................... Damit ist CGI im Verzeichnis 'board' erlaubt, jedoch nich im Verzeichnis 'admin'. Eigentlich ganz einfach, oder? Wie kann ich CGI in bestimmten Verzeichnissen erlauben? Durch genau diese Frage, bin ich auf die Idee gekommen, ein kleines Tutorial über .htaccess zu schreiben. Ich habe Board-Software, welche in Perl geschrieben ist demnach CGI verwendet, jedoch in allen möglichen Verzeichnissen. Da es nicht mein eigener Server ist, auf dem ich das Board hoste, habe ich nur die .htaccess-Datei zur Verfügung. /home/martin/public_html/bbv2/.htaccess .................................... Options +ExecCGI AddHandler cgi-script cgi pl .................................... Erledigt! Man muss 'Options' durch 'AllowOverride' erlauben (in der Serverkonfiguration), um es benutzen zu können. In der 1. Zeile wird CGI in diesem Ordner (/home/martin/public_html/bbv2) erlaubt. Mit der 2. Zeile werden alle Dateien, mit Endung .cgi oder .pl als CGI-Datei behandelt und ausgeführt. Das war's! Wie kann ich bestimmte Verzeichnisse mit einem Passwort absichern? Das ist wohl der häufigste Grund, warum .htaccess benutzt wird - Passwortschutz! Ok von Anfang an: Ein Blick in die Dokumentation verrät uns, dass man 'AuthConfig' mit 'AllowOverride' erlauben muss. /etc/httpd.conf .................................... AllowOverride AuthConfig .................................... Danach muss man eine Passwortdatei erstellen und evtl. eine Gruppendatei. Die Passwortdatei wird mit 'htpasswd' erstellt, ein Tool, das bei Apache mitgeliefert wird. SHELL .................................... htpasswd -c /usr/local/apache/passwd/passwords .................................... Das Flag -c wird nur beim Erstellen einer neuen Datei benutzt. Es darf nur beim Ersten User benutzt werden, sonst wird die Datei wieder überschrieben. Als 2. Argument folgt die Passwortdatei. Danach sollte man die richtigen Rechte setzen, um einer Kompromittierung vorzubeugen. SHELL .................................... chmod root:apache /usr/local/apache/passwd/passwords chmod 640 /usr/local/apache/passwd/passwords .................................... Nachdem die Passwortdatei erzeugt ist, kann man sich endlich der Konfiguration zuwenden. .htaccess .................................... AuthType Basic AuthName "Passwortabfrage!" AuthUserFile /usr/local/apache/passwd/passwords require valid-user .................................... Zur Erklärung: 'AuthType' gibt den Typ der Authentifizierung an (Basic == Passwort eingeben). Es gibt noch andere Verfahren ,wie z.B. die Authentifizierung per Datenbank, IP usw. 'AuthName' ist die überschrift der Dialogbox als String. 'AuthUserFile' ist die Passwortdatei. (Immer den absoluten Pfad angeben) 'require valid-user' bedeutet, dass eine Passwortdatei benutzt werden soll. Es gibt noch viele weitere Befehle wie .htaccess .................................... require user tcr .................................... Sodass nur Benutzer 'tcr' Zugang erhält. Man kann auch Gruppen verwenden: .htaccess .................................... AuthGroupFile /usr/local/apache/passwd/groups require group admins .................................... Wobei die Gruppendatei so aussieht und sich auf die Passwortdatei bezieht: /usr/local/apache/passwd/groups .................................... admins: bow00 Chris tcr .................................... Sonstige Überlegungen? Eigentlich sollte man eine .htaccess-Datei nur benutzen, wenn man keinen Zugriff auf die Server-Koniguration hat. Die Benutzung der Serverkonfigurationsdatei hat hauptsächlich einen Vorteil: Die Datei wird nur geladen, wenn der Server (neu)gestartet wird. Folgendes Verzeichnis: .................................... /usr/var/www/htdocs/board/hacks .................................... Es wird in also folgenden Verzeichnissen nach einer .htaccess-Datei gesucht: .................................... /usr/var/www/htdocs/board/hacks /usr/var/www/htdocs/board /usr/var/www/htdocs .................................... Es wird tatsächlich in 3 Verzeichnissen nach einer .htaccess-Datei gesucht. Ob sie gefunden wird oder nicht ist egal, gesucht wird auf jeden Fall. Damit noch nicht genug: Es wird bei jedem Neuen Laden einer Seite danach gesucht! Bei einer größeren Site kann das zu einigen Performance-Verlusten führen. Eines soll noch demonstriert werden: /usr/var/www/htdocs/board/.htaccess .................................... AddHandler cgi-script cgi pl .................................... /etc/httpd.conf/.htaccess .................................... <Directory /usr/var/www/htdocs/board> AddHandler cgi-script cgi pl </Directory> .................................... Beide Einträge sind völlig identisch, sie machen genau das Gleiche! Warum wird aber dann die .htaccess-Datei so oft benutzt? Ganz einfach: Viele Hoster hosten mehrere User auf einer einzigen Maschine, und damit jeder User seine eigenen Einstellungen (Anmeldung, Index-Seiten) konfigurieren kann, wird die .htaccess-Datei erlaubt. Das war's, hoffe ihr habt was gelernt, denn dann gibt es ein paar Kiddies weniger! written by tcr ----------------------------------------------------------- mfg tcr |
|
| |
|
| - Anzeige - | |
|
|
[HaBo] » Web, Network & Multimedia Palace » (Web-) Design und webbasierte Sprachen » Passwort-Abfrage über clientseitiges JavaScript nicht sicher. Weshalb?
| Themen-Optionen | |
| Ansicht | |
Linear-Darstellung
| |
Ähnliche Themen | ||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| Passwort abfrage Fenster | r3ctox | Webmaster-Security | 1 | 04.06.09 15:44 |
| PHP Passwort Abfrage, ist das sicher? | IRoot | Webmaster-Security | 4 | 27.06.07 18:57 |
| MySQL Passwort-Abfrage | Cloud2302 | (Web-) Design und webbasierte Sprachen | 1 | 26.04.06 20:27 |
| tweak-xp passwort abfrage! *help* | deli | Die Problemzone | 3 | 08.07.05 17:03 |
| Passwort-Abfrage über clientseitiges JavaScript nicht sicher. Weshalb? | dfi | (In)security allgemein | 13 | 18.06.05 20:13 |
