Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

South African bank advises against the use of password managers

twitter.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: South African bank advises against the use of password managers

#61

Post by kranner »

peterwwillis wrote: post #49
kranner wrote: post #35

Earlier quoted context omitted.

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…

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.

Re: South African bank advises against the use of password managers

#63

Post by sdinsn »

pwg wrote: post #31
mcv wrote: post #6

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…

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.

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

Re: South African bank advises against the use of password managers

#64

Post by rambojazz »

moviuro wrote: post #14
mikeash wrote: post #5

“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 m…

> 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.

Re: South African bank advises against the use of password managers

#65

Post by cr0sh »

mikeash wrote: post #39
vxNsr wrote: post #32

Earlier quoted context omitted.

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.

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).

Re: South African bank advises against the use of password managers

#66

Post by peterwwillis »

kranner wrote: post #61
peterwwillis wrote: post #49

Earlier quoted context omitted.

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…

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 n…

> 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.

Re: South African bank advises against the use of password managers

#67

Post by 0xffff2 »

moviuro wrote: post #56
vxNsr wrote: post #32

Earlier quoted context omitted.

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 ~!@#$%^&*()_+=?> 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-fo…

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.

Re: South African bank advises against the use of password managers

#68

Post by 0xffff2 »

kelnage wrote: post #19
sonnk wrote: post #12

Earlier quoted context omitted.

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.

Re: South African bank advises against the use of password managers

#69

Post by 0xffff2 »

dsfasfasfas wrote: post #40
sonnk wrote: post #12

Earlier quoted context omitted.

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

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.

Re: South African bank advises against the use of password managers

#70

Post by zAy0LfpBZLC8mAC »

GuB-42 wrote: post #53
zAy0LfpBZLC8mAC wrote: post #45

Earlier quoted context omitted.

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.

Post reply on HN