- 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).
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.
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.
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.
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".
 https://ec.europa.eu/info/law/payment-services-psd-2-directi... , https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32...
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.
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.
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 feel like this is a similar red flag as the 'no single quotes in passwords' limitation that used to be common.
Any idea if that syncs as a regular profix sync?
1. https://pages.nist.gov/800-63-3/sp800-63b.html#sec5, under 184.108.40.206 Memorized Secret Verifiers, 'Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret.'
(Then again, most governments don't seem to care much about what I think they should be doing.)
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 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.
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 . This could be commonplace, since you can't edit anything, but still seems weird that you would let just anyone traverse your directories.
 https://chrome.google.com/webstore/detail/dont-fuck-with-pas... https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
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.
If you use hardware 2FA and have lots of bank accounts (business, trading, etc) then using a password manager starts to make sense.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
There are probably some scams down the list, but claiming half of them are without an explanation is just FUD.
Personally I use password managers for most things, but exclude them when money is involved and opt to remember those.
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.
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.