Proxy Passwort

[aker]

Es gab doch eine Diskussion über die Speicherung von Proxy Passwörtern, was dazu führte, dass diese nicht mehr unverschlüsselt in der UpdateGenerator.ini stehen.
Wäre eine Implementierung, bei der die Passwörter vor dem Speichern verschlüsselt werden, in Ordnung?
Ich habe ein VB.NET Programm, dass eine Verschlüsselung vornehmen könnte. Das Ergebnis wäre ein für ein menschliches Auge unverständlicher String (evtl. auch eine ganze Adresse [http://User:passwort@server:Port/ => http://User:string@server:Port/]). Die Verschlüsselung ist umkehrbar, sodass ein bestimmter Aufruf das Passwort wieder sichtbar machen würde oder sofort den Download mit den korrekten Proxy-Daten aufrufen würde.

Viele Grüße

[boco]

Ist es Verschlüsselung oder nur Verschleierung?

[aker]

Eine Verschlüsselung mithilfe des Rijndael Algorithmus.

Viele Grüße

[boco]

Wenn der Verschlüsselungs-Key statisch ist, nützt die Verschlüsselung wenig. Die Lizensierung unter GPL verlangt, daß alles veröffentlicht werden muß, inklusive Key. Ist er dagegen wählbar oder wird für jedes System generiert (gute Idee), ist das was anderes.

Nur eine Anmerkung: Über den Satz

Die Verschlüsselung ist umkehrbar, sodass ein bestimmter Aufruf das Passwort wieder sichtbar machen würde oder sofort den Download mit den korrekten Proxy-Daten aufrufen würde.

mußte ich schmunzeln. Wenn eine Verschlüsselung nicht mehr umkehrbar ist, kommt niemand mehr an die Daten, auch nicht der, der sie benötigt. Das ist in manchen Fällen gewünscht, ist aber hier kontraproduktiv, oder?

[aker]

Sie ist umkehrbar, sonst käme das Programm selbst auch nicht mehr an das Passwort. Damit meinte ich, dass ein Aufruf mit Parameter "a" und dem Passwort, das Passwort verschlüsselt zurückgibt, damit es in der ini gespeichert werden kann, bei Parameter "b" und dem verschlüsselten String das Passwort zurückgegeben wird bzw. ein Aufruf der DownloadUpdates.cmd mit dem Passwort stattfindet.
Und wie der Schlüssel festgelegt wird, ist letztendlich egal: ich kann ihn statisch festlegen (z.B. "wsusou"), aber auch eine Funktion schreiben, die den Teilproduktschlüssel, den slmgr.vbs ausgibt, dazu verwendet. Das ist frei gestaltbar. Auch MD5 und SHA1 Hashes wären möglich.
Für Vorschläge, was ich machen könnte, bin ich natürlich offen.

Viele Grüße

[boco]

Wie gesagt, ein statischer Key ist Unsinn da alles veröffentlicht werden muß. Ein potentieller Angreifer hat somit alles in der Hand um in Windeseile die Verschlüsselung auszuhebeln. [offtopic]Diese Diskussion hatten wir im FileZilla Forum auch schon, der oben stehende Fakt ist ein Grund, warum FileZilla keine Passwörter verschlüsselt.[/offtopic]

aber auch eine Funktion schreiben, die den Teilproduktschlüssel, den slmgr.vbs ausgibt, dazu verwendet. Das ist frei gestaltbar. Auch MD5 und SHA1 Hashes wären möglich.

Die Liste, wie der Key generiert werden kann, ist endlos. Hauptsache ist, daß er sich von System zu System unterscheidet.

Möglichkeiten:
-Datum und Zeit oder andere dynamische Variablen als Quelle für einen pseudo-zufälligen Schlüssel nehmen;
-Sammeln von Entropie (Zufallsdaten);
-Einfach den Benutzer wählen lassen;
-Den PC-Namen hashen und kräftig salzen ;
etc. pp.

Aber am besten ist trotzdem das Proxy-Passwort einmal pro Sitzung abzufragen und in einer Umgebungsvariable zu speichern. Selbst wenn WSUSOU kein Cleanup machen kann überlebt diese den Reboot nicht.

[aker]

Ich würde einfach mal abwarten, was der "Chef" dazu sagt.

Viele Grüße

[WSUSUpdateAdmin]

Moin!

Hmm, ich weiß nicht, ist die Kanone nicht ein bisschen zu groß für den Spatz?

Ich meine,

• wer von unseren Benutzern arbeitet mit einem Proxy,
• wer von diesen arbeitet mit einem Proxy, der Authentifizierung erfordert,
• wer von diesen arbeitet auf einem System bzw. in einem Teil des Filesystems, auf das/den mehrere Benutzer Zugriff haben,
• wer von diesen verwendet dafür ein Passwort, das nicht im Klartext gespeichert werden darf und
• für welche dieser Benutzer ist die existierende Lösung (":@") nicht zumutbar?

Gruß
Torsten

[Markus]

Moin!

Hmm, ich weiß nicht, ist die Kanone nicht ein bisschen zu groß für den Spatz?

Ich meine,

• wer von unseren Benutzern arbeitet mit einem Proxy,
• wer von diesen arbeitet mit einem Proxy, der Authentifizierung erfordert,
• wer von diesen arbeitet auf einem System bzw. in einem Teil des Filesystems, auf das/den mehrere Benutzer Zugriff haben,
• wer von diesen verwendet dafür ein Passwort, das nicht im Klartext gespeichert werden darf und
• für welche dieser Benutzer ist die existierende Lösung (":@") nicht zumutbar?

Gruß
Torsten

Dem kann ich mich einfach nur anschließen. Die Diskussion ist wirklich etwas (imho) an den Haaren herbeigezogen.

[-Iwan-]

Nur mal so nebenbei: WSUSOU wird nicht nur privat genutzt
Ich sitze auch hinter einem Proxy, der Authentifizierung verlangt (und das zurecht).
Allerdings haben wir einen WSUS und SCCM in Einsatz, der uns das aktualisieren abnimmt.
Bei Neuinstallationen sind die wichtigstens Updates bereits im Win7-Image und Office integriert.
Lediglich bei Ausnahmen (Rechner, die gar nicht oder selten am Netz hängen) greifen wir auf WSUSOU zurück.
Das aktualisiere ich einmal wöchentlich auf einem Rechner, der per DSL direkt im Inet hängt.
Das client-Verzeichnis schubse ich dann manuell auf einen Rechner, wo die anderen Kollegen dann drauf zugreifen können.