Lack of security? Suggestion for improvement

Feedback & Ideas
#1

Hi folks,

I’ve been having a think about Monzo’s approach to log in and security.

I am a little concerned that only a single factor is required to access my account - my e-mail address. Though I do have this account secured by two-factor authentication, it feels a little lacking. With a less secure e-mail account, it would be easy to gain access to an individual’s Monzo account knowing no personal information about them.

I would very much like to see a second factor introduced in to the login process - whether that be some infomation from my card or personal information (password or recent transaction challenge) to confirm my identity.

Does anybody else have any thoughts surrounding this?

Thanks!

4 Likes
#2

I would love to see this implemented, have a second factor like SMS or some security questions (not perfect, but IMO better than a password as most people reuse passwords everywhere).

1 Like
#3

No I do not want security questions, or questions about recent transactions, or card details, etc. Just a PIN or password or both protecting the app. Unless it short and sweet and can be retained in the mind not some password app, then it becomes too much friction. Also security questions can often be answered by trawling thru social media history so they inherently insecure.

3 Likes
#4

This is a bad idea from a security perspective. Might be fine for you personally, but a system like this will lead to a lot of people using weak passwords/passcodes. The current email system is much better! Agree, though, that it would be nice to have the option of a second factor to use when first logging into the app with the magic email link.

2 Likes
#5

The issue is that the in-app passcode/PIN is only local to the app and device; all you’d need is to uninstall the app and then you would be back at the normal email “magic link” flow. This thread is about better security on the initial “magic link” login flow, not the in-app flow where you’re already considered as logged in.

1 Like
#6

But you need the card pin to do anything. That’s fine for a 2nd factor for me at least. Even if you uninstall and log in via email you still need the PIN

5 Likes
#7

No. There has been some research that proves making a password longer or more complex makes it less secure. With longer passwords people tend to reuse the same basic root to a password and just prefix it with extra digits, when a password is kept short they more willing to use different passwords. When a password more complex with multiple symbols or too frequently enforced change dates or rules on how similar it could be to previous passwords, then it more likely to be written down in a place where it could be easily found.

1 Like
#8

True; by the way if anyone is wondering, there is indeed brute force protection on that - I’ve just locked myself out after a few failed attempts. It’s not allowing me to send money anymore despite entering the correct PIN and prompts to contact support. :+1:

#9

Several of those statements are true, but you’re conflating several issues here. However, short passwords are not a secure solution. And as Andre says, we’re talking about the initial logon to the app (magic link through email), not a fingerprint/PIN every time you open the app (which has been discussed to death!).

1 Like
#10

Exactly. I wouldn’t be happy for someone to go through my transaction history but it’s no the end of the world.
Personally I’m totally happy with the security

2 Likes
#11

Password guidance here https://www.gov.uk/service-manual/design/passwords
Worth a read

2 Likes
#12

https://www.eventsentry.com/blog/2011/08/why-complex-passwords-can-be-i.html

1 Like
#13

Strange… just needed to add trusted devices to current security.
If you install application to a new device ask for some extra questions/details…

#14

Thanks, all.

Some interesting comments here :slight_smile:

#15

I’ve just realised that on iOS, I can view my PIN number after logging on using the magic link.

This means that if you gain access to a Monzo user’s e-mail account, you can install the app and transfer money to your heart’s content - as the PIN is revealed without any additional security questions.

I’m still definitely a proponent for additional security questions on first launch of the application after installation. My email account is secure, but IMO this is shifting too much emphasis on an assumption that users are savvy enough to have enabled 2FA etc.

#16

I’m sorry, I’m not even a security expert, but I have a few questions surrounding this.

  1. Why was the password human-readable and not encrypted
    1.1) If it was encrypted why was he decrypting it.
  2. How did he have access to them, group policy should stop this,
  3. He was in violation of security by checking passwords.

Longer passwords are more secure however it depends on the encryption. Hashing a password such as “TsNz_(2.,dh=?^r_P<” returns the following,.

“9FC46B186578EDE3B501F3F4989050DD6674513E93B83EC557A33A5C73FF2376BCA8CBEBF9C8334AA3FF726DD6FEC2D39A6902E7B53DA7EF5AD0107E7E27D5BC”

Not something that is easy to decrypt… Even if a database administrator was able to get access and view them for a second, it’d have no impact, and even if someone was able to gain access to the encrypted pass, on average it’d take It would take a computer about 380 QUADRILLION YEARS to crack that password, AND by then the breach would’ve been detected and people requested to change passwords.

I also used SHA-512 above, Many companies will have their own encryption algorithm which can’t be cracked using a web-decryption-tool.

Longer passwords are more secure.

#17

Just a couple of points on the above, because it confuses hashing and encryption, which are entirely different concepts:

  • Hashing is one way. It produces a different output for (hopefully) every different input. There is no way to “decrypt” a hash. It isn’t just difficult or time consuming to do so, it inherently impossible.
  • Encryption is two way. You can decrypt an encrypted message to get the original back.
  • Obviously, while hashing is one way, and cannot be reversed mathematically, you can guess, brute force, or look up hashes to get the original back.

This leads to the following conclusions:

  • When storing passwords hash them (don’t encrypt: you never want to be able to get the original back).
  • In order to “reverse” a hash you have the following options (assuming there is no vulnerability in your hashing algorithm):
    • Brute force it. This means you try every possible password combination, until you have reached the one that produces the same hash. That (and only that) is where those “x quadrillion years” estimates come from. Password hashing algorithms are specifically designed to be slow (which, incidentally is part of the reason why you shouldn’t use SHA512 for passwords)
    • Look up tables that list hashes of known strings for the hashing algorithm. Much faster, and more efficient.

Nowadays, password cracking isn’t usually done using pure brute force, randomly trying all possible passwords. Rather it’s done using massive “dictionaries” of commonly used password as well as English words (or whatever the target language of the site is), as this massively speeds things up. As an example: If you have an entirely random 10 character password such as “8LDJLGQB2O” it may take while to crack it (if hashed properly, i.e. NOT sha512). If, however, your 10 character password is a dictionary word with simple substituitons (e.g. “4PPL3J4CKS”) it may SEEM to take just as long, but because it’s a dictionary word it will be one that any password cracker will try early on, and it will thus be cracked much quicker, despite being seemingly of the same strength.

Thus, your “Longer passwords are more secure” is not universally true. “Longer, entirely random and unique passwords are more secure”.

However, and that’s the crux of the argument, you cannot force people to use entirely random and unique passwords. You can make rules such as “your password must contain at least 2 letters and 2 numbers, and be 10 characters or more”, but that forces neither uniqueness nor randomness. Most people will just use minor variations of their favourite passwords to just about fit the rules. A longer password that is not entirely random, or that has been used (and cracked) before is often LESS secure than a shorter, entirely random and unique password (obviously within limits).

Thus, when creating passwords you should (in order of descending importance)

  1. Use a unique password each and every time. NEVER reuse passwords
  2. Generate random passwords, choosing from as large a character set as is available to you.
  3. Make them reasonably long
3 Likes
#18

@nanos I did say I was no security expert, cheers for the input haha, but from what I know, no password should been human readable, the article showed he could see the users password as “888888”.

#19

True, of course. But there are tons of reasons why people get to see passwords. In IT support its usually that your client blurts out the password before you get a chance to tell them “whatever you do, don’t tell me your password”. Other reasons are people that research lists of previously leaked password.

1 Like
#20

I entirely understand that, but from a data perspective, limited people should have “Access” to a database containing passwords, and if they were to see the database, there’s no reason to brute the password to get the plain-text. A network admin shouldn’t be able to open a users table and see “88888888”. they should see a hash.

As you rightly said though, a more random password is better than a longer password, I think that’s what I meant because I use random passwords with multiple characters, naturally I thought about my own, as if I had “123?!” it’d still likely be more secure than “abcdefg”.