Banks & MFA – Fatally Flawed Solutions!

Banks “improving” security

About 6 months ago one of my bank account providers decided to change the online login security measures so as to “improve security”… they went from username and password to username, password and selected characters from a so called “memorable phrase”.

 

About 2 months ago another followed suit – again username and password were replaced by username, password and selected characters from another so called “memorable phrase”.

 

The Futility of Complaining

In both instances I complained to the bank that they were not improving security but were in all likelihood not improving security but:

  1. Stopping their customers from using password managers

  2. Making their customers most likely write passwords down

  3. Increasing the likelihood that if a breach of their security occurred user passwords and memorable phrases could be exported and used at a later date.

In my complaints I explained why this was to the banks and asked if they could explain how i) they were securing my account and ii) why they could not devise a solution that supported password managers iii) why they could not introduce MFA using a authenticator app.

In both instances I got a reply from the bank saying that they were unable to progress with my complaint as they do not reveal the security measures in place to protect their customers.

 

What’s so wrong with “memorable phrases”?

There is nothing wrong with a memorable phrase… its just that a second password isn’t a second factor and that’s exactly what a memorable phrase is. Normally a second factor (MFA means multiple factor authentication so 2FA is a special case of MFA) is not of the same type as the first factor… so think about a password being something I know whilst a second factor would be something I have… not something else that I know as that’s just a second instance of the first factor.

 

OK so is there something wrong with requesting specific characters?

Yes. Oh yes indeed. What’s wrong here is a little more complex and has to do with how passwords should be stored by the bank.

Let’s suppose my password is “chicken” and that there are no requirements to have upper case, lowercase, numbers and special characters in my password.

“chicken” has the SHA256 hash of 811EB81B9D11D65A36C53C3EBDB738EE303403CB79D781CCF4B40764E0A9D12A

and on the web its possible to enter this SHA256 hash and get the original work “chicken” back because its a regular word.

My bank needs to verify my password but if they keep my password as it is then if their password database is compromised so is my account. They need to store my password in a manner that it cannot be read and ideally where they cannot read it either. This way if they are compromised then I am still safe.

This isn’t encryption because if they encrypt my password they can also decrypt my password.

This is the purpose of a cryptographic hash function – a hash function takes a string of characters and transforms it into another string of fixed length. A cryptographic hash function is one direction meaning that without a hash dictionary (i.e. containing a list of words and the resulting hash values) you cannot determine what the original string of characters was.

This is why most websites require passwords that aren’t simple dictionary words but combinations of words, numbers, upper case, lowercase, special characters and of a certain minimum length. By doing this they ensure that the hash values are less likely to be reversed by using a hash dictionary.

“Ch1ck3n” has the SHA256 hash of

102425B52377B75B375A1B0CB6B0C78164B2C06826AEDB22F53754F12DDE456C

and this still appears on the web on a SHA256 dictionary site.

To further improve password security best practice has it that a so called “salt” is added to the users password before it is hashed. This “salt” is a per user random string of characters that is stored in the user database with the hash of the password and ensures that no matter what the users password is the hash cannot be used to determine the value of the users password. It can only be used to verify the correct password is entered.

“Ch1ck3n” with the salt “fpIqIfOWPpwOxVU2rG5F” added to the end has the SHA256 hash of

69409FE7F9488474E078DF3927F728149823A1429F9961C4E268F50091AD4410

and turns up nothing on the web on a SHA256 dictionary site.

So if my bank is storing my password or memorable phrase correctly they should not be able to determine what it actually is but only that I have entered it correctly and when combined with the “salt” and passed through the hash algorithm it results in the same hash value they have stored in their user database.

So if the bank can determine individual characters in my password or memorable phrase it means that either:

  1. They are storing my password / memorable phrase in a manner in which they can access it – which means if they are hacked so can a hacker… or

  2. They are storing salted hashes of each individual character of my password which seems very unlikely

On the second option this is better than the first option but still is not fantastic – most memorable phrases can only contain letters which means that there are only 26 different options at each entry… perhaps 52 if they allow upper and lower case letters. Thus a hacker has a 1/52 chance of getting the first character right and a 1/52 chance of getting the second character right – thus a 1 in 2704 chance of getting both right. If I have a 10 character password and I can have upper case, lower case, numbers and special symbols then there are around 100 different characters available and a hacker has a 1 in ~6 x 10^19 (i.e. 6 with 19 zeros after it) chance of getting it right.

So it would be better for a bank to decide to ask for two passwords rather than one password in its entirety and 2 characters from a memorable phrase.

But most importantly i) a memorable phrase isn’t really a second factor – its just a second instance of the first factor ii) the likelihood is they are storing my memorable phrase insecurely iii) using selected characters does not support password managers iv) they won’t tell me how they are protecting my password / memorable phrase so I have to assume the worst.

 

So what should banks do then?

I believe that there are several things banks should do as a matter of urgency.

  • First – they should publish to their customers and potential customers how they are delivering a secure online experience including informing customers how their accounts are protected – if passwords are in use they should explain if the passwords are stored and how they are stored. They should not hide behind a “Discussing our security measures will compromise our security” response – proper online security can be discussed because it should not be possible to compromise security through knowing how something is secured… clearly banks should not be storing passwords in cleartext so the only reason not to publish this is because it’s a security risk, if they were storing salted hashes of passwords they could state this without jeopardizing security.

  • Second – the FCA and NCSC should publish some guidance together on how to properly deliver online security for financial institutions and what information banks should provide to their customers about this.

  • Third – banks should properly invest in developing a MFA solution. There are plenty of MFA technologies to choose from and plenty of information on the web about how to integrate these into an application so it shouldn’t be complex for a bank so (say) replace a memorable phrase with MS authenticator, Google Authenticator or another authenticator app or even to develop their own.

Want to know more?

Why not subscribe to our FREE Newsletter to receive regular updates from us on ICT, technology and what we’ve been doing?