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

Ein Gedanke zu „Login-Verfahren

  1. Pingback: Login Mechanisms | Karl Brodowskys IT-Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


*