Autor: Torsten

Ist das Passwort als Schutz nicht ausreichend?

Das Passwort als als alleiniges Kriterium heute keine sichere Variante der Authentifizierung, besonders wenn man einen VPS (Virtual Private Server) hat und dort auch mal experimentiert. Dann kann es doch recht schnell passieren, dass das Passwort irgendwann mal im Klartext durch das Netz wandert.

Wie könnte jemand an das eigene Passwort gelangen?

• Bruteforce (durch probieren) – dafür hilft es komplexe Passwörter zu benutzen, die man aber zwangsläufig wieder irgendwo speichern oder aufschreiben muss. Der verwendeten Verschlüsselung der Datei muss man trauen. Was bedeutet komplex? Das Passwort sollte z.B. nicht Schalke04, BMWFan, Hardrock!!!, BVBDortmund oder vergleichbar lauten. Derart simple Sachen werden von Passwortknackern zuerst probiert, weil viel zu viele Leute solche Simpelpasswörter nutzen. Im Optimalfall sollte das Passwort eine gewisse Mindestlänge haben, aus Groß / Kleinbuchstaben, Sonderzeichen und Zahlen bestehen
• Lauschen – Wenn man ein Passwort auch nur einmal ungeschützt im Netz transportiert (z.B. per Mail) ist es verbrannt. Wenn die verwendete SSL Verschlüsselung kompromittiert oder geknackt wird, bietet das Passwort keinen Schutz mehr. Auch wenn man zwischendurch den Zugang über VNC (unverschlüsselt) nutzt , müsste man das oder die Passwörter danach ändern.
• Direkter Zugriff auf den Server – bei einem VPS Server stellt sich immer die Frage, ob die Mitarbeiter des Anbieters Zugriff haben und wenn ja wie. Das beste Passwort bringt nichts, wenn man es umgehen kann.
• Social engineering / Phishing – Wer kennt sie nicht die Mails. Wir haben ein Problem mit ihrem Konto festgestellt. Bitte loggen Sie sich ein und entsperren sie es. In dem Fall gibt man sein Passwort gegebenfalls selber an Betrüger weiter
• Würmer – man installiert sich selbst (versehentlich Software) die zum Beispiel Passwörter an Kriminelle überträgt. Zugegeben – ja nach Wurm hat man dann noch weitere Probleme

Das sind nur ein paar Beispiele und die Liste erhebt keineswegs Anspruch auf Vollständigkeit.

Warum überhaupt schützen? Ich habe nichts zu verbergen!

Man kann nun argumentieren, dass auf einem VPS auf dem man zum Beispiel sein WordPress laufen lässt ja keine geheimen Informationen liegen. Das mag richtig sein (wobei man definitiv Probleme im Kontext DSGVO bekommen wird, wenn sie jemand Zugriff auf die persönlichen Daten von Besuchern verschaffen kann, selbst wenn es nur Mailadressen sind) aber alleine schon aus dem Aspekt, dass die Daten von Fremden ggf. beschädigt oder gelöscht werden, ist ein etwas höherer Schutzlevel ggf. angebracht.

Wenn man auf dem Server persönliche Informationen hat zum Beispiel als Backup wie Rechnungen, Krankeninformationen, Bewerbungen, Backups, Fotos usw. ist die Gefahr noch mal höher. Einerseits des Verlustes andererseits behaupten viele, dass die keine Geheimnisse haben. Ist das wirklich so? ist es nicht unangenehm, wenn die Fotos vom letzten Saufgelage beim Arbeitgeber aufschlagen?

Gibt es irgendwelche Einkäufe, die nicht an die Öffentlichkeit gelangen sollten?

Ist es nicht blöd, wenn die eigenen Krankenakten öffentlich verfügbar sind?

Wie ist es mit der Religionszugehörigkeit? Geheim oder kann das jeder wissen?

Ein sehr unschönes Beispiel aus der Geschichte: Die detaillierten Informationen über die Religionszugehörigkeit wurden bereits vor dem zweiten Weltkrieg in den Niederlanden erfasst.

Tendenziell hätte man nun vielleicht angenommen, dass die Religionszugehörigkeit als Information beim eigenen Staat vollkommen unproblematisch ist. War sie nicht!

Wie funktioniert 2-Faktor Authentifizierung in der Praxis?

Da gebräuchlichste Verfahren ist heute die Variante über Token. Auf dem Handy befindet sich eine App, die über ein “Geheimnis”, dass der App un dem Server bekannt ist und der aktuellen Uhrzeit einen Code generiert. Diesen gibt man in der Regel zusätzlich zum Passwort ein. Beides muss für einen erfolgreichen Login stimmen. Der generierte Code ist in der Regel nur eine sehr begrenzte Zeit gültig (z.B. eine oder zwei Minuten bei dem Time based Verfahren)

Vergleichbare aber unsichere Verfahren gibt es zum Beispiel über SMS, Mail usw. – in dem Fall wird der Code nicht vom lokalen Gerät, sondern vom Server erzeugt. Aufgrund der Verzögerung durch das Senden sind diese Codes in der Regel länger gültig und können natürlich beim Senden leicht belauscht werden, weil weder eine e-Mail noch die SMS gegen Einsehen geschützt sind.

Ein Problem bei o.g. Verfahren ist, dass die Anwendung ein separates Feld für den Code anbieten muss, der nun zusätzlich benötigt wird.

Beispielsweise ist dies bei einem aktuellen Ubuntu Linux in Version 18.04 LTS gegeben, wenn man sich per SSH anmeldet. Wenn die App ein derartiges Verfahren nicht unterstützt, dann gibt es je nach Anbietet der OpenOTP Lösung die Variante das Passwort und Token direkt hintereinander einzugeben oder eine Push Authentifizierung zu nutzen. In dem Fall gibt man sein Passwort ein, bekommt dann eine Benachrichtigung auf dem Handy in der man zu Bestätigung aufgefordert wird. Dieses Verfahren funktioniert zum Beispiel, wenn man den RDP (Remote Desktop) Zugang in Linux schützen will gut.

RDP wird primär in der Windows Welt genutzt und ist nicht zwangsläufig verschlüsselt.

Und in der Praxis?

Welche Varianten habe ich getestet:

Webmin 2-Faktor

2-Faktor Authentifizierung phpMyAdmin

Plesk mit Google Authenticator

Google Authentificator – Zum Beispiel PHPMyadmin, Plesk, Webmin integriert – Die Variante ist Einfach und in der Regel direkt in der App integriert. Das bedeutet, dass abseits des Aktivierens oft keine Konfiguration nötig ist. Man scannt den QR-Code (im Optimalfall auf zwei Geräten also zum Beispiel dem Handy und dem IPad zwecks Fallbackoption, wenn eines der Geräte den Geist aufgibt oder verloren geht). Das war es auch schon. Google unterstützt kein Push aber sowohl die Kombinierte Variante von PW und Token, als auch über einen angepassten Dialog. Die verwendete Anwendung muss es natürlich unterstützen.

WebADM Seerver von RCDevs (als Gegenstück gibt es eine App namens OpenOTPToken (die Google App oder eine andere z.B. von Duo tut es aber auch)

/etc/pam.d/sshd – Konfiguration für den Zugang per SSH in Linux – common-auth = Standard, openotp-auth = RCDevs und die anderen drei Zeilen sind für Duo

Kommandozeilenlogin Putty per SSH und RCDevs OpenOTP Token + Backuppasswortliste

RCDevs OpenOTP – In dem Fall ist man vollkommen losgelöst vom Anbieter und kann seinen eigenen Authentifizierungsserver aufsetzen. RCDevs unterstützt alle Verfahren (Dialog mit Token, PW + Token, Push). Ich habe aber im Fall von RDP keine Variante zum Laufen bekommen, da dort ein separates Eingabefeld nicht vorgesehen ist. Die Push Variante funktioniert bei mir zwar mit SSH aber nicht per RDP. Der Einrichtungsaufwand ist ziemlich hoch.

Duo – Auch hier bindet man sich an einen Anbieter, von dem man Abhängig ist. Das ist aber die einzige Variante, mit der ich Push zum Laufen bekommen habe

Es ist übrigens egal welche App man auf dem mobilen Gerät nutzt. Man kann sowohl die Google App als auch z.B. die RCDevs App nutzen. Die erzeugten Codes sind immer identisch. Die einzige Ausnahme von dieser Regel ist der Pushservice. Der Duo Push funktioniert nur mit der Duo App und der von RCDevs nur mit der von RCDevs.

In der Regel muss man sich für alle Anmeldewege für ein Verfahren entscheiden. RCDevs bietet zwar die Möglichkeit nach Anwendung zu unterscheiden, dass funktioniert aber nach meiner Erfahrung eher schlecht bzw. es gibt diverse Voraussetzungen, die sich teilweise nicht erfüllen lassen.

Alle Varianten sind für den Privatgebrauch kostenlos.

Ausgesperrt?

Bedenken sollte man aber, dass man ohne den Code keine Chance mehr hat sich anzumelden. Wenn man sein Handy als einziges Gerät aktiviert, dann führt ein defektes oder verlorenes Handy ggf. dazu, dass man sich überhaupt nicht mehr anmelden kann. Es empfiehlt sich also eine Rückfalloption zu konfigurieren.

Auch andere Szenarien sollten man bedenken: Ein Beispielszenario, dass ich natürlich absichtlich <hust> gestestet habe, ist, dass die Festplatte des Servers voll ist. Wie ich festgestellt habe, funktionierte RCDevs in dem Fall bei mir nicht mehr, vermutlich weil die entsprechenden Logeinträge nicht mehr auf die Datenbank geschrieben werden konnten.

Der Fall – volle Festplatte – sollte zwar nicht vorkommen aber hey, es ist halt ein Privatserver und kein produktiver Server im Unternehmen (wobei auch dort solche Sachen vorkommen). Wenn man dann keine Alternative hat, dann hat man sich ggf. selber dauerhaft und endgültig ausgesperrt.

Beispielsweise eine Liste mit einigen Codes, die man im Notfall verwenden kann (das geht zum Beispiel bei RCDevs OpenOTP sehr einfach).

Fazit:

Mit 2-Faktor Authentifizierung kann man die Sicherheit deutlich hochschrauben. Die einfachste und an den meisten Stellen integrierte Variante ist die über Google.

Duo ermöglicht es zum Beispiel auch besondere Anforderungen wie die der RDP Authentifizierung zu erfüllen.

RCDevs OpenOTP mit eigenem Server ist vollkommen losgelöst von externen Anbietern (alles läuft auf dem eigenen Server, wenn man die Push Funktion nicht nutzt. Dafür ist der Einrichtungsaufwand mit Abstand am höchsten. Theoretisch sollte sich mit dem Werkzeug alles abbilden lassen, was mit Duo / Google auch geht (also z.B. Passwort + Code in einem Feld oder auch Push), das ist mir aber nicht in jedem Fall gelungen.