Mobil – RRZK – Regionales Rechenzentrum

Das sichere Aufbewahren von Passwörtern – Einrichtung und Nutzung von KeePassXC

Vorwort

Bitte beachten Sie, dass das RRZK bzw. der RRZK-Helpdesk zur Aufbewahrung von Passwörtern mit KeePassXC keinen Support leisten kann. Die Verwendung von KeePassXC stellt keine Nutzungsempfehlung des RRZK dar, sondern die folgenden Ausführungen sind lediglich als persönlicher Erfahrungsbericht zu verstehen.

Warum ein Passwortmanager?

Durch immer neue Arten von Trojanern, Sicherheitslecks und Datendiebstahl wird die Bedeutung von Passwörtern und der Umgang damit immer wichtiger. Schaut man sich die beliebtesten Passwörter des Jahres 2018[1] an, so wird verständlich, wieso auch ohne tiefgreifendes IT-Knowhow ein Account durch Raten und Ausprobieren vergleichsweise einfach zu „hacken“ ist.

Dabei geht es nicht nur um die Einfachheit und Beliebtheit eines Passworts, sondern auch um dessen gleichzeitige Verwendung für mehrere Dienste: Mit einer E-Mail-Adresse/einem bekannten Benutzernamen und einem erratenen oder gehackten Passwort gelangen Kriminelle so bspw. nicht nur an ein E-Mailpostfach, sondern ebenfalls an die Anmeldedaten für Netflix, das Online-Banking und das Online-Portal der Krankenkasse. Die mittlerweile allseits bekannte Schlussfolgerung ist naheliegend: Für jeden Dienst sollte ein unterschiedliches und darüber hinaus ausreichend sicheres Passwort gewählt werden. Dies ist auch die offizielle Empfehlung des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Seine bisherige Empfehlung Passwörter regelmäßig zu ändern, hat das BSI inzwischen zurückgenommen.

In Zeiten, in denen viele Menschen dutzende verschiedene Dienste im Internet benutzen, wird es jedoch immer schwieriger, sich alle Zugangsdaten zu merken bzw. diese verlässlich zu speichern. Das Anlegen einer Liste mit Passwörtern in einem Word- oder Exceldokument eignet sich aufgrund der fehlenden bzw. unzureichenden Verschlüsselungsmöglichkeiten ebenso nicht wie bei allen anderen Methoden, bei denen der Zugriff nicht ausreichend geschützt werden kann. Ein klassisches Notizbuch mit handschriftlich notierten Passwörtern scheidet ebenfalls aus, denn bei Verlust sind nicht nur alle Zugangsdaten weg, sondern können unter Umständen sogar in fremde Hände gelangen.

Es bietet sich daher an, einen der zahlreichen Passwortmanager zu verwenden, die es mittlerweile gibt. Ein Passwortmanager ist ein Programm bzw. eine Datenbank, in der die Zugangsdaten für unendlich viele Dienste verschlüsselt und damit sicher gespeichert werden können. In der Grundfunktion wird diese Datenbank mit einem Master-Passwort gesichert, welches im Anschluss das einzige ist, das sich die Nutzer*innen für den Zugang zur Passwortdatenbank merken bzw. aufbewahren müssen. Falls dieses Passwort jemals vergessen sollte, ist der Zugang auf die Datenbank unwiederbringlich verloren und der Zugriff auf die gespeicherten Zugangsdaten somit für immer verschlossen. Es bietet sich daher an, das Passwort einem sicheren Ort, z.B. einem Safe oder einem Bankschließfach, aufzubewahren.

In diesem Artikel soll das Programm „KeePassXC“ vorgestellt werden. Bei zahlreichen unabhängigen Tests zählte es bislang zu den am besten bewerteten Passwortmanagern und ist darüber hinaus als Open-Source-Software kostenlos. Zudem ist es für die gängigsten Betriebssysteme (Windows, Linux und macOS; für Android und iOS gibt kompatible Programme) verfügbar.

Bitte lassen Sie nicht verwirren lassen: Unter dem Namen KeePass gibt es mittlerweile zahlreiche unterschiedliche Versionen, so zum Beispiel KeePassX oder KeePass2. Die hier vorgestellte Version KeePassXC[2] ist im Gegensatz zu den anderen Versionen unter Windows, Linux und macOS nutzbar und hat viele sinnvolle und bereits integrierte Features, welche in den anderen Versionen händisch nachinstalliert werden müssen.

Speicherort der Datenbank

Wie schon erläutert werden die Zugangsdaten im Passwortmanager in einer verschlüsselten Datenbank gespeichert. Wählen Sie als Speicherort für diese Datenbank die lokale Festplatte, bietet dies zunächst keinen größeren Mehrwert. Denn sobald Sie den Computer nicht bei sich haben, können Sie unterwegs auch nicht auf die Zugangsdaten zugreifen. Auch wenn Sie die Passwortdatenbank auf ihrem Handy mit sich tragen würden, könnte sie bei Verlust des Handys verloren gehen. Es bietet sich daher an, die Passwort-Datenbank in einer Cloud abzuspeichern. Somit können Sie nicht nur von überall auf Ihre Passwörter zugreifen, Sie müssen sich auch keine Gedanken über ein Backup Ihrer Passwort-Datenbank machen. Als Angehörige/r der Universität zu Köln können Sie hierzu sciebo[3] verwenden. Im Gegensatz zu den anderen gängigen Cloud-Diensten wie bspw. iCloud, OneDrive, Dropbox befinden sich Ihre Daten auf einem von der WWU Münster verwalteten und DGSVO-konformen Server in NRW.

Einrichtung von KeePassXC

Im Folgenden wird die Einrichtung von KeePassXC und sciebo beschrieben. Die Anleitung[4] orientiert sich dabei an der Windows-Version, gilt aber ebenso mit minimalen Abweichungen für Linux und MacOS.

Installieren Sie zunächst den sciebo-Client[5] und richten diesen mit Ihrem sciebo-Account ein.
Laden Sie KeePassXC von der Internetseite[6] für Ihr jeweiliges Betriebssystem herunter und installieren Sie es anschließend (mit den Standardvoreinstellungen). Alternativ ist auch die Nutzung einer Portable-Version möglich, welche Sie nicht installieren müssen.
Klicken Sie nun auf „Neue Datenbank erstellen“ (oder alternativ im Menü unter „Datenbank“ auf „Neue Datenbank“).
Vergeben Sie nun einen Namen für Ihre Passwort-Datenbank („Datenbankname“). Optional können Sie noch eine Beschreibung hinzufügen.
Lassen Sie bei den „Verschlüsselungseinstellungen“ die Werte unverändert und klicken auf „weiter“.
Vergeben Sie nun bei „Datenbank-Anmeldedaten“ ein neues Master-Passwort, welches besonders sicher sein sollte. Verwenden Sie eine hinreichende Anzahl der Zeichen, Groß- und Kleinschreibung sowie Ziffern und Sonderzeichen. Folgen Sie hierfür bspw. den Hinweisen des Bundesamtes für Sicherheit in der Informationstechnik BSI https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/passwoerter_node.html.
Wie bereits erwähnt: Wenn Sie das Master-Passwort jemals vergessen sollten, ist der Zugriff auf Ihre Passwörter unwiederbringlich verloren!

Durch Klick auf das Würfel-Symbol erhalten Sie alternativ auch die Möglichkeit, sich ein sicheres Passwort per Zufall generieren zu lassen.

Sollten Sie einen Yubikey[7] besitzen, haben Sie sogar die Möglichkeit, ein sehr langes, mit vielen Sonderzeichen versehenes und „nicht sprechendes“ Passwort nicht händisch eingeben zu müssen, sondern dies per Knopfdruck den Yubikey erledigen lassen (folgen Sie hierfür der Anleitung „Static Password Mode“[8]).

Über „Zusätzlichen Schutz hinzufügen“ können Sie die Datenbank zusätzlich zum Passwort noch durch weitere Sicherheitsmechanismen schützen, siehe Exkurs „zusätzlicher Schutz“.
Nach Klick auf „Fertig“ ist Ihre Datenbank erstellt und Sie müssen diese noch abspeichern. Wählen Sie als Dateispeicherort nun einen Ordner aus, der von sciebo synchronisiert wird. Damit wird Ihre Datenbank auf allen Endgeräten sowie auf dem sciebo-Server auf dem aktuellen Stand gehalten.[9]
Nun können Sie die Datenbank mit Einträgen befüllen und Ihre Zugangsdaten eintragen. Durch das Anlegen von „Gruppen“ können Sie diese thematisch gliedern.

Sobald Ihre Datenbankdatei per sciebo synchronisiert wurde, können Sie auf diese auch von anderen Computern/Endgeräten zugreifen. Für Windows, MacOS und Linux gilt: Installieren Sie hierzu jeweils zunächst den sciebo-Client sowie KeePassXC.

Exkurs: „zusätzlicher Schutz“

Es ist festzuhalten, dass Sie den Zugang zu Ihren Passwörtern bislang zweifach gesichert haben: mit den Zugangsdaten zu sciebo sowie durch das Datenbank-Master-Passwort. Falls Sie also in KeePassXC die Datenbank noch zusätzlich mit einem Sicherheitsmechanismus versehen, erhöht sich die Zahl der Schranken auf drei (oder gar vier). Ob Sie die Passwortdatenbank zusätzlich–schützen sollten, hängt von Ihrem eigenen Schutzbedürfnis ab, ggf. auch von den zu speichernden Zugangsdaten in Ihrer Datenbank. Sie haben hierzu verschiedene Alternativen, die Nutzung einer Schlüsseldatei oder eines Yubikeys.

Durch das Generieren einer „Schlüsseldatei“ erhalten Sie eine Datei, welche fortwährend zusätzlich zur Eingabe eines Passworts für das Öffnen der Datenbank erforderlich ist. Beim Erstellen der Datei wird ein Zahlencode erzeugt, der ein Unikat darstellt bzw. nahezu unmöglich zu erraten ist. Stellen Sie sich die Schlüsseldatei einfach wie eine Schlüsselkarte vor, wie sie bspw. zum Öffnen der Zimmertür in Hotels heutzutage üblich ist. Immer wenn Sie das Passwort zum Öffnen der Datenbank eingeben, müssen Sie parallel auch die Schlüsseldatei vorzeigen. Dementsprechend müssen Sie diese immerzu „mit dabei haben“, falls Sie die Datenbank unterwegs öffnen möchten.

Damit stellt sich die Frage, wo die Schlüsseldatei aufbewahrt werden kann:

Falls Sie ausschließlich Desktop-Computer oder Laptops verwenden, bietet es sich an, die Datei auf einen USB-Stick zu speichern, den Sie immer mit sich herumtragen (bspw. am Schlüsselbund, im Geldbeutel). Die Schlüsseldatei befindet sich somit nie dauerhaft auf einem der Computer selbst. Auf mobilen Endgeräten kann der USB-Stick jedoch nicht verwendet werden.
Sie können die Schlüsseldatei auch direkt auf die entsprechenden Endgeräte kopieren. Sie ist dann aber einer potentiellen Gefahr ausgesetzt, wenn sich jemand Zugriff auf das mobile Endgerät verschafft. Durch Verschlüsselung des Datenträgers sowie durch das Einrichten eines Zugriffsschutz in Form eines Passworts (Windows, MacOS, Linux), einer PIN oder eines Fingerabdrucks usw. (Android, iOS) kann dieses Risiko wiederum minimiert werden.

Falls jemand Unerwünschtes in Besitz der Schlüsseldatei kommen sollte, sei bemerkt, dass diese ohne das Passwort und ohne Zugriff auf die Datenbank (die Cloud) wertlos ist. Wie beim Passwort gilt, dass die Schlüsseldatei bei Verlust nicht wiederhergestellt werden kann; der Zugriff auf die Datenbank wäre – auch mit dem richtigen Passwort – unwiderruflich verloren. Es bietet sich daher erneut an, die Schlüsseldatei bspw. auf einem (zweiten) USB-Stick zu Hause sicher zu verwahren.
Um eine Schlüsseldatei zu verwenden und zu erstellen, folgen Sie der obigen Anleitung unter Punkt 7 und klicken dort auf „Schlüsseldatei hinzufügen“. Wählen Sie dabei mit „Durchsuchen“ den Pfad aus, unter der die Schlüsseldatei nach dem Erstellen abgelegt werden soll und von wo Sie diesen

Mit Hilfe eines „Yubikeys“ können Sie Ihre Datenbank zusätzlich zu einem Passwort (und zu einer Schlüsseldatei) per sog. „challenge response“ absichern. Eine Anleitung findet sich hier[10]. Ähnlich wie bei einer Schlüsseldatei müssen Sie diesen immer dabeihaben, um Ihre Datenbank zu öffnen. Dieser Sicherungsmechanismus ist nur fortgeschrittenen Userinnen und Usern empfohlen. Zudem ist im Einzelfall zu prüfen, wie der Yubikey unter Android und iOS zum Einsatz kommen kann.

Nutzung unter iOS und Android

Für iOS und Android gibt es keine KeePassXC-Version; hier ist auf andere Apps zurückzugreifen: für iOS die App „Strongbox“[11] (erhältlich im AppStore), für Android die App „Keepass2Android“[12] (zu beziehen über den PlayStore). Da die Benutzung dieser Apps sich betriebssystembedingt etwas von den Desktop-Versionen unterscheidet, soll hier kurz auf diese eingegangen werden.

iOS

Installieren Sie die Apps „Strongbox“ sowie „sciebo“ und richten Sie letzteres ein. Öffnen Sie die App „Strongbox“ und klicken rechts oben auf das Plus-Symbol. Wählen Sie dort „Vorhandene hinzufügen…“. In der angezeigten Liste klicken Sie auf „WebDAV“. Geben Sie bei Verzeichnis die URL „https://uni-koeln.sciebo.de/remote.php/webdav“, bei „Benutzername“ Ihren sciebo-Benutzernamen (Achtung: Vergessen Sie nicht den Zusatz „@uni-koeln.de“ nach Ihrem Personal-Accountnamen!) sowie Ihr dazugehöriges Passwort ein. Wählen Sie im Anschluss den Pfad zu Ihrer Datenbank-Datei (die Datei hat die Endung „.kdbx“). Sie können nun den Namen der zu öffnenden Datenbank verändern oder per „Hinzufügen“ bestätigen. Klicken Sie nun auf den neu erstellten Eintrag in der Datenbankliste. Dort müssen Sie das Passwort Ihrer Datenbank eingeben und ggf. die Schlüsseldatei „Auswählen“.

Android

Installieren Sie die Apps „Keepass2Android“ und „sciebo“. Öffnen Sie diese und wählen „Datei öffnen“ sowie anschließend „ownCloud“. Geben Sie bei im obersten Feld („ownCloud-URL“) „uni-koeln.sciebo.de“, bei „Benutzername“ Ihren sciebo-Benutzernamen (Achtung: Vergessen Sie nicht den Zusatz „@uni-koeln.de“ nach Ihrem Personal-Accountnamen!) sowie Ihr dazugehöriges Passwort ein. Wählen Sie im Anschluss den Pfad zu Ihrer Datenbank-Datei (die Datei hat die Endung „.kdbx“). Im folgenden Fenster müssen Sie nun den Schutz der Datenbank auswählen: Wählen Sie bspw. „Nur Kennwort“ oder „Kennwort + Schlüsseldatei“. Geben Sie nun Ihr (Master-)Kennwort Ihrer Datenbank ein und wählen ganz unten „Entsperren“.

[1] https://hpi.de/pressemitteilungen/2018/die-top-ten-deutscher-passwoerter.html

[2] https://keepassxc.org/

[3] https://www.sciebo.de

[4] Eine sehr ausführliche Anleitung, in der alle Funktionen und Details beschrieben werden, finden Sie unter https://keepassxc.org/docs/KeePassXC_GettingStarted.html#_welcome.

[5] https://hochschulcloud.nrw/de/download/index.html

[6] https://keepassxc.org/download/

[7] Ein Yubikey ist Security-Token mit vielen verschiedenen Funktionen in Hardwareform, der wie ein kleiner USB-Stick aussieht und bspw. am Schlüsselbund oder im Geldbeutel mit sich geführt werden kann, siehe https://www.yubico.com/der-yubikey/?lang=de.

[8] https://keepass.info/help/kb/yubikey.html

[9] Alternativ ist es auch möglich, sciebo per WebDAV-Protokoll als Laufwerk im Windows-Explorer zu verbinden. Die hierfür zu verwendende URL lautet: https://uni-koeln.sciebo.de/remote.php/webdav/.

[10] https://keepassxc.org/docs/#faq-yubikey-howto

[11] https://apps.apple.com/us/app/strongbox-password-safe/id897283731

[12] https://play.google.com/store/apps/details?id=keepass2android.keepass2android

Auch Apple kann kompliziert: Mails signieren und verschlüsseln mit iPhone und iPad

Auf die Gefahr hin, dass die letzten Beiträge unseres Blogs ein klein wenig Apple-lastig werden, folgt auf den letzten Beitrag ein weiterer über iGeräte, genauer: Über verschlüsselte E-Mails, und warum die Sache mit der Usability nicht immer so einfach ist, wie man das als User*in gerne hätte.

Haben Sie, liebe Blog-Lesende, schon einmal eine E-Mail verschlüsselt? Nein? Dann gehören Sie wahrscheinlich zur großen Mehrheit von IT-Nutzenden, die das Thema zwar „schon einmal irgendwo gehört oder gelesen“ haben, aber sich selbst noch nie damit befasst haben.

Zumindest könnten Sie einmal darüber nachdenken, Ihre E-Mails mit Hilfe eines S/MIME-Zertifikats zu signieren, was gleichzusetzen ist mit einer Unterschrift. Wie Sie an der Uni Köln ein solches Zertifikat beantragen und wofür das gut ist, können Sie hier nachlesen.

Wie man sein Zertifikat dann auf verschiedenen Geräten einrichtet und nutzt, haben wir an dieser Stelle dokumentiert. Einmal eingerichtet, ist das Ganze sofort lauffähig, und Ihre Mails werden fast unmerklich digital signiert. In diesem Beitrag legen wir den Fokus auf mobile Apple-Geräte. iOS unterstützt S/MIME-Zertifikate und die E-Mail-Verschlüsselung schon seit dem Jahr 2015 – so neu ist das Thema zugegebenermaßen also nicht.

Bildschirmabbild, das das Fenster zum Erstellen einer neuen E-Mail zeigt

Verschlüsselte oder signierte E-Mails zu empfangen ist kinderleicht. Neben dem Absende-Namen taucht bei einer signierten und/oder verschlüsselten E-Mail ein kleines Häkchen und gegebenenfalls ein Schlosssymbol auf.

Jetzt kommt der Teil, der komplizierter ist, als es sein müsste: Spannend wird es, wenn man seine Mails neben dem Signieren auch verschlüsseln möchte. Dazu schweigt sich interessanterweise sogar die Anleitung von Apple selbst aus. Das führt dann dazu, dass man zunächst einmal eine Fehlermeldung erhält, wenn man es mit dem Verschlüsseln versucht (siehe Bild). Wo hakt’s? Die Anleitung von Apple sagt, dass in diesem Fall das Zertifikat der Empfänger*in nicht gefunden wurde. Aber kein Wort darüber, was man nun tun soll, damit das iGerät diesen öffentlichen Schlüssel der anderen Person kennenlernen kann…?

Spoiler: Dazu muss man das Zertifikat tatsächlich „installieren“, sagt die Oberfläche, wenn man ein bisschen danach sucht.

Hat man diese Schritte einmal gefunden, ist es ganz einfach:

1.) Eine E-Mail der Person öffnen,
2.) in der Kopfzeile auf den Namen klicken,
3.) gegebenenfalls nochmals auf den Namen klicken, dann
4.) auf „Zertifikat anzeigen“, und zum Schluss
5.) auf „Installieren“ klicken.

Diese Schritte muss man für jede Person vornehmen, der man verschlüsselte E-Mails senden will.

Zusammenfassend kann man sagen: Wenn man einmal weiß, was man tun muss, ist es gar nicht so kompliziert. Aber warum gestaltet man – beziehungsweise Apple – diesen Vorgang so umständlich? Einfacher wäre es wie beim Open-Source-Mail-Programm Mozilla Thunderbird: Hier wird der öffentliche Schlüssel der Absender*in – also der Teil des Zertifikats, der dem iOS-System wie oben genannt zunächst „bekannt gemacht“ werden muss – direkt automatisch gespeichert.

Kurzes Fazit: Weniger ist mehr. Ich würde mir wünschen, dass Apple dieses Prozedere vielleicht etwas einfacher gestaltet und zukünftig weniger Arbeitsschritte nötig sind. Das würde zur Akzeptanz von E-Mail-Zertifikaten und deren Einsatz sicher enorm beitragen.

Wie die iOS-App „Kurzbefehle“ den Alltag erleichtern kann

Die Anwendung, die ich heute vorstellen möchte, ist ein wirklich mächtiger Helfer, der an das Mac Programm „Automator“ angelehnt ist. Mit diesem lassen sich lästige Aufgaben zu Routinen zusammenfassen und mit einem einzigen Klick ausführen. Eine abgewandelte Form gibt es seit iOS 12 auch auf iPhone und iPad.
Die App gehört nicht zu den standardmäßig vorinstallierten Apps und muss erst aus dem App Store geladen werden. Aber dafür ist sie Apple-typisch natürlich kostenlos. Öffnet man die App zum ersten Mal ist die Oberfläche ein wenig gewöhnungsbedürftig und es wird schnell klar, dass sich die Anwendung eher an Erfahrene richtet. Möglicherweise ist es hilfreich erst einmal in der Galerie zu stöbern und ein paar der Tools dort unter die Lupe zu nehmen. Der Trinkgeldrechner zum Beispiel ist sehr praktisch oder auch der Wäschetimer, der eine Erinnerung sendet, wenn die Waschmaschine fertig ist. Das erspart zum einen das Warten in der ungemütlichen Waschküche, bis nach 10 Minuten endlich die letzte Minute des Waschgangs abgeschlossen ist und zum anderen vergisst man die Wäsche nicht, wenn man unterwegs ist.
Wenn man sich einmal in die App reingedacht hat, ist das Erstellen eigener Routinen aber gar nicht so schwer. Als Beispiel habe ich eine Morgenroutine erstellt, weil mir aufgefallen ist, dass ich jeden Morgen die gleichen Apps brauche. Über das Plus in der Bibliothek lege ich also nun eine neue Routine an. Vom Grundprinzip her lege ich in der Mitte alle Aktionen ab, die ablaufen sollen. Das iPhone spielt diese dann eine nach der anderen ab. Eigentlich ein simples Prinzip.
Zunächst möchte ich also, dass mein iPhone morgens das WLAN einschaltet. Über die Suche gebe ich deshalb einfach „WLAN“ ein und es erscheint die Aktion „WLAN konfigurieren“ – genau das will ich. Es erscheint die Aktion, daneben befindet sich ein Kippschalter, der auf grün steht. Das WLAN wird also eingeschaltet. Als nächstes möchte ich das Wetter angezeigt bekommen. Ich tippe also in die Suche „Wetter“ ein und schon erscheint die Aktion „Wetter am aktuellen Standort anzeigen“. Perfekt.

Und nun meine E-Mails! Damit ich genug Zeit habe mir zu überlegen, was ich heute anziehe, bevor sich die E-Mail-App öffnet, füge ich die Aktion „Warten“ hinzu. Fünf Sekunden sollten genügen, im Zweifelsfalle lässt sich die Routine nachher jederzeit anpassen und die Zeit hoch oder runter setzen. Nun also zu den E-Mails. Dazu müssen wir einen kleinen Umweg gehen, und zwar über die Aktion „App öffnen“. Nachdem die Aktion unter den anderen erscheint, wählt man dann die E-Mail App seiner Wahl aus. Tada!Übrigens, wen es auch ärgert, dass sich WLAN und Bluetooth über das Kontrollzentrum nicht mehr vollständig abschalten lassen, der sollte sich dafür eine Routine zusammenstellen. Die Aktionen „WLAN konfigurieren“ und „Bluetooth konfigurieren“ schalten WLAN und Bluetooth nämlich mit einem Klick komplett aus.
Alle Helfer lassen sich entweder im Widget anzeigen oder als App auf dem Home Bildschirm ablegen. Mehr Konfigurationsmöglichkeiten findet man in der erstellten Routine oben rechts, wenn man auf das Symbol der beiden Kippschalter tippt. Mit einem eigenen Hotword lassen sich die Routinen sogar zu Siri hinzufügen.

Streaming auf AppleTV über Subnetzgrenzen hinweg

Mit dem Update auf Softwareversion 6.1 bekam das AppleTV in Verbindung mit iOS 7.1 und höher ein neues Feature: AirPlay Discovery via Bluetooth. Dies ermöglicht nun viel einfacher die Verbindung zwischen AppleTV und AirPlay-Klienten, wenn sich diese nicht im selben IP-Subnetz befinden. Einrichtungen mit vielen IT-Anwendern sind gezwungen, einzelnen Abteilungen oder Arbeitsgruppen eigene getrennte IP-Subnetze zuzuordnen. Oft wird dem WLAN-Netz auch ein eigener IP-Bereich zugewiesen. Befindet sich das AppleTV dann netztechnisch im IP-Bereich einer Arbeitsgruppe, müssen die Klienten einige Barrieren überwinden.

Haben beide Geräte Bluetooth aktiviert und die aktuelle Softwareversion installiert, wird auf dem iPad/iPod/iPhone das AppleTV angezeigt. Unter Umständen ist jedoch keine Kommunikation zwischen den Klienten möglich. AirPlay erfordert, dass vom AppleTV eine neue TCP/UDP-Session zum Endgerät aufgebaut werden kann, obwohl die ursprüngliche Session vom Endgerät initiiert wurde.

Damit schließt AirPlay Umgebungen aus, die NAT mittels Port-Addresstranslation durchführen. Diese Hürde kann man jedoch durch Aufbau einer VPN-Verbindung überwinden. Verteilt das VPN-Gateway jedem Endgerät eine eigene IP, kann so doch AirPlay eingesetzt werden.

Nun müssen gegebenenfalls noch Freigaben eingerichtet werden, wenn die Subnetze durch eigene Firewalls abgesichert sind. Leider verwendet AirPlay dynamische Ports, so dass ganze Bereiche freigegeben werden müssen. Dabei verläuft die Kommunikation von hohen Ports (49152 – 65535) zu hohen Ports.

Folgende Freigaben sollten eingerichtet werden:

Je nach Firewall-Typ müssen auch die Rückantworten zu den fünf Freigaben eingetragen werden, also Quellnetz/-port und Zielnetz/-port vertauscht.

Mit diesen Freigaben sollte AirPlay funktionieren. Wir konnten mit den gewählten Einstellungen Videos, Musik und den Bildschirminhalt erfolgreich auf das AppleTV streamen.

Passwörter mit Dashlane aufbewahren, einsetzen und synchronisieren

Meine Ausgangspunkt

Mein digitales Leben ist „geschützt“ durch gefühlt Zillionen von Passwörtern – faktisch sind es einige Hundert, aber mit Erinnerungsvermögen ist da nichts mehr zu machen. Bisher nutzte ich meinen Browser sowie eine lokale Anwendung auf meinem Smartphone zur Verwahrung dieser Credentials. Das war mehr schlecht als recht, denn mein Gerätebestand umfasst OS X, Android, Windows7 und iOS — alles in allem ein mittlerer Alptraum.

Dashlane „betritt“ mein digitales Leben

Ein Artikel von David Pogue [1][2] machte mich auf Dashlane aufmerksam. Das Tool behebt mein Problem inzwischen wirklich recht gut. Der „Migrationsaufwand“ war bei mir nicht wirklich vernachlässigbar, weil die Import-Funktion bei mir nicht so genial funktioniert hat – also knapp unter „Do What I Think“-Niveau. Auch das Sortieren der einzelnen Records nach Kategorien nervt (auch wenn es vernünftig ist).

Nach dieser Einstiegshürde ist Dashlane aber wirklich nützlich. Ich nutze die Anwendung nicht lokal, sondern synchronisiere darüber mein gutes halbes Dutzend Devices. Das funktioniert kostenlos für 30 Tage, danach nur mit einer kostenpflichtigen Subscription – Eine schwierige Abwägung zwischen Geiz und Komfort!

Meine Konfiguration ist nun so, dass ich Dashlane auf meinem Notebook, Arbeitsplatzrechner, Android-Smartphone, iPad und den privaten Rechnern nutze. Das Smartphone nutze ich auch als One-Time-Password-Generator (Google Authenticator).

Erfahrungen

Dashlane ist schon sehr pfiffig darin, Formulare richtig auszufüllen, aber David Pogues Beschreibung erscheint mir etwas zu euphorisch. Mir sind schon etliche Seiten untergekommen, bei denen die Logik nicht funktioniert. Bei englischsprachigen Seiten funktioniert das Auto-Ausfüllen aber gut.

Wirklich cool ist, dass man das Ausfüllen auf „Subdomains“ ausdehnen bzw. einschränken kann und die Möglichkeit mit mehreren Accounts für eine Website umgehen zu können. Nett ist auch die Möglichkeit, sichere Passwörter erzeugen zu lassen; nützlich sind die Hinweise auf vermutliche kompomitierte Web-Site, bei denen man Accounts hat. Das Wallet habe ich bisher wenig (aber erfolgreich) genutzt. Die anderen Features wie Nachrichten-Austausch und so nutze ich nicht.

Risiken und Nebenwirkungen

Ach ja, das Synchronisieren geht natürlich über die Server von Dashlane. Das Sicherheitsmodell scheint mir wasserdicht zu sein, solange man auf keinem seiner Endgeräte einen Keylogger eingefangen hat oder sonst irgendwie das Masterpasswort verliert. Im Normalfall geht also „unbrauchbarer“ AES256-Datenschrott über den Austauschpunkt. Für die Sicherheit von AES256 gibt es sogar eine Zusicherung der NSA – super!

Um etwas Schutz gegen die Keylogger-Problematik zu haben, nutze ich die Zwei-Faktor-Authentifizierung. Dann kann niemand ein Endgerät mit meinem Dashlane-Datenaustausch-Account verknüpfen. Wenn ich mein Android-Smartphone UND mein Masterpasswort verliere, wäre das natürlich ganz schlecht.

Nun gut, die Prism-Tempora-Sonstwas-Maschinen wissen nun wirklich ganz genau, welche Endgeräte ich nutze. Vermutlich ist dies ja auch für jene Leute die wirklich interessante Information – Passwörter von Individuen brauchen die eh nicht so dringend. Also: „Ja, man gibt Futter für diese Maschinen“, damit das Korrelieren im Big-Data-Wust dann besser geht.

Zusammenfassung

Angesichts des Nutzens finde ich das Werkzeug sehr interessant und werde es weiterhin einsetzen. Unberührt von der technischen Coolness ist der Umstand, dass beispielsweise eine Unternehmspolicy das Hinterlegen bestimmter Credentials in Password-Manager-Anwendungen untersagen kann.

Zwei-Faktor-Verifikation für Google-Accounts

Ob das RRZK-Blog ein guter Platz ist, um über ein Feature von Google-Accounts zu schreiben? Ich bin nicht sicher, aber viele an der Uni nutzen ja die Google-Angebote und daher ist es vielleicht für ein paar Leute von Interesse.

Ich selbst nutze einen Google-Account seit 2006 für mein „persönliches digitales Leben“. Die Datenschutz-Problematik ist mir durchaus bewusst, aber die Funktionen sind einfach zu verführerisch, um widerstehen zu können. Schon lange hat mich gestört, dass meine Daten nur durch ein kleines Passwort von der Welt getrennt sind. In einer globalen Cloud können merk- und tippbare Passwörter praktisch nie ein geeigneter Schutzmechanismus sein.

Seit einigen Monaten bietet Google nun eine Authentifizierungsmethode an, die „Two Step Verification“ genannt wird. Das klingt verdächtig nach der klassischen Zwei- bzw. Mehr-Faktor-Authentifizierung. Dies legt auch die Intro-Page nahe, die sagt „Sign in will require something you know and something you have“. Klingt sehr gut.

Der Start ist auch recht simpel; eine kleine Änderung in den Account-Einstellungen und man erhält Einmal-Zugriff-PINs über SMS, Voice Call oder eine recht nette Authenticator-App (für Android, iOS usw.), die zusammen mit dem traditionellen Passwort den Zugriff auf das Konto ermöglichen. Außerdem kann man Geräte nach eigenem Ermessen als „vertrauenswürdig“ einstufen; dann entfällt dort die Eingabe der zusätzlichen PIN. Auch der Desaster-Fall ist bedacht: dafür gibt es Backup-PINs zum Ausdrucken (Natürlich nicht ausdrucken, falls der Drucker ein Gerät mit Festplatte oder Netzwerk-Anschluss ist 😉 ).

Wie immer gibt es in der schönen neuen Welt auch ein paar Relikte aus der hässlichen alten Welt; in diesem Fall sind das die „anwendungsspezifischen Passwörter„. Diese sind zwar nicht „anwendungsspezifisch“, aber Passwörter mit fast allen schlechten Eigenschaften, die Passwörter haben können. Sie sind nicht anwendungsspezifisch, weil sie den Zugriff auf das komplette Google-Konto ermöglichen. Die Terminologie bedeutet, dass sie nur für eine bestimmte Anwendung eingesetzt werden sollen.

Ein zusätzlicher Schutz (im Vergleich zum klassischen Passwort) besteht neben der Länge darin, dass es weniger Risiken gibt, das Passwort zu verlieren oder unabsichtlich offenzulegen (revealing). Faktisch wird es einmal angezeigt und dann nie wieder; schreibt man es nicht auf, sondern kopiert es sofort in die Anwendung der Wahl und vergisst es, so kann man es selbst nicht mehr verlieren. Trotzdem kann in der rauen Wirklichkeit das eigene Google-Konto über diesen Mechanismus „geknackt“ werden. Also: Der Provider kann es noch „für einen verlieren“ – quasi „RaaS, Revealing as a Service“.

Klar, die „anwendungssprezifischen Passwörter“ sind eben Passwörter und daher ist der Authentifizierungsmechanismus auch keine echte Zwei-Faktor-Authentifizierung. Ich vermute, dass Google daher auch von einer „Two Factor Verification“ spricht. Zu dem Mechanismus und seinen potenziellen Schwachstellen gibt es diverse mehr oder weniger technische Erläuterungen.

Alles sinnlos also? Falls das eigene digitale Leben spartanisch ist und sich auf die Browser-Schnittstelle bzw. moderne Android-Systeme (wohl >2.3) beschränkt, sind anwendungsspezifische Passwörter verzichtbar. Dann ist das Niveau des Zugriffschutzes mit Zwei-Faktor-Verifikation deutlich besser als ohne.

Andernfalls muss man halt mit dem kleinen Schönheitsfehler leben. Ein Sicherheitszuwachs bleibt: Falls man doch einmal das gute alte Passwort verlieren sollte oder falls es ein Service-Provider „für einen selbst“ verliert, kann nicht ohne weiteres von jedem Rechner im Internet auf das Konto zugegriffen werden.

Was man auch noch im Auge behalten sollte:

Gut auf die Backup-Codes aufpassen.
Einen kritischen Blick auf die Liste der Sites, Apps und Dienste, denen Zugriff auf die eine oder andere Information des Google-Kontos eingeräumt wird. Sicherheitsvorfälle in diesen Bereichen können auf das Google-Konto übergreifen.

SoFS-Nutzung von Android Tablets

Bislang gab es nur Hinweise, wie SoFS von Windows und MacOS aus nutzbar ist. Aber auch von Android aus kann man dank Webdav gut auf SoFS zugreifen. Man installiert sich dazu aus dem Google Playstore zunächst den „Total Commander“ und darin dann das Webdav plugin. Dieses dann mit https(!) checken, sofsdav.uni-koeln.de/private/<username> als pfad, username und password konfigurieren und fertig! Dem Hin- und Her-Kopieren von Dateien zwischen Android-Device und SoFS steht nur noch die verfügbare Bandbreite im Wege…

AirPrint-Erfahrungen

Seit einiger Zeit (ab Version 4.2.1) können iOS-Geräte wie z.B. iPads und iPhones drucken. Der offizielle Weg funktioniert aber nur in Heimnetzwerken und mit wenigen Druckermodellen. Im Netz kursieren viele Anleitungen, wie man diese Beschränkung umgehen kann. Was ich hier darstelle, ist nicht neu, sondern nur ein Erfahrungsbericht über die Fallstricke, die einem begegnen können. Der beste Ausgangspunkt für eigene Versuche, den ich gefunden habe, ist dieser Blogeintrag. Insbesondere die dort aufgelisteten Links sind sehr hilfreich.

Auf die grundsätzlichen Dinge, wie die Konfiguration von CUPS und das Erstellen der Servicerecords im DNS, gehe ich hier nicht ein. Das ist an anderer Stelle (s.o.) schon zur Genüge getan. Folgende Probleme hatte ich zunächst:

Farbausdruck ging nicht
Druck aus Safari ging nicht

Das letztere Problem wurde, wie man im CUPS-Log (mit debug-Logging) sehen konnte, dadurch ausgelöst, dass das zu druckende Dokument als URF-Image geschickt wurde. URF ist ein „raster image format“, für das Apple den MIME-Typ image/urf verwendet, das aber leider nirgends dokumentiert ist. Eigentlich sollte URF in meinem Fall nicht verwendet werden, weil ich (gemäß den Anleitungen) urf=none deklariert hatte. Ich hielt das für ein möglicherweise neues Problem und habe deshalb nach Lösungen zum Drucken von URF gesucht. Es sei hier schon verraten: das war eine falsche Fährte. Dennoch folgt ein kurzer Exkurs zum Drucken von URF.

Frühere Versionen von Mac OS X hatten einen CUPS-Filter namens urf2pdf, mit dem das Drucken von URF möglich war. Mit dem Update auf 10.6.5 hat Apple diesen Filter gelöscht, man findet ihn aber noch im Netz. Wenn man den (mit den richtigen Permissions, also root:wheel als owner/group) installiert, und in den CUPS-Einstellungen den MIME-Type image/urf aktiviert, klappt das tatsächlich – aber nur unter Mac OS X. Ich habe keine Möglichkeit gefunden, CUPS unter Linux beizubringen, mit URF umzugehen.

Das zweite Problem war, dass alle Ausdrucke schwarzweiß waren, obwohl im Servicerecord für den Drucker Farbfähigkeit annonciert war. Wie ich jetzt weiß, war beider Rätsel Lösung offenbar identisch: Tippfehler im Servicerecord. Beim Studium der „Bonjour Printing Specification“ von Apple fiel mir auf, dass ich ein (ganz anderes) Attribut falsch geschrieben hatte. Nachdem ich alles entsprechend angepasst hatte, gingen auf einmal Farb- und Duplexdruck. Es sieht so aus, als ignoriere der Parser alle Attribute nach einem falsch geschriebenen. Deshalb wurde auch mein urf=none nicht ausgewertet. Mit der korrigierten Fassung geht jetzt auch ein CUPS-Server unter Linux, weil die iOS-Geräte jetzt alle Druckjpbs als PDF schicken.

Fazit: wie so oft in der IT können kleine Ursachen große Auswirkungen haben.

Intranettes Symbian – Nokia Handys mit Cisco VPN verbinden

Dienstag abend, in einem verspäteten Regionalexpress in der Pampa zwischen Pulheim und Stommeln: Ein netter kleiner RRZK-Mitarbeiter nutzt sein hypermodernes Präzisionsinstrument aus Finnland (a.k.a. Nokia E72), um die E-Mails zu lesen, die ihn nach der Bürozeit erreicht haben. Aha, der Herr Professor Hänneschen hat Probleme mit dem Zugriff auf seinen Webspace und hat daraufhin ein Ticket bei uns eröffnet. Der nette kleine RRZK-Mitarbeiter erkennt das Problem und möchte dem armen Professor den Abend retten, also schnell auf das OTRS zugegriffen und – BÄM… „Zugriff verweigert“. Ach ja, das Ticketsystem ist nur aus dem Uninetz erreichbar. Toll, dass die Uni dafür VPN anbietet. Blöd, dass Nokia Handys sich damit nicht verbinden können.

Nun stehen zur Lösung dieses Problems im Netz diverse kostenpflichtige VPN-Clients zur Verfügung. Aber das Schöne: Es geht sogar kostenlos! Eine ganz allgemeine Anleitung dazu findet man auf den Seiten von Mobilfunk-FAQ. Hier beschränke ich mich daher auf eine etwas kürzere Anleitung für diejenigen, die sich speziell mit dem VPN der Uni Köln verbinden möchten. Vorab: Die Nutzung erfolgt auf eigene Gefahr und ohne Support oder Gewährleistung, falls etwas schief geht!

Zunächst benötigt man diese SIS-Datei, also ein Symbian-Installationspaket. Eigentlich wäre das sogar schon alles, aber leider muss die Datei für jedes Handy einzeln signiert werden. Es besteht über die Seite Symbiansigned die Möglichkeit, ein Programm zu signieren. Wichtig ist dabei die IMEI (die Seriennummer des Handys), die über die Eingabe von *#06# auf dem Handy angezeigt werden kann. Nach dem Upload der Datei erhält man per Mail das signierte Programm als Download.

Sobald Sie über die nun signierte SIS-Datei verfügen, laden Sie diese einfach auf Ihr Handy (per OVI, Bluetooth, Speicherkarte etc.) und installieren Sie das Paket. Je nach Handymodell müssen Sie nun einen neuen VPN- oder Intranetzugangspunkt einrichten und dabei die VPN-Richtlinie bzw. -Policy „VPN-Policy“ auswählen. Der Name des Zugangspunktes selbst ist beliebig. Bei der Einrichtung des Zugangspunktes müssen Sie zudem noch auswählen, über welche Netzverbindung Sie sich mit dem VPN verbinden möchten (neuere Modelle bieten praktischerweise den generischen „Internet“-ZP hierfür an). Künftig können Sie sich dann direkt über den erstellten Zugangspunkt im Uninetz anmelden. Anmerkung: Dies funktioniert *nicht* im WLAN der Uni, ist dort ja auch völlig unnötig.