Grundsatzüberlegungen zum Thema Speichern von Passwörtern

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