Passwörter/Passwortmanager

    Quelle: Cosmo

    Zitat von Cosmo

    Diese Bemerkung führt(e bei mir) zu dem Verständnis, daß nach seinem Verständnis Bugs in Paßwort-Managern bereits das unmittelbare Aus für die Sicherheit zwangsläufig zur Folge haben

    Ich habe es nicht so verstanden, dass er da bereits einen unmittelbaren Zusammenhang sieht. Für mich klang das noch nach einem "kann".

    Zitat

    und hatte bei KP von "weitgehend" Immun gegen Programm-Bugs geschrieben

    Darin ist zumindest für mich eine Wertung bzw. Abgrenzung zu erkennen, du magst das aber anders gemeint haben. Für mich heißt das: Entweder sind alle seriösen Passwortspeicher "weitgehend immun" und damit die Wertung letztlich sinnlos oder der angesprochene muss in der Hinsicht Maßnahmen ergreifen, die über die Funktionalität anderer hinausgeht. Zwar ergreift Keepass einige Sicherungsmaßnahmen, die andere Passwortspeicher nicht umsetzen, allerdings sehe ich da keinen Zusammenhang mit Bugs im Anwendungsprogramm. Darauf wollte ich hinaus, denn in dem Kontext hatte ich u.a. den Hinweis von st1519 verstanden.

    Zitat

    daß er in jeder Umgebung kostenlos ohne lizenzrechtliche Probleme und ohne Funktionsbeschränkungen eingesetzt werden kann

    In jeder Windows-Umgebung :wink: In der Hinsicht scheinen mir Keepass und KeepassX auch nicht vollkommen kompatibel zu sein.
    http://keepass.info/help/base/security.html#secdictprotect

    Zitat

    KeePassX: In contrast to KeePass, the Linux port project 'KeePassX' only partially supports protection against dictionary and guessing attacks.

    Zitat

    Der "Transport" von Zugangsdaten aus dem FF-Paßwortmanager hat natürlich da seine Grenzen, wo auf dem gerade verwendeten Rechner diese von dir angedeutete Erweiterung gar nicht installiert ist

    Da es den Fx auch in portabler Form gibt, ließe sich das Problem an der Stelle so beheben.

    Zitat

    und ob diese Methode nicht wiederum Sicherheitsrisiken bietet wäre auch noch zu hinterfragen

    Das muss man nicht hinterfragen, die Risiken sind offensichtlich vorhanden. Natürlich muss gewährleistet werden, dass eine Synchronisierung über das Web gewissen Sicherheitsmaßstäben entspricht.

    Zitat

    daß er Open Source ist und Backdoors damit praktisch ausgeschlossen sind

    Diese Annahme ist für mich "akademischer Natur". Denn in der Realität prüfen keine Anwender den Code und Code Audits durch qualifizierte Dritte sind eher die Ausnahme denn die Regel. Daher demonstriert ein Entwickler damit prinzipiell Offenheit und ermöglicht eine Prüfung des Codes durch Dritte (sowie das eigenständige Kompilieren von Binaries), wie das in der Realität aussieht, bleibt aber offen und daraus bspw. die Existenz von Backdoors "praktisch" auszuschließen ist ein wenig voreilig.

    Zitat

    so kann damit ausgeschlossen werden, daß das Programm durch einen Angreifer unter der Hand ausgetauscht wird.

    Jein. Der Programmcode mag durch die Systemrechte geschützt sein. Gelingt es allerdings einem Angreifer Code auf einem System auszuführen, so wäre bspw. folgendes Szenario denkbar:
    Der Angreifer ersetzt die Programmverknüpfungen durch eine Umleitung auf seinen Klon, der einen Backdoor enthält. Ein User würde keinen Verdacht schöpfen.
    Man müsste also darauf achten auch wirklich die durch das System geschützte Anwendung auszuführen.

    Über unterschiedliches Verständnis zu diskutieren ist müßig, den Teil überspringe ich deswegen.

    Zur "Umgebung": Da ich von KeePass geschrieben habe und das ein Windows-Programm ist, hatte ich nicht unterschiedliche OS-Umgebungen gemeint (die es für KP nicht gibt), sondern Dinge wie Privatanwender, gewerbliche, behördliche, Ausbildungsbetriebe, wo es bei zahlreicher Freeware ja durchaus lizenzrechtliche Einschränkungen gibt.

    KeePassX != KeePass, und wie ich deutlich schrieb, deswegen nicht mein Thema.

    Zum Vorschlag portabler Fuchs als Ersatz für den portablen PW-Manager: Da fallen mir spontan ein halbes Dutzend Dinge ein:

    1. In meinem(!) Verständnis ist der portable Fuchs keine(!) offizielle Distribution. Das mag jeder selber bewerten, für mich ist das bereits für sich ein KO-Kriterium.

    2. Eine weitere FF-Version erfordert auch zusätzlichen Aufwand, diese Version mitsamt aller installierter Addons zu pflegen. Im Ergebnis wäre diese Lösung also mit erheblichem Mehraufwand verbunden.

    3. Wie die Paßworte von der installierten Desktopversion in den portablen FF kommen sollen, ist weiterhin unklar, wenn man nicht erst kopieren will, wie ich schon am 24.8. eingewendet hatte.

    4. Grundsätzlich den portablen FF zu verwenden (also vom Stick, damit man nicht erst kopieren muß) ist keine lustige Sache, denn Sticks sind nun einmal langsamer als eine Festplatte.

    5. Eine portable Lösung muß sich möglichst an die gerade verwendete Umgebung (hier: der verwendete Rechner) anpassen können. Das heißt, mit dem dort zu verwendenden Browser zusammenarbeiten. Mit PW-Manager kein Problem, mit dem portablen Fuchs als PW-Manager-Ersatz nicht durchführbar. Geht es darum, aus gegebenem Anlaß eine Seite mit einem anderen Browser zu inspizieren, so hilft der im portablen FF eingebaute PW-Manager rein gar nichts. Ebenso wo wenig bei anderer Software, auf die ich am 24. ebenfalls hingewiesen hatte.

    6. Einen Browser portabel zu machen, nur um Zugangsdaten zu transportieren, klingt nicht sehr ziel führend. Dann könnte ich ebenso gut eine Live-CD verwenden, um einen anderen Rechner zu überprüfen und hätte dabei noch den Vorteil, daß dort eventuell vorhandene Software (in diesem Zusammenhang insbesondere: Keylogger) gar nicht erst die Chance haben zu starten. Aber das war ja nicht der Ausgangspunkt der Diskussion über Portabilität mit st1519.

    7. Zwar hatte ich vom Stick geschrieben, als es um die Portabilität ging (einfach deswegen, weil ich nicht noch weitere Themen aus dem vorhandenen generieren will), tatsächlich verwende ich keinen Stick, wenn ich dem betreffenden Rechner nicht absolut vertraue, sondern brenne KP mit allen erforderlichen Dateien (insgesamt 3) auf eine finalisierte CD-RW; ich will ja auf gesicherte Zugänge zugreifen und nicht welche verwalten. Ich bezweifle, daß der portable FF von einer CD ausführbar ist (und wenn, wäre er noch quälender langsam).

    Den portablen FF zu verwenden, wenn ich Zugangsdaten portabel benötige, fiele mir nicht einmal im Traum ein, und Albträume versuche ich immer so schnell wie möglich zu vergessen.


    Zum Thema Open Source:
    Ich habe den Eindruck gewonnen, daß du die Webseite von KP kennst. Dann kennst du auch das auf der Leitseite wiedergegebene Zitat von Bruce Schneier, einem der Kryptographie-Päpste weltweit:

    Zitat von Bruce Schneier

    In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice.


    Auf deutsch in kürzester Zusammenfassung: Alles außer OpenSource ist in diesem Sektor indiskutabel. (Nicht-Anglisten sei Google oder ein anderer geeigneter Übersetzungsdienst für die wörtliche Übersetzung empfohlen.)

    Zum eingeschränkten Konto:
    Den Einwand gerade von dir zu lesen hat mich überrascht. Vielleicht ist das dem Umstand geschuldet, daß das Mißverständnis entstanden ist, daß ich ein eingeschränktes Konto für die Lösung der absoluten Sicherheit halte. Dem ist nicht so. Es gibt sie nicht, auch nicht mit eingeschränkten Benutzerrechten.

    Der von dir gemachte Einwand ist technisch korrekt; ich schrieb aber hier im Camp in den letzten Tagen bereits, daß Sicherheit nicht die Frage des Einsatzes einer bestimmten Software ist, sondern ein Konzept. Und der von dir aufgezeigte Angriffsvektor ist selbst mit Bordmitteln abzufangen. Man braucht nur die Verknüpfung für den Start in die Autostartgruppe von All Users zu legen oder in den HKLM-Zweig der Registrierung und mit Benutzerrechten ist kein Eingriff (Ersetzen, Löschen) mehr möglich. Für einfache Benutzer etwas schwieriger aber ebenso erfolgreich wäre es, dem Benutzer für die übliche Verknüpfung das Schreibrecht zu nehmen.

    Sagte ich schon, daß es sich um einen ganz besonders sensiblen Bereich handelt, der der ganz besonderen Verantwortlichkeit des Anwenders unterliegt? Hier wird tatsächlich eine völlig individuelle Lösung eingesetzt, die weder eine Autostartgruppe noch irgend einen Teil der Registrierung verwendet.

    Und nein, ich gebe mich auch damit nicht der Illusion hin, daß ich damit völlige Sicherheit hätte. Aber da ich weder das Pentagon noch die CIA bin, gehe ich davon aus, daß es digitale Angreifer nicht auf mich persönlich abgesehen haben, sondern ich denselben Angriffen ausgesetzt bin wie Millionen andere auch. Diese Angreifer versuchen mit den üblichen Mitteln ihre Angriffe auszuführen und finden auch täglich ihre Opfer, so daß sie schon aus Gründen der Effektivität gar nicht erst versuchen werden, nach individuellen Angriffsmustern zu suchen, was ähnlich ineffektiv wäre wie die Suche nach Paßwörtern nach dem von st1519 abgelehnten Schema. Auch das ist keine absolute Sicherheit, reduziert aber die Wahrscheinlichkeit erfolgreicher Angriffe auf eine überschaubare Größenordnung. (Da die vielen unsicher konfigurierten Systeme unfreiwillig zu dem Schutz meines Systems beitragen, sollte ich mir eigentlich überlegen, ob ich meine Informationen und Hilfen zum Thema Sicherheit nicht abstellen sollte. Das Problem dabei ist, daß ich meine Frau nicht dazu überreden kann, sämtliche Spiegel in der Wohnung abzuschaffen.)

    Zitat von boardraider

    Ähm, Einspruch! Lies bitte nochmal oben wer
    den Begriff einbrachte.

    sorry, falls ich falsch zitiert hab.
    Thematisch sind wir uns wohl eh alle mehr oder weniger einig.

    Zitat

    Nach meiner Erfahrung halten sich selbst
    Teilnehmer solcher Threads nicht immer an solche
    "Binsenweisheiten".


    Ja, oft muß man das auch gar nicht. Wenn z.B. mein Account hier
    kompromitiert würde, wäre da jetzt ja nicht so schlimm, wie eine
    Kompromitierung eines online banking accounts :)

    Zitat

    Solche Umgebungen sind ohnehin nicht als
    vertrauenswürdig zu sehen. Dort bietet sich der Einsatz von
    Einmalpasswörtern an.


    Na ja, aber dazu muß es doch der Server unterstützen?
    Obwohl wohl viele "zivilisierte" Internetcaffees ziemlich gut
    sind (nach Sessionende werden sämtliche Sessiondaten gelöscht
    etc), aber man kann sich halt nicht unbedingt drauf verlassen,
    also nicht darauf vertrauen. Da muß man glauben :)

    Danke allen für die Passwortmanager-Links!

    Cosmo, danke für die tolle Zusammenfassung und die Infos zu
    Keepass.

    Inwiefern habe ich mich gegen sichere Paßwörter gewendet? Ich
    schrieb, dass ich der Meinung bin, dass oft weniger sichere
    Passwörter verwendet werden. Ja, starke Paßwörter und
    Passwortmanager sind für nicht-lokale Angriffe gut.
    Hardwaregestützte Passwortmanager sind noch besser. Einen
    Klasse-4 Leser mit smartcard z.B.

    Allerdings mag der Aufwand für eine Hardwarelösung für ein
    Webforum übertrieben erscheinen.
    Was keinesfalls für schwache Paßwörter sprechen soll.

    Also ganz klar: Leute, nehmt

    Code
    .___  | |_    __ _   _ __  | | __   ___
 / __| | __|  / _` | | '__| | |/ /  / _ \
 \__ \ | |_  | (_| | | |    |   <  |  __/
 |___/  \__|  \__,_| |_|    |_|\_\  \___|
 .____             ___              _   _          _                   _   _
 |  _ \    __ _   / _ \ __      __ (_)_(_)  _ __  | |_    ___   _ __  | | | |
 | |_) |  / _` | | |/ / \ \ /\ / /  / _ \  | '__| | __|  / _ \ | '__| | | | |
 |  __/  | (_| | | |\ \  \ V  V /  | (_) | | |    | |_  |  __/ | |    |_| |_|
 |_|      \__,_| | ||_/   \_/\_/    \___/  |_|     \__|  \___| |_|    (_) (_)
                 |_|

    (so richtig überzeugend ist das "code" Tag nicht,was?
    Zeilenumbrüche werden als Formatierung übernommen, blanks
    nicht, pre gibts nicht, HTML geht nicht, ich geb auf :) )

    auch wenn /ich/ für Webforen Paßwörter verwende, die ein
    schneller PC in ein paar Stunden brute-forcen kann :)

    Schönes Wochenende!

    Zitat von st1519

    Inwiefern habe ich mich gegen sichere Paßwörter gewendet? Ich
    schrieb, dass ich der Meinung bin, dass oft weniger sichere
    Passwörter verwendet werden.


    Dein Beitrag vom 17. August und der vom 20. verleiteten mich zu dieser Annahme.
    Aber du hast, Recht, du hast stets von anderen Benutzern geschrieben. Ich nehme das mit Entschuldigung zurück.

    Quelle: Cosmo

    Zitat von Cosmo

    Wie die Paßworte von der installierten Desktopversion in den portablen FF kommen sollen, ist weiterhin unklar, wenn man nicht erst kopieren will, wie ich schon am 24.8. eingewendet hatte.

    Wie bereits erwähnt sprach ich von der Nutzung entsprechender Erweiterungen.

    Zitat

    Mit PW-Manager kein Problem, mit dem portablen Fuchs als PW-Manager-Ersatz nicht durchführbar.

    Es wurde nicht behauptet der Fx-PW-Manager wäre ein vollfunktionaler Ersatz für eigenständige Lösungen.

    Zitat

    Einen Browser portabel zu machen, nur um Zugangsdaten zu transportieren, klingt nicht sehr ziel führend.

    Beim vorausgesetzten Einsatz eines portablen Fx mit der Anforderung dort gespeicherte Passwörter zu verwenden wäre eine weitere externe Lösung nicht zielführend. Eine Frage der Anforderungen und daher nochmals der Hinweis, dass es hier nicht um eine vergleichbare Lösung ging, sondern um eine eingeschränkte und spezialisierte.

    Zitat

    Dann kennst du auch das auf der Leitseite wiedergegebene Zitat von Bruce Schneier
    [...]Auf deutsch in kürzester Zusammenfassung: Alles außer OpenSource ist in diesem Sektor indiskutabel. (Nicht-Anglisten sei Google oder ein anderer geeigneter Übersetzungsdienst für die wörtliche Übersetzung empfohlen.)

    Leider ist eine wörtliche Übersetzung nicht immer geeignet den Leser gedanklich über die reinen Worte hinaus zu führen. Du behauptest oben durch Open Source wären Backdoors praktisch ausgeschlossen. Das ist schlicht unwahr und Schneier würde sich auch nicht zu einer solchen Behauptung hinreißen lassen. Das von dir angeführte Zitat beschäftigt sich im Kern mit dem Vergleich zwischen OS- und proprietärer Software. Er weist darauf hin, dass OS im Sicherheitsbereich eine Notwendigkeit darstellt. Dort steht nichts davon, dass durch den Stempel OS eine Software per se als sicher angesehen werden kann, wie du es hier "praktisch" unterstellt hast.

    Zitat

    Den Einwand gerade von dir zu lesen hat mich überrascht.

    Weshalb? Das geschilderte ist ein Angriffsszenario das verdeutlicht, dass eingeschränkte Benutzerrechten nicht in jedem Fall helfen. Ich habe dir nicht unterstellt, dass du das als Allheilmittel anpreist. Nur hielt ich die obig zitierte Aussage für ergänzungswert um nicht bei Dritten einen falschen Eindruck zu erwecken.

    Zitat

    Hier wird tatsächlich eine völlig individuelle Lösung eingesetzt, die weder eine Autostartgruppe noch irgend einen Teil der Registrierung verwendet.

    Das Vorstellen dieser Lösung wäre für den einen oder anderen sicher interessant.

    Um das Thema portabler FF hier zum Abschuß zu bringen: Ich hatte bereits in demselben Absatz, in dem ich erstmals am 24. August für den PW-Manager plädiert hatte, davon geschrieben, daß er unabhängig vom besuchten System (gemeint ist Software-Ausstattung, nicht OS) und der dort verwendeten Software (ich hatte dabei ausdrücklich auch Nicht-Browser-Software genannt!) zu verwenden ist. Ob mit oder ohne Erweiterung, der portable Fuchs kann das nicht (und ist dafür nie vorgesehen gewesen). Und ich hatte oben in 7 Punkten dargestellt, was - teilweise pro Einzelaspekt schon alleine - einen Einsatz (und konsequenterweise eine Empfehlung) durch mich kategorisch ausschließt. Es ist müßig, über die Einzelaspekte zu diskutieren.

    Zitat von boardraider

    Leider ist eine wörtliche Übersetzung nicht immer geeignet den Leser gedanklich über die reinen Worte hinaus zu führen. Du behauptest oben durch Open Source wären Backdoors praktisch ausgeschlossen. Das ist schlicht unwahr und Schneier würde sich auch nicht zu einer solchen Behauptung hinreißen lassen. Das von dir angeführte Zitat beschäftigt sich im Kern mit dem Vergleich zwischen OS- und proprietärer Software. Er weist darauf hin, dass OS im Sicherheitsbereich eine Notwendigkeit darstellt. Dort steht nichts davon, dass durch den Stempel OS eine Software per se als sicher angesehen werden kann, wie du es hier "praktisch" unterstellt hast.


    1. Die Aussage "Backdoors praktisch ausgeschlossen" und die von dir hier verwendete Aussage "per se als sicher" sind nicht dasselbe. Dein letzter Satz steht somit irgendwie ohne Bezug da.
    2. Wenn ich geschrieben hätte "Backdoors theoretisch ausgeschlossen" und du hättest dagegen protestiert, dann hättest du Recht. Aber "praktisch" ist es so und ich interpretiere Schneiers Aussage genau so. Auch eine Suche "KeePass Backdoor" oder "KeePass" Secunia" oder ähnlich bringt nicht einmal einen noch so schwachen Anschein des Gegenteils zu Tage. - Ich bin mir jetzt nicht schlüssig, ob du dich mit deiner Argumentation gegen den Nutzen von OS in diesem Segment generell wendest oder ob es dir nur um diesen Aspekt geht; in letzterem Fall ist es mir allerdings rätselhaft, wo in deinen Augen der Vorteil von OS liegen sollte (oder wo deiner Meinung nach Schneier ihn sehen sollte). (Und erzähl mir nicht, er läge darin, daß man den Code nach seinen Bedürfnissen anpassen könne. Wenn du argumentierst, daß ihn niemand lesen würde, paßt ihn auch keiner an.)

    Quelle: Cosmo

    Zitat von Cosmo

    Es ist müßig, über die Einzelaspekte zu diskutieren.

    Wurde hier nicht angestrebt, deine Punkte sind meist völlig valide. Es wurden lediglich Aufhänger genommen auf unsere verschiedenen Ansatzpunkte hinzuweisen.

    Zitat

    Die Aussage "Backdoors praktisch ausgeschlossen" und die von dir hier verwendete Aussage "per se als sicher" sind nicht dasselbe.

    Genau deine Aussage soll aber den flüchtigen Anschein erwecken, dass dem so ist. "Praktisch ausgeschlossen" wird nicht damit assoziiert, dass die Software erst durch Dritte geprüft werden muss, bevor man Aussagen über ihre Sicherheit treffen kann. Denn erst solche Audits sind "praktische Arbeit". Bis dahin ist die Sicherheit durch das OS-Merkmal rein theoretischer Natur. Deine Aussage verdeutlicht diesen Umstand allerdings nicht und weckt den Eindruck OS grundsätzlich mit "sicher" zu verknüpfen. So einfach ist das allerdings nicht.

    Zitat

    Auch eine Suche "KeePass Backdoor" oder "KeePass" Secunia" oder ähnlich bringt nicht einmal einen noch so schwachen Anschein des Gegenteils zu Tage

    Das Nicht-Wissen über Lücken sagt nichts über das Nicht-Vorhandensein aus. Auch ein Prinzip aus der Softwaresicherheit. Man kann zudem die Sicherheit einer Software nicht durch eine Google-Suche beweisen oder bemessen. Weder im Falle von KeePass, noch im Falle jedes anderen komplexeren Codes. Auch lassen sich von Einzelprojekten keine Rückschlüsse auf andere erzielen.

    Zitat

    Ich bin mir jetzt nicht schlüssig, ob du dich mit deiner Argumentation gegen den Nutzen von OS in diesem Segment generell wendest

    Keines Falls, ich halte OS in dem Bereich absolut für notwendig. Allerdings kann man die Sicherheit von Software eben nicht an einen OS-Stempel knüpfen. In der Schulmathematik sprach man damals differenzierend von notwendig und hinreichend.

    Zitat

    wo in deinen Augen der Vorteil von OS liegen sollte

    In meinen Augen liegt er im Sicherheitskontext
    a) in der demonstrierten Öffentlichkeit der Entwickler
    b) in der Möglichkeit von Audits durch Dritte
    Weder a) noch b) erhöhen allerdings die Sicherheit der Software. Erst wenn der Code tatsächlich von anderen geprüft wird, lässt sich eine Aussage über dessen Güte, Qualität od. Sicherheit treffen.

    Zitat

    Und erzähl mir nicht, er läge darin, daß man den Code nach seinen Bedürfnissen anpassen könne. Wenn du argumentierst, daß ihn niemand lesen würde, paßt ihn auch keiner an.

    Das "Anpassen" spielt im Sicherheitskontext keine sehr entscheidende Rolle, auch wenn es im Einzelfall durchaus relevant sein kann. Dabei sollte man dann differenzieren, was "Anpassungen" sind. Ich kann mir den Code von KeePass besorgen und ein paar triviale Codefragmente ändern. Dadurch kann ich zwar ein Urteil darüber fällen, wie sauber die Entwickler coden. Es erfordert aber einiges an Mehraufwand und Know-How bspw. die Implementierungen der verschiedenen Krypto-Algorithmen oder der sonstigere tiefgehende Funktionen zu prüfen oder im späteren zu modifizieren. Und an der Stelle wird es dann für die Sicherheit der Software erst interessant. Es bleibt also die Frage, wer mit welchem Know-How welchen Code mit welchem Hintergrund und mit welchem Ziel ließt.

    Cosmo stellte Folgendes dar:

    Zitat

    [...]Den portablen FF zu verwenden, wenn ich Zugangsdaten portabel benötige, fiele mir nicht einmal im Traum ein[...]

    Zustimmung. Die Sicherheit der zu verwaltenen Passwörter hängt - meinen Erkenntnissen nach – im Allgemeinen auch von:


    a. der kryptographischen Stärke der Hashfunktion,

    b. der Qualität der Rechtevergabe, bzw. der Zugriffskontrolle der Subjekte (Anwender) auf so einem System oder Stick,

    c. sowie auch dem Entzug der lokalen Leseberechtigungen für die vertrauliche Passwort-Datei selber ab.


    Portable Pw´s (z.B. über USB-Applikationen), können i.d.T. unbeabsichtigt über ein bereits kompromittiertes Fremdsystem geführt werden, von wo sie aus dann u.U. „kriminell weiterverwertbar“ wären. Gleiches würde - meiner Ansicht nach - jedoch auch für den portablen Keepass gelten müssen, da sich grundsätzlich jedes PW zu einem bestimmten Zeitpunkt entschlüsselt im RAM eines wie auch immer gearteten (trojanisierten) Fremdsystems befinden müsste.

    Vielleicht wäre es von daher sinnvoller auf so einem USB-Stick - mit seinen vertraulichen PW-Anwendungen - begleitend ein separat abgesichertes und bootbares OS zu implementieren, um somit die „Überführung“ vertraulicher Zugangswörter über ein bereits kompromittiertes und fremdes %SYSTEMROOT% zu vermeiden.


    Cosmo erklärte darüberhinaus:

    Zitat

    [...]Dann kennst du auch das auf der [Keepass] Leitseite wiedergegebene Zitat von Bruce Schneier, einem der Kryptographie-Päpste weltweit:

    Ich bin zufällig im Besitz seines Originalwerkes: [Applied Cryptography/Second Edition]. Ich glaube er [Bruce Schneier] meinte mit dem Zitat vordringlich die gewährleistete Authentizität, sowie auch die dafür notwendige Publikation des öffentlichen Schlüssels selber - und zwar zur allgemeinen Fehlerkontrolle der zugrundeliegenden Funktionsqualität. (RSA-Algorithmus / Schlüsselraum / Faktorisierung, etc.).


    Oliver

    Zitat von Oliver222

    Portable Pw´s (z.B. über USB-Applikationen), können i.d.T. unbeabsichtigt über ein bereits kompromittiertes Fremdsystem geführt werden, von wo sie aus dann u.U. „kriminell weiterverwertbar“ wären. Gleiches würde - meiner Ansicht nach - jedoch auch für den portablen Keepass gelten müssen, da sich grundsätzlich jedes PW zu einem bestimmten Zeitpunkt entschlüsselt im RAM eines wie auch immer gearteten (trojanisierten) Fremdsystems befinden müsste.

    Vielleicht wäre es von daher sinnvoller auf so einem USB-Stick - mit seinen vertraulichen PW-Anwendungen - begleitend ein separat abgesichertes und bootbares OS zu implementieren, um somit die „Überführung“ vertraulicher Zugangswörter über ein bereits kompromittiertes und fremdes %SYSTEMROOT% zu vermeiden.


    Hier sind wir uns mit Sicherheit völlig einig.
    Bei dem Szenario, das von st1519 vor nunmehr schon einiger Zeit aufgestellt worden ist, wäre es allerdings wahrscheinlich unbrauchbar. Andererseits, wenn man als Admin Rechner zu betreuen hat, die von den Anwendern nur mit eingeschränkten Benutzerrechten verwendet werden können und der Admin meldet sich zum Zweck der Betreuung an diesem Rechner ein einem Konto an, zu dem die täglichen Benutzer keinen Zugang haben (das kann das Admin-Konto oder auch ein weiteres eingeschränktes Benutzerkonto mit Paßwortzugang sein), so kann er auch sicher sein, daß keine Keylogger tätig sind.

    Auf völlig fremden Rechnern (Stichwort: Internet-Cafe) müßte ich aus gegebenen Umständen schon in großer Not sein, bevor ich dort irgend etwas, was persönliche Daten betrifft, machen würde.


    Zitat von Oliver222

    Ich bin zufällig im Besitz seines Originalwerkes: [Applied Cryptography/Second Edition]. Ich glaube er [Bruce Schneier] meinte mit dem Zitat vordringlich die gewährleistete Authentizität, sowie auch die dafür notwendige Publikation des öffentlichen Schlüssels selber - und zwar zur allgemeinen Fehlerkontrolle der zugrunde liegenden Funktionsqualität. (RSA-Algorithmus / Schlüsselraum / Faktorisierung, etc.).


    Ich habe dieses Werk nicht und kann es nicht beurteilen. Deswegen ganz wertfrei die Frage, ob du dir da sicher bist? Der Grund meiner Frage: Öffentliche Schlüssel kenne ich im Zusammenhang mit asymmetrischen Verschlüsselungsverfahren (Stichwort: PGP) und in dem Zitat (siehe oben) ist auch von Schlüsseln nicht die Rede (wäre auch unverständlich, ein öffentlicher Schlüssel ist per definitionem öffentlich). Schneiers Zitat liest sich für mich so, als ob es unabhängig davon, ob ein symmetrisches oder asymmetrisches Verfahren verwendet wird, gemeint ist.

    Cosmo erklärte Folgendes:

    Zitat

    [...]Schneiers Zitat liest sich für mich so, als ob es unabhängig davon, ob ein symmetrisches oder asymmetrisches Verfahren verwendet wird, gemeint ist.

    Du hast Recht. Ich hatte Dein obiges Zitat missverstanden.


    Zwischen OpenSource (Dein ursprüngliches Zitat), sowie auch der Offenlegung von math. Verschlüsselungsalgorithmen zur ständigen Konzeptverbesserung (meine Darstellung), besteht dennoch eine Kohärenz (Gleichnis). Beides ist bewusst offen gehalten, einsehbar und lässt sich stets verbessern.


    Keepass qualifiziert sich zwar als quelloffene und rechtsfreie OpenSource-Software. Keepass unterliegt - meiner Beurteilung nach - jedoch auch der „Qualität“ des zugrundeliegenden (symmetrischen) Verschlüsselungsverfahrens selber.


    Die Kommunikationssicherheit in einem symmetrischen Kryptosystem hängt daher nicht alleine von der „Stärke“ der Verschlüsselung selber, sondern auch von der „Verwaltung“ und „Aufbewahrung“ des „geheimen Schlüssels“ ab. (Anwenderinteraktion / Übertragung des Schlüssels / Betriebssystemsicherheit i.B. auf die vertrauliche Schlüsselverwaltung). Hier liegt meiner Ansicht nach die einzige „Schwäche“ des Passwort-Safes vor.


    Oliver

    Zitat von Oliver222

    „Verwaltung“ und „Aufbewahrung“ des „geheimen Schlüssels“ ab. (Anwenderinteraktion / Übertragung des Schlüssels / Betriebssystemsicherheit i.B. auf die vertrauliche Schlüsselverwaltung)


    Womit wir wieder beim Ausgangspunkt des Threades wären (da ging es um "ähnliche" Paßwörter): Der Anwender ist die entscheidende Schwachstelle und die vor kurzem aufgeführten Binsenweisheiten bei weitem nicht Binsen-haft genug, um auch nur die primitivsten Fehler zu vermeiden.