Was mein ist, bleibt mein

Auch wenn mich das als Egoist darstellt, sollte das jeder in Betracht ziehen. Jedenfalls wenn es um potentiell sensible Daten geht.

Ein Beispiel

Jeder der häufig im Internet unterwegs ist, sei es nun privat oder geschäftlich, kennt das. Eine Anmelde-Maske.

Wer auf Sicherheit wert legt, nutzt hoffentlich überall ein anderes Passwort. Selbstverständlich sind die auch in einem Passwort-Manager wie Keepass oder Enpass hinterlegt und mit einem sicheren Master-Passwort gesichert.

Aber mal ganz ehrlich, wer klickt im Browser bei der Frage “Soll dieses Passwort gespeichert werden?” nicht gerne auf Ja? Nun, ich hab es eine Zeit lang vermieden war aber jedes Mal traurig nicht auf Ja geklickt zu haben.

Warum? Weil ich eine üble Angewohnheit, wie viele andere wohl auch, habe.

Bequemlichkeit

Ich nutze ein Passwort niemals ein zweites Mal. Ich habe alle meine Passwörter in Keepass gespeichert. Diese Datenbank ist mit einem relativ komplexen jedoch noch leicht zu merkendem Master-Passwort versehen und mit meinem Yubikey gekoppelt. 2-Faktor Authentifizierung wie aus dem Buche.

Aber ich bin bequemlich. Jedes Mal Keepass aufzumachen und diese Prozedur durchzuführen, für jede Anmelde-Maske die ich im Laufe des Tages benutzen muss? Ein Graus. Selbstverständlich kann ich Keepass im Hintergrund offen lassen, aber das würde dem Gedanken der 2-Faktor Authenfizierung widersprechen. Sicher, Keepass schützt die Passwörter vor unerlaubten Speicherzugriffen und derlei Späßen, jedoch hab ich dennoch kein gutes Gefühl dabei.

Aber warum speichere ich dann nicht einfach die Passwörter mit Hilfe des Browsers? Werden die dort nicht auch sicher gespeichert? Na, selbstverständlich werden sie das. Doch das Problem ist ein ganz anderes.

Das schwache Glied

Die Frage ist nämlich nicht wie die Passwörter vom Browser gespeichert werden, sondern wie erneut auf sie zugegriffen wird.

Ich setze Ubuntu 18 ein. Hier werden derart gespeicherte Passwörter im GnuPG-Schlüsselbund hinterlegt. Dieser wird bei jedem Login auf dem System entsperrt. (Oder beim entsperren des Systems.)

Nun, der aufmerksame Leser wird sich nun denken können weshalb ich das als schwaches Glied in der Kette ansehe. Ich bin bequemlich, welch Überraschung. Wenn ich das System entsperren muss, möchte ich nicht erst ein super sicheres Passwort eintippen müssen. Erst recht nicht während jemand daneben steht/sitzt. Je komplexer das Passwort nämlich, desto langsamer tippe ich es. Je langsamer ich tippe, desto eher steigt die Gefahr mir schaut jemand dabei zu. (Kollegen vertraue ich selbstverständlich, aber man weiß ja nie wo man sonst ist.) Deshalb: Es ist ein einfaches Passwort das super schnell getippt ist.

Falls aber doch jemand, oder etwas, Kenntnis von diesem Passwort erlangt war alles für die Katz. Sofort sind alle Passwörter aus dem GnuPG-Schlüsselbund gefährdet. Da hilft nur eines.

Die Lücke schließen

Zum Glück hat meine Bequemlichkeit doch ihre Grenzen. Denn ich fahre mein DELL XPS 13 grundsätzlich immer herunter wenn ich es länger aus den Augen lasse.

Somit ist diese Lücke auf einen Schlag verschlossen sobald der gesamte Festplatten-Inhalt verschlüsselt ist. Und das ist er inzwischen. LUKS sei dank.

Auch hier kommt es auf die Qualität der gewählten Passwörter an, schließlich muss vor dem Start des Systems erst einmal alles entschlüsselt werden können. Aber Achtung: Ein zu schwaches Passwort ist erneut das schwache Glied.

Hier habe ich einen Kompromiss mit meiner Bequemlichkeit geschlossen. Ich habe zwei Möglichkeiten meine Festplatte zu entschlüsseln. Zum einen ein super sicheres Passwort (das nicht im Wörterbuch zu finden ist), zum anderen aber auch ein leicht zu merkendes. (Das aber auch nicht im Wörterbuch zu finden ist, jedenfalls nicht 1:1) Der Clou jedoch ist, das zweite (einfache) Passwort ist mit dem Yubikey gekoppelt.

Ein Hoch auf die 2-Faktor Authentifizerung

Man merkt es vielleicht. Ich bin ein Fan meines Yubikeys. Besser gesagt, meiner zwei Yubikeys. (Es könnte ja einer abhanden kommen) Auf die technischen Details gehe ich jetzt nicht mehr ein, das macht zum Teil bereits Marius. Doch kurz auflisten wofür ich ihn noch einsetze möchte ich:

  • GPG (Private subkeys auf dem Yubikey)
  • SSH (Dank GPG, Gunnar hatte hierzu bereits etwas geschrieben)
  • Github (FIDO U2F)

Außerdem ist mein zweiter (privater) Yubikey NFC fähig, ich kann ihn also super easy mit der Keepass App auf dem Smartphone nutzen.

Was mein ist, bleibt mein!

Johannes Meyer
Johannes Meyer
Developer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

SSH authentication with GnuPG and smart cards

Most system administrators know how to use key-based authentication with SSH. Some of the more obvious benefits include agent forwarding (i.e. being able to use your SSH key on a remote system) and not having to remember passwords. There are, however, a few issues with having your SSH key on a general-purpose computer: Malware can obtain an unencrypted copy of your private SSH key fairly easily. Also, while migrating your key to another system is fairly easy it’s virtually impossible to securely use your SSH key on another untrusted system (e.g. at a customer).
This is where smart cards come in. A smart card stores certificates (such as your SSH key) and provides functionality for operating on those certificates (e.g. using their private key to sign or decrypt data). Smart cards come in various form factors: credit cards, SIM cards, etc. – which commonly require a separate card reader in order to be usable. However, there are also USB devices which implement all the usual smart card features in addition to other security features (e.g. requiring the user to press a key on the device before an authentication request is signed).
One such device is the Yubikey 4 which I’m personally using for SSH authentication.
The first step towards using a new Yubikey for SSH authentication is enabling the OpenPGP applet on it:

$ ykpersonalize -m82

I already had a PGP key, however in order to use it for authentication I had to create an additional subkey for the key usage type “authentication”. Here’s how that can be done:

$ gpg --edit-key --expert info@example.org
gpg (GnuPG) 2.1.23; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 8
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? s
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? e
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions:
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? a
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Authenticate
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> save

Now that we’ve created a new subkey we can move its private key part to the smart card:

$ gpg --edit-key --expert info@example.org
gpg (GnuPG) 2.1.23; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> toggle
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> key 2
sec rsa2048/42330DF1CA650A40
created: 2017-08-24 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/56D8D1BBE7E720DB
created: 2017-08-24 expires: never usage: E
ssb* rsa2048/5F43E49ED794BDEF
created: 2017-08-24 expires: never usage: A
[ultimate] (1). NETWAYS Blog <info@example.org>
gpg> keytocard
Please select where to store the key:
(3) Authentication key
Your selection? 3
gpg> quit
Save changes? (y/N) y

The Yubikey 4 has three key slots which can be used for storing RSA keys with up to 4096 bits each. This might be an excellent opportunity to also move your signing and encryption key to your smart card – assuming you have an encrypted backup somewhere in case you lose access to your Yubikey.
The last step involves replacing ssh-agent with gpg-agent. This allows your SSH client to use your PGP certificates (including the authentication subkey we just created). In addition to that gpg-agent also supports regular SSH keys which might be useful if you have more than one SSH key and only plan to migrate one of them to your Yubikey:
I had to add the following snippet to my .profile file to start gpg-agent instead of ssh-agent:

[ -f ~/.gpg-agent-info ] && source ~/.gpg-agent-info
if [ -S "${GPG_AGENT_INFO%%:*}" ]; then
  export GPG_AGENT_INFO
  export SSH_AUTH_SOCK
  export SSH_AGENT_PID
else
  eval $(gpg-agent --daemon --write-env-file ~/.gpg-agent-info)
fi

And here’s OpenSSH prompting me for my smart card and PIN:

And that’s how you can literally put your PGP key on your keychain. 🙂

Weekly Snap: LConf 1.4 & ITIL, Kibana & YubiKey

weekly snap2- 6 December started the silly season with courses, camps and webinars aplenty, plus log file visualization, ITIL certification and a new LConf release to boot.
Eva counted 127 days to the OSDC 2014 with Tugdal Grall’s ‘Introduction to NoSQL with Couchbase 2.0’ and wrapped up Puppet Camp Munich with videos, slides and photos in anticipation of Puppet Camp Berlin next year.
Continuing on events, Christian announced the next round of webinars on Logstash and Icinga Web 2, posting the recent Icinga 2 webinar online as Silke added Logstash and Graphite courses to our training center offering for 2014.
Michael then released LConf 1.4, adding support for Icinga 2 to the configuration interface and Marius recommended the security token, YubiKey.
To end the week, Tobias pointed out obstacles in preparing for ITIL certification exams and Blerim looked into log file analysis with Kibana.

Security Token für Jedermann: Der YubiKey

black_singleWie schützt man seine Daten am besten? Mit starken Passwörtern und genügend Entropie!
http://xkcd.com/936/
Besseren Schutz bieten zusätzliche Sicherheitsmerkmale wie 2-Faktor-Authentifizierung. Immer mehr Dienste bieten die Möglichkeit, sich mit einem zusätzlichen Einmalpasswort anzumelden. Dieses wird entweder auf einem anderen Medium dem Benutzer zugänglich gemacht (SMS, Abruf) oder wird von einem Token generiert. Tokens sind besonders spannend, da man jederzeit die Kontrolle darüber besitzt und unabhängig von Übertragungsproblemen ist (z.B. wenn man sich im Ausland aufhält). Nachteil: Teuer (z.B. SecurID) oder für Privatanwender zu aufwendig.
Mittlerweile bietet die Firma Yubico einen Token für $25 an. Günstig und viel Ausstattung. Die kleine Kunststoffplatte mit USB Kontakten ist wasserdicht und relativ unverwüstlich. Das Gerät wird vom System als Tastatur wahrgenommen und verschickt auf Knopfdruck verschiedene Strings, die zur Authentifizierung herangezogen werden können.
Der YubiKey kann selbst programmiert werden und unterstützt folgende Modi:

  • OTP (OTP YubiCloud oder OATH-HOTP)
  • Statisches Passwort mit 32 Zeichen
  • Challenge-Response

Diese Modi können in zwei Slots auf den Token programmiert werden. Die Slots werden durch den Druckknopf angesprochen: Weniger als 1,5 Sekunden für Slot eins und ungefähr 3 Sekunden für den zweiten.
Tools zum programmieren des Tokens gibt es für alle Systeme, jeweils in GUI oder CLI. Die GUI Version bietet praktischerweise auch den Upload des eigenen Keys in die YubiCloud an, was die Einrichtung deutlich vereinfacht.
Das OTP Modul für die YubiCloud erwartet auf der Gegenseite einen AES Key, welcher das eigentliche OTP Passwort entschlüsselt und dann auch validiert. Die ersten 6 Bytes des gesendeten Strings sind dabei der Public Identifier des Tokens. Anhand diesen Keys, kann der Schlüssel auf der Gegenseite identifiziert werden, um das eigentliche OTP zu entschlüsseln.
Alles weitere befindet sich in der ausführlichen Dokumentation von Yubico. Hier ist auch der Background und die Funktionsweise der Validierung und Provisioning von YubiKeys beschrieben.
Schön ist zu erwähnen, dass die Unterstützung des YubiKey stetig steigt: LastPass, Google, PAM, Radius, Windows Login, PayPal, KeePass et cetera.
Bleibt zu hoffen, dass es noch dauert bis jemand die erste Sicherheitslücke findet 😉

Bild Rechte v.l.n.r: CC-BY Marius Hein, (c) 2013 Yubico

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.