Introduction
You may have seen my previous blog post from the "Aussie banks security" series, where we analysed the situation with the security related HTTP headers. What prompted me to write this new post was the fact that I have recently read a couple of articles about password managers and certain design considerations for web sites (especially around UI design and the underlying HTML layout) to support the use of password managers.
One of the advantages of using password managers is that you can select much longer and stronger passwords. E.g. there is nothing wrong in having a password 100 characters long. This is a great measure against brute force attacks against your password in cases when a corresponding membership database is compromised. But in order to do so the web site should actually be able to accept long passwords.
One of the common issues is web sites applying strict limits on the maximum number of characters that a user can enter into the password field:
<input type="password" size="10" maxlength="6" name="authKey" autocomplete="off">
In the case above a UI will limit the maximum possible password length to just 6 characters.
So I decided to use the same Aussie banks test set to check what they do with their login forms. Are they ready to support password managers? Are there any other interesting observations we can make by looking at the login forms' HTML? And of course it will be interesting to come up with a new rating - who is going to be at the top this time?
Methodology
- I decided to focus on the internet banking login forms (for private customers if there was a distinction between private and business customers)
- I have captured 3-4 lines of raw HTML for each bank (the form tag itself and the username/password input fields)
Something that looked similar to this:
<form name="loginform" action="/daib/processlogon.asp" method="post" autocomplete="OFF">
<input type="text" name="mn" value="">
<input type="password" name="pwd" value="" maxlength="16">
- I have also tried to click the submit buttons as in several cases the error messages were quite descriptive and revealed useful additional information about the accepted data quality, which in turn has allowed me to further clarify and improve my findings.
Here is an example of such error message:
- I put everything into the spreadsheet and analysed the raw data
- For the purpose of ranking I only used information related to passwords (but I will provide additional observations related to other fields too)
For ranking/scoring I used the following approach:
- No password length limitations - green
- Password length up to 16 characters - yellow
- Max password length between 8 and 12 characters - orange
- And there is a special category reserved for the banks that force max password length to be precisely 6 characters - red
Before we proceed to the results, I just want to make it absolutely clear - this is not a "hacking" exercise of some kind. All information is publicly available in HTML or in the error message supplied back by the systems after clicking the login button.
Results
| Bank | Username | Password | Autocomplete | Comment |
|---|---|---|---|---|
| AMP | No limits | No limits | Off | - |
| Bank of Queensland | 1000 | No limits | Off (both form and elements) | Passwords (personal access codes) are case-sensitive |
| Beyond | No limits | No limits (min 6) | Off (both form and elements) | Username: member number - digits only |
| Greater | 12 | No limits | - | - |
| Heritage | 2-16 | No limits | Off (on the form elements) | Username: member number - digits only (2-16). Passwords can be be typed in manually or entered via a virtual keyboard. Virtual keyboard only contains upper-case letters and digits |
| P&N | No limits | No limits | Off (on the form elements) | Password entered via keypad (proper size with digits,upper/lower case/special characters) |
| People's Choice Credit Union | No limits | No limits (client side), min 4 server-side | Off | No limitation on the client side. Server side requires: member number - digits only, password min 4 characters |
| Suncorp | 10 | No limits | Off (on the form elements) | Username: customer id, digits only. Additional security token - digits only |
| Teachers Mutual | No limits | No limits | Off | Passwords submitted as SHA1 hashes calculated on the client |
| ANZ | 19 | No limits (in HTML). Client side validation requires 8-16 | Off (on the form elements) | No password limitation on the form but a pop up warning says 8-16 chars, needs to contain 1 digit and 1 letter. Client side validation won't allow to submit otherwise |
| Bank West | 8 | 16 | Off | Username (PAN) is digits only [0-9]* |
| Bankaust | No limits | 16 | Off (both form and elements) | Username: client number - only digits |
| Commonwealth Bank | 8 | 6-16 | Off | Username: client number (8 digits). Password 6-16 |
| IMB | 9 | 8-16 | Off (both form and elements) | Passwords are case-sensitive |
| Bendigo Bank | 12 | 8 | Off (on the form elements) | Username: Access Id - digits only. Can support 2FA (6 digits authentication key) |
| Macquarie | 8 | 8 | Off (both form and password element) | Username: Macquaries access code (MAC) |
| St George | 16 | 12 | Off | Card number: 16 digits auto-separated by dashes (19 chars). Additional "security number" field (6 digits). |
| CUA | 16 | 6-6 | Off (on the form elements) | Password is called WAC (exactly 6 digits on the numpad) |
| ING Direct | 8 | 6-6 | Off | Username: client number. Password: Access code on the numpad, 8 places in UI but only accepts 6 digits. |
| Newcastle Permanent | 8 | 6-6 | Off (both form and elements) | Password (access code) is precisely 6 digits. Password submitted encrypted (?) (txtPassword_RSA) |
| Westpac | 12 | 6-6 | Off (both form and elements) | Password (via keypad) - can only be 6 chars. Only 0-9,a-z |
Observations
- Only 10 out of 21 banks from this list don't appear to apply password length limitations, making them properly compatible with the password managers. It doesn't mean that you can't use password managers for other banks but the potential quality of passwords will suffer as a result.
- Most of the banks in the "red" category not only limit passwords to precisely 6 characters, some of them go even further and only allow digits in the password field. In 2015 this is just terrible.
- All but 1 banks turn autocomplete off (either on the form itself or on the individual elements). This is interesting because many modern browsers ignore this setting for the login fields.
- Many banks utilise numeric logins (user names). They give them different names (member number, client number, client id, card number etc) but in the essence it is a relatively short sequence of digits. I was surprised by this fact. "Integer" user names are quite weak (predictable, can be iterated through etc)
- Several banks had a 3rd field available for a two-factor authentication process (2FA - tokens etc). I know that some other banks do support 2FA too but it is great to see this functionality on the page, meaning that more people will be made aware of it and hopefully this will lead to the higher adoption rates.
- Some banks use virtual keyboards for entering passwords. Again the terminology varies (numpad, keypad, virtual keyboard etc). Generally speaking this is a better option as it makes it harder for some banking trojans to steal passwords. But I didn't like the fact that some virtual keyboards had a severe negative impact on password quality.
Compare the following examples:
The first one only allows entering passwords that consists of uppercase letters, digits and a space character. This limitation significantly reduces password quality! While the second keyboard provides a much wider variety (uppercase/lowercase, digits, a few special characters).
Or consider the following example:
Only digits and uppercase letters. Combine it with the fact that this bank limits all passwords to precisely 6 characters and you have a situation where a login process is quite weak.
- Special cases - client side processing to avoid submitting passwords in clear text
To be honest I didn't expect that. I spotted a couple of cases where client side javascript was used to "transform" clear text passwords to another representation before submitting it to the server (there might be more - I haven't paid much attention to the way how passwords were submitted to the server as long as it was done via a secure connection).
In one case I think it was a form of RSA encryption and in another case it was a SHA-1 hash.
The SHA-1 example is an interesting one. So the application takes a SHA-1 hash (no salt) of a user supplied password and submits it to the server as part of the login process instead of a clear text original. My initial reaction was "Oh, gee, this is bad!". Indeed, by sending a SHA-1 hash to the application means that:
- The application has to store/rely on this SHA-1 hash (and SHA-1 gets easier to attack/brute force these days)
- It will be very difficult to change the hashing algorithm if they decide to do so (as there will be nothing to compare the new hash against on the server end)
- An attacker knows the length (160bit or 20bytes) and format of every password in the system (essentially a string that consists of 40 hex-digits)
On the positive side - clear text passwords don't traverse the wire.
But then I thought - what they've done is transformed ANY password to a 40 character string (0-9,a-f). Depending on how bad the original password was, this may actually improve password quality for some of them. The hash itself doesn't have to be stored as is. Instead they might use another form of hashing (or encryption) to store those user supplied hashes on the server end. We just don't know. But I still don't like the idea. I'd be keen to know what other security professionals think about this approach.