Ver- / Entschluesseln

[Simon]

Ich bin auf der Suche nach einer Moeglichkeit einen String zu verschluesseln und wieder entschluesseln.

Bevor nun der Rat kommt, dass ich das nicht brauche und man das eingegebene Passwort doch auch verschluesseln kann zum vergleichen:
ICH WEISS! Nur benoetige ich es trotzdem! Fuer eine bestimmte Funktion brauche ich das reine Passwort. Ich muss es in einer Datenbank ablegen und will es daher gerne verschluesseln (mit der Moeglichkeit es entschluesseln zu koennen)!

Jemand eine Idee wie ich das am sichersten anstelle? Das es nicht wirklich sicher ist, weiss ich...

Thx

• Simon

[dedlfix]

MySQL beispielsweise bietet Verschlüsselungsfunktionen an.
Ansonsten findest du sicher hier was brauchbares:
http://de3.php.net/manual/en/ref.mcrypt.php

[TomIRL]

Moin,

MySQL beispielsweise bietet Verschlüsselungsfunktionen an.
Ansonsten findest du sicher hier was brauchbares:
http://de3.php.net/manual/en/ref.mcrypt.php

Da kam ich gerade nicht umhin Dein Posting negativ zu voten :-)
Das Problem ist nicht Ver- sondern Entschlüsseln.
Verschlüsseln da gibs hunderte Varianten und auch viel effektivere als ausgerechnet Mysql.

Zum eigentlichen Problem:
Also wenn Du ein sicheres System benötigst, dann sind sicher richtig zertifizierte Schlüssel der richtige Weg. Wenn Du ohnehin mit diversen Unsicherheiten leben willst, dann denke Dir doch einen Schlüssel aus.
Der einfachste Weg ist sicher die Nummer des Buchstabens im Alphabet mit einer belibigen Anzahl von Zahlen Multiplizieren Addieren oder dividieren.
Klar rauszubekommen ist das Passwort dann sicher....
Vielleicht hat ja hier auch schon einer ein kleines Verschlüsselungssystem gebaut...
TomIRL

[dedlfix]

Moin,

MySQL beispielsweise bietet Verschlüsselungsfunktionen an.
Ansonsten findest du sicher hier was brauchbares:
http://de3.php.net/manual/en/ref.mcrypt.php

Da kam ich gerade nicht umhin Dein Posting negativ zu voten :-)
Das Problem ist nicht Ver- sondern Entschlüsseln.
Verschlüsseln da gibs hunderte Varianten und auch viel effektivere als ausgerechnet Mysql.

Was war denn falsch? Dass ich vergaß explizit zu erwähnen, dass in beiden Fällen neben den Verschlüsselungsfunktionen dort auch Entschlüsselungsfunktionen zu finden sind?

Vielleicht hat ja hier auch schon einer ein kleines Verschlüsselungssystem gebaut...

Moment mal, ich zitiere:

Das Problem ist nicht Ver- sondern Entschlüsseln.

:-)

[Henryk Plötz]

Moin,

Da kam ich gerade nicht umhin Dein Posting negativ zu voten :-)

Dito.

Verschlüsseln da gibs hunderte Varianten und auch viel effektivere als ausgerechnet Mysql.

Hallo, McFly, jemand zu Hause? Hast du dir wenigstens den Link angesehen der in dem Posting war auf das du antwortest. Also ich meine nichtmal die dahinterliegende Seite, einfach nur den URL?

Also wenn Du ein sicheres System benötigst, dann sind sicher richtig zertifizierte Schlüssel der richtige Weg. Wenn Du ohnehin mit diversen Unsicherheiten leben willst, dann denke Dir doch einen Schlüssel aus.

Was unterscheidet 'richtig zertifizierte Schlüssel' deiner Meinung nach von falsch zertifizierten Schlüsseln? Und warum sollte das hier überhaupt eine Rolle spielen?

Der einfachste Weg ist sicher die Nummer des Buchstabens im Alphabet mit einer belibigen Anzahl von Zahlen Multiplizieren Addieren oder dividieren.

Hu? Sowas selbst zu basteln ist deiner Meinung nach einfacher als Example 1 von http://de3.php.net/manual/en/ref.mcrypt.php? Na wenn du meinst ...

Klar rauszubekommen ist das Passwort dann sicher....
Vielleicht hat ja hier auch schon einer ein kleines Verschlüsselungssystem gebaut...

Ja, du wirst dich wundern, das hat schon jemand. Die Leute von mcrypt zum Beispiel ...

[wahsaga]

hi,

Bevor nun der Rat kommt, dass ich das nicht brauche und man das eingegebene Passwort doch auch verschluesseln kann zum vergleichen:
ICH WEISS! Nur benoetige ich es trotzdem! Fuer eine bestimmte Funktion brauche ich das reine Passwort. Ich muss es in einer Datenbank ablegen und will es daher gerne verschluesseln (mit der Moeglichkeit es entschluesseln zu koennen)!

bitte sage uns, um welche seite es sich handelt, damit keiner sich auf einer seite, der ein derartiges gefahrenpotential innewohnt, versehentlich registriert.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

Jemand eine Idee wie ich das am sichersten anstelle? Das es nicht wirklich sicher ist, weiss ich...

Ich denke, du solltest dir diesen Aufwand sparen. Nach meiner Sicht der Dinge würde dein Vorgehen die Sicherheit nicht nennenswert erhöhen:

1. Es gibt einen qualitativen Unterschied zwischen den Hash-Funktionen (die du nicht willst) und wiederherstellbarer Verschlüsselung. Letztere erfordert immer, dass der Ort, an dem die Wiederherstellung geschieht, irgendein Geheimnis in Form eines Passwortes bzw. Schlüssels besitzt.

2. Wenn aber der Ort des Geheimnisses nur ungefähr 1 Zentimeter vom Speicherort der verschlüsselten Passwörter entfernt ist, weil dein Datenbankzugriffsskript und die Datenbank auf demselben Server liegen, dann hat grundsätzlich jeder mit einigermaßen gutem Zugriff auf den Rechner (sprich: Admin-Rechte) die Möglichkeit, an die Passwörter heranzukommen, egal ob die verschlüsselt sind, oder nicht.

3. Daraus folgt, dass es viel wichtiger ist, den Zugriff auf den Server vor Unbefugten zu sichern. Wenn das aber geschieht, kann auch niemand an unverschlüsselte Passwörter gelangen.

Ergo: Der Sicherheitsgewinn durch die wiederherstellbare Verschlüsselung ist sehr gering, es erhöht den Aufwand für einen gut ausgerüsteten Angreifer nur marginal.

- Sven Rautenberg

[Christoph Zurnieden]

Hi,

Bevor nun der Rat kommt, dass ich das nicht brauche und man das eingegebene Passwort doch auch verschluesseln kann zum vergleichen:
ICH WEISS! Nur benoetige ich es trotzdem! Fuer eine bestimmte Funktion brauche ich das reine Passwort.

Das brauchst Du mit Sicherheit nicht, das sieht nur so aus.

Der einzige, der das Klartextpaßwort kennen darf ist der User, alles andere trägt ein zu hohes Risiko mit sich, da würde ich mir überlegen ein anderes System als ausgerechnet Paßwortsicherung zu nehmen.

Ich muss es in einer Datenbank ablegen und will es daher gerne verschluesseln (mit der Moeglichkeit es entschluesseln zu koennen)!

Wenn Du genau sagen würdest wofür, könnte man Dir sicherlich helfen.

Jemand eine Idee wie ich das am sichersten anstelle? Das es nicht wirklich sicher ist, weiss ich...

Warum nimmst Du es dann? Aber gut:

• möchtest Du es automatisiert ablaufen lassen? Das funktioniert gar nicht, da beißt sich die Katze in den eig'nen Schwanz. Wenn Du etwas verschlüsseln möchtest brauchst Du dafür den Klartext T  und den Schlüssel S, das ergibt den verschlüsselten Text K, möchtest Du das wieder entschlüsseln brauchst Du dafür den Schlüssel S und den verschlüsselten Text K. Wenn das automatisch gehen soll braucht der Automat also beide Male den Schlüssel S, wo soll der gespeichert werden? Am besten wird der verschlüsselt gespeichert, oder? Wenn Du etwas verschlüsseln möchtest ...

• halbautomatisch? Das ginge mit normaler asymmetrischer Verschlüsselung, der Entschlüssel-Schlüssel liegt dann bei Dir. Verschlüsseln geht so automatisch, entschlüsseln bedarf Deines Eingriffes. Die Verifikation des Paßwortes muß hierbei jedoch unterbleiben, d.h. es darf dem Verschlüsseler nicht bekannt sein, ob das zu verschlüsselnde Paßwort korrekt ist.

Eine Möglichkeit gäbe es noch: wenn der Schlüssel S_{Entschlüsseln} dem Paßwort entspricht und S_{Verschlüsseln} auf dem Server liegt (Klartext T aus /dev/random ziehen) . Was so ein System außer Kopfschmerzen bringen soll weiß ich aber nicht.

Beschreibe am Besten erstmal genau was Du vorhast, dann finden wir hier schon eine Lösung.

so short

Christoph Zurnieden

[Simon]

Ich hab befuerchtet, das sowas passiert.

Das ganze ist nicht fuer eine Community mit hunderten von Leuten gedacht! Das ist fuer eine kleine Gruppe, die einen Internen Bereich auf einer Seite haben und dort ein paar kleine Tools bekommen! Und bei einer bestimmten Einstellung eines kleinen Tools muss halt das Passwort gemerkt werden! Jedoch auch nur fuer einen Zeitlich begrenzten Rahmen (ca. zwei Wochen...)!

Und NEIN! Es geht nicht anders. Bin mit da 100%ig sicher!

Aber besten Dank an die (brauchbaren) Tippgeber...

• Simon

[Christoph Zurnieden]

Hi,

Ich hab befuerchtet, das sowas passiert.

Wir auch, Herr Kollege, wir auch.

Das ganze ist nicht fuer eine Community mit hunderten von Leuten gedacht! Das ist fuer eine kleine Gruppe,

Das spielt rein gar keine Rolle.

die einen Internen Bereich auf einer Seite haben und dort ein paar kleine Tools bekommen! Und bei einer bestimmten Einstellung eines kleinen Tools muss halt das Passwort gemerkt werden!

Das ist ein schwerer Fehler im Konzept und zu reparieren.

Jedoch auch nur fuer einen Zeitlich begrenzten Rahmen (ca. zwei Wochen...)!

Spielt hier nur eine sehr untergeordnete Rolle.

Und NEIN! Es geht nicht anders. Bin mit da 100%ig sicher!

Ich bin mir 100%ig sicher, das es anders geht. So sicher, das ich darauf ein Jahresgehalt verwette. Bruce Schneier als Schiedsrichter? (Falls er sich für sowas gewinnen läßt natürlich)

Aber besten Dank an die (brauchbaren) Tippgeber...

Ich kann also davon ausgehen, das Du trotz der erfolgten Hinweise nichts reparieren wirst? (Das hier wahrscheinlich auch gar nicht mehr liest) Du bist Dir darüber im Klarem, das es nun Vorsatz ist und Du so wahrscheinlich noch nicht einmal mehr mit "grober Fahrlässigkeit" durchkommst? Das kann dann im Fall der Fälle und ein wenig Pech zu heftigen Schadenersatzforderungen führen!

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Und NEIN! Es geht nicht anders. Bin mit da 100%ig sicher!

Ich bin mir 100%ig sicher, das es anders geht. So sicher, das ich darauf ein Jahresgehalt verwette. Bruce Schneier als Schiedsrichter? (Falls er sich für sowas gewinnen läßt natürlich)

Ruhig, Brauner. Es ist ja schon bei handelsüblichen Challenge-Response-Systemen (etwa HTTP Digest Auth) so dass auf dem authentifizierenden Server ein Klartextpasswort oder etwas vergleichbares nötig ist[1]. Und schlimmer noch: Wenn sich der Server einem anderen System gegenüber ausweisen soll und dieses nicht modifiziert werden kann, dann gibt es halt nicht wirklich einen anderen Weg. Oder willst du behaupten etwa GMX könnte einen POP3-Sammeldienst anbieten ohne die Passwörter der abzufragenden Accounts zu kennen? (Wie gesagt: "wenn das andere System nicht modifiziert werden kann")

Was die Verschlüss^WVerschleierung angeht: Das ist in vermutlich mehr als 50% der Fälle in der Tat sinnfrei. Es gibt aber einige Ausnahmen, insbesondere wenn das Skript mit dem Schlüssel und die Datenbank mit dem Geheimtext in unterschiedlichen Sicherheitskontexten laufen (was ja quasi immer der Fall ist). Ein anderer Benutzer auf dem System könnte möglicherweise ausreichend Kontrolle über das Datenbanksystem erlagen um die Datenbank zu lesen, hat damit aber noch nicht automatisch Kontrolle über das Skript. (Ja, gegen den Admin ist man _natürlich_ machtlos.) Ein anderes Szenario könnte zum Beispiel sein, dass die Datenbank ausgeführte Kommandos (also auch INSERTs) aus irgendeinem Grund mitloggt (etwa um unperformante Queries ausfindig zu machen) und diese Logs nicht mit der selben Sorgfalt behandelt werden wie die Datenbankdateien selbst. Und last but not least soll es ja hin und wieder mal vorkommen dass Datenbankdumps an den unmöglichsten Stellen auftauchen, die dazugehörigen Skripte aber nicht.

[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. Microsofts IIS speichert dann auch lieber gleich das Klartextpasswort (in einem AD, zugegeben) vermutlich um nicht für jeden Realm einen extra-Hash anlegen zu müssen.

[Christoph Zurnieden]

Hi,

Und NEIN! Es geht nicht anders. Bin mit da 100%ig sicher!

Ich bin mir 100%ig sicher, das es anders geht. So sicher, das ich darauf ein Jahresgehalt verwette. Bruce Schneier als Schiedsrichter? (Falls er sich für sowas gewinnen läßt natürlich)

Ruhig, Brauner.

Ich bin die Ruhe in Person, ich könnt' Hologramme auf der ausgestreckten Hand belichten! ;-)

Es ist ja schon bei handelsüblichen Challenge-Response-Systemen (etwa HTTP Digest Auth) so dass auf dem authentifizierenden Server ein Klartextpasswort oder etwas vergleichbares nötig ist[1].

OP wollte "etwas Sicherheit", "etwas" ist eindeutig größer als 0, oder nicht?

Und schlimmer noch: Wenn sich der Server einem anderen System gegenüber ausweisen soll und dieses nicht modifiziert werden kann, dann gibt es halt nicht wirklich einen anderen Weg.

Aber nur unter der Bedingung, das nichts modifiziert werden kann und Sicherheit keine Rolle spielt.

Oder willst du behaupten etwa GMX könnte einen POP3-Sammeldienst anbieten ohne die Passwörter der abzufragenden Accounts zu kennen? (Wie gesagt: "wenn das andere System nicht modifiziert werden kann")

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.

Einfacher Workaround dafür: Forward _von_ den Einzelaccounts _nach_ GMX und nicht umgekehrt.

Was die Verschlüss^WVerschleierung angeht: Das ist in vermutlich mehr als 50% der Fälle in der Tat sinnfrei.

Das dürften wohl eher 100% sein. Einzige Möglichkeit wäre das Herausschinden von Zeit. So ist der private Schlüsselring von GnuPG mit 128 Bit sym. verschlüsselt (darf jetzt auch etwas mehr sein, ändert aber nicht viel). Das ist nicht wirklich sicher. Aber es erfordert ein paar Minuten, das zu knacken. Das reicht normalerweise seine Public-Keys für ungültig zu erklären. Da dafür aber auch mehr oder weniger _sofort_ nach Einbruch und Diebstahl des Schlüsselrings reagiert werden muß ist das ein _zusätzliches_ Hindernis, mehr nicht. Zudem ist das Paßwort für diesen "Safe" nicht gleichzeitig und auch noch als Klartext gespeichert.

Es gibt aber einige Ausnahmen, insbesondere wenn das Skript mit dem Schlüssel und die Datenbank mit dem Geheimtext in unterschiedlichen Sicherheitskontexten laufen

Das ist schön und auch löblich, aber Klartext ist Klartext, ist zu vermeiden und es gibt da im Regelfall auch Möglichkeiten zu. Glaubt man eine Ausnahme dazu gefunden zu haben, ist irgendwo ein Fehler im Konzept.

(was ja quasi immer der Fall ist).

Sollte, ja, aber nach meiner Erfahrung gilt "quasi immer" nur für wirklich sehr große Werte von "selten". Was ich da schon mitunter gesehen habe ... *sigh*

Ein anderer Benutzer auf dem System könnte möglicherweise ausreichend Kontrolle über das Datenbanksystem erlagen um die Datenbank zu lesen, hat damit aber noch nicht automatisch Kontrolle über das Skript.

Ich gehe mal davon aus, das Du nicht meinst, das hier Script und DB auf dem gleichem System sind, oder? Dann ist eh keine saubere Trennung möglich. Deine Einschränkung

(Ja, gegen den Admin ist man _natürlich_ machtlos.)

entfällt, da das Risiko einer Sicherheitslücke mit Möglichkeit zur "privilege escalation" nicht 0 ist, dafür müßte Root entsorgt werden. Nur physische Trennung (zwei Boxen - die Möglichkeit des Prozessorsharings auf "richtiger" Hardware ignoriere ich hier einmal - mit zwischengeschalteter Firewall) kann dafür sorgen.
Dann hast Du bei gespeicherten Klartextpaßwörtern noch das Problem bei direktem Hardwarezugriff.

Ein anderes Szenario könnte zum Beispiel sein, dass die Datenbank ausgeführte Kommandos (also auch INSERTs) aus irgendeinem Grund mitloggt (etwa um unperformante Queries ausfindig zu machen) und diese Logs nicht mit der selben Sorgfalt behandelt werden wie die Datenbankdateien selbst.

Kein Problem, wenn das Paßwort verschlüsselt gespeichert ist? Klar, aber auch _nur_ für den oben beschriebenen Fall. (Bei sensiblen DB-Daten ist der Log eh asymetrisch zu verschlüsseln)

Und last but not least soll es ja hin und wieder mal vorkommen dass Datenbankdumps an den unmöglichsten Stellen auftauchen, die dazugehörigen Skripte aber nicht.

Ja, man vergißt immer leicht den menschlichen Faktor dabei. Der ist deshalb so weit wie möglich auszuschließen. Das Autodiebstahl verboten ist hindert mich ja schließlich nicht daran es abzuschließen, oder? ;-)

[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.

Microsofts

Äh ... MS' Verhalten zu zitieren, wenn es sich um Sicherheitsfragen handelt ist eher keine gute Idee, oder?
(Anders, wenn es sich um Aussagen einzener Mitarbeiter handelt, die sind individuel zu behandeln, ein Generalverdacht lehne ich dabei ab.)

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

Was macht das für einen Unterschied?

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

Faulheit ist kein Grund.

Aber ist eh alles müßig, da der OP nicht gesagt hat, wofür er es braucht. Aus welchen Gründen auch immer. Kryptanalyse macht also mangels Masse keinen Sinn.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

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. 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. 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.

[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 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, mit dem einzigen wirklichen Unterschied dass die Wahrscheinlichkeit dass das gleiche Passwort bei einem anderen realm gültig ist nahe null liegt. Dieser Hash wird dann beim Authentifizierungsvorgang zusammen mit einer handvoll anderen Werten (hauptsächlich nonces) nochmal gehasht und das dann als Response übergeben.

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.

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

Faulheit ist kein Grund.

Das ist weniger Faulheit als Managebarkeit. 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. Im IIS-Modell kann man die Benutzer frei hin- und herschieben und verwalten. 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.

[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

[Simon]

Nur damit du dich nun nicht bestaetigt fuehlst. Ich habs gelesen. ;)

Und nein es ist nicht wirklich anders machbar... Es geht darum das sich das Script einem fremden Dienst gegenueber identifizieren muss. Und die koennen halt nur was mit dem echten passwort anfangen!

[Christoph Zurnieden]

Hi,

Nur damit du dich nun nicht bestaetigt fuehlst. Ich habs gelesen. ;)

Dir war aber schon klar, das ich das schrieb, um genau diese Reaktion hervorzurufen? ;-)

Und nein es ist nicht wirklich anders machbar... Es geht darum das sich das Script einem fremden Dienst gegenueber identifizieren muss. Und die koennen halt nur was mit dem echten passwort anfangen!

Und warum soll das ein Grund sein das Paßwort zu speichern? Nein, tut mir leid, aber mit so vagen Angaben bleibe ich bei meiner Wette. Nicht zu vergessen: der einzige, der das Paßwort im Klartext kennen darf ist und bleibt nur der User! (Das prinzipielle Problem dabei ist im anderem Posting beschrieben)

Warum weigerst Du Dich eigentlich so standhaft Details preiszugeben? Nein, keine Namen o.ä., das wird nicht benötigt - Dein Wunsch nach Anonymität ist selbstverständlich, soweit technisch möglich, zu beachten - nur eine genaue Beschreibung des Problems.

Schließlich kennst Du Dich mit Kryptographie überhaupt nicht aus (sonst hättest Du ja nicht gefragt, oder? ;-), da sollte man eigentlich annehmen, das Du die angebotene Hilfe nicht derart vehement ausschlägst. Du sagst sogar noch selber, das Deine Idee Mist ist, weigerst Dich aber fast schon holzköpfigt an Alternativen auch nur zu denken.
Es gilt übrigens die Regel, das die Kryptanalayse eines Programmes niemals der Programmierer selber erstellen darf. Das heißt hier, das Du Dein Schema veröffentlichen solltest (hier z.B., ideal wäre aber natürlich sci.crypt), damit sich die Hyänen^WKryptanalysten drüber hermachen können. Das alles kostet Dich nicht mehr als ein wenig Mühe beim Beschreiben des Schemas (und evt Übersetzung falls sci.crypt) und ein paar Tage Zeit, aber nicht einen einzigen Cent (gut, Onlingebühren, klar, aber wir wollen mal ausnahmsweise nicht so kleinlich sein ;-)

so short

Christoph Zurnieden