[English]Der nächste gravierende Sicherheitsvorfall, denn der Anbieter LastPass eingestehen muss. LastPass gab gerade bekannt, dass ein Bedrohungsakteur eine Sicherungskopie der verschlüsselten Tresor-Daten (Vault Data) seiner Kunden gestohlen habe. Der Coup gelang mit Hilfe von Cloud-Speicherschlüsseln, die im August 2022 von einem LastPass-Mitarbeiter gestohlen wurden. Sollte der Angreifer die Verschlüsselung knacken können, wäre der Zugriff auf die gespeicherten Nutzerzugangsdaten möglich – der absolute GAU. Ergänzung: Jemand hat das Ganze als Konstrukt aus PR-Palaver, Weglassungen und möglichen Lügen aufbereitet.
Anzeige
LastPass ist ein Dienst zur Speicherung seiner Passwörter und Zugangsdaten für Online-Konten – wobei diese Daten in einem Vault genannten Daten-Tresor in der Cloud abgelegt werden. Sollte man tunlichst vermeiden, da man von diesem Dienst und dessen Sicherheit abhängt. LastPass musste im August einen Sicherheitsvorfall melden, bei der die Entwicklungsumgebung gehackt wurde (siehe LastPass Sicherheitsvorfall: Entwicklungsumgebung gehackt (25. August 2022)). Die Angreifer hatten vier Tage Zeit, sich im internen IT-Netzwerk umzusehen (siehe Links am Artikelende). Im November 2022 wurde bekannt, dass LastPass Kundendaten nach dem Hack eines Cloud-Speicherdiensts entwendet werden konnten.
Vault Data bei Hack erbeutet
In einer Meldung vom 20. Dez. 2022 gesteht LastPass nun den nächsten Sicherheitsvorfall ein. Beim Hack eines Cloud-Speicherdiensts (siehe LastPass-Kundendaten nach Hack eines Cloud-Speicherdiensts abgezogen (Nov. 2022)) wurde wohl mehr als bekannt an Daten abgezogen. LastPass schreibt, dass die bisherigen Ermittlungen haben ergeben, dass ein unbekannter Bedrohungsakteur auf eine Cloud-basierte Speicherumgebung zugegriffen hat. Dazu wurden Informationen aus dem Vorfall im August 2022 genutzt (LastPass Sicherheitsvorfall: Entwicklungsumgebung gehackt (25. August 2022)).
Während des Vorfalls im August 2022 wurde zwar nicht auf Kundendaten zugegriffen, aber es wurden einige Quellcodes und technische Informationen aus der LastPass-Entwicklungsumgebung gestohlen. Diese Informationen wurden verwendet, um einen anderen Mitarbeiter anzugreifen und Anmeldeinformationen und Schlüssel zu erhalten, die für den Zugriff und die Entschlüsselung einiger Speichervolumina innerhalb des Cloud-basierten Speicherdienstes verwendet wurden.
Die LastPass-Produktionsdienste werden derzeit zwar aus lokalen Rechenzentren betrieben, wobei der Cloud-basierte Speicher für verschiedene Zwecke genutzt wird, z. B. für die Speicherung von Backups und regionale Anforderungen an die Datenresidenz. Der Cloud-Speicherdienst, auf den der Bedrohungsakteur zugreifen konnte, ist physisch von der LastPass-Produktionsumgebung getrennt.
Anzeige
Die bisherige Auswertung ergab aber, dass der Bedrohungsakteur den Zugriffsschlüssel für den Cloud-Speicher und die Entschlüsselungsschlüssel für die beiden Speichercontainer erlangte. Dadurch war er in der Lage, Informationen einem dem Backup zu kopieren. Dadurch hat er Zugriff auf die grundlegende Kundenkontoinformationen und die zugehörigen Metadaten. Darunter sind auch Firmennamen, Endbenutzernamen, Rechnungsadressen, E-Mail-Adressen, Telefonnummern und die IP-Adressen, von denen aus die Kunden auf den LastPass-Dienst zugriffen.
Der Bedrohungsakteur war auch in der Lage, eine Sicherungskopie der Daten des Kundentresors aus dem verschlüsselten Speichercontainer zu kopieren,. Die Sicherungskopie ist zwar in einem proprietären Binärformat gespeichert, enthält aber sowohl unverschlüsselte Daten wie Website-URLs als auch vollständig verschlüsselte sensible Felder wie Website-Benutzernamen und -Passwörter, sichere Notizen und in Formulare eingegebene Daten.
Diese verschlüsselten Felder sind mit einer 256-Bit-AES-Verschlüsselung gesichert und können nur mit einem eindeutigen Verschlüsselungsschlüssel entschlüsselt werden, der mit Hilfe der LastPass Zero Knowledge-Architektur aus dem Master-Passwort jedes Benutzers abgeleitet wird.
Zur Erinnerung: Das Master-Passwort ist LastPass niemals bekannt und wird von LastPass weder gespeichert noch verwaltet. Die Ver- und Entschlüsselung der Daten wird nur auf dem lokalen LastPass-Client durchgeführt. Weitere Informationen über unsere Zero Knowledge Architektur und Verschlüsselungsalgorithmen gibt es hier.
Es gibt keine Hinweise darauf, dass auf unverschlüsselte Kreditkartendaten zugegriffen wurde, schreibt das Unternehmen, denn LastPass speichert keine vollständigen Kreditkartennummern und Kreditkarteninformationen werden in dieser Cloud-Speicherumgebung nicht archiviert.
Der Bedrohungsakteur könnte aber versuchen, das von Nutzern gewählte Master-Passwort mit Brute Force-Angriffen zu erraten und im Anschluss die Kopien der entwendeten Tresordaten zu entschlüsseln. Aufgrund der Hashing- und Verschlüsselungsmethoden, die LastPass zum Schutz einsetzt, wäre es äußerst schwierig, Master-Passwörter von Kunden, die den LastPass Best Practices für Passwörter befolgen, mit Brute Force-Angriffen. Alles in allem ist dies für LastPass ein Debakel.
Ergänzung: In diesem Artikel arbeitet sich jemand an der Mitteilung von LastPass ab und schreibt, dass der Vorfall im August und das jetzt gemeldete Ereignis zusammen hängen. Im Artikel wird aufbereitet, wie LastPass seine Nutzer mit den schrittweisen Meldungen der Vorfälle abspeist und dass die Verlautbarungen wohl Markting-Bullshit sind. Golem hat das Thema hier in Deutsch aufbereitet.
Ähnliche Artikel:
LastPass Sicherheitsvorfall: Entwicklungsumgebung gehackt (25. August 2022)
LastPass bestätigt: Angreifer hatten vier Tage Zugriff auf interne Systeme
LastPass-Kundendaten nach Hack eines Cloud-Speicherdiensts abgezogen (Nov. 2022)
Anzeige
Naja nur Spielkinder oder Idioten versuchen heute noch per Bruteforce solche Daten zu knacken. Es wurden doch aber alle Daten abgegriffen um sich da bequem "zwischen zu schalten", da liefern einem zumindest die dumben User die Daten dann freihaus.
Rein Interesse halber: wäre für das Knacken der Passwörter nicht eine BitCoin Farm ideal? Die haben doch massenhaft Grafikkarten von nVIDIA die sich doch angeblich so gut eignen um so etwas zu knacken oder liege ich da jetzt komplett falsch? (bin dafür nicht tief genug in der Materie)
Nein die werden das mit einer Wörterbuchattacke machen. Es gibt immer jemanden der kein Zufalls-PW verwendet und das ist dann ein gefundenes Fressen für Cyberkriminelle.
https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
Du wärst überrascht die alles knacken können. Die 100k Runden SHA256 sind auch NICHT sicher. Heutzutage verwenden man eigentlich argon2 als Hash-Funktion.
Erstmal muss man sich vor Augen führen wie die Verschlüsselung technisch grob funktioniert. Die Daten (in dem Fall Passwörter) werden durch einen Masterkey geschützt. Diese sollte bei sauberer Implementierung z.B. ein AES-256 Key sein.
Ein solcher Key ist per Bruteforce mit an Sicherheit grenzender Wahrscheinlichkeit nicht zu knacken. Selbst wenn man jeden PC und Großrechner der Welt gleichzeitig nutzen können, dann würde das Durchprobieren alle Möglichkeiten immer noch deutlich länger dauern als unser Universum existiert. Es bleibt nur die theoretische Option „Glück zu haben", denn auch der 17. getestete Key könnte ja der Richtige sein. Das ist aber wie gesagt extremst unwahrscheinlich.
Der Masterkey ist ebenfalls verschlüsselt. Die Grundlage dafür ist das Passwort, welches der Anwender für seinen Tresor vergeben hat. Dies Passwort ist der „schwache Punkt", weil Anwender häufig einfache und zu kurze Passwörter wählen. Keepass z.B. zeigt einem als grobe Hilfe eine Einschätzung zur Qualität eines Passwortes an. So kommt z.B. das folgende Passwort auf 107 Bit
ySPQArG8tJhA6r4yUgzr
Es ist damit um einen Faktor 713.623.846.352.980.000.000.000.000.000.000.000.000.000.000 schlechter als der Masterkey. Entsprechend werden Angreifer bevorzugt versuchen das Passwort zu erraten, weil die Aussichten auf Erfolg hier besser sind.
Dieser Umstand ist natürlich auch dem Entwickler der Verschlüsselung bekannt und deshalb versucht man es den Angreifern zu erschweren. Man erzeugt aus dem Passwort über eine Funktion einen Hashwert, welcher dann für die Verschlüsselung des Masterkeys verwendet wird. Den Hash zu berechnen benötigt etwas Zeit. Wie lange hängt von der Rechenleistung des PCs und dem Hashverfahren ab.
Praktisch wird die Zeit für die Berechnung verlängert, indem man die Hashfunktion mehrfach hintereinander aufruft, also das letzte Ergebnis nochmals hasht. Bei meinem PC sind es bei Keepass rund 100 Millionen Runden um 2 Sekunden Verzögerung einzubauen. Mich stören die zwei Sekunden nicht, aber ein Angreifer wird für jedes Passwort um ca. diesen Wert aufgehalten, je nach Leistungsfähigkeit seiner Hardware. Die Anzahl der Runden ist in diesem Fall also dynamisch einstellbar, aber in der Datenbank im Klartext hinterlegt. Sonst wüsste Keepass ja nicht wie oft die Hashfunktion rekursiv aufgerufen werden muss.
Andere Programme wie z.B. VeraCrypt bieten hier auch noch die Option an eine PIM zu verwenden. Das ist ein zweiter Faktor (Zahl), welcher als Multiplikator für die Hashfunktion verwendet wird. Die berechneten Runden der Hashfunktion hängen von diesem Faktor ab, so dass ein richtiges Passwort mit der falschen PIM nicht funktioniert. Liegen realistische PIM-Werte zwischen 500 und 2.000, so müsste jedes einzelne Passwort 1.500-mal getestet werden. Für den Angreifer ist nicht erkennbar, ob eine PIM benötigt wird, da dieser Faktor aus dem Wissen des Anwenders stammt.
Grundsätzlich empfehle ich lange Passwörter zu verwenden. Für einen Passwort-Container würde ich unter 20 Zeichen gar nicht anfangen. Das ist zwar nicht so bequem, aber ich muss mir ja nur dieses eine Passwort merken, die anderen nimmt mir dann der Passwort-Manager ab. Für den absoluten Notfall hilft auch ein analoges Backup zu je 10 Zeichen auf zwei Zetteln, welche man an zwei sicheren Orten hinterlegt.
Das Brute-Force-Knacken der Datenbank wird nicht zwangsläufig erforderlich sein. Wäre auch ein ziemlich aussichtsloser K(r)ampf.
Da der Quellcode ja anscheinend vorliegt wird hier wie üblich vorgegangen: Nach fehlerhaften Implementierungen der Verschlüsselung gesucht (gibt es immer! Perfekt und fehlerfrei würde eine Anwendung unbenutzbar machen) und dann "von hinten rum" eingestiegen.
Die Leute denken immer wieder zu primitiv, wenn sie sich laienhaft vorstellen, man würde derlei Verschlüsselungen per Brute-Force knacken. So arbeiten Profis nicht.
Sehe ich genauso. Da wird der Programmcode analysiert und bisschen Reverse Engineering betrieben. Solche Angreifer wie bei LastPass sind meist selbst sehr gut ausgebildete Programmierer/Informatiker, die entsprechende Fehler erkennen können. Zeigt sich ja schon bei den vorangegangen Hacks.
Wieder einer auf der großen Liste abgehakt.
Wer war doch gleich der Nächste… KeePass?
Ok, Du hast Dich weder mit dem einen, noch mit dem anderen befaßt. Die beiden Produkte haben nur das "Pass" gemeinsam.
KeePass bietet keine direkte Cloud-Speicherung an. Die kannst Du nutzen, ist aber rein optional. Die Wege des Teilens sind unerschöpflich.
Dazu wird bei KeePass die Datenbank selbst verschlüsselt und jedes mal Entropie verwendet (darum kann der Vorgang auch eine ganze Ecke dauern bei kleinen Änderungen). Auch liest Du keine Klar-Text-Daten aus der Datenbank aus.
Und zu allem Überfluß: KeePass richtet sich an einzelne Endanwender. Jeder Hans und Franz hat seine eigene Datenbank. LastPass hingegen betreibt ein Sammelsurium seiner zahlenden Kundschaft und hat alles fein säuberlich parat.
LastPass = lohnt für einen Angriff
KeePass = da mußt Du schon besonders interessant/wichtig sein, um ins Visier zu geraten…
Mag ja sein, daß die GUI von KeePass altbacken aussieht, aber technisch kann ich der Anwendung blind vertrauen (und tu dies auch).
KeePass ist gut, aber leider auch nicht unverwundbar. Keepass hat unter Windows seine Konfiguration in C:\Users\AppData\Roaming\KeePass\KeePass.config.XML liegen. In KeePass kannst du sogenannte "Trigger" anlegen, also Ereignis-gesteuerte Funktionen, wenn das passiert, dann mache das. Zum Beispiel auch "Wenn eine Passwortdatenbank geöffnet wurde, dann exportiere sie als CSV (mit Passwörtern in Klartext). Solche Trigger werden in der genannten XML-Datei abgelegt und die ist natürlich im Benutzerkontext beschreibbar, und KeePas hat keinen Kontrollmechanismus, der feststellen kann, ob die Datei manipuliert wurde. Wenn also ein Angreifer schon einen Task auf deinem PC laufen hat, schreibt er einfach in deine KeePass.config.XML einen entsprechenden Trigger rein, und greift dann die exportierte Datei ab, sobald du KeePass öffnest. Das merkst du garnicht. Auch die Linux-Version des "normalen" Keepass ist auf dem Weg angreifbar. Ich bin deswegen kürzlich auf KeePassXC umgestiegen, das macht keine solchen Trigger.
Wenn du schon eine Schadsoftware in deinem Benutzerkontext laufen hast, die also überhaupt Zugriff auf C:\Users\dich hat, brauchst du dir um solche Feinheiten keine Sorgen mehr zu machen. Gleiches gilt für Keylogger. Daher sehe ich hier absolut kein Problem bei KeePass.
Bin zwar grundsätzlich auch der Meinung, dass Du ohnehin verloren hast, wenn es einem Angreifer gelingt, auf Deinem Rechner Schadsoftware auszuführen, aber der von 1ST1 dargestellte Mechanismus dürfte doch einiges bequemer sein, als wochenlang z.B. den Datenfluss eines Keyloggers auswerten zu müssen, in der Hoffnung, dass sich irgendwann einmal etwas Lohnendes finden lässt.
@1ST1
Danke für den Hinweis.
KeePass bietet AFAIK keine Cloud Speicher Funktion an sondern wird selbst gehostet (Lokale Tresor Datei auf USB Stick). Ebenfalls können hier verschiedene Verschlüsselungstechniken gewählt und/oder kombiniert werden.
Desweiteren liegt der Quellcode offen vor (OpenSource) und kann unabhängig geprüft werden.
Die Möglichkeit bei einem Zentralen Anbieter Datenbanken vieler Kunden rauszutragen ist wohl attraktiver. (Einbruch bei Bank vs. Einbruch bei einzelnen Zielen)
KeePass ist kein Cloud Dienst …
Also auf das schmale Brett, das Brute-Force auf die abgegriffenen Tresore/Dateien schwierig sein soll, muss man auch erst einmal kommen.
Brute-Force auf passwortgeschützte _Dateien_ ist so ziemlich der feuchte Traum eines jeden Angreifers: Greife ich einen Server so an, kann der nach belieben auf die Bremse treten und Brute-Force wird zum unlösbaren Problem.
_Dateien_ kann ich millionenfach kopieren und dann auf jede Datei einen oder mehrere Angreifer darauf ansetzen. Da hilft es auch nicht, wenn das Passwort nur zur Herleitung eines wirklich sicheren kryptografischen Schlüssels verwendet wird.
Ja, viele Dateien haben Bremsen eingebaut, die jede einzelne Passwortabfrage verlangsamen (massiv Rechenleistung belegen) und damit brute-force erschweren. Aber in der heutigen Zeit der COW-Dateisysteme (Datenkopie wird erst bei Datenänderung geschrieben) kann ich Kopien von 100GB Dateien schneller erstellen, als die Passwortabfrage dauert und brauche auch 'nur' 100GB Speicher, egal wie viele Kopien ich erstelle.
Und, das ist die Ironie an der Sache: Die Cloud ist der ideale Angreifer für so etwas. Verteilte Dateisysteme sind quasi alle COW, d.h. der Speicher ist ideal und preiswert. Zudem kann ich extrem viele Angreifer mit kurzer Lebensdauer für wenig Geld bekommen.
Und mal ehrlich: Wie viele der Nutzer werden wohl Passphrasen verwenden (>32 Zeichen? Die Masse wird sich an den Minimalanforderungen orientieren, die der Dienst hat, weil die Idee, das ein Passwort auch 'Dies ist meine 5. supergeheime Passwortphrase die nienicht erraten werden kann!' den meisten fremd ist.
TL;DR: Bei passwortgeschützten Dateien hilft selbst eine lange und komplexe Passphrase bestenfalls kurzzeitig, wenn der Akteur gewillt ist, genug Mittel einzusetzen.
Bei hinreichend langen kryptographischen Schlüsseln sieht die Sache anders aus, aber auch hier ist die schützende Decke deutlich dünner.
Also: Ab in die Cloud – die bösen Jungs nutzen sie längst ;-)
Das ist salopp gesagt Unsinn: Für AES-256 brauchst du zum Brute-Forcen des Passwortes (2^254,4) erstes mehr Zeit als das Universum alt ist, zweitens mehr Energie (Strom), wie überhaupt auf den gesamten Planeten verfügbar ist und dritten mehr als alles Geld der Welt um die Energie zu bezahlen. Solange du keine nennenswerten Informationen zum Schlüssel hast, versuchst du es erst gar nicht.
Ich hätte das PASSWORTGESCHÜTZT wahrscheinlich groß, fett und blinkend schreiben sollen.
Natürlich knackt niemand AES256, das ist hier gar nicht notwendig:
Alles, was den Key schützt ist die Passphrase – und die kann man sehr wohl mit begrenztem Aufwand erraten, zumal die 'Sicherheitseinstellungen' auch noch vom Alter des Accounts abzuhängen scheinen:
https://palant.info/2022/12/26/whats-in-a-pr-statement-lastpass-breach-explained/
Alter Account = langjähriger Kunde = lächerliche Sicherheit.
Zumal zumindest laut obigem Artikel mithören des Passworts auch ein denkbares Szenario wäre – immerhin haben die lange genug gebraucht um überhaupt zu merken, dass etwas faul ist.
Die Datenbank ist nicht verschlüsselt. Nur die Paßwörter sind verschlüsselt. Die URLs sind laut dem Text unverschlüsselt, das ist schon ein enormer Breach. Und die Paßwörter können jetzt auch geknackt werden bei Nutzern, die schwache Masterpaßwörter haben.
Unwahrscheinlich, da die Kennwörter nicht mit dem Masterpasswort verschlüsselt sind, sondern mit einen eigenen "gescheiten" Schlüssel. Dieser wird lokal verschlüsselt (aus dem Masterpasswort abgeleitet), weder das Masterpasswort, noch der lokale Schlüssel verlassen das Gerät des Nutzers.
"Der Coup gelang mit Hilfe von Cloud-Speicherschlüsseln, die im August 2022 von einem LastPass-Mitarbeiter gestohlen wurden."
1. Was sind "Cloud-Speicherschlüssel" und
2. warum hat man nach dem "Diebstahl" dieser keine Gegenmaßnahmen eingeleitet gehabt, um Folgen wie diese zu verhindern?
Zu 1: Hat LastPass nicht weiter erläutert – ich interpretiere "Cloud-Speicherschlüssel" als Zugriffstokens (oder Zugangsdaten) für den Cloud-Speicher.
Zu 2: Es scheint so zu sein, dass nach dem Hack vom August 2022 das komplette Abdichten der Entwicklungsumgebung nicht gelungen ist. Der oder die Angreifer konnten jedenfalls Daten (entweder bereits im August oder im November) aus diesem Bereich abgreifen – genau wüsste ich das, wenn mir die Ergebnisse der forensischen Analyse mit Zugriffsprotokollen vorläge. Dabei ist den Leuten eine Backup-Kopie der Vault-Datenbank in die Hände gefallen.
Ansonsten lassen sich diese Fragen final nur von LastPass klären. Intention des Beitrags ist es, Leute, die auf LastPass gesetzt haben, den Sicherheitsvorfall zur Kenntnis zu bringen. Die könnten jetzt reagieren, ihr Masterpasswort und alle bei LastPass gespeicherten Kennwörter für Online-Konten ändern – und sich vielleicht überlegen, von diesem Anbieter weg zu gehen.
Danke für die Info. Das liest sich so, als sei hier einfaches Phishing eines Zugangspasswortes möglicherweise Ursache des Vorfalls im August gewesen. Peinlich für einen Mitarbeiter einer Software-Bude…
Ich frage mich auch, was denn da für Gegenmaßnahmen ergriffen wurden.
Wenn ein Schlüssel gestohlen wurde, was macht man da als erstes?
Ja, das Schloß und den Schlüssel austauschen!
Wurde anscheinend nicht gemacht, wenn Monate nach dem Diebstahl der Schlüssel diese immer noch funktionieren.
Als jemand der seinen eigenen Passwort-Manager geschrieben hat, möchte ich ein paar Anmerkungen machen:
1. Der korrekte Begriff lautet "No knowledge". "Zero knowledge" ist ein anderer Fachbegriff aus der Informatik. https://de.wikipedia.org/wiki/Null-Wissen-Beweis
2. Es überrascht mich, dass LastPass nur die Credentials verschlüsselt, nicht aber die URLs. Das ist ein lächerliches Konzept, es geht niemanden etwas an, ob ich auf pornoseite.de oder bittorrent.com unterwegs bin. DSG-VO lässt grüßen. Von "No knowledge" kann hier mMn ohnehin nicht gesprochen werden.
3. Sollten die Angreifer keine Kenntnisse über die Tresorschlüssel haben, gibt es keine Probleme mit den Zugangsdaten. AES-256 kackt niemand, und jeder der etwas Ahnung von der Materie hat, weiß das auch. Solange es kein bekanntes Angriffsszenario für AES gibt, oder große Teile des Tresorschlüssels bekannt werden (oder angenommen werden können) ist das ein aussichtsloses Unterfangen. Die Angreifer benötigen mehr Energie als überhaupt auf der Erde verfügbar ist, bevor sie auch nur einen Tresor mit AES-256 knacken. Von den Kosten dafür ganz zu schweigen.
4. Das "No knowledge"-Prinzip spielt in diesem Szenario seine Stärken aus, die Angreifer tragen die Kennworttresore raus, können damit aber nichts anfangen.
5. Für die Nutzer zum Mitnehmen: Starke Masterpasswörter verwenden und ggf. Dienste einsetzen, die nicht Teile des Tresors (URLs) unverschlüsselt sichern.
@1ST1
Auch wenn Systeme sobald ein unberechtigter User zugriff hat als komprimitiert betachtet werden müssen – ist das erschreckend.
Ein möglicher Workarround wär, Usern via NTFS-Berechtgungen Schreibrechte auf das Verzeichnis zu entziehen …
Das verschiebt den Angriffspunkt auf den Administrator der im Zweifel auch einen Keylogger mitlaufen lassen könnte.
Da die Datei im Userkontext liegt sind die Berechtigungen schon entsprechend gesetzt.
Ich überlege seit gestern, wie einfach/schwer es wäre, als nicht-Privilegierter dem User ein Batchfile unterzuschieben, dass die entsprechende Änderung in die config schreibt. sed (für Windows) wäre ein geeigneter Befehl dazu.
Ich habe sie leider nicht mehr, aber es gab vor 10 Jahren mal eine Boot-CD, um Windows ohne Passwort mit Adminrechten zu starten.
Dritte Option:
Notepad.exe als SYSTEM starten
>> Da die Datei im Userkontext liegt sind die Berechtigungen schon entsprechend gesetzt.
Man kann via NTFS Schreibrechte dem User entziehen. Dann kann im Usercontext niemand solche Trigger setzen. Das hat dann aber zur Folge das keine Programmänderungen mehr vorgenommen werden können.
>> Ich überlege seit gestern
WorstCase-Zenario: dein Browser oder der Email-Client hat eine Sicherheitslücke mit der Lese/Schreibrechte ins System ermöglicht werden. Dann könnte eine Webseite/Mail das im Usercontext den Trigger setzen, und beim nächsten Aufruf der Webseite schauen der Export existiert.
Warum bauen Entwickler solch kritischen Trigger-Funktionen in einen Passwort-Safe ein, und warum sind sie ohne deutliche Warnung per default aktiviert?!
Möglicherweise hilfts schon die Triggerfunktion manuell im Programm zu deaktivieren. Alternativ o.g. NTFS Workarround.
>> Notepad.exe als SYSTEM starten
Als Admin/System kann man auch gleich einen Keylogger starten. Das kann aber im Usercontext nicht ohne das Admin-Passwort, oder eine zweite Root-Sicherheitslücke durchgeführt werden.
Wie sieht das denn mit dem Kennworthinweis aus? Auch bei Lastpass gibt es eine Möglichkeit ein Kennworthinweis anzugeben. Man kann nur hoffen das dieser auch verschlüsselt ist. Weiß da einer vielleicht mehr?
Rein logisch betrachtet: Wäre der Hinweis zum Kennwort verschlüsselt, dann müsste man das Kennwort wissen, um den Hinweis zu lesen. Das würde den Hinweis irgendwie überflüssig machen, oder?
Ja was du sagst macht schon Sinn Aber hoffentlich wird dieser Hinweis anderweitig gesichert, ansonsten könnte es einfacher werden den Tresor zu knacken, wenn dort Passwörter abgeleitet werden können.
Es steht aber außer frage alle Passwörter der Zugänge zu ändern. Sobald der Tresor wertlos ist, ist alles andere eh wurscht. Wichtig ist meines Erachtens die Reihenfolge. Mail Accounts, Banking Account, dann andere Cloud Dienste und dann Bestellseiten, Foren etc.
klar ist das Umfangreich, wenn man so 500 Zugänge hat. aber man sollte sich hier nicht allzu lange Zeit lassen. Der Identitätsdiebstahl ist kein Zuckerschlecken.
Euch allen Frohe Weihnachten und besinnliche Festtage mit der Familie 🎅🎁🙏🎄
@Bernd B: (Vom Handy wird irgendwie immer als neuer Post geantwortet)
Eine Boot-CD würde physischen Zugriff auf das Endgerät des Anwenders erfordern. Unter dieser Konstellation gibt es deutlich mehr Angiffsvektoren. Ohne vollständig verschlüsselte Festplatten hätte man dann eh schon verloren, da beliebige Manipulationen an den Daten der Festplatte möglich sind. Passwörter von Windows lassen sich leicht löschen. Der alte Trick die utilman.exe durch eine Kopie vom cmd.exe zu ersetzen funktioniert immer noch. Schon hat man vor der Anmeldung eine Shell mit den Rechten von SYSTEM und kann sich seinen eigenen Admin anlegen oder die Passwörter beliebig anpassen.
Das Handy hängt mit dem Mobile-Theme zusammen – da macht eine Schachtelung keinen Sinn. Sollte aber in der Desktop-Darstellung eingerückt sein (ist oben bei Bernd B. der Fall). Man kann am Smartphone aber die Darstellung auf Desktop umstellen (in der Webseite nach unten blättern, am Artikelende finden sich Schaltflächen zum Umstellen Desktop/Mobile).
Bernd B. behauptet, er greife nur vom Desktop aus auf Borncity zu.
Aber da es bekanntlich keine Regel ohne Ausnahme gibt versuche ich es mal in seinem Namen hier von Android (Bromite for Android, aber im Desktopmodus, der zum Lesen eh weit besser als die Mobilmodi ist).
Der physische Zugriff ist aber der Nr.-1-Angriffsvektor vertrauter Angreifer.
Ich denke, >>90% aller (Heim)Anwender-PCs laufen ohne FDE (z.B. der Nachwuchs, der gerne Internetsperren umgehen will hat Interesse an meiner Passwortdatenbank).
Auch in Verein oder Firma genügt ein einziger "rough employee", der eben den physischen Zugriff nutzt.
Und da muss man nMn ganz klar sagen: KeePass zu verwenden ist leichtsinnig/gefährlich, weil der gesamte Schutz rel. leicht auszuhebeln ist.
Betrachten wir es versicherungsmathematisch haben wir ein überschaubares (aber realistisches) Risiko, einen maximalen Schaden zu erleiden.
Dann sollte man wirklich eher zu KeePassDX (o.Ä.) greifen, die diesen Angriffsvektor nicht bieten.
https://palant.info/2022/12/26/whats-in-a-pr-statement-lastpass-breach-explained/
https://cybernews.com/best-password-managers/keeper-vs-lastpass/