South African bank advises against the use of password managers | Hacker News Reader

South African bank advises against the use of password managers

twitter.com

58 pointsbuyx74 comments

“Bank has idiotic ideas about security” is as surprising as “sun rises at predicted time.” Something about the industry seems to push paranoid incompetence in security.

Currently at a bank's security team, here's what I gathered so far that explains (but doesn't excuse) the current state of affairs:

- there are millions of customers who hate having to use their brains (or get their phone to receive a 2FA code);

- a kilometer of requirements from whatever Central Bank, local policies and ad-hoc decisions;

- (too) limited budget to build and run whatever service (cost of SMS 2FA for millions .vs. cost of some limited fraud);

- very, very bad dev education, and general disdain for security. We do have a guide for them (the "secure development handbook"), and all our code audits reveal that it wasn't followed in all places;

- outdated perception of security issues (screengrabbers are still a threat to tackle, according to some).

I guess it depends on the country and the bank. My bank, for example, does mandatory 2FA for 15+ years and uses some anomaly based approach to decide how aggressively to ask for 2FA, like if you send money somewhere unusual, it does phone call 2FA, instead of an SMS, and if you just pay your usual bills from the same IP address and the same PC it doesn't even ask for 2FA at all. It also has other optional security features like white lists for IP subnets, internet-only credit cards, etc.

That sounds terrible. I mean, I assume they don't assume liability for bad decisions?

If "the PC" or "the IP address" was not contractually agreed to be an authentication factor (that you thus should protect from unauthorized use), it's a terrible idea to use them for authentication, while also (presumably) putting all liability on the customer.

In France, and I believe it is the case in many countries, in case the customer wants to roll back a transaction, the bank has to give the money back, unless it can prove that the transaction was legitimate.

So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN.

Banks have to maintain a balance between convenience and risk of fraud.

> unless it can prove that the transaction was legitimate.

And what is the standard of evidence for that?

> So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN.

That doesn't sound like a second factor? Or are you talking about POS transactions?

> Banks have to maintain a balance between convenience and risk of fraud.

Really, they don't. The bank should never decide to take on risks for me. There is nothing wrong with offering a feature where the customer can select to allow certain transactions without 2FA. There is everything wrong with forcing that feature on customers.

Why would that be a terrible idea? If someone has unauthorized access to my PC and knows my password from the account, he can log in and pay my bills and only the usual amounts, as paying too much would trigger 2FA.

Because there is a risk associated with it that you didn't agree to.

I'm fiercly in favor of 2FA, and with DSP2[0] coming soon(TM), I have been pushing for sane 2FA at my place, in some select projects where it can be done with as little friction as possible.

I'm very interested in your bank and how they do it, I'll see if voice 2FA is something feasible at my place. Could you share the bank's name though? Management likes to have solid evidence that someone else is already doing it when the security team proposes "weird solutions".

[0] https://ec.europa.eu/info/law/payment-services-psd-2-directi... , https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32...

> screengrabbers are still a threat to tackle, according to some

I might be one of those "some". Why do you say that screengrabbers are not a threat to consider? There are hundreds of cases that I can think of where they can be a security issue.

Thank you for sharing an inside view!

This is unintentionally hilarious.

The most confusing thing is that a lot of banks (paypal included) still don't let you use "special chars" in your password. Or they will allow it but only for a very limited set that they don't tell you.

That's not true about Paypal though: "Use lower case, upper case, a number, and a special character [like ~!@#$%^&*()_+=?><.,/]." [0]

And even if the character subset is quite small (26 lower case, 26 upper case, 10 digits), it's still good enough if it's completely random and never leaked once. Just max out the password length (start at 32 char) and back track from there.

[0] https://www.paypal.com/us/smarthelp/article/Tips-for-creatin...

I find this to be a recurring theme when banking security comes up. Every time I've ever been in a position to check, the specific claims made by HN comments about lackluster bank security practices have not been true. I assume they must have been true at one point, but commenters don't check that they are still true before commenting.

It was true in 2016 when I created my account. it was also true about BoA, they allowed a limited char-set.

That doc isn't dated, but it was true as recently as three years ago.

This one seems almost sensible to me. They probably have some ridiculous 1960s-era mainframe on the backend and it’s cheaper to keep it running than to redo it all.

It's more likely that the code and whatever was used for the DB dates from the 1960s-70s (likely a mixture of COBOL, JCL, and who knows what else), and has fixed-width columns for the data fields, with the password configured to something small.

I'd say most if not all of this code is probably running on some IBM mainframe from the 1980s or 90s - possibly later - and likely in some kind of emulation or backwards compatibility mode (so something from the 80s/90s would likely allow for running S/360 stuff, and so forth).

The actual hardware, though, has either been scrapped or is in a museum somewhere. There are very, very few instances of organizations still running "ancient" hardware (though the few that are tend to be known by the mainframe collecting community from what I understand).

I was super impressed to find that PayPal supports TOTP now, as the the brokerage Robinhood. Everyone else is still doing proprietary tokens, sms, or good looks for MFA. Tumblr had TOTP first but go PayPal, they get a pat on the back for doing something right.

I'm frequently baffled when I encounter a login form that doesn't allow pasting a password. Of course with developer tools I can just remove the attribute that causes that, but plenty of internet users lack that level of technical knowledge and are forced to resort to easy to member and very likely reused passwords.

I feel like this is a similar red flag as the 'no single quotes in passwords' limitation that used to be common.

With Firefox (at least the desktop version) one can set this about:config option (dom.event.clipboardevents.enabled) to "false" and websites can no longer block you from pasting things into form fields on your own browser on your own computer.

By far the best comment in this thread. Thank you.

Any idea if that syncs as a regular profix sync?

Thanks, I've been wondering if something like that is possible.

I prefer to use the autotype function of password managers (Ctrl-V on Keepass[0], and rofi-pass[1] for pass(1)); there are other issues with them though (such as "modern" login pages [2])

[0] https://keepass.info/help/base/autotype.html

[1] https://github.com/carnager/rofi-pass

[2] http://bradfrost.com/blog/post/dont-get-clever-with-login-fo...

In Firefox you can override this and re-enable pasting by toggling dom.event.clipboardevents.enabled to 'False' (in about:config).

https://developer.mozilla.org/en-US/docs/Mozilla/Preferences...

I use Bitwarden and often sites won't be set up for auto eneter of login credentials. In that case, Bitwarden provides an easy way to simply copy/paste the user/pass.

Sometimes using Shift+Insert instead of Ctrl+V can allow you to paste into these fields.

I can understand if a government service requires this but it also happens with a normal, ecommerce website!

If it's a US Federal Government service, you should point out to them that they are going against the explicit recommendation of NIST[1].

1. https://pages.nist.gov/800-63-3/sp800-63b.html#sec5, under 5.1.1.2 Memorized Secret Verifiers, 'Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret.'

Sadly the US Federal Government is a massive and unwieldy collection of organizations. I work in the Federal government and my part of it doesn't comply with NIST's modern guidelines at all. They probably will at some point, but department/agency level IT changes take years to be approved.

I really don't understand why. Please explain.

I do not understand why a government service would require this. Governments should improve security, not undermine it.

(Then again, most governments don't seem to care much about what I think they should be doing.)

The generated password is usually just random string and hard to memorise. If you need to use the password outside of the web, e.g. on telephone or in a physical office, then it makes sense to use a password you creates. This is similar to the "master password" used by password manager, you should remember it by heart instead of generating a random one.

Well in my little corner of the US govt the web certificates are usually expired and I can't log into my work email from home.

Are they actually expired? In both corners of the US government that I've worked most of the certificates are self-signed and work computers have the agency's root certs added to the browser.

For any customers that do use said bank, take this as an indicator of their own security practices and consider if you still trust them with your money, data and PII.

I wonder how they share credentials without a PAM or similar. All service accounts are using 'S3cur3P@$$w0rdzSuck'... Or more probably just a 'passwordz'?

What a shocking state of affairs.

I use said bank and they are generally pretty good. Also note they even said in the tweet that they acknowledge the role of password managers so I think you may have read a bit too much into the tweet. Almost every time I log on to their online banking site, I get a page detailing the latest scams and what to look out for.

I also agree with their statement for the most part. The general public, at least here in SA, aren't too discerning when it comes to tech matters who will probably download any random app from the play store. If you don't trust pretty much anyone with your credentials, why trust a probably unknown 3rd party with them.

I think the best idea in this case is to choose a strong password, try and remember it or write it down and store it in a safe.

I've been meaning to leave them since they implemented this policy last year. I uninstalled their app and have been getting by using the _Don't Fuck with Paste_ extension [0].

But I do totally agree with you that if they're blocking password manager functionality then it follows that there are probably many more security practices they're similarly getting completely wrong. It's especially concerning when you think of how basic an error this is to be making.

I don't know how security policies are written at companies their size, but there are so many resources on the benefits of password managers it's hard to believe no one could google "should you disable copy pasting passwords" and then read any link from the last 10 years which will unambiguously say: No!

Another weird security issue I noticed with them last week, is that they seem to have their email template sharepoint public [1]. This could be commonplace, since you can't edit anything, but still seems weird that you would let just anyone traverse your directories.

[0] https://chrome.google.com/webstore/detail/dont-fuck-with-pas... https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi... [1] https://www.mailers.fnbweb.co.za/Campaigns/Forms/AllItems.as...

Thirty minutes ago I closed my account with Wells Fargo because of their lack of security. Last month, they called to validate my identity. I called back, they asked for my mother's maiden name.

Me: "Since that information is on Facebook, I use a big random string starting.."

Them: "That's good enough, so what we want to talk about is.."

Then when I went into the local branch, the receptionist wanted to swipe my debit card in their tablet to add me to the line. Forget that, I'm out.

Over the weekend I had to call Time Warner Cable for support. Their support representative was willing to send an e-mail verification to any address I provided - in fact she refused to send an e-mail to the address on file because she couldn’t be sure the address was valid or who she was sending too. All this when I accessed a live chat feature from within a logged in context where I had already authenticated myself.

Considering how much S.A banks charge us in service fees they can afford to give folks who uses online banking a security fob.

If you can only remember a few long term complex secrets, then using one slot for your bank password seems reasonable to me. The other big ones for me are: google/microsoft account, password manager, FDE passphrase.

If you use hardware 2FA and have lots of bank accounts (business, trading, etc) then using a password manager starts to make sense.

American Banks are no different, they just don't tell you out loud. Here's a similar thing with Citi Bank credit card.

https://twitter.com/aruncxy/status/1163447301592891392?s=09

I have a 30 character password with upper, lower, numbers, and special characters for Citi and Bitwarden works just fine on their website. What problems are you running into?

Password managers are a very useful idea for general accounts, but I would not trust my financial solvency to them. If you only have one or two bank accounts, generate a long complex password, memorize it, don't save it anywhere, and use a mnemonic or other method to vary the password between the two accounts.

Even if password managers are implemented perfectly, there are various attacks that they can still fall victim to that a memorized password won't. Most password managers are not implemented perfectly.

> a memorized password won't

Memorized password are usually highly insecure due to being reused and short in general. So they are usually implemented as imperfect systems for most people. What is the difference to a password manager here?

The fact you remember long passwords doesn't mean everyone does.

If you're the type of person who uses no master password, and every password you would ever create is '1234', then a password manager will be a definite improvement. But if you have the ability to memorize two complex passwords, that is more secure.

My advice is solely for the person who already has a password manager, has memorized one complex password for it, and is willing to memorize another one.

Name one attack that would work against a non-cloud-based password manager like pass. Note that the encrypted passwords are stored locally and are encrypted with GPG and protected with a (hopefully) complex passphrase. If your answer depends on malware that can read the clipboard, note that the same malware can also log the keystrokes used to type the password manually.

Evil maid. Cold boot. Memory parsing. Clipboard/key event hooking. Brute force. Dictionary. Autofill hijack.

You can use the first four against typed passwords, but you either need to have malware installed, or your time window has to be very short. All of these can be used against password managers even without malware, and the time window is much longer, often due to crappy password managers not properly protecting against side channels or even cleaning up old memory.

You have the same attacks as with entering a password, plus more you wouldn't have had.

My question was specifically about pass, so your point about crappy password managers that don't clean up the clipboard is not relevant.

We can also ignore the attacks that apply to manually entering a password, as my question was about ways in which password managers are less secure compared to manually entered passwords.

What's left?

Brute force: not quite possible with the default GPG key type.

Dictionary: you'd need to guess my complex passphrase to decrypt my secret key (assuming you have access to it), and I can assure you my password if I use pass would be as long and as complex as I can make it, so I'm not sure which dictionary would contain it.

Autofill hijack: I don't use autofill for passwords.

> Brute force: not quite possible

> Dictionary: you'd need to guess my complex passphrase

Totally doable. You don't brute force the key, you brute force the passphrase that protects the key. Ask five eyes if password-protected GPG keys are impenetrable. A very large computer, smart algorithm, and good sigint can make short work of a "complex" passphrase. The difference between the password manager and memorized passwords is, if you crack the password manager, you have all the keys. If you memorize passwords, they have to intercept each key to compromise it. The most basic attack vector goes from "exfiltrate data one time" to "intercept all logins for a month".

Cold boot and evil maid also work better against someone who unlocks their gpg key for longer than a second, and extra code = extra possibility for bugs.

Even this is a wrong move from the bank, I think that using password to have access to sensible service is not the safest way. Would be better if the bank can use some ID-verification service, preferably provided by the government independent company.

Is there no 2FA? Why is there a password field at all on an online banking page?

Most transactions require an OTP to successfully complete, you also get notifications whenever a login to your account is performed.

I think it would probably be a good idea to have some sort of separate 2FA device linked at home but I doubt they'll ever implement it. You would want it separate to your phone because if your wallet and phone get stolen you can login to the online banking account and deactivate your stolen cards without having to go to the bank.

If the phone has a PIN or similar (I realize not everyone has) and the 2FA app has a pin/password, then that does seem like a reasonable level of security.

No, because getting your phone and wallet stolen (they are likely to both be on your person so both would likely be stolen at the same time) means you couldn't then log on to online banking and deactivate your credit cards (which you would want to do as soon as possible)

Edit: Just to clarify a bit more, most cards here have a tap and go function requiring no PIN up to a certain amount. Although the amount is small I'd still rather have it that no one spends my money.

That's a good point. I have done it a few times and it can be done quickly by phone at least.

Do you mean logging in with a one-time code instead of a password? It might be more secure than a password, but it's still only one "factor".

No I mean a physical thing like those little number generators that banks have had for what 20 years now, or the smartphone 2FA apps that we have used for at least 15 years.

I don't enter either a regular password nor one-time password for anything (not for transactions, not for login). I only use an identifying mechanism on a second device (a smartphone or a dedicated device). The secondary device has an 8digit pin though, so if it is stolen then it's not (immediately) compromising the security.

Yeah that is a one-time code. It's in the name: https://en.wikipedia.org/wiki/Time-based_One-time_Password_a... And again, if you use only this to log in, it's not two-factor authentication because it's only one factor. You'd have to combine it with something else (like a password or a fingerprint) to have two factors.

The rsa OTP-digit generator thing is an OTP, but what about signing with a device that doesn't generate a visible OTP? My authenticator app just asks me to produce my pin into the smartphone app and then the waiting transaction completes automatically in the computer web browser.

I suppose it could be an OTP too, but just not "manually entered"?

Is there a name for this type of authentication? It's just one factor but I do it on a separate device I mean.

Oh I see. Yeah Microsoft's authenticator app can do that, but they use it as a second factor. I don't know the details but I'd guess that it's not time-based but some kind of challenge.

Another option is Tumblr's "magic link", where they email you a link that logs you in. That's one of the few places I've seen something like that used as a single factor.

Half of Android "password managers" are scams.

I’d bet half of all Android apps are scams.

I bid higher...

I'm sure there is an app that could tell us the true count.

Have you got the numbers for it, and a proof that significant number of people actually use them? Searching for password manager I got to 16th entry before reaching an unknown author and ~40 positions before I reached anything really questionable. Even assuming the install numbers are not inflated, you don't get more than 10k users on the lower entries.

There are probably some scams down the list, but claiming half of them are without an explanation is just FUD.

While that may or may not be true, I can quite understand why the bank would want to have some certification or something of the password manager to ensure the security. A password manager that is insecure is worse than no password manager.

Aren't password managers sacrificing security for convenience? Remembering hundreds of long unique passwords being the most secure, but too difficult. If you could remember everything then you would have an uncompromisable storage system.

Personally I use password managers for most things, but exclude them when money is involved and opt to remember those.

> Aren't password managers sacrificing security for convenience?

It depends on what problem you're trying to solve / what's your threat model. The comparison is for realistic (imperfect) use of password manager vs what someone would do otherwise.

Nobody is likely to ever guess your bank password with online tries, so the likely scenarios are: protection from hashed credentials leak, and from another service leaking shared passwords. The tradeoff is your password manager bring possibly exploited. With the known frequency of each so far, no, it doesn't look like we're sacrificing security.

One of the security features that a password manager provides is retrieving passwords based on what domain you're on. They're a lot better than the human brain at making sure you don't get phished by an evil site that looks exactly like Gmail or whatever.

I'd like to believe I know better than that, but I see your point.

In a world where people have perfect, secure memories, sure.

We don't live in that world, and as such, a good password manager is the most practically secure method for the vast majority of folks.

Reply on news.ycombinator.com