Webbasierter Passwortmanager zum selbst hosten

[misterunknown]

Moin,

das Problem kennen sicherlich viele: Wer wirklich für jeden Dienst/Account andere Zugangsdaten hat, vergisst doch mal das ein oder andere Passwort, vor allem bei Diensten, die man nicht tagtäglich nutzt. Bisher habe ich dazu eine einfache Textdatei auf dem Server verwendet, welche aber mittlerweile ziemlich unübersichtlich ist.

Daher meine Frage: Kennt jemand zufällig einen webbasierten Passwortmanager zum selbst hosten? Ein kurzes Googeln hat mich nicht glücklich gemacht: Entweder war die Software nicht webbasiert, oder nicht zum selbst-hosten, oder sie wird nicht mehr weiterentwickelt... Außerdem interessiert mich natürlich, welche Lösungen bei euch Verwendung finden.

Grüße Marco

[hotti]

Moin,

... Außerdem interessiert mich natürlich, welche Lösungen bei euch Verwendung finden.

Ein Poesiealbum ;)

Buchhalter, Horst

[misterunknown]

Moin,

Ein Poesiealbum ;)

Ich schiebe diese Antwort mal darauf, dass heute quasi ein "vorgezogener" Freitag ist...

Grüße Marco

[hotti]

hi Marco,

Ein Poesiealbum ;)

Ich schiebe diese Antwort mal darauf, dass heute quasi ein "vorgezogener" Freitag ist...

Ok, am Montag heißt das Ding dann wieder Notizbuch.

Es gibt gute Gründe, Passworte eben nicht auf einem Computer zu hinterlegen oder gar im Netz, so schickt eine Bank die Zugangsdaten auch in einem richtigen Briefumschlag und nicht per eMail.

Es ist eine Frage der vertrauenswürdigen Umgebung und die ist das Internet nicht. Nicht einmal der eigene PC, der ständig daran angeschlossen ist.

Wenn ein Notizbuch verschütt geht, weiß ich, dass die Daten weg sind. Wenn Daten kopiert wurden, weiß ich nicht, ob die von jemanden kopiert worden sind (Psalm 1, Software Engineering, Haleluja).

Buchbinder, Horst

[misterunknown]

Moin,

Es gibt gute Gründe, Passworte eben nicht auf einem Computer zu hinterlegen oder gar im Netz, so schickt eine Bank die Zugangsdaten auch in einem richtigen Briefumschlag und nicht per eMail.

Nicht alle. Mittlerweile gibt es Smartcards, oder TAN-per-SMS verfahren. 100% sicher ist nichts.

Wenn ein Notizbuch verschütt geht, weiß ich, dass die Daten weg sind. Wenn Daten kopiert wurden, weiß ich nicht, ob die von jemanden kopiert worden sind (Psalm 1, Software Engineering, Haleluja).

Der Vergleich hinkt. Kann man ein Notizbuch nicht "kopieren"? Zumal ich dieses Notizbuch ständig bei mir tragen müsste, denn meinen heimischen Rechner nutze ich in letzter Zeit recht wenig. Ich brauche die Passwörter auf Arbeit, bei Bekannten oder unterwegs auf dem Handy/Tablet.

SSL + Login + Masterpasswortverschlüsselung ist IMHO sogar sicherer als Notizbuch in der Hosentasche.

Grüße Marco

[hotti]

hi,

Der Vergleich hinkt. Kann man ein Notizbuch nicht "kopieren"?

Klar: Wenn der Kopierer genügend Zeit hat und das Ding dann wieder dahin legt, wo er es gefunden hat, merkste auch nicht, dass es kopiert worden ist (außer an den Eselsohren).

Auch einen Stick kannst Du verlieren, aber da weißt Du wenigstens, dass er weg ist.

SSL

Allenfalls, wenn Du den Server selbst betreibst in einer als verstrauenswürdig eingestuften DMZ.

MfG

[M.]

Mahlzeit,

Klar: Wenn der Kopierer genügend Zeit hat und das Ding dann wieder dahin legt, wo er es gefunden hat, merkste auch nicht, dass es kopiert worden ist (außer an den Eselsohren).

Gar nicht nötig. Wenn jemand das Notizbuch klaut, hat er erstmal auf alles Zugriff. Natürlich können einige Passwörter schnell geändert werden, aber immerhin geht es um eine Liste in der Passwörter stehen, die man sich nicht merken kann/will.
Somit ist es gar nicht möglich, auf die Schnelle alle Passwörter zu ändern.

Ein solche Notizbuch ist massiv unsicher, da es gar nicht kopiert werden muss, nur geklaut/gefunden.

[Kay]

... Außerdem interessiert mich natürlich, welche Lösungen bei euch Verwendung finden.

Ich benutze KeePass2, für Unterwegs auf Stick.
Mittlerweile habe ich auch ganze Befehlsequenzen der Serveradministration gespeichert.
Ein Strg +v spart etliche Minuten täglich, besonder wenn man als Grobmotoriker und Analphabet mit so einem Wunderwerk, wie die Tastatur, es zu tun hat.

[misterunknown]

Moin,

Ich benutze KeePass2, für Unterwegs auf Stick.

Ist eine Idee, allerdings kann ich nicht überall mit USB-Stick arbeiten (beispielsweise am Handy/Tablet). Außerdem ist KeePass eine Windows-Software, auch wenn es wohl (mehr oder weniger gut gewartete?) Ports für alle möglichen Plattformen gibt.

Mittlerweile habe ich auch ganze Befehlsequenzen der Serveradministration gespeichert.
Ein Strg +v spart etliche Minuten täglich, besonder wenn man als Grobmotoriker und Analphabet mit so einem Wunderwerk, wie die Tastatur, es zu tun hat.

Ich schreibe mir meistens Shell- oder Perl-Skripte, die wiederkehrende Aufgaben übernehmen, was sich aber für viele kleinere Sachen nicht lohnt. Von daher habe ich auch ne kleine Textdatei mit umfangreicheren "Einzeilern", die man so braucht.

Grüße Marco

[hotti]

hi,

Ich schreibe mir meistens Shell- oder Perl-Skripte, die wiederkehrende Aufgaben übernehmen, was sich aber für viele kleinere Sachen nicht lohnt.

OT, hast Du schonmal über ein CLI-Framework nachgedacht? Das lohnt sich auch für kleinere Sachen mit einer nach oben offenen Erweiterbarkeitsskala: Statt einzelner Skripts nur noch Module schreiben.

MfG

[misterunknown]

Moin,

OT, hast Du schonmal über ein CLI-Framework nachgedacht? Das lohnt sich auch für kleinere Sachen mit einer nach oben offenen Erweiterbarkeitsskala: Statt einzelner Skripts nur noch Module schreiben.

Klingt interessant. Aber was ist genau der Vorteil gegenüber "normalen" Skripten, die beispielsweise unter /home/$USER/bin liegen?

Grüße Marco

[hotti]

Hi,

Klingt interessant. Aber was ist genau der Vorteil gegenüber "normalen" Skripten, die beispielsweise unter /home/$USER/bin liegen?

Das CLI-FW-Core-Script (nennen wir es cli.pl) kannste auch dahin legen. Aber nun zu den Vorteilen:

1. Anstelle kompletter Kommandozeilen-Skripts werden nur noch Klassen entwickelt, die ein Interface implementieren
2. cli.pl zeigt eine Übersicht, welche Klassen zur Verfügung stehen, der user muss sich nicht durch Verzeichnisse/Dateien wühlen, wenn er wissen will, was an Kdo.Zeilen-Tools vorhanden ist, er ruft einfach cli.pl auf
3. Kommandoklassen werden erst zur Laufzeit an das Core-Skript gebunden, der Editor einer neuen Kommandoklasse trägt diese nur in die Übersicht ein.

Praxis: Ach wie hieß doch gleich das Skript, was mir den Webseitenindex erstellt?
#cli.pl
Indexer Erstellt den Webseitenindex
#cli.pl Indexer
Options:
--remote, -r
--local, -l
#cli.pl Indexer -r

Fertisch ;)
Oder einfach im TextPad [Strg]+9 drücken.

Auf CPAN gibt es ähnliche Frameworks, ähnliche Verwendung, ähnliche Zweckbestimmung wie z.B. App::Cmd oder CLI::Framework. cli.pl ist meine eigene Entwicklung.

MfG

[M.]

Mahlzeit,

drei Spalten in der Datenbank (URL, Login, Passwort), HTTPS und eine Passwortabfrage.
Umso einfacher, umso weniger Sicherheitslücken.

Ich würde mir sowas auf die schnelle selbst bauen, weils wenig Aufwand ist. Fertiges kenn ich nicht.

[misterunknown]

Moin,

drei Spalten in der Datenbank (URL, Login, Passwort), HTTPS und eine Passwortabfrage.
Umso einfacher, umso weniger Sicherheitslücken.

Stimmt.

Ich würde mir sowas auf die schnelle selbst bauen, weils wenig Aufwand ist. Fertiges kenn ich nicht.

Stimmt auch. Allerdings ist der Anwendungsfall ja sicherlich nicht soo exotisch, als dass da nicht schon jemand eine kleine, feine, fertige Lösung hätte gebaut haben können.

Momentan sieht es aber wirklich so aus, als ob ich mir am Wochenende mal die Zeit nehme und was eigenes Stricke ;)

Grüße Marco

[1UnitedPower]

Meine Herren!

drei Spalten in der Datenbank (URL, Login, Passwort), HTTPS und eine Passwortabfrage.
Umso einfacher, umso weniger Sicherheitslücken.

„Die schlimmste Sicherheitslücke ist immer noch, sich selbst für clever zu halten.“
– molily

An der konkreten Lösung stört mich etwa, dass du nicht erwähnst, ob und wie die Datenbank verschlüsslert werden könnte/sollte, und auf welche weise der Nutzer sich beim Server authentifiziert. Eine Lösung selber zu stricken entspricht in meinen Augen grober Fahrlässigkeit.

[misterunknown]

Moin,

An der konkreten Lösung stört mich etwa, dass du nicht erwähnst, ob und wie die Datenbank verschlüsslert werden könnte/sollte, und auf welche weise der Nutzer sich beim Server authentifiziert. Eine Lösung selber zu stricken entspricht in meinen Augen grober Fahrlässigkeit.

Nun, wenn man es selbst Strickt, macht man sich auch selbst Gedanken über die Sicherheit. Bei einer fertigen Lösung muss man darauf vertrauen, dass sich der entsprechende Entwickler darüber ausreichend Gedanken gemacht hat. Und es ist ja nicht so, dass nur die kompetentesten Entwickler Anwendungen erstellen. Und selbst wenn: Auch die kochen nur mit Wasser.

Sicherlich sollte man sich nicht für zu clever halten. Aber so ein Projekt ist durchaus für einen Einzelnen überschaubar.

Grüße Marco

[1UnitedPower]

Meine Herren!

An der konkreten Lösung stört mich etwa, dass du nicht erwähnst, ob und wie die Datenbank verschlüsslert werden könnte/sollte, und auf welche weise der Nutzer sich beim Server authentifiziert. Eine Lösung selber zu stricken entspricht in meinen Augen grober Fahrlässigkeit.

Nun, wenn man es selbst Strickt, macht man sich auch selbst Gedanken über die Sicherheit.

Und was qualifiziert dich oder mich denn dafür? Ich erwarte hierauf keine Antwort, ich will nur darauf hinaus, dass es mit Sicherheit sehr viel höher qualifizierte Fachkräfte für solche Aufgaben gibt.

Bei einer fertigen Lösung muss man darauf vertrauen, dass sich der entsprechende Entwickler darüber ausreichend Gedanken gemacht hat.

Nicht bei OpenSource-Software. Da kannst du dich auch selber von der Qualität überzeugen.

Und es ist ja nicht so, dass nur die kompetentesten Entwickler Anwendungen erstellen. Und selbst wenn: Auch die kochen nur mit Wasser.

Die Kochen mit Wasser. Aber die _entwickeln_ mit Zeit, Geld einer hochspezialisierten Ausbildung und guten Erfahrungsschätzen, großen oder kleinen Teams, öffentlichen Communities… usw.

Sicherlich sollte man sich nicht für zu clever halten. Aber so ein Projekt ist durchaus für einen Einzelnen überschaubar.

Ich würde den sicherheitsrelevanten Erfolg nicht von der Größe des Projekts abhängig machen.

[misterunknown]

Moin,

Ich erwarte hierauf keine Antwort, ich will nur darauf hinaus, dass es mit Sicherheit sehr viel höher qualifizierte Fachkräfte für solche Aufgaben gibt.

Zweifelsohne. Trotzdem muss eine selbstgestrickte Anwendung nicht zwangsläufig unsicherer sein. Vor allem, wenn es doch sehr überschaubar ist.

Bei einer fertigen Lösung muss man darauf vertrauen, dass sich der entsprechende Entwickler darüber ausreichend Gedanken gemacht hat.
Nicht bei OpenSource-Software. Da kannst du dich auch selber von der Qualität überzeugen.

Nun, da beißt sich die Katze aber in den Schwanz: Wenn ich selbst nicht in der Lage bin, eine sichere Anwendung zu entwickeln, kann ich auch nicht wirklich einschätzen, ob ein OpenSource-Projekt sicher entwickelt ist.

Außerdem kann man seinen Code ja wiederum anderen Entwicklern etwa auf Github zur Verfügung stellen. Dann finden sich eventuell andere Entwickler, die verschiedene Sicherheitsaspekte überprüfen.

Ich würde den sicherheitsrelevanten Erfolg nicht von der Größe des Projekts abhängig machen.

Natürlich nicht. Aber je größer und komplexer ein Projekt ist, desto mehr Raum gibt es für potentielle Sicherheitslücken.

Grüße Marco

[Auge]

Hallo

An der konkreten Lösung stört mich etwa, dass du nicht erwähnst, ob und wie die Datenbank verschlüsslert werden könnte/sollte, und auf welche weise der Nutzer sich beim Server authentifiziert. Eine Lösung selber zu stricken entspricht in meinen Augen grober Fahrlässigkeit.

Nun, wenn man es selbst Strickt, macht man sich auch selbst Gedanken über die Sicherheit.

Und was qualifiziert dich oder mich denn dafür? Ich erwarte hierauf keine Antwort, ich will nur darauf hinaus, dass es mit Sicherheit sehr viel höher qualifizierte Fachkräfte für solche Aufgaben gibt.

Bei einer fertigen Lösung muss man darauf vertrauen, dass sich der entsprechende Entwickler darüber ausreichend Gedanken gemacht hat.

Nicht bei OpenSource-Software. Da kannst du dich auch selber von der Qualität überzeugen.

Aber auch nur, falls ich dafür qualifiziert (s.o.) bin, sonst nutzt mir die Möglichkeit, das zu dürfen, nichts.

Und es ist ja nicht so, dass nur die kompetentesten Entwickler Anwendungen erstellen. Und selbst wenn: Auch die kochen nur mit Wasser.

Die Kochen mit Wasser. Aber die _entwickeln_ mit Zeit, Geld einer hochspezialisierten Ausbildung und guten Erfahrungsschätzen, großen oder kleinen Teams, öffentlichen Communities… usw.

…  oder allein.

Dass es geht und dass es erwünscht ist, OSS gemeinsam zu erstellen und zu prüfen, heißt noch lange nicht, dass es grundsätzlich auch passiert. Die meisten OSS-Projekte sind Ein- oder Zweimannprojekte und die meisten, die OSS nutzen, sind eben nicht fähig, diese zu analysieren.

Ja, Fehler werden entdeckt, weil es geht, und ja, Fehler werden behoben, weil es geht. Aber das ist eben kein Automatismus. Oft genug werden Fehler nicht systematisch gesucht und damit eher irgendwann und zufällig gefunden und bei der Behebung an der Quelle liegt auch oft einiges im Argen. Von Verzögerungen bei Freizeitprojekten bis persönlichen Animositäten zwischen den Beteiligten ist alles dabei.

Dass das im Zweifel immer noch besser ist, als ohne die Möglichekeit einer öffentlich zugänglichen Prüfung auf den Hersteller einer Software vertrauen zu müssen, bestreite ich nicht. Und dass Fehler, wenn auch spät, mitsamt dem damit einhergehenden Getöse auf Heise-Foren-Niveau gefunden werden, ebenfalls nicht.

Nur, OSS systematisch zu vertrauen, nur weil es eben OSS ist, halte ich für blauäugig. Im Zweifelsfall – sicherheitskritische Software zähle ich unbedingt dazu – braucht man auch bei OSS qualifizierte Beratung und Unterstützung.

Tschö, Auge

[M.]

Mahlzeit,

Nicht bei OpenSource-Software. Da kannst du dich auch selber von der Qualität überzeugen.

Du hälst dich nicht für fähig, so ein einfaches Projekt selbst umzusetzen aber du glaubst, fremden Code auf Sicherheitslücken zu prüfen? Erkennst du den Widerspruch in deinen Aussagen?

[1UnitedPower]

Meine Herren!

Nicht bei OpenSource-Software. Da kannst du dich auch selber von der Qualität überzeugen.

Du hälst dich nicht für fähig, so ein einfaches Projekt selbst umzusetzen aber du glaubst, fremden Code auf Sicherheitslücken zu prüfen? Erkennst du den Widerspruch in deinen Aussagen?

Das Statement von misterunknown war, dass man Drittanbietern von Kennwortmanagern blind vertrauen müsse. Darauf habe ich entgegnet, dass das bei OpenSource-Software nicht der Fall sein muss. Die Baupläne liegen ja offen vor, es besteht also das Potenzial die Software gegen die eigenen Sicherheitsansprüche zu verifizieren. Dass ich dazu in der Lage bin, habe ich nicht gesagt, hier ging es erstmal nur um das Vertrauensargument. Und das steht in keinem Widerspruch zu meiner Aussage, dass man auf bewehrte OpenSource-Software setzen soll. Im Gegenteil das ist sogar wesentlicher Bestandteil meiner Argumentation.

[M.]

Mahlzeit,

Eine Lösung selber zu stricken entspricht in meinen Augen grober Fahrlässigkeit.

Dann gehe ich davon aus, dass deine Programmierkenntnisse so minimal sind, dass du diese einfache Aufgabe nicht bewältigen kannst.

Dummerweise ist dir nicht klar, dass jedes Programm von irgendjemand "selber gestrickt" ist. Oder glaubst du wirklich, es gibt Programme, die einfach da sind?

[1UnitedPower]

Meine Herren!

Eine Lösung selber zu stricken entspricht in meinen Augen grober Fahrlässigkeit.

Dann gehe ich davon aus, dass deine Programmierkenntnisse so minimal sind, dass du diese einfache Aufgabe nicht bewältigen kannst.

Für die Konzeption und Entwicklung eines sicheren Kennwort-Managers machen gute Programmierkenntnisse nur einen geringen Teil der nötigen Voraussetzungen aus. Andere Skills, zum Beispiel in Software-Architektur, der Kryptografie gehören und Führungsqualitäten gehören auch dazu.  Ebenso ein breit gefächterter Überblick über etablierte Sicherheitsverfahren und Vorgehensmodelle, sowie das nötige Kapital und die nötige Zeit. Die Liste ließe sich fortsetzen.

Und ich kann, ohne mich zu schämen, festellen, dass ich diese Ressourcen nicht alleine aufbringen kann, um meine eigenen Ansprüche an einen sicheren Kennwort-Manager zu erfüllen.

Dummerweise ist dir nicht klar, dass jedes Programm von irgendjemand "selber gestrickt" ist. Oder glaubst du wirklich, es gibt Programme, die einfach da sind?

Auf diese dumme Begriffstutzigkeit lasse ich mich nicht ein.

[M.]

Mahlzeit,

Und ich kann, ohne mich zu schämen, festellen, dass ich diese Ressourcen nicht alleine aufbringen kann, um meine eigenen Ansprüche an einen sicheren Kennwort-Manager zu erfüllen.

Du überschätzt die Komplexität eines Passwortsafes massiv.
Es geht nicht um eine Multiuser-Anwendung sondern um ein einfaches Storage zur Speicherung von Passwörtern.

Du brauchst da keine kryptografischen Algorythmen zu Ver- und Entschlüsselung, du brauchst eine Datenbank und eine sichere Verbindung dazu.

Aber lassen wir das, sonst kommen wir noch dahin, dass du alle Passwort-Manager, die existieren, als pauschal unsicher bezeichnest.

Was aber bezeichnend ist, auf meine Aussage, dass du dich zwar in der Lage fühlst das Programm einer anderen Person sicherheitsrelevant zu überprüfen, aber selbst kein solches zu schreiben, gehst du nicht ein. Könnte daran liegen, dass du dabei zugeben müsstest, dass du schlichtweg Unsinn erzählt hast.

Ich hab hier bewusst keine neuen Fragen an dich gestellt, Antworten sind wohl nicht zu erwarten ;) Ich bin nur froh, dass ich nichts so verbissen negativ sehe wie du dieses, wirklich kleines, Projekt.

[1UnitedPower]

Meine Herren!

Und ich kann, ohne mich zu schämen, festellen, dass ich diese Ressourcen nicht alleine aufbringen kann, um meine eigenen Ansprüche an einen sicheren Kennwort-Manager zu erfüllen.

Du überschätzt die Komplexität eines Passwortsafes massiv.

Du unterschätzt eher meine Ansprüche an einen Passwort-Manager. Um mal einen Maßstab festzulegen: Ich möchte sorglos meine Bank-Pin dort ablegen können.

Es geht nicht um eine Multiuser-Anwendung sondern um ein einfaches Storage zur Speicherung von Passwörtern.

Von Multiuser habe ich nie gesprochen. Dass Mitro das bietet ist reiner Zufall.

Du brauchst da keine kryptografischen Algorythmen zu Ver- und Entschlüsselung, du brauchst eine Datenbank und eine sichere Verbindung dazu.

Sowohl die Verbindung als auch die Persistenzschicht sollte verschlüsselt werden. Wenn ich nur die Verbindung sichere, dann könnte ja jeder Systemadministrator mit Zugriff auf die Datenbank meine Passworte lesen.

Aber lassen wir das, sonst kommen wir noch dahin, dass du alle Passwort-Manager, die existieren, als pauschal unsicher bezeichnest.

Unterstell mir nicht diesen Unsinn. Ich argumentiere hier doch klar dafür Passwort-Manager von renommierten Entwicklern einzusetzen und gegen Eigenentwicklungen.

Was aber bezeichnend ist, auf meine Aussage, dass du dich zwar in der Lage fühlst das Programm einer anderen Person sicherheitsrelevant zu überprüfen, aber selbst kein solches zu schreiben, gehst du nicht ein.

Ich bin sehr ausführlich darauf eingegangen.

Ich hab hier bewusst keine neuen Fragen an dich gestellt, Antworten sind wohl nicht zu erwarten ;)

Ich vermeide in meinen Antworten nur auf deine unsachlichen Randbemerkungen einzugehen. Auf den inhaltlichen Teil bin ich gerne bereit zu antworten, wenn der persönliche Teil in deinen Kommentaren nicht überhand gewinnt.

[Encoder]

Es kommt ja eigentlich nur auf das Verfahren zur Verschlüsselung an. Da nimmt man am besten was existierendes, TripleDES dürfte gerade aktuell sein und sich für jede Sprache als was fertiges finden lassen. Der Rest drumherum, das in eine Datenbank zu packen, ist unkritische Spielerei.

[1UnitedPower]

Meine Herren!

Es kommt ja eigentlich nur auf das Verfahren zur Verschlüsselung an.

Es stehen aktuell zwei Punkte im Raum, an denen Verschlüsselung bzw. Entschlüsselung stattfinden muss. Die Verbindung und die Persistenzschicht. M. hat bei seinem Brainstorming nur an die Verbindung gedacht und SSL(1) vorgeschlagen, du schlägst jetzt für die Persistenzschicht TripleDES vor. Damit es später nicht zur Verwirrung kommt, wollte ich das eben klar stellen.

1. Bei SSL muss auch noch das Feature-Set, das man implementieren möchte, festgelegt werden. Möchte man zum Beispiel über die heute gebräuchliche Verwendung hinaus auch Client-Zertifikate einsetzen? Welche Zertifizierungsstellen möchte man zulassen?

Sei die Wahl jetzt getroffen. Dann muss als nächstes diskutiert werden, wann und wo die Schlüssel(paare) generiert werden, wie sie transportiert werden, was man von diesen Aufgaben überhaupt automatisieren kann, und was man nicht automatisieren sollte und in die Verantwortung des Nutzers legt.

Da nimmt man am besten was existierendes, TripleDES dürfte gerade aktuell sein und sich für jede Sprache als was fertiges finden lassen.

Und wieso symmetrische Verschlüsselung? Die Wahl sollte begründet ausfallen und vorher mit seinen Alternativen diskutiert worden sein.

Der Erfolg hängt auch nicht nur von der gewählten Programmiersprache ab, sondern z.B. auch von der Umgebung, dass ein Browser eine ungeeignete Umgebung für die Schlüsselbildung ist, haben wir hier neulich erst hier diskutiert.

[Encoder]

Hallo
Hab das erst jetzt gesehen.

Damit es später nicht zur Verwirrung kommt, wollte ich das eben klar stellen.

Gute Idee.

Da nimmt man am besten was existierendes, TripleDES dürfte gerade aktuell sein und sich für jede Sprache als was fertiges finden lassen.

Und wieso symmetrische Verschlüsselung? Die Wahl sollte begründet ausfallen und vorher mit seinen Alternativen diskutiert worden sein.

Ich meinte die Verschlüsselung der Daten in der Datenbank. Asymmetrisch würde bedeuten, es muss irgendwo ein privater Schlüssel sitzen mit dem die Daten entschlüsselt werden. Den auf dem Server zu halten würde die Sache sinnlos machen. Auf den Clients wäre es auch nicht handlebar. Daher dachte ich daran, ein vom Nutzer eingegebenes Passwort zur Ver/Entschlüsselung zu verwenden. Dann ist das Passwort nirgends gespeichert, was natürlich bedeutet dass bei Verlust die Daten alle verloren sind. Das ließe sich aber durch ein Backup an einer sicheren Stelle lösen.

Weitere Maßnahmen.
Um das ganze noch etwas sicherer zu halten könnte man zum Beispiel ein Cookie auf dem Rechner oder Smartphone setzen das einen Teil des Passworts enthält. Sofern das möglich ist, wenn nur von vorher bekannten Rechnern auf das System zugegriffen werden soll.
Dann kann selbst jemand der das Passwort kennt von einem fremden Rechner aus nicht auf das System zugreifen.
Wenn man es noch etwas sicherer halten will, könnte man das Passwort um einen Zufallswert ergänzen, den man bei der Ausgabe selbstverständlich wieder abziehen muss. Z.B. 3 beliebige Zeichen anhängen. Dann hätten gleiche Passwörter verschiedene verschlüsselte Werte, wer die Datenbank sieht kann dann nicht erkennen dass mehrmals das selbe Passwort verwendet wird.

[1UnitedPower]

Meine Herren!

Da nimmt man am besten was existierendes, TripleDES dürfte gerade aktuell sein und sich für jede Sprache als was fertiges finden lassen.

Und wieso symmetrische Verschlüsselung? Die Wahl sollte begründet ausfallen und vorher mit seinen Alternativen diskutiert worden sein.
Ich meinte die Verschlüsselung der Daten in der Datenbank. Asymmetrisch würde bedeuten, es muss irgendwo ein privater Schlüssel sitzen mit dem die Daten entschlüsselt werden.

Bei symmetrischer Verschlüsselung müssen beide Schlüssel geheim gehalten werden. Wenn man den Schlüssel kennt, der zur Verschlüsselung benutzt wurde, dann kann man daraus den nötigen Schlüssel für die Entschlüsselung berechnen. Das grenzt symmetrische Verschlüsselung ja gerade von der asymmetrischen Verschlüsselung ab. Es gibt bei symmetrischer Verschlüsselung folglich keinen Teil den man öffentlich machen könnte. Oder anders formuliert, das gesamte Schlüsselpaar ist als privat einzustufen.

Den auf dem Server zu halten würde die Sache sinnlos machen.

Sehe ich auch so.

Auf den Clients wäre es auch nicht handlebar.

Doch dem Client darf man den Schlüssel anvertrauen. Am besten der Client erzeugt sich sein Schlüsselpaar direkt selbst.

Daher dachte ich daran, ein vom Nutzer eingegebenes Passwort zur Ver/Entschlüsselung zu verwenden.

Ein Passwort ist auch nur ein Schlüssel. Der Unterschied ist rein quantitativ. Unter einem Passwort verstehen wir Schlüssel, die sich menschen einfach merken können, oder die sie in akzeptabler Zeit eingeben können. Die Anschauung eines Schlüssel ist insofern etwas offener und lässt auch sehr viel längere Zeichenketten zu. In der Kryptologie spricht oft einfach von einem Geheimnis.

Dann ist das Passwort nirgends gespeichert, was natürlich bedeutet dass bei Verlust die Daten alle verloren sind. Das ließe sich aber durch ein Backup an einer sicheren Stelle lösen.

Ob ein Nutzer das Passwort oder den Schlüssel in digitaler Form speichert, kann man nicht vorhersehen. Und das ist im Endeffekt auch egal, der Nutzer muss dafür sorgen, dass der Schlüssel (das Geheimnis) geheim! bleibt, darauf kommt es an.

Ein Datenbank-Backup würde dir übrigens bei Verlust des Schlüssels auch nicht helfen, denn das Backup müsste ja ebenfalls entschlüsselt werden können.

Weitere Maßnahmen.
Um das ganze noch etwas sicherer zu halten könnte man zum Beispiel ein Cookie auf dem Rechner oder Smartphone setzen das einen Teil des Passworts enthält. Sofern das möglich ist, wenn nur von vorher bekannten Rechnern auf das System zugegriffen werden soll.

Ich verstehe nicht, wie ein Cookie hier zu mehr Sicherheit beitragen sollte.

Dann kann selbst jemand der das Passwort kennt von einem fremden Rechner aus nicht auf das System zugreifen.

Mit Kenntnis von Cookie und Passwort ginge das wieder. Und das ist ja auch gut. Jemand der den Schlüssel besitzt, der ist zugriffsberechtigt. Wenn der Schlüssel nicht mehr geheim ist, dann muss man andere Maßnahmen treffen. Man zieht in so Fällen denn Häufig eine Zertifizierungsstelle hinzu. Diese Stelle kann Zertifikate ausstellen mit denen man sich digital ausweisen kann. Zertifikate können ungültig gemacht werden, wenn die Integrität des Zertifkat-Trägers nicht mehr gewährleistet ist. Eine Alternative zu einer zentralen Zertifizierungsstelle ist ein Web-Of-Trust. Allgemein spricht man von einer Public-Key-Infrastruktur.

Wenn man es noch etwas sicherer halten will, könnte man das Passwort um einen Zufallswert ergänzen, den man bei der Ausgabe selbstverständlich wieder abziehen muss. Z.B. 3 beliebige Zeichen anhängen. Dann hätten gleiche Passwörter verschiedene verschlüsselte Werte, wer die Datenbank sieht kann dann nicht erkennen dass mehrmals das selbe Passwort verwendet wird.

Redest du von Salting? Das ist ein Verfahren, dass man oft in Verbindung mit Hashing benutzt. Bei der Verschlüsselung kann man dadurch afaik die Sicherheit nicht erhöhen.

[Christian Kruse]

Moin 1UnitedPower,

Oder anders formuliert, das gesamte Schlüsselpaar ist als privat einzustufen.

Auch wenn du rein sachlich recht hast, so spricht man bei symmetrischer Verschlüsselung nicht von einem Schlüsselpaar. Einerseits ist es kein echtes Schlüsselpaar (wie du bereits sagtest, man kann das eine aus dem anderen berechnen) und andererseits ist der Begriff stark mit asymmetrischer Verschlüsselung verknüpft.

Daher dachte ich daran, ein vom Nutzer eingegebenes Passwort zur Ver/Entschlüsselung zu verwenden.

Ein Passwort ist auch nur ein Schlüssel. Der Unterschied ist rein quantitativ. Unter einem Passwort verstehen wir Schlüssel, die sich menschen einfach merken können, oder die sie in akzeptabler Zeit eingeben können. Die Anschauung eines Schlüssel ist insofern etwas offener und lässt auch sehr viel längere Zeichenketten zu. In der Kryptologie spricht oft einfach von einem Geheimnis.

Das ist so nicht ganz richtig. Es existiert (in der modernen Kryptographie) durchaus ein Unterschied zwischen Passwort/Passphrase und Schlüssel (meh, es ist echt schwer die Fachbegriffe ins deutsche zu übersetzen). Der Gedanke dahinter ist, dass bei einer Verschlüsselung alle Schlüssel gleich wahrscheinlich sein müssen, denn sonst kann der Angreifer eine Abkürzung nehmen und die notwendige Arbeit, um den Ciphertext zu brechen signifikant reduzieren. Das wäre der Fall, wenn Passwörter direkt verwendet würden, allein schon durch die unterschiedliche Länge.

Deshalb schicken moderne Verschlüsselungsverfahren das Passwort/die Passphrase durch eine (Hash-)Funktion, deren Ergebnis dann der Key ist.

Weitere Maßnahmen.
Um das ganze noch etwas sicherer zu halten könnte man zum Beispiel ein Cookie auf dem Rechner oder Smartphone setzen das einen Teil des Passworts enthält. Sofern das möglich ist, wenn nur von vorher bekannten Rechnern auf das System zugegriffen werden soll.

Für die eindeutige Identifikation hat man kryptographische Signaturen erfunden. Die sollten für diesen Zweck auch verwendet werden.

Übrigens: moderne Webframeworks verwenden diese Methode, um die Validität eines Session-Cookies sicherzustellen.

Wenn man es noch etwas sicherer halten will, könnte man das Passwort um einen Zufallswert ergänzen, den man bei der Ausgabe selbstverständlich wieder abziehen muss. Z.B. 3 beliebige Zeichen anhängen. Dann hätten gleiche Passwörter verschiedene verschlüsselte Werte, wer die Datenbank sieht kann dann nicht erkennen dass mehrmals das selbe Passwort verwendet wird.

Redest du von Salting? Das ist ein Verfahren, dass man oft in Verbindung mit Hashing benutzt. Bei der Verschlüsselung kann man dadurch afaik die Sicherheit nicht erhöhen.

Das ist halb richtig. Richtig ist, dass man durch Ergänzung des plain texts nichts am Ergebnis ändert. Der cipher text ist (im Idealfall) nicht von Zufall zu unterscheiden. Wenn man zwei mal denselben plain text verschlüsselt, kommt bei modernen Verschlüsselungsvefahren nicht der gleiche cipher text dabei heraus.

Unrichtig ist, dass bei modernen Verschlüsselungsvefahren nicht ein Salting-ähnlicher(!) Mechanismus verwendet wird. Am Beispiel von AES:

Bei AES gibt es mehrere Modi. Für uns interessant ist (und das ist auch mit Abstand der am häufigsten verwendete Modus) der CBC-Modus. Hier wird der plain text in Blöcke zerlegt und jeder Block wird sequentiell verschlüsselt (also erst B1, dann B2, dann B3, …). Der erste Block wird mit einem Input Vector (IV) XORed und dann mit dem Key verschlüsselt. Jeder weitere Block wird mit dem vorherigen XORed und dann auch verschlüsselt. So sieht der cipher text aus wie Zufall.

Bei der Entschlüsselung wird dann der IV wieder gebraucht: zuerst wird der erste Block entschlüsselt und dann mit dem IV wieder XORed. Jeder folgende Block wird entschlüsselt und dann mit dem vorherigen XORed. Wenn also der IV verloren geht, ist maximal der erste Block verloren, jeder weitere kann weiterhin entschlüsselt werden.

Klar, das ist nicht Salting, aber die Mechanismen sind ähnlich.

LG,
 CK

[Encoder]

Hallo, in meinem Beitrag waren mehrere Gedanken enthalten. Ich versuche das zu entwirren.

Bei symmetrischer Verschlüsselung müssen beide Schlüssel geheim gehalten werden.

Dass es nur einen gibt hat ja Christian Kruse bereits gesagt. Hier kommt es drauf an wie der Schlüssel aussehen soll. Wenn das ein Passwort ist das der Eigentümer weiß und jedes mal eingeben will (im Gegensatz zu einer Passwort-Datei was ja auch denkbar wäre, die aber nicht auf beliebigen Rechnern vorhanden ist), wird dieser Schlüssel nirgends abgelegt sondern sich nur gemerkt.

Dann ist das Passwort nirgends gespeichert, was natürlich bedeutet dass bei Verlust die Daten alle verloren sind. Das ließe sich aber durch ein Backup an einer sicheren Stelle lösen.
Ob ein Nutzer das Passwort oder den Schlüssel in digitaler Form speichert, kann man nicht vorhersehen. Und das ist im Endeffekt auch egal, der Nutzer muss dafür sorgen, dass der Schlüssel (das Geheimnis) geheim! bleibt, darauf kommt es an.

Dabei dachte ich an Plaintext der ausgedruckt zuhause im Schrank liegt :-) Dann kann man das Passwort zum System vergessen und hat wenigstens nicht alle darin gespeicherten Passwörter verloren.

Um das ganze noch etwas sicherer zu halten könnte man zum Beispiel ein Cookie auf dem Rechner oder Smartphone setzen das einen Teil des Passworts enthält. Sofern das möglich ist, wenn nur von vorher bekannten Rechnern auf das System zugegriffen werden soll.
Ich verstehe nicht, wie ein Cookie hier zu mehr Sicherheit beitragen sollte.

Damit könnte ein Teil des Passworts in ein Cookie ausgelagert werden, das natürlich vorher ausdrücklich gesetzt werden muss. Somit würde praktisch das Passwort verlängert und selbst wenn jemand dem Nutzer bei der Eingabe des Passworts zusieht, kann derjenige von seinem Rechner aus immer noch nichts damit anfangen. War aber nur eine Idee, so sehr praktikabel dürfte die nicht sein.

Wenn man es noch etwas sicherer halten will, könnte man das Passwort um einen Zufallswert ergänzen, den man bei der Ausgabe selbstverständlich wieder abziehen muss. Z.B. 3 beliebige Zeichen anhängen. Dann hätten gleiche Passwörter verschiedene verschlüsselte Werte, wer die Datenbank sieht kann dann nicht erkennen dass mehrmals das selbe Passwort verwendet wird.
Redest du von Salting? Das ist ein Verfahren, dass man oft in Verbindung mit Hashing benutzt. Bei der Verschlüsselung kann man dadurch afaik die Sicherheit nicht erhöhen.

Damit würde man erreichen dass mehrere gleiche gespeicherte Werte - man hat vielleicht öfter das selbe Passwort verwendet - mit verschiedenen Zufallsstrings ergänzt wird und somit ein unterschiedlicher verschlüsselter Wert rauskommt. In gewissem Sinn wäre das mit Salting also schon vergleichbar, es ist aber letztendlich doch was anderes gemeint.

[Matthias Apsel]

Om nah hoo pez nyeetz, misterunknown!

Ich verwende das Passwort-Depot, allerdings nicht im Netz.

Matthias

[1UnitedPower]

Meine Herren!

Sie dir mal Mitro an. Die Software ist OpenSource. Zu den Investoren zählt neben anderen auch Google. Das Entwicklerteam ist inzwischen Twitter beigetreten. Damit dürftest du also ein Teil in der Hand haben, das von einem reputativen Entwicklerstab entworfen wurde und die Symphatie großer Software-Riesen genießt.

[M.]

Mahlzeit,

Sie dir mal Mitro an. Die Software ist OpenSource. Zu den Investoren zählt neben anderen auch Google. Das Entwicklerteam ist inzwischen Twitter beigetreten. Damit dürftest du also ein Teil in der Hand haben, das von einem reputativen Entwicklerstab entworfen wurde und die Symphatie großer Software-Riesen genießt.

Ich fasse mal zusammen: Du findest es einfacher, ein fertiges Projekt zu prüfen anstatt es selbst zu programmieren, obwohl es ein einfaches Projekt ist. Dann empfiehlst du etwas, was von Leuten entwickelt wird, die für die grössten Datenkraken gearbeitet haben oder arbeiten.

Bist du mir böse, wenn ich deine Vorschläge für völlig daneben halte? Und nein, das ist nicht böse gemeint, aber du machst hier exakt das Gegenteil von dem, was gesunder Menschenverstand als sinnvoll empfindet ;)

[1UnitedPower]

Meine Herren!

Sie dir mal Mitro an. Die Software ist OpenSource. Zu den Investoren zählt neben anderen auch Google. Das Entwicklerteam ist inzwischen Twitter beigetreten. Damit dürftest du also ein Teil in der Hand haben, das von einem reputativen Entwicklerstab entworfen wurde und die Symphatie großer Software-Riesen genießt.

Ich fasse mal zusammen: Du findest es einfacher, ein fertiges Projekt zu prüfen anstatt es selbst zu programmieren, obwohl es ein einfaches Projekt ist.

Die Entwicklung eines Kennwort-Managers halte ich nicht für eine einfache Aufgabe, das habe ich auch nirgends geschrieben. Ich finde im übrigen „Einfachheit“ als Faktor bei der Bewertung von Sicherheitssystemen sowieso unzulässig und habe die Worte nie in den Mund genommen.

Dann empfiehlst du etwas, was von Leuten entwickelt wird, die für die grössten Datenkraken gearbeitet haben oder arbeiten.

Meine Argumentation wendet sich klar gegen eine do-it-yourself-Lösung, und für eine Lösung, die von hochspezialisierten und renommierten Fachkräften unter Einbezug der Öffentlichkeit erarbeitet wird. Mitro passt also sehr gut in meine Argumentation.

Kannst du deine Bedenken bezüglich Google und Twitter als Investor bzw. Arbeitgeber von Mitro bitte präzisieren.

Bist du mir böse, wenn ich deine Vorschläge für völlig daneben halte? Und nein, das ist nicht böse gemeint, aber du machst hier exakt das Gegenteil von dem, was gesunder Menschenverstand als sinnvoll empfindet ;)

Auch hierauf werde ich nicht eingehen.