Frage:
Sind im Speicher gespeicherte Passwörter sicher?
Antoine Pinsard
2013-01-15 01:30:01 UTC
view on stackexchange narkive permalink

Ich habe gerade festgestellt, dass in jeder Sprache, wenn Sie ein Kennwort in einer Variablen speichern, es als einfacher Text im Speicher gespeichert wird.

Ich denke, das Betriebssystem erledigt seine Aufgabe und verbietet den Zugriff auf Prozesse einander zugewiesenen Speicher. Aber ich denke auch, dass dies irgendwie umgangen werden kann. Ich frage mich also, ob es wirklich sicher ist und ob es eine sicherere Möglichkeit gibt, Kennwörter zu speichern, um sicherzustellen, dass fremde Prozesse nicht darauf zugreifen können.

Ich habe das Betriebssystem oder die Sprache nicht angegeben, weil meine Frage lautet ganz allgemein. Dies ist eher eine Frage der Computerkenntnisse als eine Frage zu einem bestimmten Zweck.

Dies ist eigentlich die Schwäche der Verschlüsselung. Jeder nicht verschlüsselte Wert, der darauf wartet, verschlüsselt zu werden, wird im Klartext gespeichert.
Einige nützliche Hintergrundinformationen finden Sie unter [diese Frage zu Programmierern] (http://programmers.stackexchange.com/questions/181577).
Ich erinnere mich an einen Artikel über Slashdot über eine Forensik-Technik, die die DRAM-Fade-Latenz ausnutzt: Verschieben Sie RAM-Chips schnell genug von einem laufenden Computer auf einen anderen (die Anzahl lag innerhalb der menschlichen Fähigkeiten), und Sie können den gesamten Inhalt problemlos sichern.
Während andere Antworten die Nuancen "Sicher wie ..." gut abdecken, verfügen Ihre Plattformen / Bibliotheken möglicherweise über einen SecureString oder ähnliches, um das Risiko zu minimieren. Ein solches Konstrukt kann seinen eigenen Speicher überschreiben, sobald Sie angeben, dass Sie damit fertig sind, und Nuancen von Kopien von sich selbst verwalten, die durch die Speicherbereinigung usw. eingeführt wurden.
Eine gute Sicherheitsvorkehrung besteht darin, die Variable, die das Kennwort enthält, so schnell wie möglich zu überschreiben (einfacher in C / C ++ als in Java) und stattdessen mit einem abgeleiteten Schlüssel zu arbeiten (z. B. mit PBKDF2 generiert).
@OmarKohl Das habe ich für mein Skript getan. Ich frage zuerst nach dem Passwort, um den Schlüsselring zu entsperren. Dann verschlüssele ich ein zufälliges Sitzungskennwort, das ich an den Remotecomputer sende. Und sobald ich sicher bin, dass es das neue Passwort erhalten hat, überschreibe ich das Passwort des Schlüsselbunds. Wenn das Problem dadurch nicht wirklich gelöst wird, wird die Zeit begrenzt, in der das tatsächlich persistente Kennwort im Speicher gespeichert wird.
Verwandte (wie von jemandem auf Hackernews hervorgehoben): http://en.wikipedia.org/wiki/TRESOR
Gibt HeartBleed dem Angreifer nicht Speicherbereiche?
@jkd Ja, aber nur Speicher von den Prozessen, die mit der anfälligen Version von OpenSSL verknüpft sind.Leider würde dies oft Passwörter beinhalten, aber nur für diesen bestimmten Prozess.
Dreizehn antworten:
#1
+475
Thomas Pornin
2013-01-15 03:10:06 UTC
view on stackexchange narkive permalink

Sie berühren einen wunden Punkt ...

In der Vergangenheit waren Computer Mainframes , in denen viele unterschiedliche Benutzer Sitzungen und Prozesse auf dem Computer starteten gleiche physische Maschine. Unix-ähnliche Systeme (z. B. Linux), aber auch VMS und seine Verwandten (und diese Familie umfasst alle Windows der NT-Reihe, daher 2000, XP, Vista, 7, 8 ...) wurden strukturiert, um das zu unterstützen Mainframe-Modell.

Somit bietet die Hardware Berechtigungsstufen . Ein zentrales Element des Betriebssystems ist der Kernel , der auf der höchsten Berechtigungsstufe ausgeführt wird (ja, ich weiß, dass es Feinheiten in Bezug auf die Virtualisierung gibt) und die Berechtigungsstufen verwaltet. Anwendungen werden auf einer niedrigeren Ebene ausgeführt und vom Kernel gewaltsam daran gehindert, den Speicher des anderen zu lesen oder zu schreiben. Anwendungen erhalten RAM von Seiten (normalerweise 4 oder 8 kB) vom Kernel. Eine Anwendung, die versucht, auf eine Seite zuzugreifen, die zu einer anderen Anwendung gehört, wird vom Kernel blockiert und schwer bestraft ("Segmentierungsfehler", "allgemeiner Schutzfehler" ...).

Wenn eine Anwendung nicht mehr benötigt wird Bei einer Seite (insbesondere beim Beenden der Anwendung) übernimmt der Kernel die Kontrolle über die Seite und gibt sie möglicherweise an einen anderen Prozess weiter. Moderne Betriebssysteme "leeren" Seiten, bevor sie zurückgegeben werden, wobei "Ausblenden" "Füllen mit Nullen" bedeutet. Dies verhindert, dass Daten von einem Prozess zu einem anderen verloren gehen. Beachten Sie, dass Windows 95/98 / Millenium keine leeren Seiten hat und Lecks auftreten können. Diese Betriebssysteme waren jedoch für einen einzelnen Benutzer pro Computer gedacht.

Natürlich gibt es Möglichkeiten, dem Zorn des Kernels zu entkommen: Anwendungen, die "genug Privilegien" haben (nicht die gleichen Privilegien wie oben), stehen einige Türen zur Verfügung. Auf einem Linux-System ist dies ptrace (). Der Kernel ermöglicht es einem Prozess, den Speicher des anderen über ptrace () zu lesen und zu schreiben, vorausgesetzt, beide Prozesse werden unter derselben Benutzer-ID ausgeführt oder der Prozess, der ptrace () ausführt, ist ein "Root" -Prozess. Ähnliche Funktionen gibt es in Windows.

Unter dem Strich sind Kennwörter im RAM nicht sicherer als das, was das Betriebssystem zulässt. Per Definition durch Speichern einiger vertraulicher Daten im Speicher Bei einem Prozess vertrauen Sie dem Betriebssystem, dass es nicht an Dritte weitergegeben wird. Das Betriebssystem ist Ihr Freund , denn wenn das Betriebssystem ein Feind ist, haben Sie völlig verloren.


Jetzt kommt der lustige Teil. Da das Betriebssystem eine Prozesstrennung erzwingt, haben viele Menschen versucht, Wege zu finden, um diese Abwehrkräfte zu durchdringen. Und sie fanden ein paar interessante Dinge ...

  • Der "RAM", den die Anwendungen sehen, ist nicht unbedingt wahrer "Speicher". Der Kernel ist ein Meister der Illusionen und gibt Seiten, die nicht unbedingt existieren. Die Illusion wird aufrechterhalten, indem RAM-Inhalte gegen einen dedizierten Speicherplatz auf der Festplatte ausgetauscht werden, auf dem in größeren Mengen freier Speicherplatz vorhanden ist. Dies wird als virtueller Speicher bezeichnet. Anwendungen müssen sich dessen nicht bewusst sein, da der Kernel die Seiten bei Bedarf zurückbringt (aber die Festplatte ist natürlich viel langsamer als der Arbeitsspeicher). Eine unglückliche Folge ist, dass einige Daten, die angeblich im RAM gespeichert sind, auf ein physisches Medium gelangen, auf dem sie bis zum Überschreiben verbleiben. Insbesondere bleibt es dort, wenn die Stromversorgung unterbrochen wird. Dies ermöglicht Angriffe, bei denen der Bösewicht die Maschine greift und damit davonläuft, um die Daten später zu überprüfen. Oder es kann zu Undichtigkeiten kommen, wenn eine Maschine außer Betrieb genommen und bei eBay verkauft wird und der Systemadministrator vergessen hat, den Festplatteninhalt zu löschen.

    Linux bietet ein System namens mlock (), das verhindert, dass der Kernel bestimmte Seiten an den Swap Space sendet. Da das Sperren von Seiten im RAM die verfügbaren RAM-Ressourcen für andere Prozesse erschöpfen kann, benötigen Sie einige Berechtigungen (erneut root), um diese Funktion zu verwenden.

    Ein erschwerender Umstand ist, dass es nicht unbedingt einfach ist, den Überblick darüber zu behalten, wo Sie sich befinden Passwort ist wirklich im RAM. Als Programmierer greifen Sie über die von der Programmiersprache bereitgestellte Abstraktion auf RAM zu. Insbesondere Programmiersprachen, die Garbage Collection verwenden, können Objekte im RAM transparent kopieren (da dies für viele GC-Algorithmen wirklich hilfreich ist). Die meisten Programmiersprachen sind daher betroffen (z. B. Java, C # /. NET, Javascript, PHP, ... die Liste ist fast endlos).

  • Ruhezustand bringt die gleichen Themen mit aller Macht zurück. Der Ruhezustand muss von Natur aus den gesamten RAM auf die Festplatte schreiben - dies kann Seiten enthalten, die gesperrt wurden, und sogar den Inhalt der CPU-Register. Um Lecks im Ruhezustand zu vermeiden, müssen Sie drastische Maßnahmen wie die Verschlüsselung der gesamten Festplatte ergreifen. Dies bedeutet natürlich, dass Sie das Entsperrkennwort eingeben, wenn Sie den Computer aktivieren.

  • Das Mainframe-Modell geht davon aus, dass es mehrere Prozesse ausführen kann, die einander feindlich gegenüberstehen und dennoch vollkommenen Frieden und Isolation bewahren. Moderne Hardware macht das sehr schwierig. Wenn zwei Prozesse auf derselben CPU ausgeführt werden, teilen sie sich einige Ressourcen, einschließlich des Cache-Speichers. Speicherzugriffe sind im Cache viel schneller als anderswo, aber die Cache-Größe ist sehr begrenzt. Dies wurde ausgenutzt, um kryptografische Schlüssel wiederherzustellen, die von einem Prozess von einem anderen verwendet werden. Es wurden Varianten entwickelt, die andere cacheähnliche Ressourcen verwenden, z. Verzweigungsvorhersage in einer CPU. Während sich die Forschung zu diesem Thema auf kryptografische Schlüssel konzentriert, die hochwertige Geheimnisse sind, könnte sie wirklich auf alle Daten zutreffen.

    In ähnlicher Weise können Grafikkarten direkten Speicherzugriff ausführen. Ob DMA nicht zum Lesen oder Schreiben von Speicher aus anderen Prozessen missbraucht werden kann, hängt davon ab, wie gut undokumentierte Hardware, Closed-Source-Treiber und Kernel zusammenarbeiten, um die entsprechenden Zugriffskontrollen durchzusetzen. Ich würde mein letztes Shirt nicht darauf wetten ...


Fazit: Ja, wenn Sie ein Passwort im RAM speichern, Sie vertrauen dem Betriebssystem, um dies vertraulich zu behandeln. Ja, die Aufgabe ist schwierig, auf modernen Systemen sogar nahezu unmöglich. Wenn einige Daten streng vertraulich sind, sollten Sie das Mainframe-Modell wirklich nicht verwenden und potenziell feindlichen Entitäten nicht erlauben, ihren Code auf Ihrem Computer auszuführen.

(Dies bedeutet übrigens, dass virtuelle Maschinen gehostet werden und Cloud Computing kann letztendlich nicht sicher sein. Wenn Sie die Sicherheit ernst nehmen, verwenden Sie dedizierte Hardware.)

"Virtuelle Maschinen und Cloud Computing können letztendlich nicht sicher sein". Ich war Cloud Computing gegenüber immer skeptisch.
Es gibt noch einen Punkt zu machen. Irgendwann, irgendwann, für einige Zeit, muss sich der Klartext einfach im "RAM" befinden. Die gesamte Übung wird ziemlich sinnlos, wenn der Klartext niemals irgendjemandem ausgesetzt ist. Das Ergebnis ist, dass RAM, das angeblich nie bestehen bleibt und als "geschützt" gekennzeichnet werden kann, ungefähr so ​​sicher ist, wie Sie es innerhalb der Grenzen eines Computersystems erreichen. Ihr Standpunkt ist jedoch, dass Speicher (und Betriebssystemschutz derselben) nur als sicher angesehen werden, weil die Alternative darin besteht, überhaupt keine Computer zu verwenden.
Um die Offenlegung sensibler Daten als Klartext zu minimieren, bieten verschiedene Sprachen Wrapper an, die die Verwendung von Betriebssystemfunktionen vereinfachen, um ein Auslagern zu verhindern. Siehe z. [.Net SecureString] (http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx). Dies mildert das Problem jedoch nur und löst es nicht.
Ein Hinweis zum Ruhezustand - wenn die Datei selbst verschlüsselt ist (z. B. auf dm-crypt tauschen), wird auch das dort gespeicherte Kennwort verschlüsselt - und DMA - Firewire ermöglicht DMA von Geräten häufig den Zugriff auf den RAM (IOMMU würde dagegen schützen).
Ich bin mir ziemlich sicher, dass ich das alles bereits wusste, aber Ihre Erinnerungsfähigkeit und Ihre Fähigkeit zu erklären beeindrucken immer wieder, nochmals vielen Dank, Thomas.
Wenn Sie Ihren Computer verlieren und dieser noch eingeschaltet ist, ist es außerdem relativ einfach, RAM-Inhalte wiederherzustellen, indem Sie Speicherchips einfrieren und den Inhalt lesen: http://www.zdnet.com/blog/security/cryogenically-frozen- RAM-Bypass-All-Disk-Verschlüsselungsmethoden / 900
OpenGL muss den Inhalt des Framebuffers beim Erstellen von Puffern nicht löschen. Daher kann ein Schadprogramm möglicherweise abrufen, was ein anderes Programm gezeichnet hat, einschließlich der in nicht sichtbaren Puffern: http://stackoverflow.com/q / 4112421/309412
Eine gute Zusammenfassung. Der einzige zusätzliche Punkt, den ich erwähnen möchte, ist, dass das Betriebssystem zwar versucht, angemessenen Schutz und Dienste zur Unterstützung sicherer Vorgänge bereitzustellen, andere jedoch aktiv versuchen, Lücken zu finden. Hinzu kommt das unterschiedliche Verständnis, die Sorgfalt und die Fähigkeiten der Programmierer, und wir können daraus schließen, dass es keine Garantien gibt. Wie üblich müssen wir anhand des Risikos, der Wahrscheinlichkeit und der nachfolgenden Auswirkungen bewerten und dann die besten / notwendigen Maßnahmen festlegen. Dieser Artikel bietet gute Grundlagen für das Verständnis des Risikos. Die Wahrscheinlichkeit und die Auswirkungen hängen von der individuellen Situation ab.
Dies ist eine interessante Antwort. Was ich hinzufügen möchte, ist, dass die meiste Sicherheit eine Täuschung ist - wenn jemand speziell auf Sie abzielt, werden Sie normalerweise geschraubt und oft ohne Verschlüsselungen zu knacken oder besonders klug zu sein -, aber gute, altmodische, schmutzige Tricks wie das Stehlen eines Passworts, indem Sie ihm beim Eingeben zuschauen.
Ich möchte darauf hinweisen, dass `mlock` zumindest unter Linux kein Root-Privileg benötigt. Es gibt jedoch eine strikte Beschränkung, wie viel Speicher Sie sperren können, wenn Sie nicht root sind.
Welches andere Modell als das des Mainframes gibt es?
Betreff: "Das Betriebssystem ist dein Freund, denn wenn das Betriebssystem ein Feind ist, hast du völlig verloren." Matthew Garretts LibrePlanet 2013-Vortrag] (http://media.libreplanet.org/u/libby/m/embracing-secure-boot-and-rejecting-restricted-boot-matthew-garrett/) ab ca. 7:15 Uhr.
Sie haben fast alle Aspekte abgedeckt, aber Sie haben nicht erwähnt, dass Register ständig auf dem Stapel gespeichert werden. Wenn ein Kontext- oder Threadwechsel stattfindet, werden alle Register erneut in den Speicher verschoben. Ergo ist es auch nicht sicher, Geheimnisse in Registern zu behalten.
@Johan Das ist richtig, aber die gespeicherten Register werden nicht ausgetauscht.
#2
+54
user2213
2013-01-15 02:29:04 UTC
view on stackexchange narkive permalink

Ich denke, das Betriebssystem erledigt seine Arbeit und vermeidet Prozesse, um auf den zugewiesenen Speicher anderer zuzugreifen. Aber ich denke das ist irgendwie machbar.

Ja, es ist möglich, auf den Speicher eines anderen Prozesses zuzugreifen. Unter Windows bedeutet dies, dass Sie SE_DEBUG_PRIVILEGE haben und ReadProcessMemory () verwenden, um die gewünschten Informationen zu extrahieren.

Sie können Machen Sie dasselbe mit einem Windows-Treiber, obwohl es aufgrund einiger Komplikationen mit dem aktuell in der unteren Hälfte ausgelagerten Speicher etwas schwieriger ist, das Problem zu beheben.

In beiden Fällen müssen Sie Zugriff haben einem Administratorkonto oder einem Prozess, der falsch SE_DEBUG_PRIVILEGE zugewiesen wurde, oder einem Prozess mit diesem Privileg, der dazu gebracht werden kann, das zu tun, was Sie benötigen kann eskalieren, um diese Berechtigungen zu erhalten. Realistischer stellen wir sicher, dass nur vertrauenswürdige Benutzer über diese Berechtigungen verfügen können. Wenn Sie Zugriff auf ein Administratorkonto haben, können Sie ein Kennwort ganz einfach direkt aus dem Prozessspeicher eines anderen Kontos lesen.

Unter Linux können Sie dasselbe mit ptrace ( ) und die Option PTRACE_PEEK_DATA .

Sie fragen sich möglicherweise, warum diese Funktionen überhaupt vorhanden sind? Tatsächlich sind sie unglaublich praktisch zum Debuggen von Prozessen. Möglicherweise möchte ein Administrator dies tun. Im Gegensatz dazu sollten normale Benutzer nicht voneinander isoliert sein müssen und sollten voneinander isoliert sein.

Aus diesem Grund wird seit einiger Zeit davon ausgegangen, dass es im Allgemeinen keine gute Idee ist, alles unter dem Administratorkonto auszuführen.

Vielen Dank für diese kurze Erklärung für Windows und GNU / Linux (ich denke, diese Werte gelten auch für andere Unix-Systeme).
@AntoinePinsard ja, wenn sie "ptrace" implementieren, ist das sehr wahrscheinlich!
Bei Win können Sie den Speicher anderer Prozesse lesen, die auf demselben Benutzer ausgeführt werden, wenn Sie keine besonderen Berechtigungen haben.
@Code true. Ich bin mir nicht sicher, ob ein Betriebssystem Sie gegen sich selbst verteidigen kann!
@Sadaluk Das eigentliche Problem tritt auf, wenn Code, der unter Ihrem Konto ausgeführt wird, * nicht * von Ihnen ausgeführt wird. Denken Sie an Skripte, die in native Bibliotheken rufen, Pufferüberlauf-Exploits, ...
#3
+41
bob_dvb
2013-03-18 15:15:39 UTC
view on stackexchange narkive permalink

Ich arbeite in der Unterhaltungselektronik und die Sicherheit ist hier etwas anders als in der Serverumgebung. Hier müssen wir davon ausgehen, dass sich das Produkt in einer feindlichen Umgebung befindet. Aus Gründen der Abonnentenverwaltung werden die Schlüssel sicher aufbewahrt. Die erste Verteidigungslinie besteht darin, dass der SoC versteckte Register hat, auf die selbst das Betriebssystem nicht zugreifen kann. Sie werden zur Herstellungszeit eingebrannt und Chipsicherungen werden durchgebrannt, die den Zugriff verhindern. Außerdem sehen wir selbst keine Schlüssel, da dies in der Produktion unsicher wäre. Stattdessen werden sie mit einem Stapelschlüssel vorverpackt, den wir nicht kennen. Das wissen nur der Chiphersteller und die Person, die den Schlüssel erstellt hat (der Master) Schlüssel kann nach Verwendung im Chip zerstört werden). Sobald der Chip mit Geheimnissen geladen ist, kann er gesperrt und niemals * entsperrt werden.

Wenn Sie nicht auf die Schlüssel zugreifen können, wie entschlüsseln Sie dann etwas? Mit einem kryptografischen Co-Prozessor auf dem SoC können Sie Schlüsselpositionen laden, ohne den darin enthaltenen Wert zu kennen. Sie sehen auch nie den Mikrocode des Kryptoprozessors, weil Sie dann selbst zum Zeitpunkt der Herstellung nichts injizieren können.

Wenn Sie Schlüssel oder Zertifikate haben, die nicht in die großzügigen Chipregister passen, müssen Sie diese im RAM und / oder NVM speichern, jedoch aufgrund des Kryptoprozessors Sie müssen diese Werte nicht verfügbar machen. Der RAM oder NVM selbst kann vom Chip mit einem Schlüssel verschlüsselt werden, der nur ihm selbst bekannt ist.

Im Gegensatz zu Computern haben sichere eingebettete Systeme auch eine gewisse physische Sicherheit. RAM-Verbindungsspuren dürfen sich nicht auf der Oberfläche der Leiterplatte befinden ("vergrabene Durchkontaktierungen"). Dies liegt daran, dass Sie, wenn sich Elemente im RAM befinden, den Zugriff beschränken müssen, den Zugriff beschränken müssen. Es ist möglich, die CPU zu verlangsamen oder einzufrieren und dann den RAM zu prüfen.

Schließlich war es für Smartcards möglich, die Transaktionen zwischen dem SoC und der Karte abzufangen. Dies wird als "Kartenfreigabe" bezeichnet. Die Lösung hierfür besteht darin, die Transaktionen zwischen der Karte und dem SoC zu verschlüsseln und aneinander zu binden, damit sie nicht ausgetauscht oder freigegeben werden können.

Ich kenne diesen DRM / Inhaltssicherheit ist bei einigen Leuten in den Interwebs unbeliebt, aber ich dachte, ich würde einige hochrangige Konzepte aus einer Branche mit bestimmten Sicherheitsanforderungen teilen.

* Theoretisch.

+1. Wissen Sie, ob bei modernen Laptops / Desktop-Computern Anstrengungen unternommen wurden, um so etwas zu tun? Ich wette, zumindest einige Branchen (Militär, Regierung) wären daran interessiert, Zugang zu diesem Sicherheitsniveau zu erhalten. Oder müsste dies ein komplett maßgeschneidertes elektronisches Gerät sein?
Theoretisch können die neueren Änderungen am EFI-Boot, die von Microsoft verwendet werden, von Linux verwendet werden, um die Vertrauenskette aufzubauen, und wie @mricon an anderer Stelle sagt, hilft SElinux. Ich habe auch nach OKL4 für hohe Sicherheit gesucht, da Sie sichere Komponenten außerhalb von Linux auf ein anderes Betriebssystem übertragen können.
@mjuarez, möglicherweise von Interesse: [TPM-Chips entkapseln] (https://duckduckgo.com/html?q=decapping%20TPM%20chips).
#4
+26
mricon
2013-01-15 02:44:21 UTC
view on stackexchange narkive permalink

Auf der Linux-Plattform wird einige Arbeit geleistet, um den Zugriff auf den Speicher eines laufenden Prozesses selbst durch einen Superuser zu verbieten. Mit SELinux können Sie dies ab Fedora 17 tun: SELinux Deny Ptrace.

#5
+17
Giffyguy
2013-01-15 01:33:30 UTC
view on stackexchange narkive permalink

Welche Sprache / Plattform verwenden Sie?

Wenn es sich um .NET handelt, überprüfen Sie das Steuerelement PasswordBox und die Klasse SecureString.

Die SecureString-Klasse bietet eine Möglichkeit, das Kennwort im Speicher zu speichern, ohne es für jedermann zugänglich zu machen - selbst für Hacker, die einen Blick in den Speicher Ihrer Anwendung werfen.

Das PasswordBox-Steuerelement ist ein Textfeld, das enthält den SecureString, sodass Sie das Kennwort von Ende zu Ende sicher aufbewahren können.

Bitte poste nicht nur Links als deine Antwort. Versuche dein Bestes, um deine Antwort zu erarbeiten und erst dann Links als Quelle / Credits zu posten. Wenn die Links weg sind, ist auch Ihre Antwort.
@Lorenzo +1 Ich stimme zu. Ich habe die Angewohnheit, meine Antworten in einer Reihe von Änderungen zu veröffentlichen, anstatt alles auf einmal herauszuholen. Obwohl ich mir keine Sorgen darüber mache, dass MSDN-Links bald aussterben. :) :)
@Giffyguy - Es ist aus mehreren Gründen sinnvoll, einen "SecureString" in .NET zu verwenden, aber es verhindert nicht, dass * hoch entwickelte * "Hacker, die einen Blick in den Anwendungsspeicher werfen", auf das Kennwort zugreifen. es fügt jedoch Verschleierung hinzu. SecureStrings werden im Speicher verschlüsselt. Der zu entschlüsselnde Schlüssel befindet sich jedoch notwendigerweise auch im Speicher. Trotzdem ist dies besser als ein Klartext-PW im Speicher, so dass es niemals in einem Coredump / Swapfile / etc.
@dr jimbob +1 Richtig, obwohl das Hacken von .NET normalerweise ziemlich zwecklos ist. Jedes Mal, wenn eine Sicherheitsverletzung vorliegt, veröffentlicht MS in der Regel innerhalb weniger Wochen einen Patch, um ihn zu blockieren.
Was SecureString gewinnt, ist ziemlich begrenzt. Es ist gegen Crashdumps und Swapfiles. Es schützt nicht vor schädlichen Anwendungen, die auf Ihren Prozessspeicher zugreifen können. Diese Anwendungen, die Ihr Kennwort erhalten können, stellen keine Sicherheitsverletzung dar und werden von MS nicht gepatcht.
@CodesInChaos - Genau. SecureString verwendet die [Datenschutz-API] (http://en.wikipedia.org/wiki/Data_Protection_API). Das wurde 2010 rückentwickelt (nicht sicher, ob sich die MS seitdem geändert hat). Es ist nicht trivial zu brechen (z. B. wenn Sie vollen Zugriff auf ein System hatten; es ist viel einfacher, nur das Passwort zu erfassen, bevor es mit einem Keylogger auf den SecureString trifft). Da die laufende Anwendung sie jedoch entschlüsseln muss; Eine ausgefeilte Analyse (mit vollem Zugriff auf Festplatte / Speicher) muss in der Lage sein, diese wiederherzustellen.
#6
+14
petertonoli
2013-03-18 16:08:13 UTC
view on stackexchange narkive permalink

Nein, im Klartext im RAM gespeicherte Passwörter sollten nicht als sicher angesehen werden. Auf den x86- und x86-64-Architekturen mit Schnittstellen wie FireWire, ExpressCard und Thunderbolt, auf die direkt zugegriffen wird, können diese Schnittstellen im Allgemeinen verwendet werden, um den Speicherschutz des Betriebssystems zu umgehen und somit Klartextkennwörter aus dem Speicher abzurufen.

Die Verwendung von FireWire zum Abrufen von Klartextkennwörtern ist nicht nur ein theoretischer Angriff. Es wird jetzt Software verkauft, um Klartextkennwörter für BitLocker-, PGP- und TrueCrypt-verschlüsselte Festplatten zu erhalten. ElcomSoft entschlüsselt BitLocker-, PGP- und TrueCrypt-Container

Es gibt einen separaten Thread zu security.stackexchange, der darauf eingeht So verringern Sie DMA-Basisangriffe Deaktivieren Sie Firewire / Thunderbolt sicher und korrigieren Sie die DMA-Exposition unter Linux. Außerdem hat Microsoft einen Knowledge Base-Artikel zur Abschwächung von Angriffen über Firewire und Thunderbolt auf BitLocker Blockieren des SBP-2-Treibers und der Thunderbolt-Controller, um 1394 DMA- und Thunderbolt DMA-Bedrohungen für BitLocker zu reduzieren

Mehr Details zu diesem Angriff finden Sie auf Wikipedia DMA-Angriff.

#7
+7
Dan Is Fiddling By Firelight
2013-01-15 04:09:51 UTC
view on stackexchange narkive permalink

Zusätzlich zu allen Software-Angriffen, bei denen Betriebssystem-Schwachstellen ausgenutzt werden, kann ein Angreifer, wenn er physischen Zugriff auf Ihren Computer hat, möglicherweise Ihre Schlüssel direkt aus Ihrem Speicher lesen.

Wie kann sich Kälte auswirken? Boot-Angriffe werden minimiert?

"Wenn ein Angreifer physischen Zugriff auf Ihren Computer hat", werden im Allgemeinen so gut wie alle Wetten als deaktiviert angesehen, und die Fähigkeit des Angreifers, ein Kennwort aus einer Variablen im Speicher zu lesen, ist normalerweise das geringste Ihrer Probleme.
Ein möglicher Schutz gegen Kaltstartangriffe ist die Kryptografie, die den Inhalt des RAM verschlüsselt und nur die CPU-Register als "vertrauenswürdige" Speicherorte zum Speichern der Verschlüsselungsschlüssel verwendet. Überprüfen Sie z. .
#8
+7
Kaz
2013-01-15 04:59:11 UTC
view on stackexchange narkive permalink

Sie werfen ein gültiges Problem auf, das in sicherheitsrelevanter Software häufig behoben wird. Wenn sensible Objekte wie Schlüssel nicht mehr benötigt werden, geben einige Programme den Speicher nicht einfach an die Speicherverwaltungsbibliothek oder das Betriebssystem zurück, sondern löschen zuerst die sensiblen Bits durch Überschreiben.

Natürlich einige Programme müssen die Tasten dauerhaft halten. Zum Beispiel ssh-agent . Diese Programme sind also anfällig. Wenn Sie ein einfacher Benutzer auf einem Mehrbenutzercomputer sind, ist der dynamische Speicher Ihres ssh-agent für jeden anfällig, der über Root-Rechte verfügt und einen beliebigen Teil des Arbeitsspeichers des Computers sehen kann. P. >

Und selbst Programme, die kurzzeitig Schlüssel verwenden, weisen immer noch ein Fenster der Verwundbarkeit auf. Eine Mikrosekunde kann eine Ewigkeit in der CPU-Zeit sein. Ein böswilliger Superuser kann das Programm bei einer Anweisung sogar auf unbestimmte Zeit anhalten, während dieses Programm vertrauliche Daten in Klartextform irgendwo im Speicher hat.

Führen Sie daher als Faustregel keine sicherheitsrelevanten Daten aus Computer auf dem Computer, wenn auf diesem Computer Benutzer oder Software vorhanden sind, denen Sie nicht vertrauen, und ein Betriebssystem, dem Sie nicht vertrauen, um zu verhindern, dass diese Benutzer oder Software ihre Berechtigungen so erweitern, dass sie auf Ihre Schlüssel oder Klartextdaten zugreifen können.

Wenn Sie einen sicheren Client verwenden, vertrauen Sie diesem Programm und der gesamten Plattform, auf der es ausgeführt wird, bis hin zur Hardware und allen Maschinenanweisungen in jedem Programm, das vorinstalliert wurde oder das Sie anschließend installiert haben.

(Das sogenannte "Trusted Computing" behebt dies nicht; es ändert nur, wer die Bösewichte sind.)

+1 Das sogenannte "Trusted Computing" behebt dies nicht; es ändert nur, wer die Bösewichte sind
Wie wird die gesamte softwarebasierte DRM implementiert, da dies zutrifft?(Playready <3.0, Widevine, Primetime usw.)
#9
+5
Vivek Sethi
2013-01-17 20:56:09 UTC
view on stackexchange narkive permalink

Selbst wenn die Schlüssel verschlüsselt sind, kann ein Cod-Boot-Angriff Ihr Passwort abrufen: Überprüfen Sie dieses Video des laufenden Kaltstart-Angriffs. http://www.youtube.com/watch?v=JDaicPIgn9U

#10
+2
cxx6xxc
2013-01-18 17:06:29 UTC
view on stackexchange narkive permalink

Es besteht ein gewisses Maß an Vertrauen in die Sicherheit des Betriebssystems und der ausgeführten Anwendungen, es sei denn, Sie haben natürlich die Zeit, den gesamten Quellcode zu lesen und sicherzustellen, dass keine Exploits vorhanden sind. Wenn Sie diese Zeit hätten, wäre kein Vertrauen notwendig, würden Sie wissen. Das ist aber nicht wahrscheinlich. Wenn alles möglich ist, ist es am besten, proprietäre Projekte auf einem Computer auszuführen und alles, was vertrauenswürdig ist, auf einem anderen Computer laufen zu lassen. Die physische Trennung macht den Trick ziemlich gut im Vergleich zu glaubensbasierten Lösungen.

Du hast absolut recht. Das ist auch der Grund, warum ich (oder zumindest versuche) nur freie Software auf meinem Computer laufen lasse.
Können Sie erläutern, warum zwischen dem Betriebssystem und einer Anwendung ein gewisses Maß an Vertrauen bestehen muss? Ich dachte, dass es mit ausreichendem Sandboxing (Root-Jail, eingeschränkte Berechtigungen usw.) theoretisch möglich sein sollte, einen Virus sicher auszuführen. Ich schlage nicht vor, dass es praktisch oder 100% sicher ist, aber es sollte möglich sein, eine nicht vertrauenswürdige Anwendung vollständig zu sandboxen.
@Luc sicher, aber hier geht es überhaupt nicht um Sandboxing. Sie führen Ihre täglichen Aufgaben nicht in einer Sandbox aus, oder?
@Kaii Wenn ich einen wichtigen Job hätte, könnte dies eine Option sein.
#11
+2
Nakedible
2013-03-18 12:59:13 UTC
view on stackexchange narkive permalink

Eine etwas relevante Studie muss durchgeführt werden, um sicherzustellen, dass selbst der Superuser nicht auf ein Geheimnis zugreifen kann, das im Speicher eines anderen Prozesses gespeichert ist. Ich habe das Unterfangen nie wirklich beendet, es ist also nur ein Ausgangspunkt. Dies verhindert physische Angriffe wie Kaltstartangriffe nicht.

Geheimnisse vor Root unter Linux schützen

#12
+1
gimix
2013-03-15 13:29:38 UTC
view on stackexchange narkive permalink

Dies löst Ihr Problem nicht, obwohl ein Trick, mit dem Sie die Zeit minimieren können, in der ein Passwort oder ein anderes Geheimnis im Speicher gespeichert wird, darin besteht, es anschließend auf Null zu setzen.

Verwenden Sie keine garantierte Methode Sie schreiben in denselben Speicher, anstatt ein neues Objekt mit einem anderen Wert zuzuweisen. In Java würden Sie beispielsweise ein Byte [] anstelle eines String verwenden, um ein Geheimnis zu bewahren.

Ich las das und dachte etwas Ähnliches. Kann das Kennwort während dieser Zeit nicht verschlüsselt werden, wenn Sie es im RAM speichern müssen? Ich weiß, dass es irgendwann im Klartext existieren muss, aber das kann minimiert werden.
#13
  0
Charles Munger
2013-03-18 14:26:37 UTC
view on stackexchange narkive permalink

Da dies für eine Reihe von Betriebssystemen mit unterschiedlichen Schutzstufen gelten kann, sollten Sie Folgendes beachten:

  1. Unabhängig davon können Sie nicht verhindern, dass ein Kennwort vorhanden ist irgendwann in Erinnerung. Wenn jemand Live-Zugriff auf den Speicher Ihrer Anwendung hat, können Sie ihn nicht davon abhalten, ihn zu sehen.

  2. Kennwörter sind im Allgemeinen wertvoller als nur das, was sie schützen - Benutzer verwenden Kennwörter wieder und Durch das Akzeptieren der Kennwortanmeldung übernehmen Sie eine gewisse Verantwortung für die Geheimhaltung des Kennworts, auch wenn die von ihm geschützten Daten kompromittiert sind. Sie können den Schaden eines Angriffs auf den kalten Speicher (flüssiger Stickstoff oder Ruhezustand) etwas abmildern, indem Sie das Kennwort Ihres Benutzers mit einer langsamen Hash-Funktion (PBKDF, scrypt, bcrypt) haschen und den Hash zur Authentifizierung verwenden.

  3. Das Löschen des Benutzerpassworts aus dem Speicher ist eine gute Vorgehensweise. Es gibt viele Fallstricke, wenn Sie dies richtig machen. Stellen Sie daher sicher, dass Sie eine geeignete Bibliothek verwenden: Windows Linux-Beispiel

  4. ol>


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...