Investment Platform with 2 Factor Authentication

Eco_Miser

Jsscmm wrote: »

hopefully as a hash for obvious reasons.

Yes, but while with a full password, it is only necessary to compare the hash from the submitted password with the hash from the original password, how is the password hashed so that any three characters from say sixteen can be compared?

Perhaps I've been retired too long.

masonic

Eco_Miser wrote: »

Yes, but while with a full password, it is only necessary to compare the hash from the submitted password with the hash from the original password, how is the password hashed so that any three characters from say sixteen can be compared?

Perhaps I've been retired too long.

In cases where there is a password that needs to be entered in full, with a second piece of, say, memorable information, from which random characters are requested (this is how II and SVS security operate), then it can be done securely (which doesn't necessarily mean that it is).

The memorable information can be encrypted with a key derived from the password. So the server would store a (salted+peppered) hash of the password and the encrypted memorable information. The password would be verified by hashing and comparing to the stored hash, then used to decrypt the memorable information to verify the characters entered by the user.

If a platform is only asking for username and random characters, then I don't think there is a way of doing that without storing the information in an insecure manner on the server.

Jsscmm

The random characters don't have to be that random. If they have, say 6, sets of characters out of an 8 character password, such as 1,3,4 and 2,4,8 etc, they can store each groups of answers as a hash (potentially encrypted via another unique to that user key such as their password) instead of storing the entire memorable info as a single field.

TheTracker

Partial passwords are second lines of defence to prevent key logging rather than a second authentication factor. Trying to combat key logging makes sense, it's how many pieces of malware work. The password doesn't need to be stored in plaintext, it can be stored encrypted, then decrypted and checked on the fly, with the encrypted password protected with the bank's hardware security. All that said, adding a partial check doesn't really make anything any more secure. My view is it makes the customer feel a bit more secure, but like the security guard outside your hotel it is ineffectual and often counterproductive.

I second th call for 2FA on investment platforms. Dead simple to implement these days, I use it for PayPal, Slack, my Apple ID, Gmail, just about everything that offers it.

masonic

Jsscmm wrote: »

The random characters don't have to be that random. If they have, say 6, sets of characters out of an 8 character password, such as 1,3,4 and 2,4,8 etc, they can store each groups of answers as a hash (potentially encrypted via another unique to that user key such as their password) instead of storing the entire memorable info as a single field.

That would be much less secure, to the point that it might not be worth hashing the characters in the first place depending on what else is done...

Assuming an 8 character password, from which 3 characters are requested, and an alphabet of 36 characters (a-z,0-9, which is most common):

• An 8 character password would give rise to 2,800x10^9 combinations and take on average 1,400x10^9 guesses to brute force.
• An 8 character password transformed into 6 sets of 3 characters would give rise to only 0.00028x10^9 combinations and take on average 0.00014x10^9 guesses to brute force.

Now, assuming the server database used a hashing algorithm that is designed to be difficult to brute force (e.g. PBKDF2 with 10,000 iterations, which would take about 0.1 - 1 seconds of computation time on a typical server, but a GPU-accelerated brute force attack would be able to achieve around 5 million tests per second). 5 million tests per second translates into 432x10^9 guesses per day.

So, using the numbers above, for a database of hashed 8 character passwords, that would each take 1,400x10^9 guesses on average to crack, it is not going to be feasible to crack even one of those passwords within 24 hours.

However, for the database of hashed (3 character passwords) x 6, each taking only 0.00014x10^9 guesses on average to crack, around 3 million of those could be determined within 24 hours of stealing the database. That's 30 milliseconds per user.

Of course, you could argue that these passwords could be salted with a separate password that is entered in full. But, this might still be of limited value. Taking Hargreaves Lansdown for example, on the first login screen, users are prompted to enter their username and date of birth, so the latter would have to be used for this purpose. There are about 30,000 possible dates of birth (taking on average 3 milliseconds to brute force) assuming the age of the user is 18-100, so it would be negligible to crack that hash first and then move on to the 'master password' digits using this information. In other words, it would make the attack take just 10% longer per user.

Edit: I should point out, having picked on HL, that it does require users to enter their trading password in full to confirm any transactions, so the above would not give an attacker unfettered access to the user's account, just the ability to log in and poke around, but it would be a great way of scouting out some high value targets prior to concentrating efforts on cracking their master password (hopefully before HL notices the breach, or course).

jimjames

Not sure if it meets your requirements for 2 factor authentication but Fidelity have changed their process and any login from a new device requires a code to be entered that has been sent to your email address before access is allowed.

https://www.fidelity.co.uk/investor/newlogin.page

Linton

It would be helpful if someone could explain exactly what risk with broker platforms would be mitigated by a real 2FA. One must balance that risk against the inconvenience. Passwords and pins are a real pain now with one having supposedly different ones across dozens of accounts with different companies. The thought of having to manage perhaps 10 physical electronic gizmos fills me with horror. What about if one is away from home for a while - do you need to carry them all around with you? I cant see the email based logins providing much reassurance to the paranoid - perhaps a privacty attack on an individual would start with email.

EdGasket

dunstonh wrote: »

Nothing that would result in a third party obtaining funds.

Well you'd be pretty upset to log in one day and find all your investments sold and invested in some penny share about to go bust; or your funds eaten up by repeated trading by the hacker.

masonic

Linton wrote: »

It would be helpful if someone could explain exactly what risk with broker platforms would be mitigated by a real 2FA. One must balance that risk against the inconvenience. Passwords and pins are a real pain now with one having supposedly different ones across dozens of accounts with different companies. The thought of having to manage perhaps 10 physical electronic gizmos fills me with horror. What about if one is away from home for a while - do you need to carry them all around with you? I cant see the email based logins providing much reassurance to the paranoid - perhaps a privacty attack on an individual would start with email.

See #16. Such a scheme needn't be compulsory, nor does it need to be based on physical devices. Authy, for example, is quite a nice, low friction, option.

jimjames

masonic wrote: »

See #16. Such a scheme needn't be compulsory, nor does it need to be based on physical devices. Authy, for example, is quite a nice, low friction, option.

The fidelity scheme doesn't need devices. Key stored locally and email with code if different machine used