OSX Lion & Filevault 2 - quick review

SirLockholmes

Aktives Mitglied
Thread Starter
Dabei seit
22.07.2009
Beiträge
777
Reaktionspunkte
99
Hallo MU,

ich habe mir in irgendeinem Thread mal vorgenommen, Filevault2 unter OSX 10.7 wenn es denn "fertig" ist zu testen und will nun hier kurz meine Erkenntnisse festhalten.

Zu mir, ich arbeite nun seit 1994 im Bereich Network und Information Security und beschäftige mich u.a. mit Crypto-Analyse, Penetration Testing, Hacking und sonstigem über das man im dem Bereich stolpern könnte und denke, ich kann mir bestimmt eine entsprechende Meinung über die Features bilden, auch wenn es nicht wirklich viel zu sagen gibt ...

Review: OSX 10.7 Filevault2
Vorab sollte man wissen: Apple integrierte in OSX 10.7 Filevault2 welches selbst auf eine Verschlüsselung, basierend auf XTS-AES 128 (eigentlich 256 bit, dazu später mehr), für die gesamte Festplatte zurück greift. Eine zusätzliche Verschlüsselung des Home-Verzeichnisses ist für die unterschiedlichen Benutzer des Systems leider nicht möglich. Es lassen sich natürlich weiterhin verschlüsselte Images erzeugen in denen man Daten speichert und diese im Home-Verzeichnis ablegen, aber eine echte "multi-layer security" mit mehreren "Hürden" die es zu bewältigen gibt, gibt es im Vergleich zu anderen am Markt erhältlichen Lösungen leider nicht. Ich zitiere mich an dieser Stelle gerne mal wieder selbst: "Gut gemacht Apple, überlegt und integriert, aber leider mal wieder nicht zu Ende gedacht - wie leider so oft."

XTS selbst, ist in der IT-Security Branche unterschiedlich angesehen, es gibt Gruppen die sagen es sei hervorragend, andere die sagen ausreichend und wiederum andere die der Meinung sind, dass es den Prozess lediglich unnötig verkompliziert da es aufgrund des "multi-keying" keine Steigerung der Sicherheit gibt gegenüber XEX (Xor-Encrypt-Xor). Hintergrund ist hier dass XTS das Schlüsselmaterial, dass für die Verschlüsselung herangezogen wird halbiert bzw teilt und somit mit zwei (2) Schlüsseln mit halber Länge arbeitet - also bei XTS-AES-128 (eigentlich sind dies 256 bit) mit 2 Schlüsseln mit jeweils 128 bit, wo hingegen XEX mit voller Schlüssellänge (in diesem Fall 256 bit) arbeitet. Daher integriert man XTS normal auch so, dass der Benutzer die Schlüssellänge variabel nutzen kann, zB mit 256 (Filevault2) oder 512 bit um eine entsprechend "stärkere" Verschlüsselung zu erreichen, diese Funktion sucht man im OSX 10.7 Lion jedoch vergeblich. D.h. im Klartext, dass unter OSX 10.7 Lion mit XTS AES-128 die effektive Schlüssellänge lediglich 128 bit und nicht 256 bit beträgt. Weitere Details zu XTS lassen sich im IEEE Projekt 1619 nachlesen, das zur Herleitung von XTS führte. Andere Lösungen die ebenfalls auf XTS setzen sind - ohne gewähr auf Vollständigkeit - Truecrypt, Bestcrypt, DMcrypt, Free-OTFE, Diskcryptor, Free- sowie Open-BSD - soviel zum allgemeinen Verständnis.

Kommen wir nun zur integrierten Lösung selbst:
Der "Administrator" hat die Möglichkeit Filevault2 nach der Installation für die im System befindliche Festplatte zu aktivieren - später auch weitere externe oder USB-Sticks. Dieser Prozess ist meiner Einschätzung nach vollkommen unnötig, da man bei der Installation die Festplatte bereits formatieren und die Daten sofort auf ad-hoc verschlüsselten Sektoren ablegen könnte. Ich denke mal Apple hat sich hierbei gedacht, dass dies einen negativen Einfluss auf die Installationszeit haben könnte und es daher unterlassen hat, dieses Feature zu integrieren. Man muss jedoch gestehen, dass dies ein valider Einwand ist. Während die Verschlüsselung - also nach der Installation, Aktivierung von Filevault2 und Reboot (erst nach dem nächsten Start beginnt der Verschlüsselungsprozess) - im Hintergrund läuft, steht das System bereits dem Benutzer zur Nutzung zur Verfügung, dennoch ist ein "sicheres" Ausliefern nach Basisinstallation so nicht möglich. Der Verschlüsselungsprozess selbst kann jedoch durch Log-Out, Sleep Funktion oder auch Herunterfahren des Systems temporär unterbrochen werden und nimmt an der Stelle seine Arbeit wieder auf wo er "pausiert" wurde, ein warten auf Beendigung des Prozesses ist somit nicht notwendig.

Aktiviert der Administrator oder Hauptbenutzer nach der Installation dieses Feature über Systemeinstellungen/Sicherheit/Filevault, wird automatisch ein Recovery-Key erzeugt mit dem es möglich ist, Daten bei Problemen mit dem System an sich wieder herzustellen - soweit die Theorie (konnte ich bisher nicht testen). Dieser Recovery-Key kann entweder notiert und an einer "sicheren" Position abgelegt werden, alternativ bietet Apple auch an, den Recovery-Key für den Benutzer zu speichern. Letzteres benötigt die Vergabe von Antworten auf Sicherheitsfragen, mit denen der Recovery-Key selbst gesichert wird. Die Antworten auf die Sicherheitsfragen agieren, so wie ich es bisher nachvollziehen konnte, in diesem Szenario als Authentisierung gegen sowie als "Seeds" für die Verschlüsselung des Keys (packet-trace und crypto-Analyse bei/nach Übertragung des Recovery-Keys).

Nachdem der Verschlüsselungsprozess abgeschlossen ist - die Zeit ist abhängig vom System an sich, bei mir ca. 8 Stunden auf meinen basiskonfigurierten System (Mail (200.000 Mails), iTunes Library sowie ein paar Applikationen (ca.130GB an echten Daten) siehe Signatur)) - erwartet OSX 10.7 nach Kaltstart des Systems dass sich ein autorisierter Benutzer gegen Filevault2 authentisiert um das System zu starten. Leider hat Apple hier es unterlassen, die Benutzer zu verstecken und es werden letztlich die autorisierten Benutzer zur Auswahl angeboten, anders als man es zB kennt wenn man die Anmeldeoption "Anmeldefenster zeigt an: "Name und Kennwort"" gewohnt ist. Dieses erleichtert es einem potenziellem Angreifer, da er den Benutzernamen nicht zusätzlich erraten muss, sondern lediglich das Passwort - welches zusätzlich die Autorisierung gegen das Benutzeraccount darstellt. Also eine zweigeteilte Überprüfung des Benutzers nach Authentisierung und Autorisierung, einmal gegen die Festplattenverschlüsselung und dann gegen das Benutzeraccount selbst, gibt es nicht - quasi eine - aus meiner Sicht - "schlechtere" Art von Single-SignON.

Bestehen zum Punkt der Einrichtung von Filevault2 bereits weitere Benutzer auf dem System kann der Administrator oder Hauptbenutzer entscheiden ob auch andere Benutzer die Möglichkeit haben, ebenfalls das System entschlüsseln zu können. Erlaubt man es ihnen nicht muss erst umständlich der Hauptbenutzer das System starten und dann per FastUserSwitching der Zugang für anderen Benutzer ermöglicht werden.

Die Beeinträchtigung des Systems selbst bei der Benutzung ist "gefühlt" nicht wirklich hoch, das Starten eines Systems, hier zB mein in der Signatur genanntes MacBook Pro, beträgt nach der Authentisierung gegen Filevault2, Systemstart, automatischer Anmeldung an ein Wireless Netzwerk und manuelles starten von Safari mit www.google.com als Startseite ca. 40 Sekunden (5400rpm HDD).

Also kurz zusammengefasst, aus meiner Sicht ein guter Anfang, aber bei weitem nicht zu Ende gedacht und es gibt sehr viel Spielraum für Verbesserung. Was die Belastung des Systems angeht, konnte ich bisher nichts negatives feststellen, auch nicht bei hoher Speicher und hoher Festplattenaktivität, also zB Speicher nahezu ausgelastet und lesen von zB HD Material 1080p oder gar 4k. Auch das Abspielen und bearbeiten von größeren Logic-Projekten wurde nicht wirklich signifikant beeinträchtigt.

Problematisch bzw Nachbesserung erhoffe ich mir an folgenden Punkten:
- Nicht beeinflussbare Schlüssellänge - zB 512 bit

- Autorisierte Benutzer - ich möchte a) verstecken welche Benutzer das System entschlüsseln können und b) Berechtigungen zuweisen und auch wieder entziehen können - bei SingleUser Systemen bestimmt zu vernachlässigen.

- Authentisierung & Autorisierung - ich möchte kein Single-SignOn, es sollten getrennte Möglichkeiten bestehen, a) die Festplatte entschlüsseln und das System starten zu können und b) der/die Benutzer sich gegen ihr Benutzerprofil authentisieren können.

- Verschlüsselung des Benutzerprofils - der Benutzer sollte die Möglichkeit haben, sein Profil zusätzlich zu verschlüsseln, dies mit einem anderen Schlüssel, damit seine Daten gegenüber anderen Benutzern auf dem System und auch generell zusätzlich geschützt sind.

- "Network-Keys" - es sollte möglich sein, Benutzern innerhalb eines Netzwerks Zugriff zu erlauben oder zu negieren, derzeit verläuft es so, dass sobald eine zB AFP- oder SMB-Session im Benutzerkontext erlaubt ist, dies auch innerhalb des Benutzerkontexts verläuft (Usermode). Es kann somit jeder Benutzer, dem man erlaubt über das Netzwerk auf Daten zu zugreifen auf diese Daten unverschlüsselt zugreifen und diese auch unverschlüsselt zB lokal auf seinem Rechner ablegen.

Träume und Wünsche:
- Unterstützung von zusätzlichen Medien zur Authentisierung, zB USB-Stick mit einem De-cryption- oder Authentication-Key der an den Benutzer gebunden ist (Smartcard oder Fingerprint lasse ich mal aufgrund fehlender Hardware außen vor).

- "Key-Sharing" - für geteilte Verzeichnisse oder Dateien selbst auf zB OSX 10.7 Server sollte man unterschiedlichen Benutzern mit unterschiedlichen Keys Zugriff auf Daten erlauben können - ich weiss es war bestimmt nicht die Intention von Apple aber man darf doch auch noch Wünsche äussern oder?

Soweit erstmal der "quick review", den ich vielleicht noch hier und da je nach Erfahrungen ergänzen werde.

Hoffe für einige hilfreich ...
SirLockholmes
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: relax, detto87, andi42 und 18 andere
Erweiterungen

Ich mache hier mal wieder, da die Beiträge auf Länge begrenzt sind:

- Kennwort nun immer "sofort" erforderlich nach Display-Sleep oder Bildschirmschoner (Edit 1)
Wer Filevault2 aktiviert, der verliert die Möglichkeit, das Verhalten der Kennworteingabe nach Beginn des Ruhestand oder Bildschrimschoners zu beeinflussen. Systemeinstellungen/Sicherheit/Allgemein: Kennwort erforderlich: "sofort bis zu einer Stunde" wird nach der Aktivierung von Filevault2 immer auf "sofort" zurück gesetzt. Dies kann unschöne Nebeneffekte haben, zB funktionieren einige Wecker unter OSX wenn diese Option gesetzt ist nicht mehr.

- Verwendung des Recover-Key (Edit 2)
Der bei der Installation erzeugte Recovery-Key wird in der PreBootAuthentisierung verwendet, sollte man sein Passwort vergessen haben. Man klickt einfach nach Systemstart auf das Fragezeichen und hat dann die Möglichkeit den Recovery-Key dort einzugeben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: beoliving, smn und chaos_inc
Erweiterungen 2 (Platzhalter)

- Verschlüsseln von externen Medien
Man kann mit Filevault2 auch externe Medien verschlüsseln, als Beispiel nehme ich hier mal einen USB-Stick.
Um den USB-Stick zu verschlüsseln, öffnet man das Festplatten-Diesntprogramm, wähl das entsprechende Medium aus und geht auf Löschen und hat dann die Möglichkeit als Format "Mac OS Extendend (Journaled, Verschlüsselt)" oder ""Mac OS Extendend (Gross/Kleinschreibung, Journaled, Verschlüsselt)" auszuwählen. Klickt man nun auf Löschen, wird man zur Eingabe eines Passworts aufgefordert und kann noch eine Merkhilfe für das Passwort vergeben. Bestätigt man nun abermals mit Löschen wird das Medium formatiert, jegliche Daten werden gelöscht, und danach das Medium verschlüsselt. Von nun an wird man jedes Mal wenn das Medium angesteckt wird zur Eingabe des Passworts gebeten. Alternativ zum Letzteren, kann man das Passwort selbst auch im Schlüsselbund sichern und sich somit die Eingabe am heimischen Mac zB ersparen. Die Merkhilfe wird lediglich angezeigt, wenn man diese auch vergeben hat. Eine weitere Sicherheitsfunktion für das verschlüsselte Medium selbst, also zB Zerstören oder Löschen der Daten nach x-facher Fehleingabe des Passworts sucht man auch hier leider vergebens.

Wichtig:
1) Hat man das Passwort vergessen und die Merkhilfe hilft einem auch nicht weiter, kann man das Medium nicht einfach mit dem Festplatten-Dienstprogramm neu Löschen, die Partition bleibt leider dem Benutzer erstmal unzugänglich. Man kann dies nur umgehen, wenn man das Format ändert zB zu MS-DOS-Dateisystem (FAT), nur so lässt sich das Medium wieder in "Betrieb" nehmen.

2) Das neue Dateisystem kann übrigens nur von OSX 10.7 Lion gelesen werden, ältere Systeme können damit nicht umgehen!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: chaos_inc und ProUser
Aus Sicherheitsperspektive kann ich der ersten Zusammenfassung zustimmen. Aus Sicht des Einzelanwenders stört mich allerdings nur der Punkt von Edit1, dafür ganz gewaltig. Ich suche verzweifelt nach einer Möglichkeit, die Kennwortabfrage nach Beginn des Bildschirmschoners abzuschalten.

Situation: Ich verwende mein MBP die meiste Zeit zuhause, Bildschirmschoner kommt nach 5 Minuten. Mir wurde erst die letzten zwei Tage klar, wie oft ich den wegmache. Und es kotzt mich regelrecht an, dann immer das PW eingeben zu müssen, bin schliesslich zuhause. Wenn ich das Notebook ausser Haus nehme, sperre ich es grundsätzlich immer indem ich zum Anmeldebildschirm wechsle.

Umgehungsmöglichkeiten bisher:
- Bildschirmschoner + Ruhezustand für Monitor deaktivieren und bei Bedarf manuell aktivieren z.B. via Aktive Ecke. Halte ich für inakzeptabel.
- "Kennwort erforderlich" Zeit von sofort auf maximum (1h) ändern. Soweit akzeptabel, aber: danach unter Systemeinstellungen nie wieder die Sicherheitseinstellungen ansehen. Sobald man dies tut, ist die Zeit wieder auf sofort gesetzt.

IMHO ideale Lösung: Kennwortabfrage nur bei Standby aktivieren, jedoch nicht beim Bildschirmschoner. Oder das automatische Ändern der Verzögerung auf "sofort" verhindern. Wenn jemand weiss wie man das einrichten kann, bitte posten.
 
Aus Sicherheitsperspektive kann ich der ersten Zusammenfassung zustimmen. Aus Sicht des Einzelanwenders stört mich allerdings nur der Punkt von Edit1, dafür ganz gewaltig. Ich suche verzweifelt nach einer Möglichkeit, die Kennwortabfrage nach Beginn des Bildschirmschoners abzuschalten.

Situation: Ich verwende mein MBP die meiste Zeit zuhause, Bildschirmschoner kommt nach 5 Minuten. Mir wurde erst die letzten zwei Tage klar, wie oft ich den wegmache. Und es kotzt mich regelrecht an, dann immer das PW eingeben zu müssen, bin schliesslich zuhause. Wenn ich das Notebook ausser Haus nehme, sperre ich es grundsätzlich immer indem ich zum Anmeldebildschirm wechsle.

Umgehungsmöglichkeiten bisher:
- Bildschirmschoner + Ruhezustand für Monitor deaktivieren und bei Bedarf manuell aktivieren z.B. via Aktive Ecke. Halte ich für inakzeptabel.
- "Kennwort erforderlich" Zeit von sofort auf maximum (1h) ändern. Soweit akzeptabel, aber: danach unter Systemeinstellungen nie wieder die Sicherheitseinstellungen ansehen. Sobald man dies tut, ist die Zeit wieder auf sofort gesetzt.

IMHO ideale Lösung: Kennwortabfrage nur bei Standby aktivieren, jedoch nicht beim Bildschirmschoner. Oder das automatische Ändern der Verzögerung auf "sofort" verhindern. Wenn jemand weiss wie man das einrichten kann, bitte posten.

Tja, das Problem kenn ich ... Ich nutze zudem Shades (http://www.charcoaldesign.co.uk/shades) dass lässt sich schön per Keyboard-Shortcut de-aktivieren, jedoch nicht wenn das Passwort Prompt erstmal zugeschlagen hat ...
Ich denke vielleicht ist das für dich ne Lösung, lässt sich per Keyboard-Shortcuts hell und dunkel stellen, eine andere Lösung hab ich bisher nicht gefunden.
 
Kurz zu deinen Kritikpunkten, Multi-User Umgebungen lasse ich mal weg, weil sie mich nicht betreffen und ich mich damit nicht auskenne.

Beeinflussung der Schlüssellänge:
Ist dies momentan wirklich ein relevanter Faktor? Meines Wissens nach gilt AES als sicher bzw. ist kein Angriff bekannt der einen 256Bit Key in sinnvollem Zeitaufwand knacken könnte, warum also der Wunsch nach höherer Schlüssellänge (Immer ausgehend von einem 'sicheren' Key.)?

Network-Key:
Stimme ich zu, halte ich auch für einen Kritikpunkt
Selbiges geht für zusätzliche Medien zur Authentifizierung

Zur Bildschirmschoner Problematik, bei mir wird der Bildschirm nach 15Min dunkel, es wird aber kein Bildschirmschoner oder automatischer Ruhezustand aktiviert, würde dort auch die erzwungene Passworteingabe greifen?

Externe Medien:
Sicherlich sind hier Verbesserungen möglich, allerdings eignet sich meiner Meinung nach für portable Medien TrueCrypt eh besser, da die Medien auch unter anderen Systemen entschlüsselt werden können.

Wie 'Zerstören oder Löschen der Daten nach x-facher Fehleingabe des Passworts' Softwarebasiert bei externen Medien sicher funktionieren soll, erklärt sich mir momentan nicht.

Als Fragen allgemeinerer Natur habe ich noch 2.
Kommt bei dieser Verschlüsselung ebenfalls ein Angriff via Bootloader in Frage, also man erlangt physischen Zugriff aufs den verschlüsselten Mac, und installiert im Bootloader einen Keylogger o.ä. so das das System bei zweiten physichen Zugriff entschlüsselt werden kann?

Wie beurteilst du die Möglichkeit von Fehler bei der Implementierung der Verschlüsselung seitens Apple, die diese angreifbar machen würde, bzw. dem Vorhandensein einer Backdoor?

Gruß und Danke für das Review.
 
Man könnte gegebenenfalls noch ergänzen, dass es möglich ist auch andere Volumes als das interne ohne Datenverlust zu verschlüsseln. Dazu muss man allerdings das Terminal bemühen:

Command-line tools to the rescue: diskutil will happily attempt to encrypt any volume you point it at, without erasing it first. Actually, the process is to convert it to a Core Storage volume which may optionally include encryption. Let's encrypt the Timex volume, shown as disk1s4 in the earlier diskutil list output.

Code:
% diskutil cs convert disk1s4 -passphrase mysecret

(vgl. hier, ungefähr ab der Mitte der Seite).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SirLockholmes
Kurz zu deinen Kritikpunkten, Multi-User Umgebungen lasse ich mal weg, weil sie mich nicht betreffen und ich mich damit nicht auskenne.

Beeinflussung der Schlüssellänge:
Ist dies momentan wirklich ein relevanter Faktor? Meines Wissens nach gilt AES als sicher bzw. ist kein Angriff bekannt der einen 256Bit Key in sinnvollem Zeitaufwand knacken könnte, warum also der Wunsch nach höherer Schlüssellänge (Immer ausgehend von einem 'sicheren' Key.)?

Weil Apple eben mit 2x 128 und nicht mit 1x 256 bit arbeitet ... alleine aus dem Grund ..
Network-Key:
Stimme ich zu, halte ich auch für einen Kritikpunkt
Selbiges geht für zusätzliche Medien zur Authentifizierung


Zur Bildschirmschoner Problematik, bei mir wird der Bildschirm nach 15Min dunkel, es wird aber kein Bildschirmschoner oder automatischer Ruhezustand aktiviert, würde dort auch die erzwungene Passworteingabe greifen?

Da kann ich noch keine verlässliche Aussage zu treffen, habe bisher keine Möglichkeit gefunden das Passswort zu deaktivieren, sodass zB Remote Tools wie Logmein, Teamviewer etc funktionieren sobald Filevault2 aktiv ist ... wird noch nachgereicht, zu wenig Zeit unter der Woche ...

Externe Medien:
Sicherlich sind hier Verbesserungen möglich, allerdings eignet sich meiner Meinung nach für portable Medien TrueCrypt eh besser, da die Medien auch unter anderen Systemen entschlüsselt werden können.

Wie 'Zerstören oder Löschen der Daten nach x-facher Fehleingabe des Passworts' Softwarebasiert bei externen Medien sicher funktionieren soll, erklärt sich mir momentan nicht.

Ganz einfach, wenn das Passwort mehrfach falsch eingegeben und der Host es unterstützt wird dem Anwender einfach etwas vorgegaukelt und im Hintergrund das Medium mit Nullen überschrieben ... "Löschen oder Zerstört" ...

Als Fragen allgemeinerer Natur habe ich noch 2.
Kommt bei dieser Verschlüsselung ebenfalls ein Angriff via Bootloader in Frage, also man erlangt physischen Zugriff aufs den verschlüsselten Mac, und installiert im Bootloader einen Keylogger o.ä. so das das System bei zweiten physichen Zugriff entschlüsselt werden kann?

Wie beurteilst du die Möglichkeit von Fehler bei der Implementierung der Verschlüsselung seitens Apple, die diese angreifbar machen würde, bzw. dem Vorhandensein einer Backdoor?

Gruß und Danke für das Review.

Soweit ich es bisher beurteilen kann, lässt sich kein Keylogger im Bootloader derzeit "injecten" - ongoing Process ...

Zu deiner zweiten Frage, kann man noch nicht einschätzen, da es sich eben um closed source handelt, vorstellbar ist sowas muss allerdings erst bewiesen werden - ohne Beweis kann man nur sagen Alles kann Nichts muss .. Oder man macht überhaupt keine Aussage bevor meine seine Aussage nicht untermauern kann, dazu tendiere ich in diesem Szenario ...
 
  • Gefällt mir
Reaktionen: Killerhund
Ich hab leider gar keine Ahnung von der Materie, bin aber schon auf Sicherheit bedacht.
Ich habe Lion per Clean-Install auf mein MacBook Pro (late '08) drauf gemacht. Kann ich FileVault ohne weiteres aktivieren? Und ist dieses Verschlüsselungssystem tatsächlich knacksicher?
Mir ist schon klar, das kein Mensch an meinen Dateien so sehr interessiert ist, dass er eine ganz Rechner-Farm arbeiten lässt, um meine Verschlüsselung zu knacken. Aber es sollte für Otto Normalverbraucher unmöglich sein. Bringt mir das FileVault2?
Wie sollte der Schlüssel aussehen? Groß- und Kleinschreibung, Zahlen, Buchstaben, Mindestlänge?
 
Für Otto-Normaldieb wird's wohl knacksicher sein. Aktivierung ist problem- und gefahrlos, würd ich sagen (so lange du nicht Passwort und Recoveryschlüssel verschlampst). Für das Passwort gelten die selben Regeln wie für alle anderen: Je komplexer und unlogischer, desto besser. Also lang genug, Ziffern und Buchstaben, Sonderzeichen. Und natürlich nicht Name der Freundin oder Geburtstag.

Hinweis: Bei der Passwortabfrage vor dem Booten ist das Tastaturlayout per default Englisch (US). Das kannst du oben rechts auf Deutsch umstellen.
 
  • Gefällt mir
Reaktionen: Boogieman
Danke für das Review, ich hatte gehofft, von dir etwas zum Thema zu Lesen :)

Eine Frage zum Recovery-Key: Der hat 24 Stellen, allerdings ohne Sonderzeichen oder Groß-/Kleinschreibung und ist somit kürzer und weniger kompliziert, als meine Passwörter - d.h. ich kann meine Passwörter vereinfachen, weil der Recovery Key das ganze limitiert.
 
Danke für das Review, ich hatte gehofft, von dir etwas zum Thema zu Lesen :)

Eine Frage zum Recovery-Key: Der hat 24 Stellen, allerdings ohne Sonderzeichen oder Groß-/Kleinschreibung und ist somit kürzer und weniger kompliziert, als meine Passwörter - d.h. ich kann meine Passwörter vereinfachen, weil der Recovery Key das ganze limitiert.

Ja weil Apple keine Sicherheitshürde bei der xfachen Fehleingabe des Recovery-Keys eingebaut hat, ich sagte doch schon:
Ich zitiere mich an dieser Stelle gerne mal wieder selbst: "Gut gemacht Apple, überlegt und integriert, aber leider mal wieder nicht zu Ende gedacht - wie leider so oft."
 
Nebenbei:
Wenn du den Key bei Apple speicherst, ist die ganze Verschlüsselung dann ja auch nur so sicher wie dein Apple-Account Passwort plus generische Frage-Antwort! Oder halt so sicher wie Apple die Keys speichert^^ Je nachdem was schwächer ist.
Ich sehe ehrlich gesagt keinen Grund warum man den Key bei Apple speichern sollte. Zuhause im Tresor ist das doch tausend mal sicherer.
 
Nebenbei:
Wenn du den Key bei Apple speicherst, ist die ganze Verschlüsselung dann ja auch nur so sicher wie dein Apple-Account Passwort plus generische Frage-Antwort! Oder halt so sicher wie Apple die Keys speichert^^ Je nachdem was schwächer ist.
Ich sehe ehrlich gesagt keinen Grund warum man den Key bei Apple speichern sollte. Zuhause im Tresor ist das doch tausend mal sicherer.

wenn dein Tresor gestohlen wird oder nicht so feuerfest ist wie du gedacht hast und später seine Geheimnisse nicht Preis gibt bestimmt nicht ... Es gilt die gleiche Regel wie bei Backups - multiple Aufbewahrungsorte, diese müssen min. in unterschiedlichen Gebäuden die feuersicher, also zB vor Überspringen geschützt sind ...

Wie ich schon schrieb geht es ja nicht alleine per AppleID Passwort sondern auch noch um die Sicherheitsfragen ... zum Thema "Secure Storage" ich schicke dir gerne meinen Sicherheitskey, dann kannste mal versuchen in Besitz meines Gerätes zu kommen, da dürfte schwieriger werden ...
 
Zurück
Oben Unten