[10.7 Lion] Sicherheit :: Festplattenverschlüsselung (FileVault) Sicherheitsproblematik

[MacAlzenau]

Zu meiner Frage: Wo ist das Problem, wenn man Non-ASCII-Zeichen verwendet?

Gib mal "RäppmßlÜög4" auf einem US-Keyboard ein. Oder "0_~\ß°55€@" über eine VNC-Verbindung. Dann hast du's raus.

Nun, warum sollte ich eine US-Tastatur verwenden oder eine VNC-Verbindung?
Mich interessiert ehrlich gesagt nur, was die Verwendung auf meinem eigenen Rechner betrifft.
Aber en passant interessiert mich doch, wie man ein ASCII-Passwort dann auf einer chinesischen oder sonstigen nichtlateinischen Tastatur eingibt. Haben die das amerikanische Layout zusätzlich aufgedruckt?

 

[smoe]

Hast du schon mal irgendwas programmiert? Klingt nicht so.

Doch, genau deshalb kann ich mir nicht vorstellen wie du darauf kommst? Es gibt so viele Ansätze wie man BF-Verfahren optimieren kann, indem man eben zb ein wenig Statistik einbringt, und gängige Muster zuerst abarbeitet....

 

[Rastafari]

Nun, warum sollte ich eine US-Tastatur verwenden

Offenkundig warst du noch nie auf Firmware-Shells oder Single-User Mode angewiesen. Und virtuelle Maschinen oder einfach nur Befehlszeilen magst du wohl auch nicht so gerne.

oder eine VNC-Verbindung?

Weil das nur ein anderer Name für die Bildschirmfreigabe ist?
(Und sicher nutzt du auch keine anderen Betrübsysteme, um auf deine eigenen Freigaben von anderer Art zuzugreifen.)

Aber en passant interessiert mich doch, wie man ein ASCII-Passwort dann auf einer chinesischen oder sonstigen nichtlateinischen Tastatur eingibt.

Chinesen schreiben auf dem gleichen Keyboard wie du.

Haben die das amerikanische Layout zusätzlich aufgedruckt?

Streiche das "zusätzlich".

 

[David X]

Oder dem dämlichen Dogma von der inhärenten Systemsicherheit durch Unix.

Nur zu meinem Verständnis…

…und ein paar grundsätzliche einleitende Worte:

- Sicherheit ist immer relativ und nie absolut
- das größere Sicherheitsrisiko sitzt immer vor dem Rechner und nicht als OS auf der Festplatte

Dies vorausgeschickt, seh' ich das falsch, wenn ich behaupte, dass UNIX-Systeme einfach z.B. Windows-Systemen in Bezug auf grundsätzliche Systemarchitektur in Punkto "Sicherheit" überlegen sind (was aber eben nicht bedeutet, dass sie grundsätzlich "sicher" sind).

 

[Rastafari]

seh' ich das falsch, wenn ich behaupte, dass UNIX-Systeme einfach z.B. Windows-Systemen in Bezug auf grundsätzliche Systemarchitektur in Punkto "Sicherheit" überlegen sind

Das siehst du absolut falsch, denn zumindest von den Grundlagen her wäre Windows in diesem Punkt um Längen überlegen.

"The first fact to face is that Unix was not developed with security, in any realistic sense, in mind..."
[Dennis M. Ritchie]

 

[naich]

Falsch.
http://xkcd.com/936/

Ich bezweifle mal stark, dass es so sinnvoll ist, 3 Wörter aus dem Wörterbuch hintereinanderzuschreiben - wenn bei Wörterbuch-Attacken auch mal mehrere Wörter hintereinandergehangen werden.

 

[smoe]

Naja du hast dann eben die Mächtigkeit des Wörterbuches hoch 3 Möglichkeiten. Das ist schonmal nicht wenig... (Leerzeichen ect kommen auch nochmal positiv dazu...)

 

[ImperatoR]

Um Passwörter zu generieren benutze ich einfach den Kennwortassistent (Option "einprägsam") vom Schlüsselbund.

 

[naich]

Naja du hast dann eben die Mächtigkeit des Wörterbuches hoch 3 Möglichkeiten. Das ist schonmal nicht wenig... (Leerzeichen ect kommen auch nochmal positiv dazu...)

Aber immer noch deutlich weniger als zusammenhanglose Buchstaben.

Ich denke Merkhilfen wie "nehme von deinem Lieblingssatz immer den ersten Buchstaben jedes Wortes" sind da effektiver...

 

[Rastafari]

Ich bezweifle mal stark, dass es so sinnvoll ist, 3 Wörter aus dem Wörterbuch hintereinanderzuschreiben - wenn bei Wörterbuch-Attacken auch mal mehrere Wörter hintereinandergehangen werden.

Wörter aus einem Wörterbuch sind äquivalent zu einzelnen Zeichen eines unglaublich grossen Zeichensatzes.
Solange die Worte in keinem semantischen/logischen Inhalt zueinander stehen ist das Verfahren absolut safe.

Nur mal so zum Nachdenken...

Worte, Silben und Phoneme in einschlägigen Wortlisten: ca. 25.000
Anzahl der möglichen Kombinationen aus nur zwei davon: ca. 625.000.000
Anzahl der möglichen Kombinationen aus drei Worten: ca. 15.625.000.000.000
Anzahl der möglichen Kombinationen aus vier Worten: ca. 4 Trillionen.

Ist darüber hinaus noch unbekannt, ob die Worte gross oder klein zu schreiben sowie durch Whitespace oder andere Verbindungszeichen zu trennen sind, steigt die Zahl der Kombinationen nochmals erheblich an.
Selbst eine ganz einfach zu merkende Folge von nur vier einprägsamen Worten aus dem ganz alltäglichen Grundwortschatz einer einzigen Sprache (wie zB typisches Duden-Deutsch) erlangt somit die gleiche Permutationshöhe wie eine völlig zufällig generierte, kompaktere, aber für das Gedächtnis eines Menschen völlig inakzeptable Folge von 10 bis 12 alphanumerischen Zeichen.
(Im Gegensatz zu dieser Zeichenfolge müsste aber für die Wortfolgen eine komplett neue, separate Datenbank an Rainbow-Tables angelegt werden, woran schlichtweg niemand auch nur zu denken wagt. Die bestehenden Tabellen sind dafür als untauglich einzustufen.)
Ergo --> Viel Vergnügen beim Brute-forcen.

 

[SilentCry]

Das geht doch. Zuerst erstellst Du vor der Aktivierung von FileVault2 zwei Admin-Accounts. ...

Ergänzung: UND den zu verwendenden User-Account. Das darf man nicht vergessen, denn jeder Benutzer, den man danach erstellt, führt zu dem von mit benannten Problem.

 

[David X]

Ja, das ist ein echter Bug in der Systemeinstellung. Erstelle ich bei Lion Server mit der Server.app einen lokalen neuen Benutzer, kann dieser nicht die Festplatte entschlüsseln, erstelle ich einen neuen Benutzer über die Benutzerverwaltung in den Systemeinstellungen, darf der neue Benutzer die Festplatte entschlüsseln. Das ist a) unlogisch und b) ein Sicherheitsrisiko für alle, die nur die Möglichkeit haben neue Benutzer über die Systemeinstellungen anzulegen, da sie nicht den Server installiert haben.

 

[naich]

Ich finde es durchaus logisch, das ein nach Einschalten der FDE neu erstellter User die Festplatte entschlüsseln darf. Schließlich will sich ein neuer User auch nach einem Neustart des Systems noch anmelden dürfen.

 

[David X]

Was ein neuer Benutzer auf einer Maschine darf oder nicht entscheidet grundsätzlich der Admin, nicht das "Wollen" eines Benutzers. Wenn ich sensible Daten auf einer Festplatte mittels FDE sichere, dann will auch entscheiden, wem ich den Schlüssel dafür in die Hand gebe. Ansonsten ist das Feature, gerade im gewerblichen Umfeld, sinnbefreit.

 

[naich]

Edit, s.u.

Wenn ich sensible Daten auf einer Festplatte mittels FDE sichere, dann will auch entscheiden, wem ich den Schlüssel dafür in die Hand gebe.

Nicht du als ein Nutzer verschlüsselst deine Daten, sondern alle Daten des Rechners werden (mit dem gleichen Master-Schlüssel) verschlüsselt - egal welchem Benutzer sie gehören.

Ansonsten ist das Feature, gerade im gewerblichen Umfeld, sinnbefreit.

Im gewerblichen Umfeld wird der Admin schlau genug sein, 3 Klicks mehr zu machen, wenn ein Nutzer sich nicht beim Start des Rechners anmelden darf.
Im Heim-Umfeld hingegen wundert sich der Benutzer evt. nur, das der neu erstellte Account sich nicht anmelden kann.

Und wenn man an das Nutzungsszenario eines Servers denkt, ist die unterschiedliche Handhabung durchaus logisch: Ein Server läuft normalerweise immer und wird nur vom Admin neugestartet. Andere Benutzer greifen dann wahrscheinlich vor allem übers Netzwerk darauf zu.

 

[David X]

Genial, Du weißt also wie das geht. Erklär mir bitte, wie ich einem, bei bereits vorher aktivierten FileVault2, lokal angelegten Benutzer das Recht zur Festplattenentschlüsselung wieder entziehe.

Und die Edith fragt, wie man eigentlich generell einem Nutzer, egal auf welche Art angelegt, dieses Recht wieder entzieht, ohne den Benutzer-Account ganz zu löschen.

 

[naich]

OK, jetzt verstehe ich dein Problem. Ich habe angenommen, das das gehen würde, sorry. Hier ist unten ein Lösungsvorschlag beschrieben, den man probieren könnte. Vielleicht gibt es ja im Laufe der Zeit eine offizielle Möglichkeit dafür...

Nichtsdestotrotz sehe ich im Moment kein Szenario, wo das wirklich Sinn macht, einem Nutzer die Rechte zu entziehen. Wenn er einmal angemeldet ist, kann er ja eh auf die Platte zugreifen wie er will / kann. Allein ein Missbrauch der Funktion als "Kinder-Sicherung" könnte ich mir vorstellen. (Kann ein solcher User auch noch nach einem Ruhezustand dann wieder auf die Platte zugreifen?)

 

[David X]

Jetzt muss ich doch ein wenig ausholen…

Mit der Einführung von Lion sind Macs ohne zusätzliche Verschlüsselungstools als Multi-User-Arbeitsplatzrechner praktisch nicht mehr zu gebrauchen (unter dem Aspekt Sicherheit betrachtet). Vor Lion brauchte man ein Installationsmedium, das einem einen Passwort-Reset ermöglichte. Da man Anwendern ja nicht so einfach mal die Install-DVDs in die Hand drückt und ein Mitarbeiter dann schon seine eigenen Upgrade-DVDs mit in die Firma bringen musste, war ein Missbrauch zwar noch immer möglich aber unter Umständen doch schon ziemlich auffällig ("Was macht denn der Mayer da mit der Apple-DVD an seinem iMac?"). Aber jetzt, Neustart → cmd+R → Utilities → Terminal → resetpassword → Welchen Account hätten's denn gern, gnä Frau? - Ein Witz…

Aktiviertes FileVault2 unterbindet das allerdings wirkungsvoll, da man zwar noch immer mit cmd+R booten kann, im Terminal aber resetpassword nicht mehr funktioniert. Genauso verhält es sich jetzt auch im Service-Fall, kein Techniker kann in die Accounts auf der Festplatte gucken. Worst-Case-Szenario ist jetzt also nur Datenverlust aber kein Datenklau. Bis hierhin ist FileVault2 unter Lion also ein sinnvolles Tool.

Kommen wir nun zu dem Punkt, wer darf booten und warum darf jemand das unter Umständen nicht (oder sollte es nicht dürfen). Bei Systemen die praktisch nur nach Updates neu starten, ist das natürlich nicht besonders wichtig, da im Normalfall die Platte für alle berechtigten Benutzer entschlüsselt ist. Was aber wenn ich bestimmten Mitarbeitern das Benutzen des Rechners nur unter Aufsicht gestatten will und deshalb die Rechner abends runterfahre und morgens neu starte? Gründe dafür kann es je nach Unternehmen und Sensibilität der Daten auf dem Rechner viele geben (und ein berechtigter Nutzer auf dem Rechner ist ja wohl immer eine größere Gefahr, als ein Rechner, der sich gar nicht erst booten lässt…).

Paradox ist auch, dass jeder langjährige Mitarbeiter mit seinem Account bei der Aktivierung von FileVault2 per Default ausgeschlossen ist, während z.B. jeder Praktikant mit seinem neuen Account per Default booten darf. Auf Lion Clients ist dies anders nicht möglich (es sei denn der von Dir verlinkte Workaround funktioniert, aber das kann's doch eigentlich nicht sein). Aber auch auf Lion-Server-Systemen ist die Implementierung nicht logisch. Warum kann ich mit der Server.App einen neuen Benutzer ohne Berechtigung erstellen, mit der Systemsteuerung wiederum nicht? Und warum kann ich auf dem Server eine ein mal erteilte Berechtigung nicht widerrufen? Oder kann ich das und es ist bisher nur nicht dokumentiert bzw. ich war unfähig es zu finden?

 

[Rastafari]

Aber auch auf Lion-Server-Systemen ist die Implementierung nicht logisch.

Es ist vielmehr nicht logisch, auf einem Server überhaupt eine Festplattenverschlüsselung zu aktivieren.
Bei einem mobilen Rechner mag das ja sinnvoll erscheinen, aber wozu sollte man die HD eines Systems verschlüsseln das dazu gemacht ist, permanent durchzulaufen und im Falle eines Stromausfalls ganz von selbst wieder auf die Beine zu kommen, ohne jeden Benutzereingriff?
Nur mal eben so, zum reinen Spass an sinnfrei durcheinandergewürfelten Daten?

 

[David X]

Da hast Du natürlich Recht, Rastafari, bei mir ist FilVault2 auf dem Mini auch nur aktiviert zum Ausprobieren (ist hier zu Hause eh nur ein "Testcenter"-Setup). Ändert aber nichts an der Tatsache, dass die Implementierung nicht konsistent ist.