nicht angemeldet
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