Wie sicher ist Unix Basic Crypt

thonix · Beitrag von **thonix** » 11.06.2004 16:30:28

Webserver und Proxy Authentifizierung läuft lediglich mit der Basic verschlüsslung.
Welche Möglichkeiten gibt es diese zu knacken?

pdreker · Beitrag von **pdreker** » 11.06.2004 17:01:17

Da der Username und das Passwort im Klartext über das Netz geschickt werden, kann man die Verbindung einfach sniffen (tcpdump, ethereal und andere Tools) und das Passwort dort trivial auslesen.

https (HTTP + SSL) dichtet diesen Angriffsvektor einigermassen zuverlässig ab, da der Angreifer dann nicht nur mitlesen können muss, sondern auch den Traffic manipuieren können muss (sog. Man-in-the-middle Attacke)

Auf dem Server (wenigstens bei Apache) wird das Passwort verschlüsselt gespeichert, und sollte damit wenigstens so sicher sein, wie die UNIX Login Passwörter.

Patrick

Joghurt · Beitrag von **Joghurt** » 11.06.2004 19:51:18

pdreker hat geschrieben:Da der Username und das Passwort im Klartext über das Netz geschickt werden, kann man die Verbindung einfach sniffen (tcpdump, ethereal und andere Tools) und das Passwort dort trivial auslesen.

BTW, Nicht "Klartext" im engsten Sinne, es wird "Benutzername:Passwort" in Base 64 "kodiert" und dann übertragen.

fago · Beitrag von **fago** » 11.06.2004 20:43:43

sehr interessant.

zu welchem zweck wird denn dann http auth base64 kodiert? dass es nicht ganz so offensichtlich ist?

ich hatte testweise schon mal probiert passwörter aus der verbindung zu meinen apachen zu sniffen - erfolglos, und hab in folge keine weiteren absicherungen vorgenommen

peschmae · Beitrag von **peschmae** » 12.06.2004 10:52:35

base64 kodiert afaik Nachrichten von 8 bit auf 7 bit runter, weil irgendwer manchmal nur 7 richtig überträgt - oder so ähnlich. Benutzt man afaik z.B. bei Mails um Bilder und anderes Binärzeugs zu kodieren.
Das ist aber kein Verschlüsselungsverfahren oder so.

MfG Peschmä

Joghurt · Beitrag von **Joghurt** » 12.06.2004 11:57:05

Stimmt schon, aber das HTTP legt fest, dass die Übertragung 8-bit-safe sein muss.

pdreker · Beitrag von **pdreker** » 12.06.2004 15:17:59

Wenn's nicht richtig verschlüsselt ist, ist es Klartext... Wenigstens vom Sicherheitsaspekt her.

Patrick

Joghurt · Beitrag von **Joghurt** » 12.06.2004 15:30:26

pdreker hat geschrieben:Wenn's nicht richtig verschlüsselt ist, ist es Klartext... Wenigstens vom Sicherheitsaspekt her.

Genau das meinte ich auch. Nur halt nicht Klartext im engsten Sinne...

thonix · Beitrag von **thonix** » 12.06.2004 17:06:20

Sehr interessant. Ich werde mir mal dasBase64 anschauen.

Bei einem Webserver habe ich ja die Möglichkeit mit SSL zu arbeiten. Was gibt es aber für Möglichkeiten bei einem Proxy Server um den Benutzername und Passwort sicher zu übertragen?

LittleBoy · Beitrag von **LittleBoy** » 22.06.2004 14:44:16

Base64 ist wie bereits gemerkt ein Kodierung - und keine Verschlüsselung. Somit wird das Passwort im Klartext übertragen. Das macht das ganze anfällig fürs sniffen.
Ebenfalls problematisch ist ggf. die nicht stattfindende Authentifizierung - man könnte hier einiges spoofen.

Im .htpasswd werden die Kennwörter entweder in einer MD5-Abart oder im crypt-Format abgelegt. Beide Formate sind anfällig gegen Dictionary-Attacken (ich weiss nicht, inwieweit ein seed verwendet wird) - beim crypt greift wahrscheinlich auch ein Brute-Force.

Aber: Wenn man keinen Zugriff auf die .htpasswd Datei hat und auch nicht die Möglichkeit hat, die Verbindung abzuhören (was bei Internet-Verbindungen zu 99,9999% der Fall ist) dann ist der .htaccess Schutz gar nicht so schlecht...

Die Linux-Anmeldung ist mittlerweile um einiges sicherer. Heute wird eigentlich nur noch md5 verwendet (bzw. es sollte zumindest so ein), und dazu noch ein ordentlicher seed

fago · Beitrag von **fago** » 22.06.2004 16:30:05

naja, aber im lan ist das mithören kein problem

welcher möglichkeiten bleiben?
ssl ist wohl etwas overkill, und selbstsignierte zertifikate sind wohl auch nicht so das wahre (lästige browsermeldungen)

ev http://httpd.apache.org/docs/mod/mod_auth_digest.html ?
nur stört daran:

Status: Experimental

LittleBoy · Beitrag von **LittleBoy** » 22.06.2004 17:15:50

[quote="fago"]naja, aber im lan ist das mithören kein problem[/ssh]

Im LAN hat man aber auch eine vertrauenswürdige Umgebung.

Wenn du gegen "sniffen" resistent sein willst, musst du auf was mit public keys zurückgreifen - und da bleibt letztlich nur VPN, SSH (tunnel) oder SSL.

Aber selbst da bleibt die Möglichkeits des sniffen, weil die meisten User jede Browserwarnung über abgelaufene oder nicht vertrauenswürdige Zertifikate einfach wegklicken, weil es davon so viele gibt...

Eine Stufe drunter wäre noch ein Challenge-Response Verfahren angesiedelt. Wenn die wirklich gut implementiert sind (und das sind leider die wenigsten) dann bieten die auch einen recht guten Schutz. Wenn du ein eigenes Skript absichern willst, kannst du sowas auch selber implementieren.

thonix · Beitrag von **thonix** » 22.06.2004 23:20:39

Nun etwas was nicht ganz zum Thema passt - aber vielleicht von Interesse ist.

Interessiert es jamend wie man die Browsermeldung von nicht Vertrauenswürdigen Zertifikate auf dem client wegbekommt?
Ich habe da ein bissel gesucht und bin auf eine Lösung gestößen - muss zwar auf jedem Client gemacht werden - aber nur 1 mal.

Ich Frage wil ich keine Lust habe das umsonst niederzuschreiben....

pdreker · Beitrag von **pdreker** » 23.06.2004 04:05:41

Naja, wenn man selbst signierte Zertifikate verwendet, oder man selbst seine eigene CA ist (Certification Authority), dann muss man den Clients halt die entsprechenden RootCA Zertifikate bereitstellen, damit diese die ausgelieferten Zertifikate vom Server auch verifizieren können...

Habe ich das richtig verstanden?

Patrick

fago · Beitrag von **fago** » 23.06.2004 15:34:57

denk schon

nur find ich das umständlich, und ein viele user wären damit wohl schon überfordert