Banking log ins

I

iandoug

Well-Known Member
Joined
Aug 28, 2008
Messages
140
Reaction score
24
Hi

Std bank wants me to move to their new platform, where I will need to log in with my email address and a password.

On current system I need to enter a 16 digit card number, plus a 5 digit pin, plus a password.

Am curious as to what other banks use... (apart from Capitec which I know uses a dongle or app for one-time passwords).

Is it just me or is email+password a major fail as a security system for banking?

Thanks, Ian
 
FNB uses a username and password.
Absa, your card and password with a passphrase.
Capitec - I forgot.
Nedbank - Online Profile Number + Pin + Password
 
Yeah, those sentiments were echoed recently in another thread. I'm sure someone will post the link, as I can't recall it.
 
faniebraai said:
why do you say it's a major fail?
Click to expand...

- using an email address as the primary key makes it more widely known than a random username.
- knowing the email address, it is easier to target phishing attacks
- people tend to use the same email address and password combination
 
ABSA:

You enter your account number and a PIN, which is not the same as your card PIN
On the next screen, you enter randomly chosen characters from your passphrase. It also displays a "memorable phrase" on the screen which you chose when you set up your profile initially, which ensures its not a phishing site
 
Capitec: username+password+security token
 
iandoug said:
Hi

Std bank wants me to move to their new platform, where I will need to log in with my email address and a password.

On current system I need to enter a 16 digit card number, plus a 5 digit pin, plus a password.

Am curious as to what other banks use... (apart from Capitec which I know uses a dongle or app for one-time passwords).

Is it just me or is email+password a major fail as a security system for banking?

Thanks, Ian
Click to expand...

Make sure you keep you use a strong password, keep your password safe and don't use that password for anything else. It would be good if they add a 3rd step or 2FA/3FA.
 
stricken said:
- using an email address as the primary key makes it more widely known than a random username.
- knowing the email address, it is easier to target phishing attacks
- people tend to use the same email address and password combination
Click to expand...

sounds more like a user fail if you ask me
 
faniebraai said:
sounds more like a user fail if you ask me
Click to expand...

Peoples' email addresses are hardly secret. That's even before we consider all the "database leaks" in recent years. So that's already one of two login credentials compromised.

So it's trivial for a botnet to test the banking sites in (Country) with email addresses (from Country), until they find a password that works. Botnets are large, they have all the time in the world, and can stagger the attempts (different sources) so that Fail2Ban does not kick in.

The password requirements are:
Must contain at least 1 UPPERCASE, 1 lowercase, 1 number and a minimum of 8 alphanumeric characters

According to Howsecureismypassword .net....
Your password looks like it might just be a word and a few digits. This is a very common pattern and would be cracked very quickly.

They estimate 2 hours. But that is non-stop on local machine, not logins over the net. But still, won't take forever to crack.

Even worse, there is a max length:
Maximum of 20 characters

Which is worrying... because they should be storing a hash, and then the length is irrelevant.... or am I mistaken? Or maybe they think people will screw up a long password? Even when it is something simple like
ThisIsMyNewStandardBankPassword1

Once my account is breached, the bank will blame me, rather than their inadequate security. And how do I prove I am not at fault?

Yes they send OTP for new beneficiaries but that process has already been broken, judging by press reports.
 
According to Howsecureismypassword .net.... my password will take 16 bn years to crack.
 
iandoug said:
Peoples' email addresses are hardly secret. That's even before we consider all the "database leaks" in recent years. So that's already one of two login credentials compromised.

So it's trivial for a botnet to test the banking sites in (Country) with email addresses (from Country), until they find a password that works. Botnets are large, they have all the time in the world, and can stagger the attempts (different sources) so that Fail2Ban does not kick in.

The password requirements are:
Must contain at least 1 UPPERCASE, 1 lowercase, 1 number and a minimum of 8 alphanumeric characters

According to Howsecureismypassword .net....
Your password looks like it might just be a word and a few digits. This is a very common pattern and would be cracked very quickly.

They estimate 2 hours. But that is non-stop on local machine, not logins over the net. But still, won't take forever to crack.

Even worse, there is a max length:
Maximum of 20 characters

Which is worrying... because they should be storing a hash, and then the length is irrelevant.... or am I mistaken? Or maybe they think people will screw up a long password? Even when it is something simple like
ThisIsMyNewStandardBankPassword1

Once my account is breached, the bank will blame me, rather than their inadequate security. And how do I prove I am not at fault?

Yes they send OTP for new beneficiaries but that process has already been broken, judging by press reports.
Click to expand...

You are spot on with your comment about max length. We are not in the 50's and storage is cheap - there is no reason why a max length should be imposed - unless they are storing it in the clear, which I hope not (and doubt)
 
vic777 said:
You are spot on with your comment about max length. We are not in the 50's and storage is cheap - there is no reason why a max length should be imposed - unless they are storing it in the clear, which I hope not (and doubt)
Click to expand...

Max length for any input is a requirement. Else I could very well stream /dev/random to their server as my "password" and the request never ends.

I'm hoping they store the password as a hash which at least allows the password to be very large, eg. 1024 characters (hopefully something like 4KiB @ 4 bytes per character) or whatever
 
Last edited:
My company is huge on security, our system is username + password (something you know) combined with Yubikey (something you have).

Capitec is the only bank I believe that has the same.
Unless I'm mistaken all the other banks rely on "something you know".

That is simply not adequate imo.
 
Pho3nix said:
FNB uses a username and password.
Absa, your card and password with a passphrase.
Capitec - I forgot.
Nedbank - Online Profile Number + Pin + Password
Click to expand...
Investec uses ID number and password. Thereafter in App confirmation on the cell you set up
 
Gnome said:
Max length for any input is a requirement. Else I could very well stream /dev/random to their server as my "password" and the request never ends.

I'm hoping they store the password as a hash which at least allows the password to be very large, eg. 1024 characters (hopefully something like 4KiB @ 4 bytes per character) or whatever
Click to expand...

Obviously, the limit on the persistence layer field determines what the max length is that can possibly be stored - that is not what I mean. I mean that there is no good reason to limit me to x amount of characters on a password

This is a web page we are talking about here, you can't stream to the HTML input type text, its a control and the form needs to be submitted - how are you enabled to "stream" random data to a HTML control just because max length is not enforced?
 
vic777 said:
This is a web page we are talking about here, you can't stream to the HTML input type text, its a control and the form needs to be submitted - how are you enabled to "stream" random data to a HTML control just because max length is not enforced?
Click to expand...

I mean you realize the format of a HTTP POST is as follows:
Code: 
POST /... HTTP/1.1\r\n
Host: somehost\r\n
Content-Length: 18446744073709551616\r\n
\r\n
username=<some username>, password=<start streaming infinite data until application behave in some strange way>

Obviously I made up my own HTTP POST body, but you can stream forever to a server because HTTP is simply a text protocol (http1.x) on top of TCP.

Most servers require content-length on a post to prevent this sort of attack and/or limit the maximum post length.

But it is in my opinion just bad practice to not set maximum lengths on the front-end.

If I didn't set something on the front-end the above would be perfectly acceptable.
And there is no way an HTTP server can accept 2^64 bytes, most of which will be my password
 
Last edited:
Gnome said:
I mean you realize the format of a HTTP POST is as follows:
Code: 
POST /... HTTP/1.1\r\n
Host: somehost\r\n
\r\n
username=<some username>, password=<start streaming infinite data until application behave in some strange way>

Obviously I made up my own HTTP POST body, but you can stream forever to a server because HTTP is simply a text protocol (http1.x) on top of TCP.

Most servers require content-length on a post to prevent this sort of attack and/or limit the maximum post length.

But it is in my opinion just bad practice to not set maximum lengths on the front-end.
Click to expand...

I misunderstood what you meant originally.

You can do what you suggest regardless whether you enforce max length on the front end or not, if done in Javascript you can edit it in developer mode in Chrome and bypass - or just do a direct HTTP post to the server, using CURL, or whatever tool you want. As you say, max content length will probably help here.

Presumably, the API / servlet on the server side would do sanity checks for this kind of attack though.

My comment wasn't that there should be no limit to safeguard the service at the back, but that the limit should not be due to the fact that the developer thought it would be a good idea to store the password in the clear on the database as a CHAR field or something similar (which I have seen, countless times - it always makes me think the developer is storing something in the clear)

Anyway, just because people can disable front-end validation doesn't mean one shouldn't do it, I agree
 
faniebraai said:
sounds more like a user fail if you ask me
Click to expand...

Really? You'd be comfortable using only your email + password for your online banking instead of a username + password? Come on.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X