HTTP-Authentifizierung: Basic vs. Digest

Das Thema Sicherheit steht nicht nur bei mir hoch im Kurs. Wenn man sich fast tagtäglich mit Webservern und dem Rest des Internets befasst, stößt man auf so manch guten Tipp bzw. Trick. Nun wissen viele, dass man ein Verzeichnis auf einem Webspace oder Server mit einem Verzeichnisschutz vor ungewollten Zugriffen schützen kann. Das ist vor allem dann sehr sinnvoll, wenn es sich um Administrationsoberflächen handelt. Um diesen Schutz zu gewährleisten, gibt es unter Linux zwei Verfahren.

Basic Access Authentication

Gern genommen und sehr häufig anzutreffen. In einer entsprechenden Datei, meist “.htpasswd” genannt werden die Nutzer und die dazu gehörigen Passwörter abgelegt. Für die Verschlüsselung der Passwörter wird oft auf MD5 gesetzt. Möchte man sich nun einloggen, dann wird nach den Login-Daten gefragt und man gibt diese ein. An den Server wird ein Base64 codierter Wert gesendet, und wenn man sich kurz die Mühe macht und diesen zurückcodiert, dann werden manche staunen. Benutzer und Passwort stehen dann im Klartext da. Bedeutet, dass diese Authentifizierungsverfahren keine wirkliche Verschlüsselung besitzt.

AuthType Basic
AuthName "TITEL"
AuthUserFile /SERVERPFAD_ZUR_DATEI/.htpasswd
  require valid-user

Eintrag einer Basic Auth in eine .htaccess-Datei

Nutzt man eine Basic Access Authentication in Kombination mit SSL/TLS via https, dann ist dieses Verfahren ausreichend geschützt. Denn es wird bereits vorher eine verschlüsselte Verbindung aufgebaut und ein Auslesen des Base64-Hashs ist nicht möglich. Sonst eignet sich dieses Verfahren nur, um Bots und neugierige Geister von einem Verzeichnis fernzuhalten. Eine wirkliche Sicherheit besteht dann jedoch nicht. Anders sieht es bei Digest Access Authentication aus.

Digest Access Authentication

Möchte man wirkliche Sicherheit haben, dann sollte man auf dieses Verfahren setzen. Die Übertragung und Generierung des Zugangs wird hier über eine deutlich komplexere Berechnung vollzogen. Ein Sniffen (erschnüffeln) der Login-Daten ist nicht möglich. Es werden zufällige Hash-Werte für jede Sitzung generiert und dann mit Benutzername, Passwort, erhaltener Zeichenfolge, HTTP-Methode und angeforderter URI gekoppelt. Auch ohne SSL/TLS kann ein sicherer Login gewährleistet werden, danach ist die Verbindung aber wieder unverschlüsselt. Man muss nur schauen, ob der Webspace- oder Serveranbieter das Modul auth _digest erlaubt. Nur wenn das der Fall ist, kann auf diese Verifizierung zurückgegriffen werden.

AuthType Digest
AuthName "TITEL"
AuthDigestDomain DOMAIN
AuthUserFile /SERVERPFAD_ZUR_DATEI/.htpasswd
  require valid-user

Eintrag einer Digest Auth in eine .htaccess-Datei

Um Digest zu verwenden, bedarf es keinem Mehraufwand, lediglich nach einem Generator für die Einträge in die Passwort-Datei muss man ein bisschen suchen. Die gibt es nicht wie Sand am Meer. Ich habe zwei gefunden, die ganz brauchbar sind. Zum einen auf AskApache und zum andern bei Jesin’s Blog. Wer einen eigenen Server hat oder Linux besitzt, kann auch über den Terminal “auth_digest” aufrufen und sich dort alles selbst konfigurieren.

Fazit und Zusammenfassung

Tja, im Vergleich kann eine Basic Access Authentication sehr viel leichter entschlüsselt werden, wenn der Netzwerkverkehr abgefangen oder überwacht wird. Erstrecht wenn, kein SSL/TLS zum Einsatz kommt. Kann jeder gern auch mal selbst ausprobieren und in den Antwort-Header eines solchen Logins schauen. Den Hash dann kopieren und in einem einfach gebastelten PHP-Script einfügen, ausführen und voilà.

<?php echo
base64_decode(cmVyYWlzZWFjZTpTIWNoZXJlc1Bhc3NXMHJ0); ?>
Ergebis: reraiseace:S!cheresPassW0rt

PHP Base64 Decode Funktion

Wer auf Sicherheit setzt, der verwendet besser Digest und dazu falls möglich noch https, dann kann nicht viel anbrennen. Ist man mal auf Reisen und steigt in einem Hotel mit W-LAN ab, dann weiß man nicht, ob und wie der Netzwerkverkehr dort überwacht werden könnte. Für sensible Bereiche ist diese Authentifizierungsmethode sehr zu empfehlen.

Artikel anderer Blogger zu diesem Thema:


Avatar von reraiseace
Autor: Markus Werner (reraiseace) Twitterreraiseace, Google+reraiseace, Twittercb_werner
Ich bin Redaktionsvolontär bei der COMPUTER BILD in Hamburg, Fernstudent am Deutschen Journalistenkolleg und schreibe auf re{raise}ace privat über Webdesign und Programmierung. Seit 2015 schrieb ich auch regelmäßig für andere Medien.

2 Kommentare

Du kannst diesen Artikel nicht mehr kommentieren.

  1. Kommentar von rené · · #

    hi,

    ich habe heut den usbwebserver getestet und bin bei meinen problemen und meiner suche nach einer lösung auf deinen beitrag “basic vs. digest” gestoßen. fand ich sehr hilfreich zur entscheidungsfindung (danke dafür)

    da gibt es aber noch so einiges was bei mir nicht so recht funktioniert:

    wenn man “authtype digest” benutzt, sollte dann unter “áuthuserfile” nicht auf die datei .htdigest statt auf die datei .htpasswd verwiesen werden?

    die bezeichnung “authdigestdomain domain” ist für mich nicht erkennbar, … was kommt da rein? (ich erhalte im error-log immer den hinweis “a module not included in the server configuration”)

    ein user-login funktioniert auch nicht.
    verification of user schlägt immer wieder fehl und man landet an der eingabebox

    vielleicht erkennst du ja leicht meine “anfängerfehler” und kannst mir “auf die sprünge helfen”, … ich würde mich freuen!

    mit grüßen aus berlin
    rené

  2. Kommentar von reraiseace · · #

    Ob das File nun “.htdigest” oder “.htpasswd” heißt ist egal. Es geht um die Informationen dir darin abgelegt sind. Die Einträge sehen bei Digest ganz anders aus, als bei Basic. Man kann die Passwort-Datei auch nennen, wie man will. Selbst die “.htaccess” kann anders benannt werden. Die Namen sind nur die Standardvorgaben des Servers.

    Bei der “authdigestdomain” kommt der Domainname rein, wo der Schutz aktiv sein soll. Damit verknüpft Digest das Ganze zusätzlich mit der Domain. In deinem Fall “localhost” oder “127.0.0.1”. Geht das danach nicht, dann lass diese Angabe vorerst weg.

    Schau mal in der Apache Conf nach, dass das Digest Modul bei dir auch aktiv ist.

    LoadModule auth_digest_module modules/mod_auth_digest.so

    Steht da eine # davor, mach diese weg und speichere ab. Danach den Apachen neustarten und nochmals testen.