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

Some thoughts about ssh

Deutsch

In the good old days, when the participants of the Internet still kind of knew each other, it was reasonable to trust each other, because the bad guys where not likely among the few and they did not have much to gain there from an ordinary user. So it was common to use telnet or rlogin or sethost to connect to other computers. Usually the password was transmitted unencrypted, which was actually quite irresponsible.

Today we have to use ssh instead and it does pretty much what telnet could do in the old days, but also quite a bit more, even much more than can be mentioned in these lines. It is not only important to transmit the password in an encrypted way, but also to ensure that the other side is really the desired node, not some man in the middle, trying to capture the password, which would leave us where we were with telnet.

For this purpose the .ssh-directory contains those certificates, which are files like id_rsa and id_rsa.pub. The id_rsa should be kept safe. They must not be given away, but they should also not be changed, which means that they should not be lost, because they are hard to reproduce, otherwise they would not be secret. The security of the whole protocol depends on this. With ssh-keygen it is possible to create such certificates, optionally in such a way that a password needs to be provided prior to using it. This password remains within the local computer. Certificates have fingerprints, that can be shown with ssh-keygen -l. Exactly this fingerprint will be shown when logging into a node from some other node for the first time and it needs to be confirmed. So it is important to make sure that the fingerprints have been transferred on a safe channel prior to this login, because otherwise we could possibly just confirm the fingerprint of the man in the middle. This is like with infectious diseases. It is necessary to work in a very hygienic way all the way, otherwise the security is at risk. A good way might be to start the first ssh-session to some node in a cabled network, where the cable and network topology is well known and trusted and simple enough to assume that the network traffic really goes to the desired host. Another way is to write down the fingerprint on paper or to print it or to use a USB stick to copy it to the host from which ssh is initiated. With this first login an entry to .ssh/known_hosts is created, which will be used subsequently. As long as .ssh/known_hosts contains no corrupted entries, it will be very hard for a man in the middle to do his evil job and the whole process provides a reasonable level of security.

Now the public key from id_rsa.pub of the own computer can be transferred to the remote computer and added to .ssh/authorized_keys on the remote hosts. This results in the possibility to log into that host without the need to enter a password, unless the local certificate needs a password, which it should in such a case. For convenience this password needs to be typed only once per session by calling ssh-add.

ssh is used even for other purposes, because it supports tunneling of other protocols like subversion or git.

Very beautiful is the possibility to use ssh in conjunction with X11 by calling

ssh -X user@host

This allows to start graphical applications on the remote computer and they are displayed on the local computer. The x11-windowing system is network enabled and uses the ssh tunnel.

Redirection of displays has been common practice in the Unix and Linux-world for more than 25 years, but with ssh it is much more secure than with the unencrypted protocols that ware used in the old days. Who of you still knows xhost +?

All of this is referring to ssh for Linux, but it should work exactly the same way on all kinds of recent Unix systems like Solaris or BSD variants. On MS-Windows-computers it is possible and useful to install putty. Many of the capabilities of ssh can be found in putty as well, just packaged and used in a different way. I actually prefer to use cygwin and its ssh implementation on MS-Windows, which is very similar to the Linux-ssh. It is even possible to build up an ssh-server with MS-Windows using cygwin, but this is not so easy.

Share Button