Ver- / Entschluesseln

[Christoph Zurnieden]

Hi,

Unter dieser Bedingung _und_ der Bedingung das Sicherheit keine Rolle mehr spielt. Wer sein Paßwort einfach weiterreicht braucht keines mehr, das ist dann zweckfrei. Manche Accounts verbieten das auch.

Hu? Es gibt diverseste Bedrohungsszenarien bei denen man davon ausgehen kann dass der Sicherheitskontext des Skriptes nicht kompromittiert ist.

Ich wüßte zwar nicht welche, aber die Wahrscheinlichkeit wird wohl nicht bei 0 liegen. Aber was hilft das? Nix. Das Paßwort kennen mehr Leute als nur der User, damit ist es nicht mehr benutzbar.
Tut mir leid, aber auch wenn Du noch soviele Blümchen drauf pinselst: das Konzept an sich ist bereits Mist, da läßt sich nichts mehr reparieren.

Wenn sich das Skript einem anderen System gegenüber authentifizieren soll, bleibt dir sogar gar keine andere Wahl als davon auszugehen, sonst hast du schon von den Vorraussetzungen her verloren.

Du hast verloren, ja, aber nicht aufgrund der Deiner Vorausetzungen. Das Script kann isch durchaus guten Gewissens identifizieren, dafür gibt es Mittel und Wege, aber was hast Du davon? Du weiß, das das Script das Script ist, wofür es sich ausgibt, mehr nicht.
Das beschert Dir zwar die Möglichkeit _nur_ das Script zuzulassen, aber damit hast Du nur das Transportproblem gelöst, mehr nicht.

Da spielt es dann qualitativ auch keine Rolle mehr ob das Skript das Passwort hat, oder einen private Key der berechtigt ist, oder auch ob das andere System die Daten weiterleitet. Wenn das Skript kompromittiert ist, hat der Angreifer halt den privaten Schlüssel, bzw. direkt die emails.

Du hast es erfasst, ja. Deshalb ist Automatik ja auch nicht zulässig.

[1] Für Digest ist strenggenommen 'nur' ein Hash aus Benutzername, Passwort und Realm nötig, dieser Hash reicht aber bereits um sich dem Server gegenüber zu authentifizieren.

Ja, aber normalerweise nur einmal.

Nein. Beim Apache-Modul wird der Hash über Benutzername, Realm und Passwort gespeichert

Ah, so, dann war's ein Mißverständnis, sorry, hatte den _ganzen_ Auth-prozeß vor Augen.

und dieser Hash reicht zusammen mit dem Benutzernamen aus um sich über HTTP Digest Auth zu authentifizieren (H(A1) in Sektion 3.2.2.1 von RFC 2617). .htdigest-Dateien enthalten also quasi Klartextpasswörter,

Diese Dateien enthalten MD5-Summen von '"%s:%s:%s", user, realm, pw' (vid. add_password() in $APACHE/support/htdigest.c)
Es werden also _keine_ Klartextpaßwörter gespeichert, wie sich das auch gehört.

mit dem einzigen wirklichen Unterschied dass die Wahrscheinlichkeit dass das gleiche Passwort bei einem anderen realm gültig ist nahe null liegt.

"nahe Null" ist bei MD5 schon gefährlich groß geworden.

Ja, ich weiß, aber wenn wir hier schon die Beckmesser kreuzen ... ;-)

Dieser Hash wird dann beim Authentifizierungsvorgang zusammen mit einer handvoll anderen Werten (hauptsächlich nonces) nochmal gehasht und das dann als Response übergeben.

So ungefähr geht das, ja. Wo ist hier aber das Klartextpaßwort?

IIS speichert dann auch lieber gleich das Klartextpasswort (in einem AD, zugegeben)

Was macht das für einen Unterschied?

Ich hege die Hoffnung dass Webserver und AD-Controller physikalisch getrennt sind, die Daten also nicht im Filesystem des Webservers liegen, sowie dass die Kommunikation IIS-AD verschlüsselt und authentifiziert abläuft. So _ganz_ doof ist man da ja auch nicht.

Das hat nichts mit Intelligenz zu tun, sondern mit Kosten, leider. Bei MS (nur, um ein Beispiel zu nennen, könnte auch Oracle sein o.ä. große Firma) haben einige der besten Köpfe gearbeitet und arbeiten da teilweise heute auch noch (wenn uachnicht mehr die Gleichen), an der Unfähigkeit der Programmierer _kann_ es also schon mal kaum liegen.

Deshalb würde ich sensible Daten auch nie geschlossenen Systemen anvertrauen.

vermutlich um nicht für jeden Realm einen extra-Hash anlegen zu müssen.

Faulheit ist kein Grund.

Das ist weniger Faulheit als Managebarkeit.

Managbarkeit? Für ein paaar hundert oder, laß es hoch kommen, ein paar tausend? Mit ein wenig Overhead 20 Byte das Stück (gehen mal von 8 Bit/Byte aus) macht auch bei 10.000 Stück gerade mal knapp 193 KiB.
Du möchtest mich veräppeln, oder?  ;-)

Im Apache-Modell muss man für jeden Benutzer für jeden Realm einen neuen Hash anlegen, was unter anderem bedeutet dass der Benutzer herangezogen werden muss um sein Passwort einzutippen damit es gehasht werden kann.

Ja, das ist auch vollkommen korrekt so. (man könnte das ohne größere Sicherheitseinbußen ändern, aber das ist ziemlich kompliziert. Neu eintippeln lassen ist da günstiger.)

Im IIS-Modell kann man die Benutzer frei hin- und herschieben und verwalten.

Und das bringt Dir genau was? Nein, ehrliche Frage, ich wüßte keinen Grund, an einem festgelegtem Design on-the-fly etwas zu ändern.

Einen qualitativen Sicherheitsnachteil hat das nur dadurch dass das verwendete Passwort tendentiell auch für andere Dienste als den jeweiligen HTTP-Digest-Realm verwendet wird.

Ja, aber das ist nicht weiter schlimm, wenn das Paßwort gut genug ist und auch regelmäßig geändert wird. Es ist sogar qualitativ besser im Falle, das zwar viele verschiedene Paßwörter benutzt werden, diese aber z.B. aus den Vornamen der bucklichten Verwandschaft ausgewählt wurden.

Aber bevor ich hier in der erzwungene Kürze ungenau, vielleicht sogar falsch verstanden werden könnte laß Dir noch gesagt sein: Sicherheit mit und durch Kryptographie ist ein sehr komplexes und heikles Thema - ein chaotisches System, das schon geringste Veränderungen an den Eingangsgrößen rigoros abstraft. Deshalb: nicht nur wohlerprobte Verschlüsselungsalgorithmen verwenden sondern vor allem wohlerprobte Systeme! Sich da 'was selber zu basteln und das auch noch "mal eben" geht so gut wie immer in's Auge. Es gibt ein paar Symptome für solch' Selbstgestricktes und "Paßwort im Klartext speichern" ist eines der Sichersten [sic!].
Ein Grund, warum die heikelste Stelle immer die Übergabe des eingegebenen Keys in die Hashingroutine ist. Da wird sich ganz schön verbogen damit alles im RAM bleibt, nichts geswappt wird und sofort nach Bearbeitung mit 0en überschrieben. Das alles im RAM gehalten werden soll wird bei manchen OS nur Root erlaubt zu bestimmen, was dann wieder bedeutet, das das Paßwortprogramm suid-0 sein muß, was dann wieder selber ein Sicherheitsproblem darstellt.
Hier wird also das Paßwort tatsächlich im Klartext gespeichert. Allerdings nur einmalig und für Sekundenbruchteile und nur im RAM. Nicht für 2 Wochen auf der Platte.

so short

Christoph Zurnieden