By Karl Brodowsky IT Sky Consulting GmbH…
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:
- 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…
Schreibe einen Kommentar