Ein absolut sehenswertes Resümee zu den Themen Datenverschlüsselung, Apple und was das FBI damit zu tun hat.
youtube/watch?v=zsjZ2r9Ygzw
Artikel zum Schlagwort: Sicherheit
Cookie 5 · Cookie-Manager lädt zum Betatest ein
Bei Cookie handelt sich um eine App, die sich in gewissen Zeitabständen, beim Schließen des Browsers oder beim Anmelden eines Nutzers unter OS X automatisch um diese kleinen, fiesen Spionageschnipsel namens Cookies kümmert.
Neben ‘normalen’ Cookies können auch Tracking Cookies, Flash Cookies, Datenbanken (u.a. Silverlight) sowie der Browser Cache, die Browser History, Favicons, Webseiten Previews oder die Download-History automatisiert gelöscht werden. An Browsern werden der Safari, Chrome, Firefox, Chromium, Opera und Camino unterstützt. Ein kleines Review zu einer älteren Version von Cookie ist hier zu finden.
Um die Entwicklung der fünften Version des Cookie-Managers voranzutreiben, lädt Russell Gray, der Entwickler der App, seit ein paar Tagen zur offenen Beta ein. Eine Anmeldung oder dergleichen ist nicht notwendig. Einfach die App herunterladen und loslegen; Bestandskunden sollten ggf. darauf achten, dass bereits vorhandene Versionen von Cookie beim Installieren der Beta überschrieben werden. Daher ist ein vorheriges Backup empfehlenswert.
Was ist neu?
Neben einer neu gestalteten Oberfläche sowie etlichen Verbesserungen unter der Haube ist Cookie nun ‘sandboxed’ und setzt OS X El Capitan zur Installation voraus. Dazu wurde die Art und Weise Cookies zu favorisieren verändert, was die vormals verwendete Blacklist überflüssig macht.
Eine genaue Auflistung der Neuerungen, noch zu implementierende Features (u.a. iCloud Sync), weiterführende Kommentare und der Downloadlink zur Beta sind im Forum des Entwicklers zu finden.
Occupy Flash
Der Flash Player ist tot. Seine Zeit ist abgelaufen. Er ist fehlerhaft. Er stürzt häufig ab. Er benötigt andauernd Sicherheitsaktualisierungen. Er funktioniert nicht auf den meisten Mobilgeräten. Er ist ein Fossil, übrig geblieben aus der Zeit geschlossener Standards und einseitiger Firmenkontrollen über Webtechnologien. Internetseiten, die auf Flash vertrauen, stellen ein vollständig inkonsistentes (und oft unbenutzbares) Erlebnis dar für den rasant wachsenden Anteil der Nutzer, die keinen Desktopbrowser verwenden. Zudem beinhaltet Flash dank der Flash Cookies einige erschreckende Mängel in den Bereichen der Sicherheit und der Privatsphäre.
Ich persönlich bin ja schon seit etlichen Jahren der Meinung, dass man seine alltäglichen Arbeiten am Rechner auch sehr gut ohne Adobes Flash Player bewältigen kann. Ich weiß gar nicht wie oft ich in der Vergangenheit Freunden und Bekannten zur Deinstallation von Flash geraten hatte… Gleiches gilt übrigens auch für Microsofts Flash-Konkurrenten Silverlight und selbstverständlich Java.
In den letzten Tagen hat Alex Stamos, seines Zeichens Sicherheitschef bei Facebook, endlich ein end-of-life-date für Flash gefordert.
It is time for Adobe to announce the end-of-life date for Flash and to ask the browsers to set killbits on the same day.
— Alex Stamos (@alexstamos) 12. Juli 2015
In die gleiche Kerbe haut Mark Schmidt, der Support Chef bei Mozilla, der gestern per Tweet angekündigt hat, dass Firefox ab sofort alle Flash-Versionen per default blockiert.
BIG NEWS!! All versions of Flash are blocked by default in Firefox as of now. https://t.co/4SjVoqKPrR #tech #infosec pic.twitter.com/VRws3L0CBW
— Mark Schmidt (@MarkSchmidty) 14. Juli 2015
Ich kann gar nicht genug wiederholen wie sehr mich Flash die letzten Jahre genervt hat; und das vermutlich auch die kommenden Jahre noch tun wird. Denn wer glaubt ernsthaft daran, dass dieses mit Scheunentor großen Löchern versehene, technisch komplett überholte Stück Software in zwei oder drei Jahren gänzlich von der Bildfläche verschwinden wird?!
Das Problem liegt hier einfach bei den Anbietern. Und ich meine hier nicht irgendwelche Browser-Spiele, die Flash zum Zocken voraussetzen. Viele Streaming-Portale wie YouTube, Vimeo, Soundcloud & Co. setzen seit Jahren auf HTML5. Selbst Netflix und Maxdome haben als bisher einzige Streaming-Dienste auf HTML5 umgestellt und damit Silverlight (zumindest etwas) den Kampf angesagt. Aber was ist mit dem Spotify Web Player, was ist mit Amazon Instant Video, Sky Go/Snap/Online, Watchever und viele andere?! All diese Dienste benötigen zum Funktionieren auf dem Desktop zwingend Adobe Flash oder Silverlight! Warum?!
Das muss endlich mal ein Ende haben und daher ist der Vorstoß von Facebook und Mozilla schon als kleiner Erfolg zu werten. Auch, dass Google mit Chrome und Microsoft mit dem Internet Explorer ihre eigenen Flash-Versionen gekapselt ausliefern, ist positiv zu sehen und allemal besser als ein systemweit installiertes Flash. Dennoch sind auch diese Versionen angreifbar und bieten keinen Schutz vor Zugriff durch Dritte.
Ich kann daher nur erneut an alle Leser appellieren sich von Flash zu verabschieden, der Occupy Flash Bewegung zu folgen und moderne Web-Technologien zu nutzen. Es macht das Internet, und ich verweise in diesem Zusammenhang gerne auf einen offenen Brief von Steve Jobs aus dem Jahre 2010, auf Dauer sicherer!
P.S. Ich musste mich beim Schreiben des Artikels übrigens sehr zusammenreißen nicht komplett im Rage-Modus zu verfallen und 1000+ Worte zu schreiben.
OS X Tipp: Tastaturkürzel in 1Password
Dass ich ein Hardcore-1Password-Nutzer bin, sollte spätestens nach meinem Artikel zum Übertragen der Einmal-Passwörter (OTA) vom Google Authenticator auf 1Password klar geworden sein.
Damals nicht angesprochen aber mindestens genauso wichtig sind meiner Meinung nach die 1Password-Shortcuts, die in den Einstellungen der App definiert werden können.
Login-Daten auf der aktuellen Webseite ausfüllen
Hier kann man natürlich mit der Maus den Weg über die 1Password-Browsererweiterung gehen. Wesentlich schneller geht es über Shortcuts; in meinem Fall Cmd + #.
Dazu ist es wichtig zu wissen: sollte 1Password nicht entsperrt sein, wird man nach dem Drücken von Cmd + # aufgefordert das Master-Passwort einzugeben. Anschließend werden die Login-Daten zur entsprechenden Webseite ohne weiteres Zutun automatisch eingefügt. Sollten mehrere Logins für eine Webseite existieren, wählt man mit den Pfeiltasten und Enter den gewünschten aus.
Sofern die Zwei-Faktor-Authentifizierung bei einer Webseiten aktiviert ist, kann daran anschließend der zweite Faktor (sofern dieser nach meinem anfänglich erwähnten HowTo überhaupt in 1Password gespeichert ist) über das Anzeigen von 1Password mini über den Shortcut Alt + Cmd + # und den Pfeiltasten, Enter und Cmd + V eingefügt werden.
Und das alles ohne auch nur einmal die Maus angefasst zu haben.
Login-Daten in eine App eingeben
Auch dieses Szenario ist gar nicht mal so selten. Ich sage nur mal das Stichwort iTunes…
Hier gibt in der Regel keine Erweiterungen aber auch hier führt der Weg über 1Password mini mit seinem Shortcut Alt + Cmd + #.
Da der Focus bei iTunes bei der Abfrage der Apple-ID schon auf dem Passwort liegt, muss man ähnlich wie bei der Eingabe des zweiten Faktors auf Webseiten vorgehen. Es gibt allerdings einen kleinen Haken.
1Passwort mini weiß im Gegensatz zur 1Password-Browsererweiterung leider nicht, zu welcher App gerade ein Login gefordert wird. Daher muss man die App zunächst über das Suchfeld suchen…
…oder ggf. über die Favoriten-Funktion von 1Password gehen.
Bei beiden Methoden liegt der Focus in 1Password mini auch direkt wieder beim Passwort, das mit Enter kopiert und Cmd + V in die App, in meinem Fall iTunes, eingefügt werden kann.
Du siehst also, dass Tastaturkürzel in 1Password durchaus eine Berechtigung haben und bei häufigem Einsatz eine ganze Menge Zeit sparen können.
[app 443987910]
Howto: Einmal-Passwörter vom Google Authenticator auf 1Password übertragen
Über den hohen Nutzen einer zweistufigen Authentifizierung bei Logins müssen wir uns hier, denke ich, nicht weiter unterhalten. Eine ständig aktualisierte Liste aller Services, die eine Zwei-Faktor-Authentifizierung (kurz: 2FA) anbieten, hatte ich auch schon mal kurz in einem Artikel vorgestellt.
Dort ist u.a. auch eine vorhandene Software-Implementierung vermerkt, um die es in diesem Artikel gehen soll.
Warum ich zu 1Password gewechselt bin?
Wie die Überschrift schon vermuten lässt, habe ich bei der 2FA lange Jahre auf den Google Authenticator gesetzt. Die App war (ist) nicht sonderlich hübsch oder funktional; erfüllte aber ihren Zweck. Später kamen Tools wie Authy hinzu, die optisch und funktional anspruchsvoller waren und zusätzlich auch eine Mac-App im Angebot hatten. Leider erwies sich diese von Authy auf Bluetooth-Kommunikation aufbauende Combo von mobiler und Desktop-App in der Praxis als zu umständlich und instabil, so dass keine wirkliche Besserung gegenüber dem Google Authenticator eintrat…
[app 388497605]
[app 494168017]
Daher war ich umso erfreuter, dass mein favorisierter Passwort-Manager 1Password genau diese Funktionalität für Einmal-Passwörter (OTP) kürzlich per Update nachlieferte, so dass man auch ohne Bluetooth sehr komfortabel damit arbeiten kann. Und das gilt sowohl für die Mac- als auch iOS-App.
Passwort und Einmal-Passwort in einer App?
Hier kann man von einem Sicherheitsrisiko sprechen, da die eigentlichen Passwörter und der zweite Faktor nicht mehr räumlich in zwei Apps getrennt sind. Ich für meinen Teil sehe hier aus zwei Gründen keinen großen Unterschied zur vorherigen Methode. Zum einen betrachte ich 1Password durch verschiedene Sicherheitsmechanismen (256-Bit AES Verschlüsselung, Touch ID oder Master-Passwort…) als sicher. Zum anderen habe ich auch sämtliche Emergency Recovery Codes, die beim Verlust des zweiten Faktors zum Einsatz kommen, in 1Password gespeichert.
Ist also jemand in dem sehr unwahrscheinlichen Fall in der Lage meinen 1Password-Tresor zu stehlen und zu entschlüsseln, hätte er durch die Recovery Codes eh Zugriff auf alle Accounts. Da ist der nun zusätzlich gespeicherte zweite Faktor nicht mehr von großer Bedeutung.
Die Antwort auf diese Frage muss aber jeder für sich selbst beantworten. Man muss die richtige Balance zwischen Sicherheit und Komfort finden. Ich kann mit diesem ‘Risiko’ leben; andere nicht.
Einmal-Passwörter in 1Passwort einrichten
Nutzer des Google Authenticator, die sich jedes Jahr ein neues iPhone kaufen, werden dieses Prozedere kennen und hassen.
Im Endeffekt muss man sich in allen Accounts, für die man eine 2FA eingerichtet hat, einmalig einloggen und in den Sicherheitseinstellungen schauen wie man den zweiten Faktor, der in der Regel über einen QR-Code abgebildet ist, auf ein neues Gerät (in diesem Fall 1Password) übertragen kann. Das Ganze ist leider bei jedem Dienst unterschiedlich. Bei Google kann man beispielsweise den zweiten Faktor ganz bequem auf Klick auf ein neues Gerät umziehen, bei Dropbox oder Buffer muss man die Autorisierungsmethode ändern, bei GitHub, Hootsuite, Facebook oder Evernote muss man den Code Generator neu einstellen u.s.w…
In 1Password gestaltet sich die Sache weitaus weniger aufwendig. Als Voraussetzung muss man mindestens Version 5.3 auf seinem Mac (wurde letzte Woche veröffentlicht) bzw. 5.2 unter iOS (erschien im Januar 2015; aktuell ist ebenfalls 5.3) installiert haben.
In einem ersten Schritt muss man ein neues Merkmal, ich habe es 2FA genannt, erstellen und rechts über das Auswahlmenü Einmal-Passwort auswählen.
Anschließend wird ein kleines QR-Code-Symbol angezeigt, dass auf Klick einen Barcode Scanner zum Vorschein bringt.
Diesen Barcode Scanner, der immer im Vordergrund angezeigt wird, bewegt man über den zur Generation des zweiten Faktors benötigen QR Code auf der jeweiligen Webseite.
Jetzt muss man den aus dem QR Code generieten Link nur noch speichern und bekommt augenblicklich den zeitgesteuerten zweiten Faktor in 1Password angezeigt.
Durch die Synchronisation von 1Password über WLAN, die iCloud oder Dropbox muss man diese Einrichtung auch nur einmalig vornehmen und bekommt die Einmal Passwörter auf dem Mac, iPhone und iPad gleichermaßen angezeigt. Da stört es auch wenig, wenn ich alle zwei Wochen einen neuen Mac oder neues iPhone habe. Die Daten sind vorhanden und können auf einfachste Weise, ohne Generation neuer QR Codes für den zweiten Faktor, abgeglichen werden.
Logge ich mich nun wie hier bei GitHub über die 1Password-Erweiterung des Browser ein, muss ich nicht mehr mein iPhone aus der Hosentasche holen und entsperren, die Google Authenticator App suchen und starten, den richtigen Dienst in der Liste suchen, mir das Einmal Passwort merken bzw. abtippen… ich kann nun endlich direkt aus der 1P-Erweiterung den zweiten Faktor kopieren und per Cmd-V ohne großen Zeitverlust eingeben. Tolle Sache!!!
Wenn du 1Password für den Mac nicht besitzt, kann die Erstellung des Einmalpasswortes auch mobil auf dem iPhone oder iPad erfolgen.
Die Einrichtung ist mit der auf dem Mac vergleichbar. Der Vorteil liegt auch hier auf der Hand: man kann über die 1Password-Erweiterung des mobilen Safaris ohne großen Zeitverlust auf den zweiten Faktor zugreifen.
Abschließend noch ein Tipp: bevor man jetzt den Google Authenticator oder Authy von seinem iPhone löscht, sollte man sicherstellen, dass man auch wirklich alle darin aufgeführten Dienste in 1Password übernommen hat. Andernfalls steht man unter Umständen vor einem Problem und kann sich ohne Recovery Codes nicht mehr in seine Accounts einloggen.
[app 443987910]
[app 568903335]
Video: Setting Up One-Time Passwords in 1Password for Mac
youtube/watch?v=eZyb-ArMK9g
(inspired by)
Howto: E-Mail-Verschlüsselung und -Signierung mit S/MIME und OpenPGP (bei Apple Mail) einrichten
Wenn es um die Verschlüsselung oder Signierung von E-Mails geht, und da darf sich jeder mal selbst an die Nase packen, ist der Durchschnittsinternetnutzer doch eher zurückhaltend. Dem einen ist es zu kompliziert, dem anderen zu aufwendig und wieder andere sehen den Inhalt ihrer E-Mails nicht als schützenswert an.
Nun, die ersten beiden Argumente lassen sich relativ schnell entkräften. Das letzte lasse ich einfach mal unkommentiert im Raum stehen… ;)
Generell muss man sich beim Verschlüsseln und Signieren von E-Mails zwischen zwei Protokollen entscheiden: S/MIME und OpenPGP, die beide nicht miteinander kompatibel sind und auch ‘nur’ den Inhalt der E-Mail verschlüsseln. Die Metadaten, wie Absender, Empfänger und Betreff, bleiben unverschlüsselt.
Ich möchte jetzt gar nicht groß ins technische Detail gehen oder den Glaubenskrieg fortführen, der zwischen den Nutzern dieser Protokolle herrscht. Ich möchte vielmehr die praktische Seite von S/MIME und OpenPGP beleuchten und kurz zeigen wie einfach man sie unter OS X oder iOS einrichten kann.
S/MIME vs OpenPGP
Nüchtern betrachtet gibt es vom Standpunkt der Sicherheit keinen Favoriten. Beide Protokolle entsprechen aktuellen Sicherheitsanforderungen; unterscheiden sich aber in grundlegenden Dingen, die in der Praxis durchaus von Bedeutung sind.
S/MIME benötigt beispielsweise keine große Einrichtung und lässt sich out-of-the-box sowohl am Mac, als auch unter iOS nutzen. OpenPGP erfordert dahingegen unter OS X etwas Handarbeit und hat die Einschränkung, dass es von Apples mobiler Mail.app unter iOS leider nicht unterstützt wird.
Der wichtigste Unterschied zwischen den beiden Protokollen liegt aber im Verfahren zur Authentifizierung. Während S/MIME über ein hierarchisches System mit einen Zertifikat die Echtheit garantiert, nutzt OpenPGP mit dem so genannten Web of Trust einen anarchischen Ansatz.
S/MIME-Zertifikat
Für die Verschlüsselung von E-Mails mit S/MIME sind die schon angesprochenen Zertifikate der wichtigste Bestandteil. Diese gibt es in verschiedenen Sicherheitsstufen, die alle unterschiedliche Ausprägungen bei der Validierung von Daten haben und unterschiedlich kosten. Für den Privat-Anwender sind diese Sicherheitsstufen in der Regel aber uninteressant, so dass man auch mit kostenlosen Zertifikaten, die meistens ein Jahr lang gültig sind, seine E-Mails verschlüsseln und signieren kann.
Fragt man DuckDuckGo, Google oder Bing nach kostenlosen E-Mail Zertifikaten, werden einem eine Reihe Anbieter wie Comodo oder StartSSL angezeigt.
Wichtig, neben dem Namen und der E-Mail Adresse, für die das Zertifikat beantragt werden soll, ist die Schlüssellänge (bei Comodo, wie im Screenshot zu sehen, 2048 Bit) und das Revoke-Passwort, mit dem das Zertifikat im Fall der Fälle als ungültig erklärt werden kann.
Ist dieses Online-Formular ausgefüllt, erhält man nach dem Absenden eine Bestätigungsemail, mit der man das Zertifikat herunterladen kann.
Je nach Konfiguration landet das Zertifikat, das in meinem Fall den Dateinamen CollectCCC.p7s hat, im Downloadordner des Macs.
Startet man diese Datei per Doppelklick öffnet sich die OS X Schlüsselbundverwaltung, in die man das Zertifikat nur hinzufügen muss.
Anschließend startet man die Mail.app neu, die das Zertifikat automatisch erkennt und ab sofort E-Mails verschlüsselt und signiert versenden kann.
Dazu gibt es bei Mail beim Schreiben einer neuen E-Mail zwei neue Schaltflächen. Zum einen ein Schloss, welches die Verschlüsselung der E-Mail aktiviert. Zum anderen einen Haken, der die E-Mail signiert. Der Haken ist per Default immer aktiviert. Es wird also jede E-Mail signiert versendet. Das Schloss kann dahingegen nur angeklickt werden, wenn der Adressat ebenfalls ein gültiges S/MIME Zertifikat besitzt.
Oben rechts sieht man zudem, sofern man OpenPGP schon nutzt, eine blaue S/MIME Schaltfläche. Setzt man einzig und alleine auf S/MIME, ist diese Schaltfläche nicht zu sehen.
Besonderheit iOS
Das iOS mit dem vom Comodo zugesendeten Zertifikat im *.p7s Format nichts anfangen kann, muss man es zunächst in ein für iOS lesbares Format umwandeln.
Dazu nutzt man die OS X Schlüsselbundverwaltung, in der man per Rechtsklick das entsprechende Zertifikat, mit einem Passwort geschützt, ins *.p12 Format konvertieren kann.
Nachdem man das Zertifikat per E-Mail o.ä. aufs iPhone, iPad oder den iPod touch übertragen und installiert hat, muss man S/MIME in den Einstellungen > Mail, Kontakte, Kalender > E-Mail Account > Account > Erweitert aktivieren und findet in der mobilen Mail.app nun ähnliche Schaltflächen wie schon unter OS X.
OpenPGP-Schlüsselpaar
Wie schon erwähnt, wird dieses Protokoll im Gegensatz zu S/MIME nicht von iOS unterstützt. Daher ist die folgende Anleitung auch ausschließlich für OS X ausgelegt.
Zunächst muss man sich die GPG Suite, deren Source Code auch bei Github zu finden ist, herunterladen und installieren. Für OS X Yosemite wurde erst kürzlich eine kostenlose Beta veröffentlicht. Das Ganze wird aber, wie die Entwickler schon Mitte Oktober 2014 angekündigt haben, in der finalen Version nicht kostenlos bleiben. Wie hoch die small fee für das Mail Plugin GPGMail, welches Bestandteil der GPG Suite ist, ausfallen wird, bleibt abzuwarten aber alleine vom Sicherheitsgedanken sollte man darüber nicht groß nachdenken.
Nach der Installation findet man das Plugin GPGMail, welches schlussendlich für das Verschlüsseln und Signieren von E-Mails verantwortlich ist, in den Mail Einstellungen.
Da (Open)PGP keine Zertifikate braucht, sondern die benötigten Schlüssel dezentral über einen öffentlichen Schlüsselserver verwaltet, gestaltet sich die weitere Einrichtung wesentlich einfacher als bei S/MIME.
Mit der Installation der GPG Suite hat sich neben dem Mail Plugin u.a. auch eine App namens GPG Keychain ins OS X Programme-Verzeichnis installiert. Neben dem Erstellen neuer bzw. Widerrufen vorhandener Schlüsselpaare für die eigenen E-Mail Adressen, werden hier auch die öffentlichen Schlüssel von Adressaten verwaltet.
Wichtig beim Erstellen ist der Haken bei Upload public key, der den eigenen öffentlichen Schlüssel auf den Schlüsselserver hoch lädt. Andernfalls ist es Adressaten, die ebenfalls (Open)PGP nutzen, nicht möglich verschlüsselte E-Mails zu schreiben, die mit dem privaten Schlüssel, der auf dem eigenen Rechner liegt, entschlüsselt werden.
Das Fenster zum Schreiben neuer Mails hat in der Mail.app nun auch wieder die beiden zusätzlichen Schaltflächen zum Verschlüsseln und Signieren von E-Mails. Bei installiertem S/MIME gibt es darüber hinaus oben rechts eine grüne OpenPGP Schaltfläche, die zwischen den Protokollen umschalten kann.
FAZIT
Ich hoffe, dass einigermaßen klar wird, dass das Verschlüsseln und Signieren von E-Mails kein Hexenwerk ist, für das man kryptische Informatik studiert haben muss.
Es empfiehlt sich außerdem S/MIME und OpenPGP parallel installiert zu haben. Zum einen sind, wie schon erwähnt, beide Protokolle zueinander nicht kompatibel. Zum anderen hat sich bisher auch kein Favorit herauskristallisiert, so dass momentan jeder das nutzt, was er für richtig hält.
Die Anleitung kann im Übrigen natürlich auch auf andere OS X Mail-Clients wie MailMate (siehe Screenshot) oder auch Airmail 2 angewendet werden.
Für einen tieferen technischen Hintergrund um S/MIME und OpenPGP empfehle ich einen Artikel von Christian Kirsch.
Touch ID und die trügerische Sicherheit
Apples Touch ID ist zum Anmelden bei Apps ist eine sehr komfortable Geschichte. Es vergeht seit der Veröffentlichung von iOS 8, mit dem Touch ID für 3rd Party Apps verfügbar wurde, kaum eine Woche, in der nicht irgendein anderer Entwickler mit der Integration dieses Features in seiner App hausieren geht.
Doch wie sieht es mit der Sicherheit von Touch ID, fernab der hinlänglich bekannten Sicherheitsprobleme, die bei der Verwendung eines Fingerabdrucks entstehen, aus?!
Andreas Kurtz beschäftigt sich in seinem Blogeintrag ausgiebig mit diesem Thema und zeigt am Beispiel der Dropbox App welch trügerische Sicherheit Apple mit dem Local Authentication Framework, einer API, die Apple zur Verwendung von Touch ID den Entwicklern zur Verfügung stellt, dem Nutzer vorgaukelt.
Since I first heard about this new framework, I have questioned its usefulness. Ultimately, Local Authentication becomes only important when an unlocked device falls into the wrong hands. Than Local Authentication is designed to ensure that, when an app is launched, an additional login screen is displayed to prevent access to the app’s contents. However, in this very moment it is still possible, e.g., to directly access all app data via the USB interface (for example, by creating a backup). After all, the device is already unlocked (otherwise you wouldn’t need Local Authentication).
Ähnliche Sicherheitsbedenken hat auch die Subsembly GmbH aus München, die erst letzte Woche Touch ID in ihre großartige Online-Banking App Banking 4i integriert hatte. Wie auf der Facebook-Seite des Entwicklers zu lesen, ist man mit Apples Umsetzung des Local Authentication Frameworks unzufrieden, hat aber dennoch über einen sogenannten Zweitschlüssel einen Weg gefunden, der das eigentliche Passwort zum Entsperren der App nicht lokal auf dem iPhone oder iPad speichert.
Die übliche, von Apple empfohlene Vorgehensweise für die Implementierung von Touch ID sieht vor, dass das mit Touch ID zu schützende Passwort einfach im Schlüsselbund auf dem Gerät gespeichert wird. Unser Grundprinzip, das Passwort niemals irgendwo in irgendeiner Weise zu speichern wäre damit gebrochen. Nun kann man argumentieren, dass der Schlüsselbund in iOS sehr sicher ist, und die Speicherung des Passworts im Schlüsselbund deshalb kein Risiko darstellt. Ich glaube das nicht. So kann zum Beispiel ein “trojanisches Pferd” auf einem iPhone mit Jail-Break den Schlüsselbund einfach auslesen.
-> iOS 8 Touch ID Authentication API
-> Touch ID in Banking 4i