Login Mechanisms

By Karl Brodowsky IT Sky Consulting GmbH

Deutsch

E-Banking examples

  • „Calculator“
  • RSA-Number-Generator
  • SMS
  • Sheet with 100 Codes
  • Android-App
  • USB-Device
  • SmartCard
  • Not so common for banks: plain old username+password
  • Login with google, twitter, facebook

Calculator

  • Enter PIN Code
  • Enter Code from login page
  • Read Result from calculator
  • Enter Result in Login Page

Security Questions:

  • Depends on how the calculator works
  • Due to calculator PIN/Password some security agains theft/loss of device

Practical Questions:

  • Always forgotten calculator
  • Expensive hardware required

Summary:

This method is potentially quite good, if it is done well with good algorithms and good data.

Number Generator

  • On login page enter 6-digit code from RSA device in addition to username+password

Security issues

  • Looks good because it comes from RSA
  • Does the timing always work well enough in sync (apparently yes)?
  • Device can be stolen, no additional protection
  • No Challenge-Response, not as good as the calculator

Practical issues:

  • Device is small enough to be in the pocket all the time
  • Device is quite expensive

SMS

  • Enter username and password
  • Receive code by SMS
  • Enter Code

Security issues

  • How secure is the mobile network?
  • How secure is the phone? Not-so-smart phones are better. Ideally use the old Nokia phone for this with a prepaid SIM-card
  • For m-banking two phones are needed or the security is much lower

Practical issues

  • Phone is in the pocket
  • But if an additional phone is needed just for this not very practical any more
  • Sometimes SMS get lost
  • some people play with many SIM cards (not a common problem)
  • Battery of phone can be empty (only a problem for older generation)

Summary

This seems to be a solid mechanism, but is slightly inferior to the calculator.

Sheet with 100 codes

  • Login with username and password
  • Page requests code with a given number from a given sheet.
  • Each number is used only once
  • New sheet supplied when 80% used up

Security issues

  • Depends on quality of numbers
  • Paper can be lost or stolen
  • Printing and handling of numbers leaves a lot of vulnerability which is hard to control.

Practical issues

  • Paper needs to be managed by bank and customer
  • Needs to be in the luggage or as image on the phone
  • Needs to be stored carefully

Summary

Mechanism seems to be in the middle field. Apart from being uncool the mechanism is not so bad, but it is inferior to the calculator.

Android App

Can off course technically work for your favorite smart phone, even if it is not Android… 😉

  • Login with username and password
  • A colored code is displayed:

code

  • Run Android App which takes a photo of the code and provides a 6 digit code plus some information.
  • Enter that for login
  • Remark: the App needs to be personalized, so it is only working for the own e-banking, not for someone elses.

Security issues

  • No password within App
  • Depends on keeping phone safe
  • Positive is that it is so easy that it can be used a lot, even for verifiying single bookings to an unknown receipient
  • The code can transport information that can be displayed in the

Practical issues

  • Requires Smart phone that supports the App
  • Phone is always in the pocket

USB-Device

An USB-device is plugged into the PC. It can be „smart“ and communicate directly with the server. Can also provide secure browser or even boot PC into a specially safety-hardened Linux distribution.

I have only theoretical knowledge about this, not used it.

Security issues

  • Has a lot of potential
  • A „bad PC“ can be a problem, but there are ways to implement this that are quite secure, as long as encrypted data traffic is considered secure at all. If not, we should forget the internet for anything that requires any non-trivial level of security.

Practical issues

  • requires special USB-stick
  • USB is disabled or „castrated“ on many PCs, so it might be hard to let the PC accept the device
  • Are there „device driver issues“?

Smart Card

This is just like the USB device, but with a chip card instead of an USB device.

Username + Password

  • For ebanking not enough (some banks don’t care)
  • For „simple“ apps it is a pain to keep usernames and passwords safe on server
  • Still „easy default“
  • How about user management?

Security issues

  • This has the lowest security of all mechanisms presented here.
  • user and password database is always a risk

Login with Google

  • Use google+, facebook, twitter etc. for login
  • Assume Google here…
  • Login into google (you normally are anyway…)
  • Click login with google
  • First time google asks if it is ok to provide the identity information to web page xyz
  • In Google settings this can be removed…

Security issues:

  • Do we want to have NSA-connected companies involved in our login process?
  • User management is something that the big guys claim to do well
  • OAuth2 is our friend for this, it is not so hard to do

Just remember this

  • Always use https when serious about security
  • http means transmitting password unencrypted and making some of our „friends“ who could intercept traffic very happy
  • Especially if it deals with money.
  • Serious https helps at least a little bit
  • Maybe, who knows what the NSA knows. 🙁

As a task for me I have to get this page on https…

 

Share Button

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

Auf GPU rechnen

Heutige Rechner haben bekanntlich sehr leistungsfähige CPUs mit „Quadcore“ und mehr.
Aber auch die Grafikkarten sind ziemlich toll geworden und haben zum Teil auch so große eigene Lüfter wie die CPU.
Sie haben eine Menge eigenes Memory und sie können recht komplizierte Operationen selbsttätig rechnen, natürlich nur für die grafische Darstellung.

Nun stellt sich die Frage, ob man das auch sonst zum Rechnen benutzen kann. Man hört Geschichten, dass die Grafikkarte um Größenordnungen leistungsfähiger als die CPU sei. Warum schaffen das die Grafikkartenhersteller so leicht nebenbei, besser als die CPU in deren Kernaufgabe zu sein und außerdem noch Grafik darzustellen?

Grafikkarten bieten die Möglichkeit, massiv parallel zu rechnen, aber nach dem Prinzip SIMD. Das heißt, dass ein oder sehr wenige Befehlsströme verarbeitet werden und eine große Zahl von Recheneinheiten jeweils den identischen Code mit verschiedenen Daten ausführt. Für Vektoroperationen ist das optimal. Und es erklärt auch die brachiale Leistung der Grafikchips, weil man den aufwändigen Teil, Maschinencode zu interpretieren, nur einmal (oder wenige Male) baut und nur die eigentliche Recheneinheit mehrfach. Man bekommt so mit derselben Siliziummenge mehr Rechenleistung, aber mit der Einschränkung, SIMD (oder fast SIMD) zu sein. Aber man hat diese Geräte in den Rechnern drin. Es gibt sogar „Grafikkarten“, die nur rechnen können, aber bei denen man die eigentlichen Grafikchips weggelassen hat. Und viele Rechner haben den Grafikkern mit auf dem selben Chip wie die CPU-Kerne, so dass man eine einfache Grafik zur Verfügung hat, aber man baut dann doch zusätzlich noch eine externe Grafikkarte ein, die noch besser ist. Selbst ohne die Grafikfähigkeit zu gefährden hat man also eine GPU zum Rechnen übrig.

Nun ist das Programmieren dieser Geräte nicht so einfach. Grundsätzlich muss man sich mit einem völlig neuen Programmiermodell herumschlagen. Viele Algorithmen lassen sich speziell für SIMD entwickeln, aber sie sind anders als was wir gewohnt sind und automatisch lässt sich da nur beschränkt etwas optimieren. In der Regel muss man also mit C das Programm schreiben und kann dabei auf OpenCL bauen. Das ist ein nützlicher Standard, der einiges erleichtert, aber es bleibt schwierig. Für manche Zwecke lohnt es sich aber, den Entwicklungsaufwand zu treiben.

Vor ein paar Tagen habe ich drei Vorträge über Ansätze gehört, F# zu verwenden, um die GPU zu programmieren. Man kann also unter Einhaltung gewisser Regeln F#-Programme schreiben, die sich etwa in OpenCL übersetzen lassen und dann compiliert die GPU nutzen:

  • FSCL: Homogeneous Programming and Execution on Heterogeneous Platforms (by Gabriele Cocco, Pisa University)
  • Professional GPU Development with F# and the Alea Compiler Suite (by Daniel Egloff, QuantAlea)
  • New Abstractions for Radically Simplified GPU Programming in F# and .NET (by Luc Bläser, HSR, based on joint work with QuantAlea)

All diese Ansätze sollten schon heute oder zumindest in zukünftigen Implementierungen auch für Mono laufen und damit für Linux zur Verfügung stehen.

Es würde wohl den Rahmen dieses Artikels sprengen, im Einzelnen darauf einzugehen, aber vielleicht kann ich noch Links bekommen, die auf weiterführendes Material zu den einzelnen Lösungsansätzen führen.

Share Button