Fragen zur Passwortsicherheit

  • Vor- und Nachteile sind überall. Ich nutze Bitwarden, gehostet in deren Cloud. Was genau die machen weiß ich natürlich nicht. Ich traue mir aber auch nicht zu das sicher selbst zu hosten. Von daher muss ich halt vertrauen. Da ich davon ausgehe das dort Leute arbeiten die Ahnung von ihren Sachen haben, wird das besser sein als wenn das einer ohne Ahnung (Ich) macht.

    Das ist auch genau meine Ansicht, mit allen Vor- und Nachteilen. Hinzu kommt, dass ich die Passwort Cloud gar nicht in meiner Infrastruktur haben möchte, da sie sonst bei Problemen mit dieser auch mit ausfallen würde - wenn man sie ggfalls gerade besonders dringend benötigen würde.


    Beide Herangehensweisen sind fein, jede:r setzt da andere Maßstäbe an.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

  • absolut keinen Sinn darin nicht auf wirklich sichere open source Lösungen zu setzten - ein valides Argument dies nicht zu tun ist mir noch nie über den Weg gelaufen.

    Ich setze gerne und oft auf OSS. In diesem Fall kann man das auch machen und das eine schließt das andere ja auch nicht aus. Allerdings benötigt man in diesem Fall eine Synchronisationslösung. Und diese ist dann halt jemandes anderen Cloud.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

  • "security by obscurity" ist nie eine gute Methode.

    Was schon häufig bewiesen wurden, ist.

    Wobei im Fallen, der meisten Passwort Manger reicht, dass der Client Code open source ist, wenn sich dadurch nachvollziehen lässt, dass die Ent- und Verschlüsslung nur lokal erfolgt. Dann agiert der Server nicht viel anderes als z.B. die Nextcloud oder Google Cloud die, die Keepass Datei synchronisiert.

  • Wo diskreditiere ich denn bitte?

    Diskreditiere, Bedeutung:

    • abqualifizieren, abwerten, durch den Schmutz ziehen, herabsetzen


    Irgendwelche Non-Open Source Drittanbieterapps für KeePass auf mobilen Endgeräten disqualifizieren sich aus Sicherheitsgründen von selbst. Damit ist ein solcher Passwortmanager nur auf Computern einsetzbar. Und wo ist das dann "die bessere Software"? Ein Passwortmanager muss eine Software sein, die überall verfügbar ist

    Falschaussage


    "Belege für Behauptungen" findet man für so ziemlich alles, inklusive dass die Erde flach sei.

    Falschaussage und ins lächerliche ziehen. Vielleicht kennst du aber auch den Unterschied einer Behauptung und eines Beleges nicht, denn wenn es Belege für eine flache Erde gäbe, wäre es ja bewiesen dass die Erde flach ist. An diesem Punkt irgendwelche Verschwörungstheorien ins Spiel zu bringen ist halt Taktik um das Gegenüber zu diffamieren. Gleiche Strategie fährst du oft eben z.b. bei dieser gender Diskussion.

    Und dann schreibst du auch noch gerne was von "ad hominem" obwohl du selbst lediglich Scheinargumente bringst und genau das hier ein perfektes Beispiel für Brunnenvergiftung und tu quoque ist. ;D


    Tiefer möchte ich gar nicht eindringen - letztlich ist das jedem selbst überlassen. Kann gut sein, dass 1Password sehr sicher ist, aber nur weil 1Password schreibt wie sicher sie sind, bedeutet das nicht, dass dem so ist.

    Braucht sich nur jemand in deren System Hacken und klar Codes aus dem RAM auslesen oder oder oder. Klar, kann mir privat auch passieren, keine Frage, aber zumindest weiß ich (wenn mich es interessiert) was die Software genau wie macht und biete nicht so eine große Grundlage überhaupt angegriffen zu werden.

    Nur weil du eine Lokale Kopie deiner Datenbank im Cache heißt, heißt das nicht, dass du die Datenbank lokal hast in der Form wie sie auf deren Server liegen - 1Password ging ja lange Zeit offline, habe es vor vielen Jahren selbst verwendet. Mit dem Cloud Zwang disqualifizieren sie sich aus Sicherheitstechnischer Sicht nun von selbst - meiner Meinung nach.


    Zum Thema "ad hominem"

  • Das habe ich nicht bezweifelt. Das Gegenteil ist halt auch nicht sicherer.

    Naja - per se ist Open Source Software nicht besser oder sicherer, das stimmt schon. Kommt halt immer drauf an was für Code verwendet wird und wie groß das Projekt ist. Ab einer kritischen Masse von Mitlesern und Leuten wird FOSS dann doch deutlich sicherer statistisch gesehen und sobald eine Lücke publik wird, muss und wird diese auch geschlossen - was bei anderer Software nicht unbedingt der Fall sein muss.

    Viele Features von Open Source Software werden auch nur langsam hinzugefügt bis wirklich ausreichend getestet wurde und es gibt verschiedene Kanäle welche ein Anwender dann verwenden kann, "stable" "beta" etc. Ein Gewinnorientiertes Unternehmen arbeitet hier im allgemeinen dann doch etwas anders da es ja direkte Konkurrenz gibt.

    Im Grunde ist eh alles OS was sich decompilieren lässt.

    Naja, nein. Zum einen ist mir keine reverse engineering Methode bekannt die wirklich den verwendeten Code ausspuckt und zum anderen kommt es ja auch auf den Compiler an wie das kompilierte Programm letztlich aussieht - was auch gewisse Sicherheitsrisiken im Open Source Bereich mit sich bringt. --> Sicherheitslücke im Compiler führt zu Sicherheitslücke im Programm auch wenn der Code sauber ist.


    Hat alles seine für und wider. Aber gerade was Verschlüsselung und Betriebssystem anbelangt ist für mich klar, dass ich auf Open Source Lösungen setzte und lieber weniger Funktionen habe (was ja nicht immer der Fall sein muss)

  • sobald eine Lücke publik wird, muss und wird diese auch geschlossen

    Eine schöne Traumvorstellung. Leider vorbei an der Realität.

    Zumal jemand der gemütlich irgendwas hacken kann, weil er im Code nach Löchern suchen konnte, diese kaum direkt verrät - sondern weiterhin verwendet oder für Geld verkauft.
    Bei OS hat man den Code vor sich und kann finden durch stöbern.
    Bei Nicht-OS, findet man Lücken durch Try&Error.

    Letzteres finde ich Aufwändiger. Lücken findet man bei beidem, mehr Sicherheit sehe ich in keinem Konzept.

  • Aber gerade was Verschlüsselung und Betriebssystem anbelangt ist für mich klar, dass ich auf Open Source

    Lösungen setzte

    Verbietet Dir niemand, schätze ich. Jeder hat seinen Weg und einen Grund dafür. Und zum Glück muss niemand die Überzeugungen von jemandem übernehmen.


    Zum einen ist mir keine reverse engineering Methode bekannt die wirklich den verwendeten Code ausspuckt

    Das Dir keine bekannt ist, bedeutet nicht, das es sie nicht gibt.
    Ich mache das (unter anderem) beruflich. Bevor eine Software zum Kunden geht, wird sie dekompiliert um die Bereiche zu finden die mehr geschützt werden müssen.

  • Zumal jemand der gemütlich irgendwas hacken kann, weil er im Code nach Löchern suchen konnte, diese kaum direkt verrät - sondern weiterhin verwendet oder für Geld verkauft.
    Bei OS hat man den Code vor sich und kann finden durch stöbern.
    Bei Nicht-OS, findet man Lücken durch Try&Error.

    Ich halte diese Aussage ehrlich gesagt eher für eine Traumvorstellung insbesondere wenn ein Programm eine gewisse Komplexität erreicht hat.

    Deine Aussage steht im übrigen in keinem Bezug zu meiner Aussage, denn sobald eine Lücke bekannt wird wird diese auch geschlossen - das war meine Aussage. Wenn es wirklich eine Person X geben würde der sich einer Lücke bewusst ist und diese ausnutzt, ist diese Lücke ja nicht allgemein bekannt.

    Bei Softwareherstellern schaut es anders aus, die müssen erst reagieren wenn die Kacke am dampfen ist und wissen womöglich von Lücken im eigenen Code, welche aber schwer zu stopfen sind und hoffen, dass erstmal alles gut geht ;D


    Es ist meiner Erfahrung nach weitaus komplizierter und bedeutend schwerer eine offensichtliche Hintertür / Fehler in einem Code zu finden als einfach via Try & Error Unmengen an Dingen / Angriffe austesten zu lassen und entsprechend dem Verhalten weiter zu agieren. Solche Fehler im Programm bzw Sicherheitslücken kommen ja oft durch das Zusammenspiel von mehreren unabhängig voneinander geschriebenen Codes zusammen.


    Bei Open Source Software hast du ja auch keine kontinuierliche Erweiterung des Programmes sondern es werden genauso Updates erzeugt nachdem der Code überarbeitet und geprüft wurde.


    Das Dir keine bekannt ist, bedeutet nicht, das es sie nicht gibt.
    Ich mache das (unter anderem) beruflich. Bevor eine Software zum Kunden geht, wird sie dekompiliert um die Bereiche zu finden die mehr geschützt werden müssen.

    Es ist vollkommen richtig, dass nur weil ich es nicht kenne, es nicht heißt dass es das nicht gibt - habe ich ja auch so geschrieben.

    Aber wenn eine gewinnorientierte Software Firma nicht möchte, dass du das Programm dekompilieren kannst, dann wirst du das niemals dekompilieren können.

    Ich weiß nicht was du beruflich machst, aber kommerzielle Software zu dekompilieren ist in der Regel illegal und Open Source Software zu dekompilieren ist sinnlos. Ich zweifle sehr stark an der Korrektheit deiner Aussage, gebe ich offen zu.

    Um "Bereiche zu finden die mehr geschützt werden müssen" zu finden, brauche ich kein Programm dekompilieren, weil Änderungen kann ich nur vornehmen wenn ich das Programm selbst geschrieben habe oder es nicht geschützt ist.

    Und wenn es um eigene Software geht, kann ich diese natürlich so schreiben dass ich sie auch wieder dekompilieren kann, nur werde ich sie in dieser Form wohl kaum an einen Kunden liefern und tut in diesem Kontext wiederum nichts zur Sache.

  • Um "Bereiche zu finden die mehr geschützt werden müssen" zu finden, brauche ich kein Programm dekompilieren, weil Änderungen kann ich nur vornehmen wenn ich das Programm selbst geschrieben habe oder es nicht geschützt ist.

    Zu wenig geschützte Bereiche zu finden, bedeutet nicht die Software zu ändern.

    Abgesehen davon unterschätzt Du gewaltig was alles möglich ist zu decompilieren.

    Du unterschätzt gewaltig wieviele bekannte Lücken über Jahrzehnte nicht gestopft werden. Bei OS und auch bei Nicht-OS.

    Bei Softwareherstellern schaut es anders aus, die müssen erst reagieren wenn die Kacke am dampfen ist

    Woher Du das hast weiß ich nicht. Sicher gibt es Softwarehersteller die ohne Qualitätssicherung so schluderig arbeiten.

    Die Regel ist das nicht. Schon aus finanziellen Gründen.

    How Ever, ich bin hier raus. Das führt zu weit weg vom Thema.

    Mir ging es eigentlich nur darum das OS genauso wie Nicht-OS vor- und Nachteile hat und das beides keine Sicherheit aufgrund ihrer Methodik bietet.

    Was jemand davon einsetzt wird immer eine individuelle Entscheidung sein, angepasst an Gegebenheiten. Für mich gibt es im Kontext des Thread kein "XY ist definitiv besser weil ...".

    Und was Passwörter angeht ist wohl das sicherste, nicht öffentlich zu diskutieren was sicher ist uns warum, um nicht den evtl. mitlesenden Hackern einen Weg zu zeigen *g*.


    Schönen Restsonntag :).


  • Du unterschätzt gewaltig wieviele bekannte Lücken über Jahrzehnte nicht gestopft werden. Bei OS und auch bei Nicht-OS.

    Sehr gut möglich, ja. Wenn es so gewaltig viel ist, könntest du mir 2-3 Beispiele nennen? Dann kann ich mich etwas informieren.


    Aber deine Aussage stützt ja meine Aussage, dass Softwarehersteller nicht zwingend Löcher stopfen (müssen) außer sie richtigen Schaden an etc.


    Zu wenig geschützte Bereiche zu finden, bedeutet nicht die Software zu ändern.

    Ändert nichts daran, dass es in der Regel trotzdem verboten ist.

    und das beides keine Sicherheit aufgrund ihrer Methodik bietet.

    Da stimme ich dir allgemein im Bezug auf Software zu.

    Bei Passwort Managern schaut es aber trotzdem etwas anders aus, weil eine Firma die Millionen von Passwörtern von abertausenden Leuten speichert ein sehr viel interessanteres Ziel darstellt als meine individuell durch Open Source Software verschlüsselte Datenbank daheim auf meinem Laptop und das verschiebt die Rechnung etwas.


    Auch die Statistik über ausgenutzte Schwachstellen deutet daraufhin, dass Open Source Software sicherer ist. Aber die jeweiligen Anwender spielen hier vermutlich auch keine zu geringe Rolle.



    Finde die Diskussion mit dir aber wirklich interessant, weil es doch immer etwas mehr Komplexität aufweist, als es den Anschein macht und du hast schon recht, dass nichts eine Endgültige Lösung darstellt solange es Leute gibt die Software Schwächen gezielt ausnutzen und immer der Anwendungsfall entscheiden mit eine Rolle spielt.

  • Nur aus Interesse: Wofür müsst ihr denn eure Keepass Datei auf jedem Gerät synchronisiert haben? Wie oft greift ihr wirklich auf euer Hello Kitty Online Passwort von unterwegs zu? :/


    Seit vielen Jahren liegt meine auf meinem Rechner und als Backup auf dem NAS, das wars und reicht mehr als aus :)

  • Ich habe einen beruflichen Laptop, einen privaten Desktop, ein Smartphone, ein Tablet sowie mehrere Remote Desktops auf denen die Accounts synchron sein sollen/müssen. Zudem gibt es beruflich geteilte Tresore zwischen mehreren Personen.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

  • Und in welcher cloud synchronisiert du dann deine KeePass Datei TBT?


    Valkyrie

    Ich hab die Datei in meiner privaten Nextcloud schon alleine aus dem Grund der mehrfachen Speicherung, falls irgendwas mit meinem Laptop sein sollte etc.

    Aber ich verwende den Tresor auch aufm Handy und aufm Tablet. Tablet weniger aber Handy schon mehrfach täglich.


    Eine notwendigkeit auf sämtlichen Maschinen den Tresor lauffähig zu machen, insbesondere Remote Desktops etc, sehe ich nicht und würde ich auch nicht machen. Dafür kann ich ja einfach die Auto Type Funktion von KeePassXC verwenden - was auch der Grund für mich ist warum ich bis jetzt noch nicht auf Bitwarden gewechselt habe.