Password Manager

Es gibt nur selbstgefrickeltes Zeug. Alles hat irgendjemand, irgendwann, irgendwo gefrickelt. Entweder bei einer Firma oder Privat.

Was macht denn einen Experten aus? Irgendjemand denkt sich was aus, schreibt es auf, macht daraus einen Kurs und verkauft den Teilnehmern ein Zertifikat, dass diese dann als Experten ausweist. Natürlich gegen Kostenerstattung. Danke darauf kann ich verzichten. Selbst Uncle Bob verschickt Clean Coder Gummibändchen. Die Definition von Experte möchte ich gerne mal hören.

Was ist den jetzt besser, Keepass oder Password Safe? Vermutlich ist beides unsicher, wenn man als Installationsquelle sourceforge nimmt, dass einem Browsererweiterungen und Keylogger unterjubelt. Wie repariert man Keepass, wenn da doch mal was entdeckt werden sollte oder die Algorithmen nicht mehr ausreichend sind, aus welcher Quelle bezieht man es am besten, kompiliert man es am besten selbst oder kann man da auch zuviel falsch machen und um alles in der Welt, wie konfiguriert man es dann auch so, dass da gute Passwörter rauskommen.

Beim schreiben eines Passwortmanagers lernt man die Schwierigkeiten kennen, die man lösen muss. Bei einem selbstgeschriebenen Passwortmanager weiss man wie man ihn reparieren muss. Einen selbstgeschriebenen Passwortmanager wird man nicht mit unnötigem Zeug, dass man nicht braucht vollstopfen, dass nur weitere Probleme mit sich bringt.

Um das ganze mal auf ein anderes Abstraktionsniveau zu hieven, Kochen. Es soll tatsächlich Menschen geben die selbst kochen und das gekochte dann auch essen. Ok, dass sind keine Experten wie die Köche im Restaurant, bei denen auch hin und wieder der Amtsarzt vorstellig wird oder die Aufsicht nach der Hygiene schaut. Bei den Kochprofis auf RTL2 sieht man dann hin und wieder, was da dann für Leute in der Küche rumkaspern.
Jetzt kann man natürlich hingehen und sich auf das Aufwärmen von Fertiggerichten beschränken. Dann weiss man allerdings immer noch nicht was man da überhaupt zu sich nimmt.
Beim selber kochen kann auch einiges schief gehen. Vergiftungen bis hin zum Tod und schwere Verletzungen durch umherspritzendes Fett und scharfe Messer sind da in der Praxis immer wieder anzutreffen. Das es hin und wieder mal schlechter schmeckt muss man in kauf nehmen.
Aber nur durch kochen lernt man kochen und darüber hinaus auch was „gutes Essen“ ausmacht. Jemandem vom selber kochen abzuraten halte ich daher in der Regel nicht für sinnvoll.

Der Punkt mit Kryptographie ist, dass es nur „wenige“ auf der Welt gibt, die sie wirklich verstanden haben. Beim Kochen merkt man sofort, ob man was falsch gemacht hat. Bei Kryptographie kann es jahrzehntelang unentdeckt bleiben.
Auf diesen Punkt hatte ich mit den Beispielen meines letzten Beitrages versucht hinzuweisen. Die dort angefangene Liste könnte man beliebig lang fortsetzen. Mit Beispielen, bei denen auch Kryptologen Defizite nicht bemerkt haben.

Kryptographieexperte wird man sicher nicht durch irgendwelche Zertifikate, sondern durch akademische Weiterbildung. Die Masse der Kryptologen dürfte an Universitäten sitzen.

Kochen lernt man durch Kochen. Programmieren durch Programmieren. Kryptographie aber lernt man nicht durch die Anwendung von Kryptographie, sondern durch Forschung und Weiterbildung. Denn was hier fehlt, ist die Feedbackschleife, wenn man etwas falsch gemacht hat.

Das bestreitet ja auch keiner. Im Gegenteil, die Beispiele oben belegen diese Aussage. Und auch die aktuell durch WannaCry ausgenutzte Sicherheitslücke ist seit über einem Jahrzehnt in millionenfach genutzter Software vorhanden.
Aber, und das ist der Punkt, die Wahrscheinlichkeit, dass dort eine Schwachstelle bekannt wird, ist größer als bei selbstgebauter und wenig genutzter Software. Das ist natürlich zugleich Vor- wie Nachteil. Dadurch kann ggf. jemand ohne großes Know-How die Schwachstelle ausnutzen. Bei einem aktiv gepflegten Projekt sollte sowas aber schnell behoben werden und dann den Vorteil bieten, dass die Anwendung wieder ein Stückchen sicherer (auch gegen versierte Anhreifer) geworden ist.

1 Like

Deswegen bin ich ja auch nach wie vor der Meinung, dass man bei Verwendung von PW-Managern eher gefahr läuft, gleich alle Passwörter zu verlieren als ohne. Stift und Zettel haben da netzwerktechnisch weit weniger Sicherheitslücken.

Das ist die grundsätzliche Frage. Deshalb gibt es ja auch Alternativen, wie die Passwortkarte. Damit kann man sich sichere, unterschiedliche Passworte für verschiedene Dienste “generieren”.
Aber das war ja nicht die Ausgangsfrage dieses Threads, in welchem es darum gehen soll, einen geeigneten Passwortmanager zu finden.

Dann bräuchte man für jedes Passwort einen anderen Algorithmus, oder einen anderen Seed. Was, wenn (ich Blödi) den mal vergesse, Schulseligkeit, dann hab ich vielleicht auf die Hälfte der Dienste keinen Zugriff mehr.

Ich kann mir schon kaum die vierstellige PIN des Rasenmäherroboters merken! (Nur, um einfach mal ein Bsp. zu nennen…)

Anmerkung: https://www.ines-it.de/datenschutz-it-sicherheit/schulung-awareness/passwortkarte.html

Wenn man keine ID angibt, dann wird jedes Mal eine andere Karte generiert.

Ich denke, da liegst du falsch. Du wirst eben nicht lernen, ob dein Passwort Manager sicher ist. Sondern einzig und allein, ob er funktioniert. Außer du machst ein Codereview nach üblichen Standards. Wenn du dazu in der Lage bist, und das ist unabhängig von irgendeinem Zertifikat sondern einzig durch Verständnis und Erfahrung, dann kannst du vll. einen sicheren Passwortmanager bauen. Im Normalfall beherrscht „der Entwickler“ aber kaum sicherheitskritisches Programmieren.

Und es gibt einen Unterschied zwischen Programmen die nach Standards entwickelt werden, verschiedene Stufen der Qualitätsicherung durchlaufen und Programmen die eine Person zu Hause schreibt.

1 Like

Schusseligkeit!

Kann heut Morgen noch nicht lesen.^^

Schaut doch bitte mal in den oben erwähnten Link.

Dem kann ich nur zustimmen. Ich habe schon mehrere APIs gesehen, wo die Entwickler sich wohl dachten, eine Passwortübertragung als Hash sei „sicher“ und verwenden dann statt dem Passwort einen MD5-Hash. Wahrscheinlich nur, weil sie mal was von MD5 gehört haben und auch ständig hören, dass man Passworte hashen soll.
Dass (zumindest bei einer unverschlüsselten Übertragung) eine Übertragung des Passworthashes keinerlei Mehr an Sicherheit bietet, ist den Entwicklern wahrscheinlich schlicht nicht bewusst. Ja: das Passwort bekommt ein Angreifer nach einem Mitschnitt des Netzwerkverkehrs nicht direkt serviert. Aber das braucht er ja gar nicht, weil der Hash gleichwertig ist…
Selbst wenn man keinen „kaputten“ Hash wie MD5 verwenden würde. Bspw. wäre SHA512 nach heutigen Gesichtspunkten „sicher“. Aber nicht für den Anwendungsfall der Passwortübertragung ohne weitere Maßnahmen.

Das selbe gilt für Verschlüsselungsalgorithmen. Je nach Anwendungsfall ist dieser oder jener Modus geeignet. Je nach Anwendungsfall muss man ein bestimmtes Padding wählen. Aus dem Passwort muss auf die richtige Weise der Schlüssel abgeleitet werden…

Warum wird den jede Software gepatcht? Es ist ja teilweise schon so absurd, dass es heute ein Qualitätsmerkmal ist, wenn der Hersteller verspricht seine Software regelmäßig zu reparieren.
Der übliche Standard ist, dass man den Standard Standard sein lässt und macht was einem passt. Zudem ist es nur eine Behauptung ohne Grundlage, dass sich das an das halten an Standards zu einem guten Produkt führt.

Wenn man etwas nicht beherrscht, dann sollte man es wohl sein lassen? Ein Neugeborenes kann weder Sprechen, noch Lesen, Schreiben, Gehen oder gar Programmieren. Hätte mir das damals jemand gesagt, hätte ich denjenigen zwar nicht verstanden, würde aber heute immer noch im Kinderbett liegen und gefüttert werden.
Man kann aber alles lernen, genau wie sicherheitskritisches Programmieren.

Das muss man wohl nur lange genug hören bis man es dann auch selbst glaubt. Nur weil jemand bei Google, Facebook oder Microsoft arbeitet, macht es denjenigen nicht zum besseren Programmierer.

Wenn jemand den Netzwerkverkehr, den unverschlüsselten mitschneiden kann, dann braucht er meist auch kein Passwort um das zu erfahren, was es zu erfahren gilt. Auf der anderen Seite liegen dann die Daten bei irgendeinem Cloud-Dienst, der mit den Daten eh macht was er möchte.

Kurz und Knapp, wer es nicht schafft selbst einen Passwortmanager zu erstellen, sich das nötige Wissen über Kryptographie anzueignen, sollte lieber die Finger von Softwareentwicklung, lassen bis er in der Lage ist einen Passwortmanager selbst zu erstellen.

Ich sehe das anders. Ich habe hier Software zu beurteilen und testen. Bei einigen weiß ich bzw. kann es nachfragen, wie der Entwicklungsprozess abläuft. Häufig steht die Qualität der Software in direkter Relation zu den Qualitätsprozessen sowie der Einhaltung von Standards oder eben Best-Practises. Manchmal habe ich Software, die wird wild mit nem Framework zusammengeschustert, dass seit 6 Monaten auf dem Markt ist. Da hat man den Datenbankzugriff innerhalb von ein paar Stunden. Das Rad ständig neu zu erfinden bzw. zu programmieren weil man gerade meint, das sei der tollste Weg ist mE falsch.

Nein, aber die Prozesse bei diesen Unternehmen machen die guten Resultate aus. Das alle diese Produkte Sicherheitslöcher aufweisen…geschenkt. Bei zig Milliarden Zeilen Code und einer derart öffentlichen Verbreitung sind die paar Lücken eine unglaubliche Leistung. Patches sind absolut nichts verwerfliches. Nachbesserungen existieren in jedem Bereich.

Gibts von dir ein (sicherheitsrelevantes) Programm, was du veröffentlicht hast?

1 Like

Ich persönlich sehe keine Stelle, an welcher timbeau dies behauptet hat. Ich hätte deswegen auch gesagt (ohne je seine Folgebeiträge studiert zu haben), dass er eher das Gegenteil meint - Software, die im stillen Kämmerlein entwickelt wurde, ist nicht selten von höherer Qualität als solche, die nur professionellen Standards genügt.
Klar, Mr. Privat muss sich kaum Gedanken über die sichere Übertragung eines Passwords Gedanken machen, zumindest solange er, als einziger Nutzer seiner Software, ebenso der Einzige ist, der Quelle und Ziel des Passwortes kennt. Ihm würde im Quellcode der Kommentar „Bitte nur mit https verwenden!“ genügen - professioneller Software genügt dieses aber eben nicht.

Und Software ohne Patches? Das geht nicht! Entwicklungsprozesse bestehen nicht nur aus dem Aufbauen sondern auch aus dem Abriss von Wänden. D.H. selbst wenn Software einst perfekt tadellos veröffentlicht wurde, wird sie im Laufe der Zeit von findigen Leuten soweit aufgebohrt - nicht zuletzt durch bessere Hardware, dass sie wieder als unsicher eingestuft werden muss.

Ich hab auch mal einen kurzen Einblick in die Entwicklung bei Microsoft bekommen. Alles eher ‚gelassen‘ (dehnbarer Begriff). Allgemein bekannt ist auch das agil. Das ändert aber nix daran, dass tausende Zeilen Code keine Rechtfertigung für einen Dummbatz ist, wie @anon94273153 meint. Auch ist das ‚Aufnahmenritual‘ eher speziell…

Nichtsdestotrotz… So schwierig ist das Verstehen moderner Verschlüsselungsverfahren nicht(*), und dann weiß man auch, dass Rechner bis zum Ende des Welt (setzt irgendetwas dafür ein) rechnen können, ohne die Verschlüsselung zu bekommen.

Von daher finde ich es komisch, jetzt zu behaupten, ja einfach das Encrypted bekommen, und alles ist gut. Nein, ist es eben nicht. Verschlüsselt heißt Verschlüsselt, weil man es OHNE (GROß, fett, kursiv…) ‚Schlüssel‘ eben nicht bekommen kann.

(*): Okii, das ist eine Lüge gewesen. :smile:

Man, so weit vom Thema ab. Der nächste kommt vielleicht mit Enigma. o.O

Die meisten Dinge kann man lernen, ja. Dazu gehört auch sicherheitskritisches Programmieren. Aber das lernt man eben nicht nur, indem man es „versucht“. Dazu gehört eben doch einiges an theoretischem Know-How, welches man sich nicht durch die Programmierung allein aneignen kann.

Fehler sind menschlich und die passieren nunmal hin und wieder. Selbst mit den besten Managementprozessen. Und je mehr Zeilen Code man produziert, desto mehr Fehler passieren auch. Und wenn ein Softwarehersteller seine Fehler nicht ausbügelt, ärgert sich der Nutzer. Jemand, der behauptet, seine Software absolut fehlerfrei ausliefern zu können, leidet entweder unter Hybris oder hat eine Trivialsoftware erstellt.

Mit einer sicheren Übertragung schützt man sich bspw. vor einem gehackten Router (ist in letzter Zeit massenhaft mit privaten Routern vorgekommen). Wenn der Clouddienst gehackt wird oder der Anbieter nicht vertrauenswürdig ist, hat man ein anderes Problem, gegen das man sich mit anderen Mechanismen schützen muss (bspw. Verschlüsselung auf dem Endgerät).

Bei manchen reichen dafür 20 Zeilen Code.

In den seltensten Fällen ist die Schwachstelle so dämlich wie bei Heartbleed. Und plötzlich sind Algorithmen wie RC4 nicht mehr sicher…weil ein Unternehmen wie Google 30TB Netzwerkverkehr mitgeschnitten hat…als RC4 erfunden wurde, waren 30TB wahrscheinlich das Internetvolumen eines Jahres.

Hast du jemals ernsthaft versucht einen Passwortmanager zu schreiben und falls ja, an welcher Stelle bist du daran gescheitert?

Man nehme z.B. einen bekannten Algorithmus und zum Beispiel die Implementierung die bei Java dabei ist, wie AES256, dazu ein Master-Password und generiert sich ein Salt um die Entropie zu erhöhen.

Nun schreibt man seine Login Daten in ein Bytearray das man mit dem Algorithmus und einem Schlüssel bestehend aus Master-Password und Salt verschlüsselt und dann auf Platte schreibt (Passwörterdatei).

Was anderes macht Keepass auch nicht.

Dann baut man sich eine GUI, welche beim Start Masterpassword, Salt (z.B. in einer eigenen Datei) und Datei mit den Daten abfragt und damit die Passwörter entschlüsselt, anzeigt und evtl. in die Zwischenablage kopiert und daraus nach einer gewissen Zeit wieder löscht, etc. pp. Business as usual.
Danach kann man, wenn man mutig ist, seine Passwörterdatei ins Netz stellen oder anderweitig verbreiten. Auf die anderen Geräte überträgt man dann die Salt-Datei.

Absolut nichts besonderes. Sollte dann irgendwann mal AES256 durch etwas besseres ersetzt werden, integriert man den besseren Algorithmus ändert alle seine Passwörter, nutzt ein neues Salt und neues Master Passwort.

Dies sollte man in der Regel auch immer wieder machen, egal was man nutzt.

Klar muss man sich auch mit der Theorie befassen. Aber wer befasst sich mit der Theorie, wenn er diese nie in die Praxis umsetzen möchte? Und die Theorie ist ja auch jedem zugänglich der möchte.

Bei Updates sollte man auch tunlichst Feature-Updates und Bugfixes unterscheiden. Es macht einen immensen Unterschied ob man eine Wand rausreist, weil man einen größeren Raum haben möchte oder weil der Maurer der die Mauer gebaut hat zu doof war eine Wasserwaage und ein Maasband korrekt einzusetzen um danach dann eine neue Mauer zu setzen.

Und bei den zig Milliarden Zeilen Code stellt sich die Frage ob es nicht auch 100 Mio Zeilen Code getan hätten. Code der nicht existiert hat auch keine Bugs. Nach der Logik könnte man auch einen Codegenerator erstellen, der ein Projekt einfach auf zig Milliarden Zeilen Code bloatet, die nie ausgeführt werden um die 50 Bugs in den 1000 Zeilen „richtigen Code“ zu rechtfertigen.

1 Like

Wenn ihr das mit Java schreiben wollt, verwendet bitte die: ‘Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files’…

Ich geb mal ein Beispiel: Folgendes Verschlüsseltes enthält mein Passwort in der Form:
CyborgBeta = MEIN_GEHEIMES_PASSWORT

NJDbGIlH1nQvyw5gMRVjlPOJslQ/6hBCj5Cyxp6fRtKAVb1q+qafbaW4CrD0NkD9

Vielleicht findet es jemand heraus(*), das Verfahren kann ich, wenn gefordert, auch nennen.

(*): Nein, jetzt bitte keine Panik, nicht mein BWN Passwort, sondern eine lustige Nachricht.

(**): Eigentlich bin ich der Annahme, dass es keiner herausfindet, auch nicht mit der und der Rechenpower.

(***): Mir gefällt der/die Beiträge von @ionutbaiu , klicke aber nicht jedesmal auf ‘gefällt mir’.

Das lässt noch Detailfragen offen: in welchem Modus soll verschlüsselt werden? Wird jedes Passwort einzeln verschlüsselt? Wird die ganze Datenbank als ein Dokument verschlüsselt? Will man bei jedem geänderten PW die ganze Datei neu schreiben? Wie erzeugt man den IV?

Vielleicht meinst du das auch, aber man sollte den Schlüssel nicht direkt aus PW und Salt bilden, sondern eine Ableitungsfunktion anwenden (Stichwort PBKDF).

Das mit den Milliarden Zeilen Code bezieht sich wohl auf die Unternehmensgröße und die Art der Produkte, die dieses Unternehmen herstellt. Deine Argumentation mit einem Codegenerator führt das Argument ad absurdum und du weißt selbst was mit der Aussage gemeint war. Es gibt nunmal einen linearen Zusammenhang zwischen Anzahl Programmierfehlern und der Menge produziertem Code, für den die Anzahl Codezeilen eine gängige Metrik ist.

Ja, statistisch oder im Durchschnitt gesehen. So ist jeder bestimmt auch zu 0,5 % kriminell. Nützt aber doch nichts, der eine produziert mehr Fehler, der andere weniger.

Das ist es genau, worauf @anon94273153 hinaus wollte :dizzy_face: Milliarden Zeilen Code, dabei wenige Fehler. Folglich: gute Quote…

Wie verhinderst du Angriffe auf den Ram, vielleicht doch eher verlangsamende Hashalgos wie schon erwähnt PBKDF2 oder scrypt? Dann gibt es vielleicht noch aus Vershen temporäre Dateien, das Passwort wird nicht aus der Zwischenablage gelöscht und das sind jetzt nur 3 oder 4 Überlegungen die mir adhoc einfallen.

Das Hauptproblem ist NICHT die Stärke eines bekannten Algorithmus. Als normaler Anwender (Admin, Entwickler, …) muss man darauf vertrauen, dass Stellen wie das BSI und der NIST aber auch Google ihre Empfehlungen schon begründen können. Das sollte man dann aber auch befolgen und sich immer wieder informieren.
Das Grundproblem sind die Fallstricke, die bei der Entwicklung von Programmen vorhanden sind. Daher macht es exakt keinen Sinn hier irgendeinen Super-Mega-Hash zu posten.