Noch was neues: Passwort

[Engywuck]

Was mir grad auffällt: Das Passwort wird ja als "plain text" in pref.xml gespeichert. Es wäre doch nicht zu knifflig, das Passwort mit einer leichten Verschlüsselung abzuspeichern. Das hält dann zwar keinen hohen Sicherheitsstandards stand, aber immerhin besser, als einfach nur ablesen zu müssen ;-)

Grüße,
Engywuck

 

[huzzel]

Man muss den Punkt auch nicht password nennen

 

[MiK]

Wenn ich es nur verschleiere, kann ich es auch gleich plain ablegen. Wer das nicht will, muss es ja nicht speichern. Außerdem halte ich das geocaching-Passwort jetzt für nichts besonders sicherheitsrelevantes.

 

[Engywuck]

Wenn ich es nur verschleiere, kann ich es auch gleich plain ablegen.

[x] Wenn ich meine Haustür nicht mit einem Hochsicherheitsschloss schützen kann, kannst ich sie auch gleich auflassen.
[x] Wenn ich mein Funknetz nur mit WEP schützen kann, kann ich es auch gleich ungeschützt lassen.
[x] Wenn ich das Abitur nicht mit 1.0 bestehe, brauche ich es gar nicht.
usw ;-)

Außerdem halte ich das geocaching-Passwort jetzt für nichts besonders sicherheitsrelevantes.

Es sei denn, es ist das gleiche Passwort, das man auch für seinen Ebay-, Mail- und Online-Banking-Account verwendet. Und sag mir nicht "dann ist man selber schuld" - wir machen schließlich Software für Anwender und nicht für Datenschützer. Und der Otto-Normal-Geocacher macht sich da vielleicht keine Gedanken drum und speichert das Passwort halt ganz unbedarft. Und der pfiffige Filius schaut sich dann mal die Dateien an und probiert das neu erworbene Wissen mal bei Ebay aus...
Klar, man kann den Eltern sagen, dass sie einfach besser auf Ihre Kinder aufpassen sollen, wenn diese mal wieder den Kloreiniger ausgesoffen haben - man kann aber auch einen einigermaßen kindersicheren Verschluß konstruieren. Auch wenn es vielleicht Kinder gibt, die den leicht aufbekommen...

Aber vielleicht kommt ja auch noch die ein oder andere Stellungnahme aus der Anwenderschaft. Meine Meinung soll da nicht maßgeblich sein...

Grüße,
Engywuck

 

[maierkurt]

Aber vielleicht kommt ja auch noch die ein oder andere Stellungnahme aus der Anwenderschaft.

Man kann ja noch einen Warnhinweis ausgeben, dass das Passwort im Klartext abgespeichert wird.
Btw: NotesScreen.java ist ja noch gar nicht lokalisiert.

Gruß, maierkurt

 

[lahmer]

Und wie genau willst du das Passwort schützen?
Ziemlich sicher wäre wohl einen Hash zu berechnen... nur kann es dann nicht mehr genutzt werden ;-)
Aber ein wenig verschleiern würde ich schon befürworten, da das für die meisten Angreifer schon eine ganz ordentliche Hürde ist

 

[Engywuck]

Und wie genau willst du das Passwort schützen?

Mein Gott, was seid ihr phantasielos ;-)
Mal so ins blaue philosophiert:
Man nehme den ASCII-Code des ersten Zeichens, multipliziere ihn mit 3, addiere 257, lese die Zahl von hinten nach vorne und schreibe sie auf. Das macht man mit den anderen zeichen ebenso, wobei man beim zweiten Zeichen 258 addiert, beim dritten 259, usw.
Dürfte alles problemlos zu programmieren sein und dennoch macht es das dem Angreifer doch deutlich schwerer...

Engywuck

 

[maierkurt]

Mein Gott, was seid ihr phantasielos

Ich wäre für ROT13
Der Benutzer sollte aber eventuell darauf hingewiesen werden, dass der Passwortschutz nicht wahnsinnig stark ist.
Andersrum: Wenn ich wirklich ein Passwort aus dem CW herausbekommen wollte, würde ich mal ins SVN schauen und siehe da, dort steht Engywucks Algorithmus. Ich meine, wenn schon Passwortgeschütze aufgefahren werden, dann richtig. Verschlüsselung, die nur auf Geheimhaltung des Algorithmus basiert taugt nicht viel.




Gruß, maierkurt

 

[MiK]

Also wenn wir eine Warnung schreiben wollen, dann muss sie auf jeden Fall hin. Auch wenn wir das Passwort verschleiern. Und wirklich sicher können wir es nicht machen. Denn zum Verschlüsseln gehört, wie der Name schon sagt, ein Schlüssel. Und wo soll der her kommen? Das läuft dann entweder wieder auf irgendein Master-Passwort oder einen Hardwareschutz hinaus.

Also entweder eine Warnung oder wir nehmen es ganz aus der GUI. Wer es selbst in die pref.xml schreibt, sollte sich dann des Risikos bewusst sein. Eine Verschleierung täuscht nur Sicherheit vor, die nicht existiert.

 

[pfeffer]

Ich bin Engywucks Meinung. Mein Vorschlag wäre allerdings, ein ordentliches Verschlüsselungsverfahren zu verwenden und das Erstellungsdatum des Dateisystems als Schlüssel zu verwenden.
Selbstverständlich entspricht dies nicht den Anforderungen zur sicheren Speicherung von wichtigen Passwörtern. Aber dieses Passwort wird ohnehin unverschlüsselt durch's Internet geschickt. Wer es also wirklich bekommen will, der hat dazu bereits jetzt gute Gelegenheiten. Eine (leichte) verschlüsselte Speicherung des Geocachung.com-Passworts entspricht diesen Anforderungen recht genau, finde ich.

Ich bin dafür, jetzt für die 1.0 _keine_ neuen Features einzubauen. Dazu zähle ich auch diese Verschlüsselung. Aber danach bin ich dafür.

Gruß,
Pfeffer.

 

[MiK]

@Engywuck: Willst Du das jetzt eigentlich noch in die 1.0 einbauen oder hältst Du Dich jetzt selbst nicht an Deine eigenen Ratschläge?

 

[Engywuck]

Ich bin doch nicht verrückt und mach irgendwas daran, bevor hier nicht allgemeiner Konsens - auch über Art und Umfang - erreicht ist ;-)
Bislang sehe ich 3 Alternativen:

• Keine Verschlüsselung (Vorschlag MiK)
• Einfache Hausfrauen-Verschlüsselung (Vorschlag Engywuck)
• Semiprofessionelle Verschlüsselung (Vorschlag Pfeffer)

Wenn wir uns darüber einigen, was und wieviel gemacht werden soll, bin ich gerne mit im Boot.

Grüße,
Engywuck

 

[lahmer]

Bislang sehe ich 3 Alternativen:

• Keine Verschlüsselung (Vorschlag MiK)
• Einfache Hausfrauen-Verschlüsselung (Vorschlag Engywuck)
• Semiprofessionelle Verschlüsselung (Vorschlag Pfeffer)

In diesem Fall wäre ich ganz klar für Pfeffers Vorschlag.
Der Hinweis darauf, dass das Passwort nicht sicher ist, sollte aber sicherlich trotzdem rein, da das ja der Wahrheit entspricht ps:

 

[MiK]

Ich bin doch nicht verrückt und mach irgendwas daran, bevor hier nicht allgemeiner Konsens - auch über Art und Umfang - erreicht ist ;-)

Das ändert nichts an der Frage, ob Du dies noch unbedingt in der 1.0 sehen willst.

 

[Engywuck]

Ach, das wolltest Du wissen.
Für meinen persönlichen Zweck ist mir das relativ egal. Es ist mir nur aufgefallen, dass wir an der Stelle noch eine Schwachstelle haben und habe sie deshalb mal erwähnt, damit wir zumindest mal darüber nachdenken, wie wir damit umgehen.
So vom Bauchgefühl her würde ich sagen, dass es schon in die 1.0 rein soll, einfach weil es die Software noch ein gutes Stück runder macht. Ob das aber die andern auch so sehen? Vielleicht reden wir über akademische Probleme, die in der Praxis keinen Anwender interessieren. Mach doch mal ne Umfrage ;-)

Grüße,
Engywuck

 

[Kappler]

Ich würde das nicht mehr vor der 1.0 einbauen...

Wenn wir alle Vorschläge übernehmen wollten, die den CW "runder" machen, dann würde es nie zu einer fertigen Version kommen...

 

[MiK]

Volle Zustimmung! Wir haben schon viel zu viele Ausnahmen in der letzten Zeit gemacht. Jetzt mit dem RC sollte damit Schluss sein. Wir haben genug zu tun, die Bugs zu fixen.

 

[mirabilos]

Man kann keine Verschlüsselung anbringen, weil dann der Schlüssel in CacheWolf
selber untergebracht sein müßte, oder sonstwie für den Angreifer ohnehin sichtbar
wäre. Außerdem machts nur Probleme (Erstellungsdatum des Dateisystems? Bitte?
Hast Du ’ne Ahnung, wie oft sich das bei mir ändert?) und führt zu Datenverlust
bei Migrationen.

Hashen geht auch nicht, da man’s als Plaintext braucht.

Hier geht nur: chmod 0700 prefs.xml
Sonst leider nix. Machen andere Programme auch so (zum Beispiel centericq,
mcabber) und geht leider auch nicht anders, wenn das OS nichts anbietet, wie
z.B. Apples Keychain – und da bei CW das „OS“ Ewe ist…

Also: laßt es.

@Engywuck: Deine Argumente sind zwar in der Regel okay, aber Verschleiern ist
was anderes als die Haustür offenlassen. Da müßte schon eine (schwache) Ver-
schlüsselung ran – die aber hier halt nicht machbar ist