Login-Verfahren

Karl Brodowsky IT Sky Consulting GmbH

English

Für die Authentisierung in Webapplikationen gibt es verschieden Ansätze.
Ich beschreibe einmal einige, die mir tatsächlich begegnet sind, und mache mir ein paar Gedanken, was man davon erwarten kann.

Nun ist die Frage, ob so etwas nicht sehr einfach ist, man muss nur irgendwo Namen und Passwörter speichern und dann beim login einen Abgleich machen. Das können die ganzen coolen Frameworks heute gut, egal ob Java, Ruby, Perl, PHP, Scala, F# oder Python.

Aber es kommen einige Fragen auf:
– Sicherheit
– Vergessene Passwörter
– Benutzerfreundlichkeit

Beispiele für E-Banking und anderes

  • „Taschenrechner“
  • RSA-Zahlen-Generator
  • SMS
  • Zettel mit 100 Codes
  • Android-App
  • USB-Device
  • SmartCard
  • Einfach Username + Password
  • Login mit Google, Twitter oder Facebook

Taschenrechner

  • Auf Login-Seite Username + Password eingeben
  • PIN Code in TR eingeben
  • Code von Login-Seite in TR eingeben
  • Ergebnis von Taschenrechner ablesen
  • In Login-Seite eingeben

Security.Fragen:

  • Abhängig davon, wie der Taschenrechner funktioniert
  • Weil der Taschenrechner einen PIN-Code braucht gewisse Sicherheit gegen Verlust + Diebstahl

Praktische Fragen:

  • Taschenrechner nie dabei
  • Wer bezahlt die teure Hardware
  • Distribution der Hardware muss organisiert werden

Zusammenfassung:

Diese Methode is potentiell recht gut, wenn sie sauber und mit guten Algorithmen und guten Daten implementiert ist.

RSA-Zahlen-Generator

  • Auf der Login-Seite wird zusätzlich ein vom Gerät abgelesener 6-stelliger Code eingegeben.
  • Alle paar Sekunden/Minuten ändert sich der angezeigte Code

Security-Fragen

  • Sieht gut aus weil es von RSA kommt
  • Sind die Uhren immer gut genug synchron? Es scheint so.
  • Kein zusätzlicher Schutz, wenn das Gerät gestohlen wird
  • Kein Challenge-Response, nicht so gut wie der Taschenrechner

Praktische Fragen:

  • Gerät ist klein genug um es immer dabei zu haben
  • Gerät ist sehr teuer

SMS

  • username und password eingeben
  • code kommt als SMS
  • Code eingeben

Security-Fragen

  • Wie sicher ist das Mobilnetz?
  • Wie sicher ist das Telefon? Altes Nokia mit Prepaid-SIM ist sicher, aber modernes Smartphone riskanter
  • Für m-banking problematisch, wenn beides auf demselben Telefon läuft

Praktische Fragen

  • Telefon ist immer dabei
  • Aber nicht, wenn man dem Smartphone nicht traut und ein zweites braucht
  • SMS gehen verloren
  • Manche Leute haben viele SIM-Karten. Ist aber nicht so verbreitete Gewohnheit, man zahlt sehr gerne große Roaming-Rechnungen
  • Batterie kann leer sein. (Nur ein Problem der älteren Generation)
  • SMS-Roaming-Gebühren spielen für diesen Anwendungsfall keine große Rolle

Zusammenfassung

Solider Mechanismus, aber etwas schlechter als Taschenrechner.

Zettel mit 100 Codes

  • Login mit Username und Password
  • Die Seite verlangt Code von einer bestimmten Seite und einer bestimmten Nummer
  • Jede Nummer wird nur einmal verwendet
  • Neuer Zettel, wenn alter ca. 80% aufgebraucht

Security-Fragen

  • Hängt von der Qualität der Zahlen ab
  • Papier kann verloren gehen oder gestohlen werden
  • Drucken und Handhaben der Zahlen bietet viele Schwachstellen im ganzen Prozess

Praktische Fragen

  • Papier muss von Kunde und Bank verwaltet und aufbewahrt werden
  • Muss immer dabei sein, eventuell als Foto auf dem Telefon
  • Muss sorgfältig aufbewahrt werden

Zusammenfassung

Mechanismus rangiert irgendwo im Mittelfeld. Abgesehen davon, dass es nicht so cool ist, ist es nicht wirklich schlecht, aber schlechter als der Taschenrechner.

Android App

Oder mit anderen Smartphones auch machbar…

  • Login mit Username und Password
  • Ein farbiger Code wird angezeigt:

code

  • Starte Android-App die den Code fotografiert und auswertet.
  • Eine 6-stellige Zahl und eventuell mehr Information wird angezeigt.
  • 6-stelligen Code auf Login-Seite eingeben
  • Bemerkung: Die App muss personalisiert werden und funktioniert nur für das eigene e-Banking

Security-Fragen

  • Kein Password innerhalb der App
  • Telefon muss sicher aufbewahrt werden und Password- oder PIN-Schutz haben
  • Positiv ist, dass es so einfach geht, dass man das Verfahren auch zur Verifizierung einzelner Buchungen mit neuem Empfänger verwenden kann.
  • Der Code kann Information transportieren, die man in der App anzeigen kann

Praktische Fragen

  • Braucht passendes Smartphone
  • Smartphone ist immer dabei

USB-Device

Ein USB-Gerät wird in den Rechner gesteckt. Dieses kann „smart“ sein und direkt mit dem Server kommunizieren. Man kann sogar ein speziell sicheres Linux vom USB-Stick booten für das E-Banking.

Ich habe nur theoretisches Wissen dazu, keine Erfahrungen.

Security-Fragen

  • Hat sehr viel Potential
  • Ein manipulierter PC kann viel schaden, idealerweise aber den Traffic zwischen Device und Server nicht manipulieren.

Praktische Fragen

  • braucht speziellen USB-stick
  • USB ist in manchen Großbetrieben abgeschaltet, speziell das Booten von USB
  • Gerätetreiber sind immer ein Problem, wenn man sie braucht

Smart Card

Wie USB-Gerät, nur mit SmartCard statt USB-Stick.

Username + Password

  • Für E-Banking nicht genug, aber es soll Banken geben, denen das egal ist
  • Für einfache Applikationen ist es heikel, Username und Passörter auf dem eigenen Server zu haben
  • Immer noch der Default-Ansatz, einfach
  • Wie geht die User-Verwaltung??

Security-Fragen

  • Niedrigste Security
  • Benutzer- und Password-Datenbank ist immer ein Risiko, siehe iCloud

Login mit Google

  • Benutze google+, facebook, twitter etc. für login
  • Hier nehmen wir Google an um weniger schreiben und lesen zu müssen…
  • Bei Google einloggen. Sind wir sowieso normalerweise schon
  • Klick auf „Login mit Google“
  • Beim ersten Mal fragt Google, ob sie der Applikation die Identität geben dürfen.
  • In den Google-Settings kann das entfernt werden.

Security-Fragen:

  • Wie sehr lieben wir die NSA
  • User management kann Google besser als wir
  • OAuth2 ist unser Freund, nicht so schwierig zu verwenden

Immer dran denken

  • Wir sollten immer https verwenden
  • http bedeutet, dass Passwörter im Klartext übertragen werden, „Freunde“ im Netz können sie mitlesen.
  • Wenn es um Geld geht, geht http gar nicht, nur https
  • Das hilft jedenfalls etwas.
  • Wer weiß, was die NSA über https weiß, was nicht veröffentlicht worden ist?

Ich möchte diese Seite bald auf https umstellen… 😉

Share Button

WLAN-Router

Aus Sicherheits- und Durchsatzgründen ist es immer noch eine gute Idee, ein Netzwerk mit Kabeln anzulegen. Da wir so arbeiten, dass das Home-Verzeichnis auf einem NFS-Server liegt und alle Dateien auf diesem Rechner gespeichert werden und außerdem X11-Applikationen gelegentlich auf anderen Rechnern mit umgeleitetem Display laufen, ist ein zuverlässiges und schnelles und sicheres lokales Netzwerk sehr wichtig. Die Verkabelung im Gebäude ist dafür eingebaut worden.

Aber ein WLAN-Netzwerk ist trotzdem sinnvoll. Inzwischen können fast alle Mobiltelefone damit umgehen und man kann z.B. mit iO oder Skype telefonieren und das auch Gästen zur Verfügung stellen. Da Mobiltelefone und andere Mobilgeräte, die WLAN können, sowieso an anderen Orten direkt und ohne Firewall im Internet sind, habe ich eine Firewall zwischen WLAN und dem Kabelnetz eingefügt. Witzigerweise bieten die üblichen WLAN-Router zwar eine rudimentäre Firewall-Funktionalität, aber nur gegenüber der Netzwerkverbindung nach außen, weil anscheinend kaum jemand das Kabelnetz und as WLAN trennen will. Das lässt sich alles lösen, weil man natürlich die Firmware des WLAN-Routers austauschen kann und wenn nicht einen kaufen kann, bei dem das geht. Letztlich erwies es sich aber als einfacher, eine dezidierte Firewall zu kaufen und dazwischen zu schalten.

Für das WLAN selbst ist nun die Verschlüsselung eigentlich nicht sonderlich wichtig, sie erschwert es nur Gästen, das Netz zu benutzen. Da ja alle Geräte, die das WLAN benutzen, auch gelegentlich öffentliche WLAN- oder Mobilnetze verwenden, ist es sowieso notwending, die Geräte genügend abzusichern oder deren normaler Konfiguration zu vertrauen.

Hierzu kann man auch bei Bruce Schneier lesen, warum er sein
WLAN offen hat.

Share Button

Ein paar Gedanken zu ssh

English

Früher, als man noch jedem im Internet und sogar im Intranet vertraute, hat man sich ja einfach mit telnet in andere Rechner eingeloggt. Oder mit rlogin, damit die Umlaute auch funktioniert haben. Leider ging dabei das Password im Klartext über das Netz, was natürlich unverantwortlich ist.

Nun hat man also stattdessen ssh und es funktioniert recht ähnlich wie damals telnet, kann aber gleich noch sehr viel mehr, auch wesentlich mehr als ich hier in ein paar Zeilen schreiben kann. Wichtig ist nicht nur, daß man das Password verschlüsselt überträgt, sondern auch, daß man sicherstellt, daß die Gegenseite wirklich der gewünschte Rechner ist, sonst kan ein „man in the middle“ das Password abfangen und man ist wieder da, wo wir mit telnet standen.

Dazu gibt es im .ssh-Verzeichnis diese Zeritifikate, also solche Dateien wie id_rsa und id_rsa.pub. Die id_rsa sollte man hüten wie seinen Augapfel, da die Sicherheit des ganzen Protokolls davon abhängt. Mit ssh-keygen kann man sich solche Zertifikate auch anlegen, wahlweise auch so, daß man bei deren Verwendung ein Password eingeben muß (das nur auf dem lokalen Rechner bleibt). Die Zertifikate haben sogenannte „Fingerprints“, die man sich mit ssh-keygen -l anzeigen lassen kann. Genau dieser Fingerprint wird beim ersten mal angezeigt und man muß ihn bestätigen. Man sollte diesen also auf einem sicheren Kanal vorher überprüfen, daß er auch wirklich stimmt, zum Beispiel wenn man zwischen zwei Rechnern in einem verkabelten Netz, dem man traut, aufeinander zugreift, oder indem an sich den Fingerprint notiert oder ausdruckt. Wenn man ihn einmal bestätigt hat, wird er in .ssh/known_hosts eingetragen und man kann dort natürlich auch aufräumen, indem man unnötige Einträge löscht. Oder sogar mit USB-Stick übertragene Fingerprints reineditieren, wenn man das Format verstanden hat. Solange known_hosts keine falschen Einträge enthält, hat ein „man in the middle“ es sehr schwer und das Verfahren bietet eine vernünftige Sicherheit.

Nun läßt sich der „public key“ aus id_rsa.pub des eigenen Rechners in .ssh/authorized_keys des Rechners, auf dem man sich einloggen will, eintragen. Damit erreicht man, daß das ohne Password-Abfrage möglich ist, außer das lokale Zertifikat braucht eine Password-Abfrage. Die kann man aber auch einmalig pro Session mittels ssh-add durchführen.

ssh wird auch für andere Zwecke verwendet, weil man andere Protokolle darüber tunneln kann, z.B. Subversion oder git.

Sehr schön ist es auch, wenn man unter X11 ein

ssh -X user@host

aufruft. Dann kann man auf dem entfernten Rechner grafische Applikationen starten und das Display wird über den ssh-Tunnel umgeleitet.

Display umleiten ist in der Unix- und Linux-Welt schon seit über 25 Jahren gängige Praxis, aber mit ssh geht es nun auch sicherer als mit den unverschlüsselten Protokollen, die man damals gerne verwendet hat. Wer kennt noch xhost +?

Diese Überlegungen beziehen sich auf ssh unter Linux, gelten aber auch für alle möglichen Unix-Systeme, wie z.B. Solaris. Auf MS-Windows-Rechnern gibt es putty als verbreitete SSH-Client-Implementierung. Mit Putty findet man sicher vieles von dem wieder, was das Linux/Unix ssh kann, nur in etwas anderer Verpackung. Ich bevorzuge aber auf MS-Windowsrechnern cygwin und dessen ssh-Implementierung, die sehr ähnlich funktioniert. Es ist sogar möglich, mit cygwin einen ssh-Server aufzusetzen. Allerdings ist der Vorgang nicht ganz einfach.

Share Button

Zufallszahlen

Wofür braucht man überhaupt Zufallszahlen? Es gibt recht viele probabilistische Algorithmen, die besser funktinonieren, wenn man „gute“ Zufallszahlen hat. Besonders wichtig sind diese aber auch in der Kryptographie, zum Beispiel zur Generierung von Schlüsseln.

Die Qualität der Zufallszahlen ergibt sich aus der Vorhersehbarkeit des nächsten Werts. Wenn dieser z.B. mit heutigen Mitteln aus bekannten Werten berechnet werden kann oder nur schon dieser berechnete Wert mit höherer Wahrscheinlichkeit zu erwarten ist als bei Gleichverteilung, dann sind die Zufallszahlen nicht mehr optimal. Man kann dann zum Beispiel den „private key“ eines Schlüsselpaars erraten und dadurch die Sicherheit des Verfahrens vermindern.

Nun ist die Frage, ob es wirklichen Zufall in der Natur gibt. Nach heutigen Erkenntnissen glaubt man das und findet als Beispiel den radioakativen Zerfall. Also müßte nur jeder Rechner einen „Radiumkarte“ eingebaut bekommen und schon hätte man überall gute Zuzfallszählengeneratoren zur Verfügung. Doch es gibt einige andere Effekte, die man nutzen kann, z.B. Zenerdioden oder den Luftdruck. Radiowellen aus dem Weltall wären sicher auf den ersten Blick auch gut, aber da diese für jeden empfangbar sind, ist es sehr schwierig, eine Vorhersehbarkeit der Zufallszahlen auszuschließen. Zenerdioden eignen sich wohl auch ganz gut. So kann man recht gute Zufallszahlengeneratoren auf die CPU einbauen: RdRand (en.wikipedia.org) oder rdrand (Intel)

Ist das Thema damit gegessen? Vielleicht, zumindest für viele Anwendungszwecke. Vielleicht traut man dem nicht und braucht dort, wo es wirklich darauf ankommt, noch bessere Verfahren? Auf jeden Fall wird es noch eine Weile dauern, bis man das wirklich verwenden kann. Heute haben das neue Intel-CPUs, wann haben es auch CPUs anderer Hersteller? Wann wird das durch die verschiedenen Betriebssysteme genutzt? Mindestens ein paar Jahre dürfen wir uns noch darauf freuen, daß dieses Feature breit verfügbar ist.

Linux hat einen Zufallszahlengenerator auf OS-Basis, der als /dev/random ansprechbar ist. Dieser nutzt „Zufälligkeiten“ wie Tastatureingaben, Mausbewegungen, vielleicht auch Plattenbewegungen u.s.w. aus. Vielleicht nicht ganz so gut wie rdrand, aber dafür schon lange verfügbar. Vielleicht haben andere Betriebssysteme ähnliche Möglichkeiten.

Wie funktioniert das? Wenn man teilweise zufällige Informationen hat, dann läßt sich das nächste Stück mit einer gewissen Wahrscheinlichkeit vorhersagen. Typisches Beispiel wäre etwa ein Text, der eingegeben wird. Der kann einer abstrakten Sprache angehören, z.B. einer natürlichen Sprache, einer Programmiersprache (mit einer natürlichen Sprache für die Kommentare) oder so etwas. Wenn das einigermaßen fehlerarm eingegeben wird, dann läßt sich ein unvollständiges Wort oft auf nur wenige Arten vervollständigen, so daß von den vielen möglichen Zeichen einige wenige wahrscheinlich sind. Wenn man mal von einem 8-bit-Zeichensatz ausgeht, bringt dieses eine Zeichen vielleicht nur etwa 1 Bit an Information, wenn etwa zwei Vervollständigungen sehr wahrscheinlich sind, statt 8 Bit. Dieses eine Bit wäre idealerweise die Zufälligkeit, also ein Zufallsbit, wenn man es schafft, das herauszudestilieren.

Nun ist es bei eingegebenen Texten etwas schwieriger. Wenn das bekannte Texte sind, etwa weil es abgeschrieben wird, oder wenn es ein ehemaliger Minister schreibt, sogar kopiert wird, dann besteht die Zufälligkeit nur noch in der Auswahl der passenden Texte, aber auch bei selbstgeschriebenen Texten schränkt der Kontext ein, was passen würde und was wahrscheinlich ist. Hinzu kommt das Wissen des Schreibers, dessen „Fingerabdruck“, der sich auch in den verfaßten Texten (oder Programmen oder was auch immer geschrieben wird) ausdrückt. Vielleicht ist das Wissen eines Menschen groß genug, um für viele Jahre oder sogar ein Leben lang Texte zu produzieren, die genug Zufälligkeit enthalten, aber wenn keine neue Information durch Kommunikation einfließt, ist das doch zu hinterfragen. Aber viele von uns arbeiten in Bürotätigkeiten, die in irgendeiner Form überwiegend darin bestehen, zu kommunizieren oder doch zumindest etwas einzugeben oder zu schreiben. Vielleicht gibt es dabei gänzlich unkreative Tätigkeiten, wo man etwas ausfüllen muß und genau eine Lösung richtig ist. Aber alle auch nur teilweise kreativen Tätigkeiten produzieren Information, die ohne diese nicht da war und würden sich somit als Basis für die Zufallszahlengenerierung grundsätzlich eignen.

Wir brauchen vielleicht den Kontakt zu unseren Mitmenschen, um neue Ideen zu entwickeln. Und nun fließt die aufgenommene Information natürlich wieder ein. Deshalb ist die Zufälligkeit der geschriebenen Textinhalte nicht leicht abzuschätzen und sie sinkt vielleicht um eine Größenordnung, wenn man verschiedene der hier angesprochenen Aspekte zu fassen bekommt oder ignoriert, weil man sie für nicht fassbar hält. Nun kann man die Texte aber verlustfrei komprimieren. Wenn man viel darüber weiß, was wirklich die reine Information (oder der Zufallsgehalt) ist, auf eine Größe, die knapp über diesem Informationgehalt liegt. Nun kann man auch geschickte „Hash-Codes“ verwenden, die aus den Texten Bytesquenzen generieren, die etwas kleiner sind, als der Informationsgehalt. Wenn das gut gemacht wird, ist das ein brauchbarer Zufallszahlengenerator, der aber für kryptographische Anwendungen sofort einiges an Wert verliert, wenn man aus der Kommunikation der Person nach dem Verfassen des Textes oder gar aus der direkten Verwendung des Textes Rückschlüsse auf diesen ziehen kann.

Wenn der Text öffentlich oder teilweise öffentlich zugänglich wird, zum Beispiel auf einer Webseite erscheint, wie der Text, der hier gerade geschrieben wird, dann besteht die Zufälligkeit nur noch in der Auswahl des Textes von den Milliarden Webseiten, die es gibt, was aber nur noch maximal ein paar Dutzend Bits sind. Und wer will schon eine kreative Tätigkeit nur für die Zufallszahlengeneration ausüben, ohne daß die eigentlichen Ergebnisse dieser Tätigkeit sinnvoll verwendet werden? Und wer will das gar noch bezahlen?

Die Zeitabstände zwischen den Tastatureingaben sind sicher auch so etwas wie ein Fingerabdruck, was individuell den Schreiber erkennen ließe, aber die Zufälligkeit dieser Zeiten läßt sich viel besser nutzen, weil wir das nicht verwenden, um Information zu transportieren. Ich werde mich also auch nicht erinnern, welche Zeitabstände ich zwischen den Zeichen hatte, außer daß der Schreibrhythmus natürlich beim nächsten Mal ähnlich (aber nicht identisch) sein wird. Und die Zeitabstände sind auch nicht auf dieser Webseite nachlesbar.

Share Button

Verknüpfung Social Media anderen mit Webseiten

Wir finden oft auf beliebigen Webseiten Facebook-„Like“-Buttons oder „+1“-Buttons oder „Twitter“-Buttons. Ich habe selber welche hier drauf.

Es gibt aber auch Seiten, die anbieten „login mit Facebook“ oder „login mit Google+“ oder „login mit Twitter“.

Was bedeuten diese Verknüpfungen?

Es sind, wie man unschwer erkennen kann, zwei verschiedene Mechanismen. Grundsätzlich basieren sie darauf, daß viele von uns an einem oder mehreren dieser Social-Media-Systeme teilnehmen. Dazu muß man dort einen Account erwerben, eine Mailadresse und eventuell eine Mobiltelefonnummer angeben, ein Password und ein Captcha abtippen und dann ist man nach der Bestätigung einer Testmail dabei. Nun gibt es Leute, die sich nach Gebrauch bei diesen Social-Media-Seiten abmelden und sogar die Cookies aufräumen oder im „private-Modus“, den Firefox anbietet, auf diese Seiten gehen. Das ärgerliche daran ist, daß man mehr und mehr dazu übergehen muß, wirklich gute Passwörter zu verwenden und auch noch verschiedene für jede dieser seiten. Und man darf sie nicht aufschreiben. Das ganze soll dann noch auf diversen Computern, Mobiltelefonen und anderen Geräten funktionieren. Und google bietet schon einen sichereren Login-Mechanismus wie bei E-Banking an, wo man zusätzlich noch einen SMS-Code eingeben muß. Schlimm, wenn man sein Leben in diese Social-Media-Systeme verlegt hat und sein Mobiltelefon verlegt hat. Aber sowas kann uns in der heutigen Zeit ja nicht passieren… Eher vergißt man seine Füße oder seinen Kopf oder so etwas zuhause, wenn man aus dem Haus geht.

Die Erfahrung zeigt, daß die meisten Computerbenutzer immer bei allen Social-Media-Netzen eingeloggt sind. Man kann also Facebook, Google+ und Twitter starten und einfach losschreiben. Wie sicher ist das? Nun, gemäß N. Kaspersky: „A security guy who says that something is absolutely secure is not a real security guy“. Ob ich nun ein Security-Guy bin oder nicht, es ist also nicht absolut sicher, denn wenn der Rechner, an dem wir sitzen, Teil eines Bot-Netzes ist, hat der Bot-Netz-Betreiber Zugriff auf alles, was auf dem Rechner läuft, also auch auf Cookies, Passwörter, Tastatureingaben u.s.w. Je nach Features der Bot-Netz-Software. Und es sind so viele Rechner in der Welt mit Schadsoftware „infiziert“, daß diese Botnetze groß sind. Man kann sie ja von entsprechenden Geheimfirmen im zehntausender-Pack mieten, habe ich gehört.

Aber gut, wenn unser Rechner sauber ist und wenn wir nicht glauben, daß der Hersteller eines propritären Betriebssytems Features eingebaut hat und nutzt, um sich auf unserem Rechner umzusehen, dann kommen wir zur Serverseite. Jede von diesen Seiten, auf der wir uns einloggen können, muß Passwörter speichern, außer sie setzen ganz auf dieses „login in via…“-Zeug. Wenn wir überall verschiedene Passwörter verwenden, ist das nicht so tragisch, kann aber schnell *sehr* ärgerlich werden, wenn jemand Kommentare oder EMails oder Tweets unter unserem Namen schickt. Vor allem, wenn man das nicht so schnell merkt. Aber man kann auch Server, die im Internet stehen, vernünftig absichern und das Risiko von Einbrüchen über das Netz verringern. Wie sieht es mit der Netzwerkverbindung aus?

Auf Seiten, die ein Passwort erfordern, sollten wir immer https verwenden. Das hat den Nachteil, daß die Proxys nichts mehr cachen können, weil für dieselbe Seite durch die verwendete Verschlüsselung für jeden Empfänger andere Daten übertragen werden. Die grobe Idee ist etwa die folgende: Der https-Server hat ein Zertifikat, das im Wesentlichen aus einem privaten Schlüssel besteht, der nur auf dem Server bekannt sein darf, und aus einem öffentlichen Schlüssel, der in mit dem Domainnamen und weiteren Metainformationen verknüpft ist und wiederum mit dem privaten Schlüssel einer Zertifizierungsstelle signiert ist. Die Browser kennen nun die Public-Keys aller gängigen Zertifizierungsstellen und können so diese Kombination abprüfen. Wenn also die Zertifizierungsstelle sauber arbeitet, vergibt sie das Zertifikat nur an denjenigen, der die entsprechende Domain hat. Nun kann unser Browser erkennen, ob wir wirklich mit der Domain kommunizieren, zu der das Zertifikat gehört. Wenn nicht, erscheinen komische Fehlerboxen, die man nicht einfach wegklicken sollte. So wird schon verhindert (oder sehr erschwert), daß wir über gefälschtes DNS, gefälschtes Routing oder gefälschte Proxys auf die falsche Seite gelangen. Denn die falsche Seite kommt nicht an das richtige Zeritifikat heran, bzw. kann es nicht einfach aus dem öffentlichen Teil rekonstruieren, weil der private Schlüssel fehlt.

Die gesamte Kommunikation findet verschlüsselt statt und man kann dabei eine Verschlüsselung haben, die wahrscheinlich nach heutigen Erkenntnissen sichtbar ist. Vielleicht kann jemand den https-Traffic aufzeichnen und in 20 Jahren entschlüsseln, aber dafür muß es schon sehr interessant sein. Wichtig ist, daß das Passwort nicht im Klartext über das Netz geht. Nun bekommt der Browser einen Cookie, also ein paar Bytes. Jedesmal wenn wir auf dieselbe Seite gehen, wird dieser Cookie wieder an den Server geschickt und daran kann dieser erkennen, daß wir noch eingeloggt sind. Wenn nur das login via https erfolgt, der Rest der Kommunikation aber über http, kann unterwegs jemand den Cookie abgreifen und unsere Session übernehmen. Daher ist es sinnvoll, die Seiten mit login komplett via https anzusprechen.

Wenn nun jemand, der in Facebook noch eingeloggt ist, auf eine Seite mit like-Buttons kommt, dann wird mit dem Laden dieser Seite auch ein bißchen Code von Facebook geladen. Dabei wird der Cookie an Facebook geschickt und die wissen dadurch etwas darüber, welche Webseiten uns interessieren. Mit dem Like-Button wird nun etwas bequemer dasselbe nachgebildet wie wenn wir die URL in ein Facebook-Fenster Kopieren und man kann je nach Social-Media-System noch etwas dazu schreiben.

Dieser Login-via-Google-Knopf dient zwei Zwecken. Er soll uns Anwender sparen, noch ein Passwort mehr zu lernen und er soll dem Serverbetreiber sparen, die Passwörter sicher zu handhaben. Aber auch hier wird natürlich google (oder twitter, Facebook o.ä.) über den Besuch der Seite jeweils informiert. Damit das funktioniert, müssen wir als Benutzer in unserem google-Account die Seite, auf der wir uns einloggen, autorisieren, unsere Identitätsinformation zu beziehen, wenn wir dort eingeloggt sind. Das ist, wenn man es sich überlegt, nichts anderes als ein Login. Aufpassen muß man aber, daß wir diesen Seiten nicht zu viele Rechte auf unserem Account einräumen, sonst schicken die Spam-Nachrichten oder so etwas in unserem Namen.

Share Button

Drittanwendungen in Twitter, Facebook, Google+ & Co.

Diese Social-Media-Systeme erlauben es, daß man Drittanwendungen Zugriff auf seinen Account gibt. Es gibt durchaus legitime Gründe, aber man sollte schauen, ob man der Drittanwendung und deren Security-Team traut und eventuell die Zugriffe abstellen oder reduzieren. So geht es:

Twitter mit Web-Client (geht auch auf dem Mobiltelefon mit twitter.com):

  • Oben rechts das Zahnrad anklicken
  • In dem Zahnrad-Menü auf „Einstellungen“
  • Links auf „Apps“
  • Die Liste der Apps durchschauen und die unerwünschten Zugriffsrechte sperren

Facebook mit Web-Client (geht auch auf dem Mobiltelefon mit facebook.com):

  • Auch oben rechts das Zahnrad anklicken, ist nur kleiner als bei Twitter
  • In dem Zahnrad-Menü auf „Konto-Einstellungen“
  • Links auf Anwendungen
  • Unerwünschte Anwendungen weg-x-en
  • Legitime Anwendungen mit „Bearbeiten“ überprüfen

Google+ mit Web-Clienten (Gugel+):

  • Auch oben rechts das Zahnrad anklicken, ist wieder größer als bei Facebook. Haben die drei sich abgesprochen??
  • In dem Zahnrad-Menü auf „Einstellungen“
  • Sicherheit
  • Verbundene Anwendungen und Websites: „Zugriff verwalten“
  • Verbundene Websites, Apps und Dienste
  • Bei unerwünschten Anwendungen die Zugriffsrechte widerrufen

Nun gibt es Seiten, die ein „Login mit Facebook“, „Login mit Google(+)“, „Login mit Twitter“ o.ä. erlauben. Dieser Mechanismus ist besser als überall dasselbe Passwort zu verwenden, ob man ihn will oder nicht ist eine längere Diskussion. Aber alle Seiten, auf denen man sich mit Twitter, Google oder Facebook anmeldet, tauchen hier auf und wenn man die weglöscht, löscht man sein Login auf diesen Seiten. Aber warum eine Seite, auf die ich mich mit Twitter anmelden kann, deshalb das Recht bekommen soll, in meinem Namen Tweets oder Facebook-Kommentare oder Google+-Beiträge zu schreiben, ist eine andere Frage.

Und noch was: Seiten, auf denen man sich einloggt, bitte immer mit https und nicht http ansprechen! Wenn die Seite kein http kann, dann ist das Passwort dieser Seite quasi öffentlich, sollte also auf keinem Fall mit einem Passwort auf einer https-Seite übereinstimmen. E-Banking ist immer mit https. Google(+), Facebook, Xing, Wikipedia und viele andere Seiten können mit https angesprochen werden oder schalten automatisch darauf um.

Ich versuche bis zum kommenden Freitag einen Blog-Artikel zu schreiben, in dem ich genauer auf die Funktionsweise dieser Mechanismen eingehe.

Share Button

Cyber-Attacke gegen Twitter

tagesanzeiger.ch

Share Button

Security: physikalische Trennung

Für viele Aktivitäten im Internet ist die schwächste Stelle der Weg durchs Internet, da dieser oft unverschlüsselt erfogt, zum Beispiel über http oder über EMail. Auch ein verschlüsselter Kommunikationspfad (z.B. https oder skype) hilft natürlich nur so weit, wie man dem Betreiber des Servers traut, auf den man dabei zugreift. Durch Umstellung der Kommunikation auf sicherer Mechanismen (z.B. https) wird der Kommunikationspfad sicherer. Dabei finden solche Zugriffe über das Web heute nicht nur sichtbar über die mit dem Browser angesurften Seiten und deren Ergänzungen (Bilder, CSS, JavaScript) statt, sondern auch durch Programme, insbesondere JavaScript-Programme, die im Browser laufen und sich einzelne Informationsstücke vom Server holen und diese in die Seite einbauen.
Das heißt u.a.:

  • Ein Angreifer im Netz kann nur mit sehr großem Aufwand oder gar nicht abhören, was der Inhalt der Kommunikation ist. Das betrifft beide Richtungen, also auch die Frage, welche URLs man auf dem betreffenden Server anspricht. Sehr nützlich ist das auch beim Einloggen für die Übermittlung des Passwords.
  • Ein Angreifer kann die Nachricht nur mit sehr großem Aufwand oder gar nicht ändern oder verfälschen. Da ist man gerade beim e-Banking froh, wenn das nicht so einfach ist.

Eine Schwachstelle bleibt aber der Rechner des Benutzers selbst. Den hat man ja bei sich im Haus stehen und da kommt kein Einbrecher durch die Tür und macht damit was Ungewünschstes, außer es ist ein Laptop oder ein Rechner im Großraumbüro. Aber wir wissen ja, daß der Einbrecher unsichtbar durch das Netz kommt. Sobald man einen Rechner direkt ins Netz hängt, kann man beobachten, daß Angreifer ihn nach kurzer Zeit entdecken und alle möglichen Attacken probieren, die auf häufige Schwachstellen aufsetzen. Das geht heute natürlich alles vollautomatisch. Auch sonst gibt es viele Wege für Schadsoftware auf den Rechner und Al Capones heutige Berufskollegen haben ganze Botnetze aus Rechnern anderer Leute aufgebaut, die ihnen zwar nicht gehören, aber gehorchen. Solange diese kriminelle Nutzung des Rechners im Hintergrund bleibt, merken das viele Benutzer gar nicht, weil das, was sie selber machen, ja noch funktioniert, nur vielleicht etwas langsamer. Wenn es zu langsam läuft, hilft bei MS-Windows-Anwendern oft das „Windows neu installieren“, dann ist nebenbei die Schadsoftware auch wieder weg, wenn man Glück hat. Anscheinend sind auch staatliche Stellen mancher Staaten in diesem Bereich unterwegs. Heutige Mobiltelefone sind natürlich auch fast vollwertige Rechner, also von solchen Überlegungen auch betroffen. Nun ist schon an sich ärgerlich, Teil eines Botnetzes zu sein, weil man dadurch letztlich ungewollt daran beteiligt ist, wieder andere Rechner anzugreifen oder andere kriminelle Aktivititäten des Botnetzbetreibers zu alimentieren. Interessant ist aber auch der Gedanke, daß der Botnetzbetreiber den vollen Zugriff auf den Rechner hat, also zum Beispiel beim e-Banking im Browser die unverschlüsselten Daten sehen und ändern kann. Das ist schwierig, aber prinzipiell möglich.

Ein recht drastischer Ansatz wäre nun, in einem Laptopgehäuse oder sogar in einem Mobiltelefongehäuse physikalisch mehrere Rechner unterzubringen. Der Raspberry Pi zeigt, daß es möglich ist, kostengünstig sehr kleine (Linux-)Rechner zu bauen. Wenn das Gehäuse eines neuen Laptops nur etwas größer ist, bringt man zusätzlich noch so einen kleinen Rechner darin unter, der keine oder nur sehr wenige lokale Benutzerdaten speichert und nur für e-Banking und andere sicherheitskritische Aktivitäten benutzt wird. In Desktoprechner wird der zusätzliche Platzbedarf im Gehäuse kaum auffallen. Ich stelle mir ein speziell schlankes Linux vor, das als einzige Applikation einen Browser hat, der für diesen Zweck optimiert ist. Mit einem Schalter wird physikalisch umgeschaltet, welcher Rechner Display, Tastatur und Maus hat.

Ein ähnlicher Effekt ließe sich natürlich auch erreichen, wenn man seinen Rechner voll virtualisiert, so daß das direkt auf dem Rechner laufende System nur dazu dient, virtuelle Umgebungen für die Systeme bereitzustellen, in denen man dann arbeitet. Wenn das gut gemacht ist, hat man auch eine recht gute Trennung zwischen dem e-Banking-System und den anderen virtuellen Sytemen auf dem Rechner, aber man hat in diesem Fall immmer die Performance-Einbuße durch die Virtualisierung hinzunehmen. Das läßt sich alles auch für Mobiltelefone umsetzen, nur muß man dann natürlich ein paar Gramm mehr und ein dickeres oder größeres Telefon mit sich herumschleppen, weil diese ja schon recht vollgepackt sind.

Ich habe mal eine Startup-Firma gesehen, die Desktoprechner nach diesem Prinzip gebaut hat, sogar mit mechanischen Schaltern und drei separaten Rechnern in einem Gehäuse. So etwas kann man aber trotzdem heute noch kaum kaufen, aber ich denke, daß es vielleicht eine gute Idee ist, die sich in ein paar Jahren etablieren könnte.

Share Button