Grundsatzüberlegungen zum Thema Speichern von Passwörtern

[Codehunter]

Hallo!

Nachdem die SuFu zu "Passwort speichern" knapp 450 Treffer liefert und nach ca. 30 Minuten noch nichts wirklich erquickliches dabei war, will ich doch mal einen neuen Thread aufmachen.

Angenommen, ich habe ein FTP-Programm bzw. schreibe eines. Darin will man als User ja seine FTP-Accounts hinterlegen. Zu jedem Account gibt es üblicherweise ein Passwort. Dieses soll verschlüsselt in einer Datei auf dem lokalen Rechner gespeichert werden. Soweit ist das ja nichts weltbewegendes, kann jedes x-beliebige FTP-Programm.

Was mich jetzt prinzipiell wundert: Keines der mir bekannten FTP-Programme fragt mich jemals nach einer Art Masterpasswort. Daraus folgt doch eigentlich, dass die Methode zur Verschlüsselung der Passwörter mehr oder weniger hartcodiert sein muss und die Sicherheit dabei vorrangig auf "Security by Obscurity" basiert. Oder mache ich einen Denkfehler?

Nehmen wir als Beispiel mal Dreamweaver. Da liegen die ganzen FTP-Accounts als Untermenge der Site-Konfiguration in Dateien vor. Wenn man weiß wo die Dateien liegen kann man sie einfach von einem Rechner zum nächsten kopieren und das dortige Dreamweaver hat alle Daten um sich mit FTP verbinden zu können. Insofern hat man zwar nie das FTP-Passwort im Klartext aber zumindest Zugang zum Server.

WS_FTP scheint bei der Verschlüsselung etwas kleverer zu sein. Hier werden die Passwörter anscheinend mit irgendwelchen Informationen verschlüsselt, die vom jeweiligen Rechner abgeleitet werden. Kopiert man die Account-Dateien auf einen anderen Rechner funktionieren die FTP-Logins nicht mehr. Genauso, wenn man das Windows auf dem eigenen Rechner neu aufsetzt und die gebackupten Account-Dateien zurückspielt.

Beide Varianten sind für mich nicht so recht befriedigend. Erstere ist unsicher, keine Frage. Die zweite ist sicherer, sabotiert aber prinzipbedingt die Funktion von Backups für den Fall einer Windows-Neuinstallation oder Austausch von Hardwarekomponenten an deren Vorhandensein die Entschlüsselung gekoppelt ist.

Angenommen, ich möchte bei meinem Programm ebenfalls auf die Notwendigkeit eines Master-Passwortes verzichten. Welche Möglichkeiten gibt es, Passwörter halbwegs sicher zu verschlüsseln und das verschlüsselte Resultat portabel zu halten? Je mehr ich darüber nachdenke umso weniger erscheint mir das möglich, wobei ich kein Krypto-Experte bin.

[jfheins]

Ich habe das damals wie folgt gemacht:

Delphi-Quellcode:

Base64Encode(RCxEncode(PassEdit.Text, UserEdit.Text))

Das Passwort wurde also mit dem FTP-benutzernamen verschlüsselt und gespeichert. Damit ist es natürlich so dass die gleiche Datei überall anderes ebenso funktioniert. Die Hauptfunktion war aber eben auch, die Passwörter nicht im Klartext zu speichern. Ein netter Nebeneffekt dieser Methode (also den Usernamen einzubeziehen) ist, dass identische Passwörter oft nicht identisch gespeichert werden. (Mal abgesehen von anonymous/anonymous)

So als mögliche Vorgehensweise könntest du das Passwort mit der Windows UID verschlüsseln: Wenn man den Rechner von nem Backup wiederherstellt wird diese auch wieder die gleiche sein. Auf anderen Rechnern (oder auch für andere Benutzer auf dem gleichen PC) sind diese dann nicht direkt sichtbar wenn man die Datei kopiert.

[mentaltec]

Hi

die Sicherheit wird wohl hauptsächlich darauf beruhen, dass nicht autorisierte Nutzer/Prozesse keine Leserechte an der PW-Datei haben.
Wenn dem so ist, sind wir schon mal ganz weit vorn!
alles Andere - wie Verschlüsselung - dient hauptsächlich dazu, dem Administrator/Hacker den Zugriff zu verwehren; inwieweit das sinnvoll
ist, muss jeder selbst wissen; wenn jemand die Maschine gehackt hat, ist was ganz anderes faul und ein Admin ist ein Admin ist ein Admin!

bei Windows wird (glaub ich) aus den Anmeldedaten ein Accessytoken erzeugt, mit dem man einen reproduzierbaren Key für diverse Verschlüsselungsgeschichten generieren kann - aber wenn ein Angreifer die Anmeldung am System auskundschaften kann (z.B. autologin), kann er auch das Token nachbauen
will man eine (PW)-Datei an ein System binden, geht das laut Lehrbuch über TPM oder auch CPUIID / HDDID / oder für ganz Leichtgläubige über MAC-Adressen

weiterführende Literatur:

Access Tokens
Security Descriptors
Securable Objects

mfg

[Mschmidt]

Nun ja - grundsaetzlich scheint mir das speichern von Kennwoertern - egal wie - ein Sicherheitsrisiko zu sein. Und irgentwie kontakariert das Speichern der Kennwoerter deren Sinn : Die Autentifizierung des Anwenders.
Ich kann mir nicht sicher sein, ob das das Kennwort vom Anwender kommt, oder von der Platte.
In meinen entwickelten Anwendungen muss daher der Anwender immer sein usr/pwd eingeben, es sei denn, ich kann die Windowsanmeldung verwenden ( sspi, etc.)
Cheers mathias

[implementation]

In welcher Form das in der Datei steht, ist doch eigentlich relativ wurscht, solange nur die Personen Zugang zu ihr haben, die ihn auch haben sollen. Dazu wichtig wäre ja primär die Rechteverwaltung des Datei- und Betriebssystems.
Das hilft natürlich nichts, wenn jemand sich einfach deine Festplatte schnappt, oder von CD/Memory-Stick was anderes bootet. Aber wenn deine FTP-Daten sensibel sind, dann wirst du sicherlich auch andere sensible/persönliche Daten auf der Platte haben, ergo solltest du sowieso Systemvoll- oder zumindest Heimatverschlüsselung haben.

Aber wenn es wirklich reines FTP ist, und dein Rechner geknackt wurde, dann hilft jede Verschlüsselung des Passworts doch eh nichts. Dann haut der Cracker 'nen Netzwerkrecorder drauf und schneidet mit, welche Daten der Client an den Server schickt.² Im Protokoll ist das Passwort eh Klartext. Also sollte es eigentlich auch keine großen Sorgen bereiten, sie gleich in Klartext abzuspeichern.¹



¹) Wie ich gerade sehe, macht Filezilla genau das.
²) Gleiches, wenn jemand deine (unverschlüsselte) HDD hat. Eine gewisse Datei ersetzen, dann klappt die Windows-Authentifizierung nicht mehr, man kann sich als du einloggen, Netzwerkrecorder einschalten, und mit dem FTP-Client verbinden. Dann hat er das Passwort, egal wie clever du sonst vorgehst.


Fazit: Wenn du Sicherheit willst, musst du schon irgendwo ein Master-Passwort (oder 'ne Keyfile auf'm USB-Stick, Magnetkarte, etc.) einbringen und ein anderes Protokoll wählen. Alles andere ist nur Placebo.

Edit: Oder war FTP nur ein Beispiel und es geht gar nicht darum? Dann solltest du dir unbedingt überlegen, inwiefern ähnliche Szenarien auch bei deinem Programm möglich sind!

[r2c2]

Grundregel Security: Überlege dir genau vor was du dich schützen willst. Mach dir ne Liste mit möglichen Angreifern und möglichen Angriffsszenarien [1]. Wenn du die Liste hast, kannst du dir überlegen, wogegen du dich überhaupt schützen kannst (wenn jemand die Festplatte klaut, kannst du als FTP-programm nicht viel dagegen tun. Das Mittel dagegen ist die Platte zu verschlüsseln. Aber das ist nicht Aufgabe eines FTP-Programms, also weiter... So in der Art. Damit kannst du dir dann ein sinnvolles Sicherheitskonzept ausarbeiten [2].

Kurz aus dem Bauch heraus: Nein, ohne eine Form von Masterpasswort wirst du nicht wirklich sicherer sein, als mit ner einfachen Verschleierung. Prinzipbedingt nicht.

mfg

Christian

[1] Man kann das auch noch systematischer machen. Attack Trees, FMECA, ... Im einfachsten Fall reicht aber auch ne Liste.
[2] Das hört sich jetzt einfach an, ist es aber leider nicht.

[stOrM]

Zitat:

Was mich jetzt prinzipiell wundert: Keines der mir bekannten FTP-Programme fragt mich jemals nach einer Art Masterpasswort. Daraus folgt doch eigentlich, dass die Methode zur Verschlüsselung der Passwörter mehr oder weniger hartcodiert sein muss und die Sicherheit dabei vorrangig auf "Security by Obscurity" basiert. Oder mache ich einen Denkfehler?

Nö da denkst du völlig richtig. Ich nutze FlashFXP das fragt auch nie nach einem PW. Die Accountdaten liegen zwar verschlüsselt in der Sites.dat wobei das nicht wirklich ein Hindernis darstellt. Diverse units zum endschlüsseln findest du dazu im Inet für Delphi. Sicherheit sieht wohl anders aus :shock:

[Codehunter]

Die größte Sicherheitslücke ist immer der menschliche Faktor. Vermutlich kommt man doch inzwischen an die Grenzen des menschlich Machbaren. Man soll überall ein anderes, möglichst kompliziertes Passwort verwenden und dieses dann nirgendwo speichern oder aufschreiben. Bedenkt man die schiere Masse der Logins, mit denen man im IT-Alltag zu tun hat, dann ist das eigentlich gar nicht machbar. Wenn dann noch jemand auf die Idee kommt, Komplexitätsregeln und Wechselzyklen zu verlangen (z.B. die Standardeinstellung beim Windows Server 2008) dann ist man endgültig außerhalb des Beherrschbaren. Also braucht man technische Hilfsmittel, um Zugangsdaten zu verwalten.

Ich bin zwar grundsätzlich über den Anwendungsfall FTP auf das Problem aufmerksam geworden aber im Grunde betrifft es ja jede Art von Programm, dass seinerseits mehrere Logins anderer Dienste verwaltet.

FTP ist sicherlich ein ungünstiges Beispiel, da wie schon richtig bemerkt das Passwort im Klartext an den FTP-Server weitergereicht wird. Es ist eben ein Dinosaurier der Netzwerkprotokolle. SFTP soll die Probleme ja beheben.

Man könnte auch Instant Messenger wie Trillian oder diverse News-Push-Anwendungen als Beispiele anführen. Viele speichern die Passwörter der einzelnen Accounts *irgendwo* mit *irgendeiner* Verschlüsselung ohne Masterpasswort.

Das ist wohl in erster Linie dem Bestreben nach Usability geschuldet. Faktisch kollidiert diese aber mit der Sicherheit der Passwörter.

Richtig ist meiner Ansicht nach, dass JEDE reversible Verschlüsselung von Passwörtern ein Sicherheitsrisiko darstellt. Aber prinzipbedingt müssen derartige Programme genau das tun, denn nur das entschlüsselte Passwort lässt sich richtigerweise zum Login an die entsprechenden Dienste weiterreichen.

Ich persönlich finde es komfortabel, wenn man das Masterpasswort als eine Art Zufalls-Token generiert und auf einem USB-Stick hinterlegt. Man kann ja relativ viele Hardwaredaten aus dem Stick auslesen, sodass man das Token genau an diesen einen Stick koppeln kann. So ähnlich macht das glaub ich KeePass. Dann darf nur nicht der Stick kaputt oder verloren gehen sonst hat man datentechnischen Brettschiss ;-)

Ich bin einfach an euren Meinungen interessiert, welche grundsätzliche Herangehensweise man anwenden sollte.

[mentaltec]

Hi

bis jetzt hast Du uns ja noch nichtmal verraten, auf welcher Plattform sich das abspielt.
als Client Im Windows sollte das idR so laufen: wenn Du Dich das erste Mal mit einem Server verbindest, werden die eingegebenen Anmeldedaten im KeyTresor des users gespeichert, der zZt. angemeldet ist
gugg ma unter Systemsteuerung/Benutzerkonten/Anmeldeinformationsverwaltung und dort generische Anmeldeinformationen
dort landen imho auch die Kryptokeys/Zertifikate für verschlüsselte Verzeichnisse

wenn Du hingegen einen Server hast, speichert der nicht die Klartext-Anmeldeinformationen, sondern die, durch eine Einwegfunktion mit Salz erzeugten Hashes ; will ein Client nun Zugriff, wird seine Anweldung auch gehasht und dann mit der "shadow" verglichen

mfg mentaltec

[p80286]

Worauf willst Du hinaus?
Eine eigene Anwendung mit eigenem Passwort?
Dann mach es doch so wie "alle" das was ein Passwort sein soll, durch eine Hash-Funktion und dann mit den vorhandenen (gehashten)Passwörtern vergleichen.

Willst Du Deine Passwörter irgendwo ablegen/speichern/dokumentieren?
auf einem Zettel mit einem 8bittigen prefix und postfix in Base16 notieren und den Zettel immer im linken Socken verwaren.

Gruß
K-H

[Delphi-Laie]

Zitat:

Zitat von Codehunter (Beitrag 1211015)

Was mich jetzt prinzipiell wundert: Keines der mir bekannten FTP-Programme fragt mich jemals nach einer Art Masterpasswort. Daraus folgt doch eigentlich, dass die Methode zur Verschlüsselung der Passwörter mehr oder weniger hartcodiert sein muss und die Sicherheit dabei vorrangig auf "Security by Obscurity" basiert. Oder mache ich einen Denkfehler?

Ich verstehe das so, daß - abhängig von einem ggf. einzugebenden Masterpaßwort - die Paßwörter unterschiedlich codiert sein können.

Diese "hardcodiert" ist dann m.E. aber dennoch vorhanden, sprich: Der Verschlüsselungsalgorithmus. Nur gibt es eben (flexiblere) Algorithmen, die - abhängig von weiteren Eingaben, hier eben dem Masterpaßwort - zu anderen Verarbeitungen und damit Ausgaben führen können.

Stimmen Paßwort und Masterpaßwort überein, so ist auch das verschlüsselte Paßwort dasselbe (Verschlüsselungsalgorithmen müssen nach meinem Verständnis determiniert arbeiten, sonst wäre Entschlüsselung doch gar nicht möglich). Ist also nur eine Verlagerung des Problems auf eine Metaebene.

[jfheins]

Zitat:

Zitat von Delphi-Laie (Beitrag 1211119)

Stimmen Paßwort und Masterpaßwort überein, so ist auch das verschlüsselte Paßwort dasselbe (Verschlüsselungsalgorithmen müssen nach meinem Verständnis determiniert arbeiten, sonst wäre Entschlüsselung doch gar nicht möglich). Ist also nur eine Verlagerung des Problems auf eine Metaebene.

Nö. Wenn man das Passwort im Kalrtext, oder base64enkodiert oder ohne Masterpasswort verschlüsselt, dann befinden sich alle Informationen die man zum Entschlüsseln benötigt auf der Festplatte.
Mit einem Masterpasswort hingegen wäre der Benutzer gezwungen dieses jedes Mal einzugeben. Die Information zum Entschlüsseln befindet sich also nicht auf der HDD. (Sondern ggf. auf dem Post-it am Monitor)

"Klaut" jetzt also ein Trojaner die config-datei kann der Angreifer damit erstmal nichts anfangen da er das Passwort nicht kennt. ==> Zusätzliche Sicherheit

[Aphton]

Edit: Zu undurchdacht

[sx2008]

Mein Vorschlag sieht so aus:

1.) man legt ein Masterpasswort fest; dies kann entweder hartcodiert in der Anwendung sein oder von Aussen kommen
2.) man berechnet

Delphi-Quellcode:

masterkey := MD5(masterpasswort)

3.) man erzeugt für jeden Vorgang einen "randomkeystring" (3 - 10 Zeichen)

Delphi-Quellcode:

key := MD5(masterkey + randomkeystring);

4.) dieser "key" hat eine Länge von 16 Bytes.
Damit wir auch Passwörter mit mehr als 16 Zeichen verschlüsseln können, wird der key verlängert:

Delphi-Quellcode:

key := key + MD5(key);

Damit hat der key eine Länge von 32 Bytes.
Diese Art der Verlängerung kann wiederholt werden um so einen key mit 48 oder 64 Bytes zu erhalten.
5.) das zu verschlüsselnde Passwort wird auf mindestens 32 Zeichen verländert

Delphi-Quellcode:

if Length(password) < 32 then
   paddedPW := copy(password+#0+Randomstring2, 1,32)
else
   paddedPW := password;

6.) das verlängerte Passwort wird nun einfach mit dem Key XOR verknüpft

Delphi-Quellcode:

cryptedPW := XORstring(key, paddedPW);

7.) gespeichert wird so

Code:

$randomkeystring$cryptedPW$

Die Dollarzeichen dienen dazu, die beiden Teilstücke später wieder zu trennen.
Das cryptedPW muss hexadezimal codiert werden weil es ja alle Zeichen zwischen #0 bis #255 enthalten kann.

Vorteile:
* ohne Kenntniss des masterpassworts oder masterkeys ist die Verschlüsselung kaum zu knacken (zumindest nicht wirtschaftlich lohnend)
* selbst wenn alle FTP-Passwörter = "123456" sind entsteht durch den randomkeystring jedesmal eine neue Verschlüsselung
* da das zu verschlüsselnde PW auf 32 Zeichen verlängert wurde, kann der Angreifer nicht erkennen wie lange das ursprüngliche PW ist

[Codehunter]

Wenn das Masterpasswort schon hartcodiert wäre, dann müßte wenigstens ein "komplizierter" Algorithmus dafür sorgen, dass die als Ausgangswerte verwendeten Daten nochmal ordentlich "verwurschtelt" werden bevor der daraus entstehende Key als Passwort für den eigentlichen "Passwort-Safe" verwendet wird.

Die Idee, die zu verschlüsselnden Daten künstlich zu verlängern kam mir auch schon. Mit langen Keys verschlüsselt wird das eine harte Nuss, selbst für hardwarebeschleunigte Passwortknacker. Allerdings wäre ich nicht auf die Idee gekommen, XOR zum Verschlüsseln zu verwenden. Eher was schickes aus dem DEC. Vielleicht sogar 16 verschiedene Verschlüsselungsalgorithmen und das erste Byte des MD5-Hashes vom eigentlichen Masterpasswort entscheidet, welche davon verwendet wird. Die nächsten vier Bytes entscheiden, wie viele Runden verschlüsselt wird. Hach ja, da kann man sich mal richtig austoben ^^

Aber dieses ganze Prinzip kann man nur dann als halbwegs sicher ansehen, solange der Rechner auf dem die Anwendung läuft nicht kompromittiert ist. Andernfalls gibt es immer Möglichkeiten, die entschlüsselnde Anwendung zu belauschen. Dann bräuchte man die Daten nicht mal aufwendig knacken, man holt sich alles aus dem Speicher der laufenden Anwendung.

[r2c2]

Sry, aber so wird das nichts. Entschuldigung, wenn ich das so direkt sage, aber das hier ist blindes Security-Rumgerate und und das führt zu allem nur nicht zu einem sicheren System.

- Mein Post von oben, war durchaus ernst gemeint und nicht nur "guckt mal her, was ich alles im Studium gelernt habe". Wenn man nicht weiß, vor was man sich schützen will, braucht man gar nicht erst anzufangen. Also @Codehunter: Wenn du wirklich an einem sicheren System interessiert bist, poste hier eine Liste der Angreifer, gegen du dich schützen willst. Am besten gleich noch eine der Angriffsszenarien, aber die können wir auch gemeinsam ableiten.
- @sx2008: Sry, aber deine Verschüsselung ist IMHO *nicht* sicher. Ich bin jetzt kein ausgemachter Security-Experte, und kann deshalb deinen Algo nicht einfach so im Handumdrehen auseinander nehmen, aber eine handgestrickte Stromchiffre zu bauen (und auch noch auf Basis vom md5) und einfach zu behaupten, sie sei sicher, ist gewagt. Krypto ist kompliziert. Verdammt kompliziert. Und selbst echt Experten haben damit mitunter Probleme. Ich rate dringend davon ab, Alogs selbst zu erfinden. Nur mal so aus dem Bauch heraus, was ich, der ich mich auch nach drei Security-Vorlesungen noch als Krypto-Laie bezeichnen muss, so vermute:
-- md5 ist gebrochen. Damit kann man vielleicht was lustiges anstellen.
-- wenn das Passwort hartkodiert ist, braucht man sich eh keine mühe machen. Da ist Rot13 gut genug. Aber das mit den Angriffsszenarien hatten wir ja schon.
-- ein Problem sind die Zufallswerte, die mitunter nicht leicht sind, kryptographisch zufällig hinzukriegen
-- die Schlüssel-Verlängerung erscheint mir angreifbar
-- über die #0 im paddedPW kann man ggf. leicht nen Gültigkeitstest bauen. Das macht BruteForce *deutlich* schneller
-- ggf. kann man darüber auch was basteln, weil man ja einen teil des Plaintexts kennt
-- ...

Also bitte: Macht keine Krypto selbst. Benutzt einen bekanntermaßen für sicher befundenen Algo wie AES, aus einer Implementierung von jemandem, dem ihr sehr gute Kryptokenntnisse zutraut (negaH...). Das sichere Verwenden einer Library wie des DEC ist definitiv kompliziert genug und bietet ausreichend Fehlerpotenzial.

Ich will damit niemandes Bemühungen kleinreden: Sich über sowas Gedanken zu machen und ein bisschen mit Krypto rumzuspielen ist gut. Man lernt dadurch viel. Das ist aber nur was zum Spielen, nichts, was man in echten Projekten einsetzen sollte...

Zitat:

Wenn das Masterpasswort schon hartcodiert wäre, dann müßte wenigstens ein "komplizierter" Algorithmus dafür sorgen, dass die als Ausgangswerte verwendeten Daten nochmal ordentlich "verwurschtelt" werden bevor der daraus entstehende Key als Passwort für den eigentlichen "Passwort-Safe" verwendet wird.

Nein. Wenn das Passwort hartcodiert ist, nützt der beste Algo nichts. Das ist Augenwischerei.

Zitat:

Die Idee, die zu verschlüsselnden Daten künstlich zu verlängern kam mir auch schon. Mit langen Keys verschlüsselt wird das eine harte Nuss, selbst für hardwarebeschleunigte Passwortknacker. Allerdings wäre ich nicht auf die Idee gekommen, XOR zum Verschlüsseln zu verwenden.

xor an sich ist nicht schlecht. Das ist das Prinzip von Stromchiffren. Wie RC4 z.B. das Problem dabei nicht das xor, sondern der Keystream..

Zitat:

Eher was schickes aus dem DEC.

Ja, siehe oben.

Zitat:

Vielleicht sogar 16 verschiedene Verschlüsselungsalgorithmen und das erste Byte des MD5-Hashes vom eigentlichen Masterpasswort entscheidet, welche davon verwendet wird.

Das hat zur Folge, dass die Sicherheit auf das Level des unsichersten dieser 16 Algos sinkt.

Zitat:

Die nächsten vier Bytes entscheiden, wie viele Runden verschlüsselt wird.

Das hat zur Folge, dass das Sicherheitsniveau vom zufall abhängig ist bzw. genau genommen auch wieder so ist, die bei einer Runde. Runden haben nicht den Zweck Veränderung zu schaffen. Sie sollen den Algo langsam machen. Deshalb muss die Anzahl der Runden -- so man so etwas einsetzt -- groß sein und fest.

Zitat:

Aber dieses ganze Prinzip kann man nur dann als halbwegs sicher ansehen, solange der Rechner auf dem die Anwendung läuft nicht kompromittiert ist. Andernfalls gibt es immer Möglichkeiten, die entschlüsselnde Anwendung zu belauschen. Dann bräuchte man die Daten nicht mal aufwendig knacken, man holt sich alles aus dem Speicher der laufenden Anwendung.

Deshalb solltest du dir Gedanken über Angriffsszenarien machen.

mfg

Christian

[DeddyH]

[OT] Ihr könnt ja auch mal den Kryptochef fragen :mrgreen: [/OT]

[Sir Rufo]

Es ist doch wie im Leben - einfach mal nachdenken:

Zitat:

Die sicherste, dickste, mit 2 Trilliarden Sicherheitskomponenten geschützte Haustür nützt rein gar nichts, wenn der Schlüssel unter der Fussmatte liegt.

Ist das Passwort also auf dem Rechner, dann liegt der damit "unter der Fussmatte".

So einfach ist das ... und das "Andere" sich das Leben einfach machen, heißt nicht, dass die das gut machen.

@r2c2 :thumb:

[Codehunter]

Zitat:

Zitat von Sir Rufo (Beitrag 1211226)

Ist das Passwort also auf dem Rechner, dann liegt der damit "unter der Fussmatte".

Womit wir wieder bei meinem Eröffnungspost wären (einfach nochmal lesen). Denn genau das brachte mich ja darauf, über die Problemstellung nachzudenken.

Frage 1:
Was ist besser: Ein userdefiniertes oder ein hartcodiertes Passwort?
Antwort: Userdefiniert.

Frage 2:
Wenn ein Programm mit hartcodiertem Passwort verlangt wird, wie sollte es am besten konstruiert sein?
Antwort: So kompliziert wie möglich.

Das userdefinierte Masterpasswort hat eben den Nachteil dass man bei jedem Programmstart danach gefragt wird. Manche Leute wollen das nicht. Das kann man als Entwickler gut oder schlecht finden, man muss damit leben. Ich denke, der beste Kompromiss wäre, userdefiniertes und hartcodiertes Passwort parallel zu implementieren und dem Anwender per Konfigurationsoption die Wahl zu lassen.

Als Entwickler hat man ja auch prinzipiell zwei Möglichkeiten: Entweder man implementiert was richtig gutes, was natürlich Zeit und Geld kostet sowie permanent auf dem aktuellen Stand gehalten werden muss. Oder man implementiert "irgendwas", hält sich selbst für den tollsten Hecht der Welt, der Kunde (selbst Laie) sieht nur verschlüsselte Daten und nimmt das Programm so ab, und am Ende hoffen Entwickler und Kunde einfach nur dass die Sache "irgendwie" dicht hält.

Insofern gebe ich r2c2 vollkommen recht, das Thema ist eine Sache für Spezialisten zu denen ich mich nicht zähle. Darum kann ich nur bewährte Prinzipien anwenden und auf sichere Algos wie AES aus dem DEC vertrauen. Garantieren würde ICH trotzdem nicht dafür. Nach allem was ich so lese kann es sichere Kryptografie gar nicht geben. Höchstens solche, die wenn sie gut gemacht ist, den Angriff darauf in hohem Maße erschwert. In meinen Augen begibt sich derjenige, der für sichere Verschlüsselung GARANTIERT, auf sehr dünnes Eis.

[Sharky]

Zitat:

Zitat von Codehunter (Beitrag 1211234)

Frage 1:
Was ist besser: Ein userdefiniertes oder ein hartcodiertes Passwort?
Antwort: Userdefiniert.

Frage 2:
Wenn ein Programm mit hartcodiertem Passwort verlangt wird, wie sollte es am besten konstruiert sein?
Antwort: So kompliziert wie möglich.

Die Richtige Antwort lauter bei Frage 2 eigentlich. Auftrag ablehnen da absolut unsicher.

[Klaus01]

man könnte das Master-Passwort optional auch als Parameter übergeben.
Ist nicht sicher, aber bequem.
Dann liegt es am User ob er/sie es sicher oder bequem haben will.

Grüße
Klaus

[jfheins]

Zitat:

Zitat von Sharky (Beitrag 1211245)

Die Richtige Antwort lauter bei Frage 2 eigentlich. Auftrag ablehnen da absolut unsicher.

Also ein FTP Client der die Speicherung von Passwörtern nicht unterstützt fliegt auch ganz schnell wieder von der Platte. Da gibt es genügend Alternativen. Und nein, jedesmal das Passwort wieder neu einzugeben ist keine Option.

[Codehunter]

Genau. Die User wollen eben super sichere Software, die aber am besten alles sicherheitstechnische im Hintergrund erledigt, sodass man sich als User am besten überhaupt nicht mit dem Thema auseinander setzen muss. Und dann bei Sicherheitslücken, die eigentlich nur genau wegen der Usability entstanden sind, SKANDAAAL schreien.

Bloß gut, dass ich kein Programmierer bin und alles unter einen Hut kriegen muss :evil:

[sx2008]

Also ich halte meinen Vorschlag aus folgenden Gründen doch für sinnvoll:
1.) FTP-Passwörter können im Klartext im Netzwerk ausgelesen werden.
Deshalb sind FTP-Passwörter by Design eh nicht 100% sicher
2.) selbst wenn der Angreifer das FTP-Passwort + den Algorithmus + das verschlüsselte PW kennt, hat er doch einen ziemlich harten Job um an das Master-PW heranzukommen
Er könnte in Erfahrung gebracht haben, dass bei 3 FTP-Konten als Passwort "123abc" verwendet wurde.
Also kennt er 6+1 Bytes von 32 Bytes.
Sein Ziel wäre nun an den MasterKey/MasterPW heranzukommen um damit alle restlichen PWs zu knacken.
Jetzt müsste er mehrfach den MD5-Hash brechen um weiterzukommen.
Allein schon um per Disassembler den Algorithmus zu erfahren überfordert einen normalen Hacker.

3.) Schauen wir doch mal an wie die "Konkurrenz" das Problem löst.
Filezilla dürfte einer der bekanntesten und beliebtesten FTP-Clients sein.
Der MasterKey ist hartcodiert und lautet "FILEZILLA1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ ".
Und der Algorithmus ist ziemlich einfach: http://filezilla.cvs.sourceforge.net...pp?view=markup

Mit diesen Infos kann ein Scriptkiddi alle Filezilla-Passwörter entschlüsseln.
Was Filezilla hier macht ist geradezu fahrlässig einfach.

Scriptkiddies und "normale" Hacker werden sich an meiner Verschlüsselung die Zähne ausbeisen.
Es bräuchte schon "richtige" Hacker wie man sie bei NSA und anderen Geheimdiensten findet.

[jfheins]

Zitat:

Zitat von sx2008 (Beitrag 1211276)

3.) Schauen wir doch mal an wie die "Konkurrenz" das Problem löst.
Filezilla dürfte einer der bekanntesten und beliebtesten FTP-Clients sein.
Der MasterKey ist hartcodiert und lautet "FILEZILLA1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ ".
Und der Algorithmus ist ziemlich einfach: http://filezilla.cvs.sourceforge.net...pp?view=markup

Hä? Wie bekommt man ihn denn dazu? bei mir sind die als Klartext in der xml Datei...

Zitat:

Mit diesen Infos kann ein Scriptkiddi alle Filezilla-Passwörter entschlüsseln.
Was Filezilla hier macht ist geradezu fahrlässig einfach.

Scriptkiddies und "normale" Hacker werden sich an meiner Verschlüsselung die Zähne ausbeisen.
Es bräuchte schon "richtige" Hacker wie man sie bei NSA und anderen Geheimdiensten findet.

Naja, wie der Herr Schneier das mal formuliert hat: "Es gibt zwei Arten von Kryptographie. Die eine hält die kleine Schwester vom Lesen der Daten ab, und die andere hindert die Regierung daran".
Sowohl dein Vorschlag als auch diese FileZilla-Verschlüsselung erreichen ersteres. Zweiteres ist bei FTP Unsinn. Dein Vorschlag ist also nicht schlecht, aber vielleicht unnötig viel Aufwand für das Angriffsszenario ;-)

P.S.: "richtige Hacker" können Wireshark benutzen und dann ist denen dein Algorithmus aber sowas von egal. Oder (falls es um SSH/FTPS geht) auch einen eigenen kleinen Server aufmachen, die hosts Datei manipulieren und *bingo* ;-)

[r2c2]

Zitat:

Zitat von Codehunter (Beitrag 1211234)

Frage 1:
Was ist besser: Ein userdefiniertes oder ein hartcodiertes Passwort?
Antwort: Userdefiniert.

Ja.

Zitat:

Frage 2:
Wenn ein Programm mit hartcodiertem Passwort verlangt wird, wie sollte es am besten konstruiert sein?
Antwort: So kompliziert wie möglich.

Nein. Sicherheitstechnisch ist kompliziert nicht besser als einfach. Wenn der Key hartkodiert ist, ist *jeder* Algo nur ein besseres Rot13 mit ein paar Blümchen dran.

Zitat:

Das userdefinierte Masterpasswort hat eben den Nachteil dass man bei jedem Programmstart danach gefragt wird. Manche Leute wollen das nicht. Das kann man als Entwickler gut oder schlecht finden, man muss damit leben. Ich denke, der beste Kompromiss wäre, userdefiniertes und hartcodiertes Passwort parallel zu implementieren und dem Anwender per Konfigurationsoption die Wahl zu lassen.

Da geh ich mit.

Zitat:

Als Entwickler hat man ja auch prinzipiell zwei Möglichkeiten: Entweder man implementiert was richtig gutes, was natürlich Zeit und Geld kostet sowie permanent auf dem aktuellen Stand gehalten werden muss. Oder man implementiert "irgendwas", hält sich selbst für den tollsten Hecht der Welt, der Kunde (selbst Laie) sieht nur verschlüsselte Daten und nimmt das Programm so ab, und am Ende hoffen Entwickler und Kunde einfach nur dass die Sache "irgendwie" dicht hält.

Und Möglichkeit 3: Man nimmt ne fertige Implementierung eines sicheren Argorithmus.

Zitat:

In meinen Augen begibt sich derjenige, der für sichere Verschlüsselung GARANTIERT, auf sehr dünnes Eis.

Naja, ganz so ist es nun auch wieder nicht. Es gibt schon ziemlich gute Algorithmen. Und auch, wenn man Sicherheit nicht beweisen kann, so kann man -- mit genügen Ahnung, Zeit und Geld -- ein System schon so sicher machen, dass eine Garantie, die man abgibt, "garantierter" ist, als das, was man sonst so garantiert kriegt.

Zitat:

Zitat von sx2008

Also ich halte meinen Vorschlag aus folgenden Gründen doch für sinnvoll:
1.) FTP-Passwörter können im Klartext im Netzwerk ausgelesen werden.
Deshalb sind FTP-Passwörter by Design eh nicht 100% sicher

Ich hoffe mal, du benutzt für alles nicht total irrelevante, eh SFTP, nicht?

Zitat:

2.) selbst wenn der Angreifer das FTP-Passwort + den Algorithmus + das verschlüsselte PW kennt, hat er doch einen ziemlich harten Job um an das Master-PW heranzukommen

- Wenn das Masterpasswort hartcodiert ist, liest man es aus. Wer würde sich die Mühe machen, es zu errechnen?
- Wer will denn das Masterpasswort haben? Der Plaintext reicht schon. Das Masterpasswort braucht man nur, wenn man selbst verschlüsseln will. Wobei man bei deinem Algo mit dem einen auch bald das andere hat.
- Nur weil du das nicht knacken kannst, heißt das noch lange nicht, dass das nicht andere können. Was passiert in der Praxis? Ein einziger Mensch auf diesem lustigen Planeten muss den Algo knacken. Der schreibt dann n Programm, dass jeder Depp bedienen kann um das Passwort zu kriegen.
- Wenn du die Wahl hast, zwischen AES und einem Eigenbau, was nimmst du dann? Wenn du nen Ferrari geschenkt kriegst, willst du dir dann noch ne Selbstbauanleitung für nen Trabbi zulegen?

Sry, wenn das jetzt alles so flapsig klingt. Ich finde es gut, dass du dich mit Kryptographie beschäftigst. Mach da weiter. Da lernt man viel dabei und das kann ausgesprochen interessant sein. Ich möchte dir deinene Elan ja eigentlich nicht nehmen. Aber es gibt absolut überhaupt gar keinen Grund, Eigenbau-Algos produktiv einzusetzen.

Zitat:

Er könnte in Erfahrung gebracht haben, dass bei 3 FTP-Konten als Passwort "123abc" verwendet wurde.
Also kennt er 6+1 Bytes von 32 Bytes.
Sein Ziel wäre nun an den MasterKey/MasterPW heranzukommen um damit alle restlichen PWs zu knacken.
Jetzt müsste er mehrfach den MD5-Hash brechen um weiterzukommen.

Da versteh ich momentan deinen Angriff nicht. Aber, wenn das geht, ist das schonmal ein Problem.

Zitat:

Allein schon um per Disassembler den Algorithmus zu erfahren überfordert einen normalen Hacker.

Wo hast du denn die Info her? Da halte ich mal stark dagegen. Nen Disassembler zu bedienen ist kein Hexenwerk. Nichts für Scriptkiddies aber ansonsten. So n Ding hab ich rudimentär auch schon bedient. Das ist lernbar.

Zitat:

3.) Schauen wir doch mal an wie die "Konkurrenz" das Problem löst.
Filezilla dürfte einer der bekanntesten und beliebtesten FTP-Clients sein.
Der MasterKey ist hartcodiert und lautet "FILEZILLA1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ ".
Und der Algorithmus ist ziemlich einfach: http://filezilla.cvs.sourceforge.net...pp?view=markup

Mit diesen Infos kann ein Scriptkiddi alle Filezilla-Passwörter entschlüsseln.
Was Filezilla hier macht ist geradezu fahrlässig einfach.

Das ist nur dann fahrlässig, wenn man meint, damit mehr als eine Verschleierung erreicht zu haben. Wenn Verschleierung reicht, und das kann je nach Anforderungen durchaus sein, ist das vollkommen in Ordnung.

Deshalb nochmal meine Aufforderung: Wenn hier irgendjemand ersthaft daran interessiert ist, eine halbwegs fundierte Antwort auf die Ausgangsfrage zu erarbeiten, sollten wir uns darüber Gedanken machen, wovor wir uns schützen wollen.

Zitat:

Naja, wie der Herr Schneider das mal formuliert hat: "Es gibt zwei Arten von Kryptographie. Die eine hält die kleine Schwester vom Lesen der Daten ab, und die andere hindert die Regierung daran".
Sowohl dein Vorschlag als auch diese FileZilla-Verschlüsselung erreichen ersteres. Zweiteres ist bei FTP Unsinn. Dein Vorschlag ist also nicht schlecht, aber vielleicht unnötig viel Aufwand für das Angriffsszenario

Sehr schön gesagt. Dem schließe ich mich an. BTW: Meinst du Schneider oder Scheier? Würde nämlich zu letzterem passen...

mfg

Christian

[Meflin]

Zitat:

Zitat von r2c2 (Beitrag 1211322)

BTW: Meinst du Schneider oder Scheier? Würde nämlich zu letzterem passen...

Vermutlich Schneier :stupid:

[jfheins]

Zitat:

Zitat von Meflin (Beitrag 1211328)

Zitat:

Zitat von r2c2 (Beitrag 1211322)

BTW: Meinst du Schneider oder Scheier? Würde nämlich zu letzterem passen...

Vermutlich Schneier :stupid:

Ja, natürlich. Da ist wohl noch aus Versehen ein d mit hineingerutscht :oops:
Dafür nochmal die Originalquelle: http://www.schneier.com/book-applied-2preface.html :-)

[Codehunter]

Zitat:

Zitat von jfheins (Beitrag 1211351)

Zitat:

Zitat von Meflin (Beitrag 1211328)

Zitat:

Zitat von r2c2 (Beitrag 1211322)

BTW: Meinst du Schneider oder Sch[.]ei[.]er? Würde nämlich zu letzterem passen...

Vermutlich Schnei[.]er :stupid:

Ja, natürlich. Da ist wohl noch aus Versehen ein d mit hineingerutscht

Göttlich! :-D

Ok, wovor sollte man sich schützen wollen. Angenommen, man hat beschriebenes netzwerkfähiges Programm mit der Möglichkeit, verschiedene Zugangsdaten zu Servern zu speichern. Ferner angenommen, der User ist nicht bereit, die Passwörter der einzelnen Accounts bei jedem Login neu einzugeben. Damit ist Fakt, die Passwörter müssen in irgendeiner Form reversibel verschlüsselt gespeichert werden (oder eben im Klartext, aber das blenden wir mal aus). Der Einsatzbereich des Programms ist nicht exakt abzugrenzen: Kann sowohl im privaten Kinderzimmer auf der Daddelkiste als auch im Unternehmen im Produktiveinsatz. Die Verbreitung des Programms lässt sich auch nicht abschätzen. Ich gehe zwar von einem eher kleinen Nutzerkreis aus aber man kann ja nie wissen.

Wer dürfte Interesse an den Logins haben? Im privaten Bereich fielen mir z.B. Mitschüler ein, Stichwort Cybermobbing usw. Dass die Jugend zum Teil schon geniale kryptografische Talente besitzt hat sich in der Vergangenheit ja mehrfach gezeigt. In Unternehmen fiele mir z.B. Industriespionage ein oder das Verteilen von Malware.

Die Tatsache dass die Passwörter reversibel verschlüsselt sein müssen bedingt die weitere Tatsache, dass das Programm belauscht und die Klartext-Passwörter mitgeschnitten werden können. Das trifft insbesondere auf unsichere Netzwerkprotokolle zu. Diese Möglichkeit halte ich für das wahrscheinlichste Angriffszenario. Demzufolge wäre der beste programmeigene Verschlüsselungs-Algo nichts wert. Darum sollte eine Verschleierungstaktik gegen zufälliges manuelles Lesen der Accountdateien ausreichen. Für alles weiterführende sind eigentlich externe Sicherungstechniken anzuraten. Denn wenn das eigene Netzwerk bzw. Rechner kompromittiert ist stehen die Daten sowieso direkt im Frontgraben.

Allerdings ist es der Reputation nicht gerade zuträglich, wenn das eigene Programm im Fall eines Datenlecks beim Kunden durch einen dilettantischen Verschlüsselungs-Algo wie XOR auffällt. Darum würde ich einen derzeit als sicher geltenden Algo verwenden. SHA256 und/oder AES scheinen das Mittel der Wahl zu sein. Fertige Implementierungen a la DEC einzubinden kostet nicht viel Arbeit und man hat zumindest programmseitig alles getan was machbar war. Der Rest obliegt dem Anwender. Eben auch, ob er das hartkodierte Masterpasswort der Bequemlichkeit wegen einem händisch einzugebenden vorzieht.

So seh ich die Sache inzwischen.

[Aphton]

Man kann den Speicherort des Passworts ja auch verschleiern. Sprich man verschlüsselt das Masterpasswort usw usf. und speichert das nicht in eine "logindata.dat" Datei ab sondern versucht, das iwie zu verstecken - siehe z.B. Steganographie.

Ein Beispiel wäre - wenn die Anwendung mehrere Bilder verwendet, die (höchstens) verlustlos komprimiert sind, kann man die Daten mit einer Länge n gestückelt in m Teile, wobei m = Anzahl der Bilder, ja auf diese Bildern aufteilen und darin verstecken.

Eines vorweg - klar kann man, wenn man sich mit der Materie auskennt oder einfach gute Reversing Kenntnisse hat, aus Programmcode rausfinden, wie bzw. wo das Passwort gespeichert wird. Trotzdem wird der Vorgang damit erschwert.

[Romiox]

r2c2 hat absolut Recht, selbst zusammengefummelte Kryptosysteme sind kryptographisch mit allerhöchster Wahrscheinlichkeit Größenordnung Caesar. Wenn man das Masterpasswort speichert, kann man genau so gut auch alle Passwörter im Plaintext speichern, oder mit einem hardcodierten Schlüssel XOR-Verknüpfen, das wäre dann die Anti-Schwester-Krypto. Auch alle Algorithmen, die ohne einen weiteren, nicht gespeicherten Parameter das Passwort verschleiern, erhöhen im Endeffekt die Sicherheit nicht nennenswert. Das allererste, was man in Vorlesungen zur angewandten Kryptographie lernt, ist das Kerkhoffsche Prinzip, und das sollte man ernst nehmen (Wer wissen will warum sollte sich z.B. mal über das Schicksal der Mifare Classic Karten informieren).
Und da der Threadtitel nunmal "Grundsatzüberlegungen" ankündigt, muss man einfach ganz klar sagen, dass nur ein Masterpasswort eben die Sicherheit bietet, die für empfindliche Daten angemessen ist, und selbst das nur, wenn das Kryptosystem sehr sorgfältig implementiert wurde.