
Banks, Arbitrary Password Restrictions and Why They Don't Matter - weinzierl
https://www.troyhunt.com/banks-arbitrary-password-restrictions-and-why-they-dont-matter/
======
mquander
_He turned to me and said, "Do you really think the only thing the bank does
to log people on is to check the username and password?" Banks are way more
sophisticated than this and it goes well beyond merely string-matching
credentials; there's all sorts of other environment, behavioural and heuristic
patterns used to establish legitimacy. You won't ever see a bank telling you
how they do it, but those "hidden security features" make a significant
contribution to the bank's security posture._

Their response to having visible security that sucks is to say that they also
have a lot of super complicated invisible security which is actually really
good? Why am I supposed to believe that? Their invisible security probably
sucks even more.

~~~
tialaramex
I agree, Troy is way too gullible here.

> Do you really think the only thing the bank does to log people on is to
> check the username and password?

Yes. I assure you that when bad guys with your username and password log in
and steal all your money the bank _won't_ say:

"Doh, our sophisticated environment, behavioural and heuristic patterns used
to establish legitimacy let you down this time. We'll pay for this"

No, they'll say it is your fault because the bad guys had your username and
password.

And that's all you need to know.

~~~
Swizec
On the other hand I log into my bank with my computer using the same browser
as always and my username and password, but this time I'm in a different
country. Even just a different Wi-Fi (like at a coffee shop)

And the bank _freaks out_. Omg omg omg hacking hacking! Quick to the 2FA
mobile! Should we call you? Can we text you? Do you prefer email?

That's before we even get into how trigger happy they are about credit cards
being used in weird ways. You buy one thing out of the ordinary (like a $3000
downpayment for a motorcycle) and immediately get 5 texts, 10 emails, and 2
phone calls. YO did you do that?

Or the one time my girlfriend deposited a physical cheque and it was so out of
the ordinary the bank had a melt down and started shutting down all her
accounts and blacklisting her from the bank.

I don't know about "sophisticated", but they definitely do _something_.

~~~
dpark
You really want to work yourself into a frenzy about minor inconveniences,
huh? You’re so hyperbolic here that you sound like you’re basically making
stuff up.

> _You buy one thing out of the ordinary (like a $3000 downpayment for a
> motorcycle) and immediately get 5 texts, 10 emails, and 2 phone calls. YO
> did you do that?_

First, dropping 3 grand at a motorcycle dealership is extremely out of the
ordinary for most people. Second, my money says you got exactly one text, one
email, and either one or zero calls. It makes perfect sense that they’d want
to do the fraud check here. It also makes sense that they’d use multiple means
of contact to reach you quickly.

As for the girlfriend blacklisting story, I don’t know if you’ve just horribly
mangled this story or what. It doesn’t make sense. If you deposit a check,
there is no potential fraudulent withdrawal from your account. Also, a bank
cannot randomly close your accounts and “blacklist” you. They are _holding
your money_. Stealing money from your depositors is generally frowned upon
from a regulatory standpoint.

~~~
NewsAware
I didn't understand the gist of the GP to criticize bank actions, but wanting
to point out that banks do indeed have alarm systems in place beyond simple
IP-change rules.

~~~
joshjje
Some do. Many do not.

------
viraptor
> Do you really think the only thing the bank does to log people on is to
> check the username and password?

Yes, I do think that. I automated some banking functions for myself and the
last 4 retail banks worked just fine when accessed with curl, or headless
chrome. I didn't even change the user agent for curl and used no delay between
requests. Not only do they trust credentials, there are no extra checks in
most cases. This is experience from UK and Oz. Lloyds, CommBank, ANZ, ING.

ING is actually the "hardest" one. Their 4-digit scrambled keypad varies
colours slightly so it requires closest-match comparison to known samples.
That was like 3 extra lines of code.

~~~
throwaway201606
Access control is not on a binary 'yes-or-no ' decision on a per single-signal
basis.

It is usually a weighted result of multiple signals. For example, it may look
at say 20 factors and have a failure threshold of 15 passed. Most of the
signals are evaluated server-side.

By design, some signals used are picked such that customer convenience, among
other things, is not affected (e.g. the account holder data pull automation
that you describe in your example ).

Examples of signals include timezone, time of login vs. past logins, hardware
profiling (OS, screen resolution, IP, ISP, VPN vs. no VPN - based on known VPN
server lists ) etc.

I agree that not all banks are doing this but the more sophisticated ones are
(quite a few of them). Point here is curl or headless browsers working is not
evidence of only account and password being checked.

~~~
viraptor
I did it scheduled past midnight, from "abroad", from known AWS us-east
ranges, with headless resolution set to 1000x1000, completely ignoring their
browser detection JS, identifying as either curl or "bank bot", not following
links and redirects, causing lots of unexpected failures which should be
impossible with a normal browser while developing my scripts. (including 503s
from bad csrf token passing)

Basically if there was any check, I would fail it. I did that on purpose -
better to know immediately than get silent failures later on. I really don't
know what else I'd have to do to trigger "this it not a real person"
detection.

~~~
throwaway201606
Thanks for taking the time to explain this: it does indeed seem clear that
they are just doing username and password detection for access.

A followup question: I have lived in Europe and have accounts in banks in
Ireland. For those accounts, actually executing any financial transaction
requires entering a one time token generated by a device that uses your debit
card and PIN.

Like so:

[https://www.youtube.com/watch?v=kEOEQzC8-Fc](https://www.youtube.com/watch?v=kEOEQzC8-Fc)

Do the banks you tested have a similar setup?

Just trying to find out if these specific banks have chosen to control view
transactions with just the username / password but require some other
additional authentication for actual financial transactions.

~~~
viraptor
None of them required extra authorisation to get data. (even transactions
going back 5+ years) They did have the SMS validation when adding new transfer
targets, but not for executing transactions to existing contacts - which is
potentially an issue if you can pay off a different credit card just by
changing the reference field.

------
hyperman1
The 5 number 3 tries bank does not seem very secure:

It is (at least in my country) very easy to guess valid acount numbers: They
are incrementally numbered + have a checksum. So while 1 account of a 5 number
3 tries bank is safe, attacking all of them in volume is not:

With N numbers, T tries, A accounts, the chance of guessing at least 1 account
is pow(1-T/pow(10,N),A)

5 numbers 3 tries means a chance of 0.9997 of being locked out of 1 account.
For A=100 000 accounts, the chance is 0.049, so more than 95% chance you
guessed one account right. For A=1 000 000, you're almost certain.

And that's the dumbest possible way. Try guessing with the most common
password like 12345, take only 1 try each month so people unknowingly reset
the account number when doing payments, and use a botnet to spread the load
over tons of IP adresses and randomize the numbers.

~~~
SamBam
Exactly. The math is not in their favor at all if the attacker is able to work
out or guess numerous account numbers.

~~~
bscphil
I think this is exactly right. My bank has predictable account numbers too,
and if they had one of these 4 or 5 digit password limitations, they would be
a very ripe target for someone using a botnet to just go through all the
accounts. The risk isn't that someone will target you personally, the risk is
that someone will happen to hit you while attempting the profitable activity
of hacking every account. (Plus, at least with a bank, if they manage to hack
in and steal the database, one of the most profitable ways to use it would
just be to log in and steal money. No effective hashing on a 5 char password.)

I also _completely_ distrust the "advanced security measures" claim. I have no
trouble logging into my bank via curl, including from remote IP addresses.
(They finally rolled out 2FA, but I can still type the text code into my
script.)

A couple years ago I discovered a number of vulnerabilities in their account
site, too (including some many years old software with vulnerabilities with a
CVSS of 10). After I reported this to them, the response from the guy who
worked there was basically "Yeah, that's from the crappy vendor who supplies
us with this software. Please don't say anything about this because we're
replacing it with a new in-house backend in a couple months."

------
RHSeeger
>> Hey [bank], does that 16 character limit mean you've got a varchar(16)
column somewhere and you're storing passwords as plain text?

> As much as I don't believe that's the case in any modern bank of
> significance, it's definitely not a good look. Inevitably the root cause in
> situations like this is "legacy" \- there's some great hulking back-end
> banking solution the modern front-end needs to play nice with and the
> decisions of yesteryear are bubbling up to the surface. It's a reason,
> granted, but it's not a very good one for any organisation willing to make
> an investment to evolve things.

But the only reason that "legacy" system would have a limit is because it's
storing your password. So

> I don't believe that's the case in any modern bank of significance

It _is_ the case. It may not be the case in their most recent systems, but a
chain is only as strong as it's weakest link. You can be hashing/salting the
user's password and locking it behind a vault door to make sure noone can
access it. But if you _also_ keep a copy of the password in plain text on a
piece of paper taped to the outside door, the vault copy doesn't protect it.

------
kemiller2002
Wow this made me laugh. I spent long time working for banks, financial
institutions, and credit agencies. "So many things that lock the account down"
Really? Out of ALL of articles about breaking into systems leveraging
techniques like lateral attacks on systems, and this is supposed to be
believable.

People ask me what it was like working there as far as processes etc. I always
say the same thing. "Banks are like the mafia. They have a lot of money, and
they don't like giving any of it away." Banks (especially) care about 2
things, money and risk. They spend just enough money to mitigate the risk and
then stop. What this means is that they may buy good systems to help with
security administration, but rarely did I see them take extra time to make
sure they have multiple security redundancies like Troy describes. Employees
were "trained" to what the letter of the law required. Don't get me wrong,
there were some great people there, but let's not pretend they only hired from
a select group of highly trained and extremely smart people. It's just like
almost anyplace else. Employee's and contractors are there to get a paycheck
and go home. They do what risk wants and when their done, bam they go home til
tomorrow, because the fights just not worth it after a while.

I briefly worked with a sales guy from a vendor we used, and he used to work
in the banking industry. He had the best quote (that I shamelessly stole) to
describe banks. He said, "If people knew what I know about banks, mattress
sales would skyrocket."

------
ufmace
I think basically everyone in this thread is looking at this all wrong. Banks
don't have a ton of fancy hidden security gating the login itself most of the
time. Trying to build a digital Ft. Knox in front of the login page and then
paying no attention to what the users do after they login is the wrong way to
go about securing these types of accounts.

I'm pretty sure they have much more security around detecting and blocking
suspicious behaviors after you've logged in, like adding new payees on bill
pay systems, requesting transfers of large amounts of money to random
accounts, particularly overseas, etc.

I also argue that banks have much, much better security than anything most of
us have ever touched, because they handle billions of dollars moving around
routinely and manage not to lose it. Meanwhile, half of the internet can't
manage not to lose the email addresses of everyone who signed up for their cat
picture website. If they're trying that hard to steal something of little
value like that, how hard to you think people are trying to steal the billions
of dollars that banks handle?

~~~
Radle
" I also argue that banks have much, much better security than anything most
of us have ever touched, because they handle billions of dollars moving around
routinely and manage not to lose it. Meanwhile, half of the internet can't
manage not to lose the email addresses of everyone who signed up for their cat
picture website. If they're trying that hard to steal something of little
value like that, how hard to you think people are trying to steal the billions
of dollars that banks handle?"

Exactly this is the reason why I don't think Troy is being gullible here.

~~~
lawn
There's a logical fallacy here that I don't know the name of:

"Because it's so important, surely they must be competent."

Which does __not __follow.

~~~
ufmace
I do not argue that they're competent because they're important. I argue that
they are competent because there is a multi-billion dollar pile of cash that
they're guarding. If they aren't competent, how come nobody has stolen it all
yet?

Look at the efforts spent hacking Bitcoin exchanges and identified large
holders. Lots and lots of money being taken there. Look at the efforts made to
hack much less important things. How come no big banks have suffered a serious
compromise leading to the loss of 9-figure plus amounts of money yet?

~~~
syrrim
Banks normally don't actually transfer any money. There's a funny story from
the 1920s of the Bank of England pushing money across the vault floor to
indicate a transfer to France, who held an account with them. The money
doesn't actually go anywhere, it just says so on the balance sheet. If someone
"steals" 1 billion dollars by making the system think they took it, someone
will eventually notice, then they'll send somebody down to the vault to push
it back to the other side.

Bitcoin is very different: when the bitcoin blockchain says someone else has
your money, they have it. Imagine someone had heard that Ethereum had suffered
no major attacks on exchanges, but hadn't heard of the DAO attack. They must
think that Ethereum is extremely secure. Actually, Ethereum is very insecure,
but a large enough target will get special treatment. Bitcoin doesn't have the
same tendency as Ethereum (and real life) towards hard forks, so of course it
will have more attacks on it. But this doesn't imply that anyone will hard
fork when you get hacked, nor will the banks necessarily reverse the
transaction when someone guesses your password.

------
shanecoin
I would argue that this is not just banks but a number of different services.
This entire Github repository [1] and this Twitter account [2] are dedicated
to sites with dumb password rules. Passwords are not meant for humans.

Here is a link to a hackernews thread discussing the worst of the requirements
in the repository is here [3].

[1] [https://github.com/dumb-password-rules/dumb-password-
rules](https://github.com/dumb-password-rules/dumb-password-rules)

[2] [https://twitter.com/dumb_pw_rules](https://twitter.com/dumb_pw_rules)

[3]
[https://news.ycombinator.com/item?id=20890381](https://news.ycombinator.com/item?id=20890381)

~~~
pingyong
The PayPal section doesn't mention that they have a 20 character limit too. I
honestly wonder what kind of buffoons are in charge of making this shit up at
multi-million dollar companies.

------
londons_explore
If someone guesses the _2 numeric digits_ necessary to gain telephone access
to my pension fund, and they then transfer out the $10M value to the cayman
islands, will they really give me back the money? Would I have any chance in
court? - proving it wasn't me is near impossible.

Yet this pension company has millions of customers, and presumably isn't
seeing widespread fraud. How come?

~~~
patio11
Because you're evaluating the effectiveness of one control in isolation,
whereas the pension fund has a lot of controls, including e.g. an operational
team which knows that wiring money to the Caymans is intrinsically high risk,
a written procedure that they'll follow for high risk transfers specifically
to papertrail up evidence in the event it is contested, a legal environment
which will put the burden of proof on them rather than you if they did
something that self-evidently stupid, the medallion guarantee program and
associated regulation, etc etc.

Fraud happens. Financial institutions spend a lot of money defanging it; they
also, when push comes to shove, have budgets for it.

~~~
whitepoplar
I'm curious--how big are those budgets?

~~~
throwaway201606
For the really large banks: $XYYMM (i.e. hundreds of million dollars aka the
cost of doing business) across all lines of business.

All this is mostly public info as it has to go into financials, you can find
it under "Operational Losses" for any public bank (Note that "Operational
Losses" are not the same as "Operating Losses").

A sample multi-year summary can be found here from an industry body in Europe
for losses for debit. (losses are demonimated in Euro):look at page 7 under
the last column for the rows "Retail Banking". Important to note that credit
ops losses are an order (or maybe two) of maginitude higher.

[https://managingrisktogether.orx.org/sites/default/files/dow...](https://managingrisktogether.orx.org/sites/default/files/downloads/2018/09/annualbankinglossreport2018-printversion.pdf)

~~~
whitepoplar
Thanks!

------
PhasmaFelis
> _That very first tweet touched on the first reason why it doesn 't matter:
> banks aggressively lock out accounts being brute forced._

Until a hacker steals the salted password database and brute forces it as much
as they like. A truly strong password is secure even when the attacker has the
salted version.

(Anyone who tells you that it's completely impossible for a hacker to ever get
their password file is lying either to you or to themselves.)

------
kardos
This 'hidden security features' explanation sounds a bit like security by
obscurity. Mouse movement fingerprinting? Browser fingerprinting? Locking
people out when they get a new laptop doesn't sound like a good time

~~~
mobjack
It likely means they use reCAPTCHA.

They could be doing 2FA when someone logs in with a new device too.

------
pridkett
The challenge is that if a system only offers a four or a five number
passcode, you can still attack accounts by just guessing passcodes for account
names/numbers. This is addressed a little bit by pointing out that it’s
sometimes not easy to enumerate accounts - but if you’re malicious and have
purchased a list of compromised accounts, you could then pound the system from
a botnet even after the passwords have been changed. In this case you’re not
concerned about a _specific_ account, but rather you’re concerned about _any_
account. And with a 4 or 5 number passphrase, you’d get hit pretty quickly.

~~~
philliphaydon
If you knew the bank and the account, you could assume that people login to
their account atleast once a month. So every month you could try a
combination. Known passcodes could be tried first. If a dump also has the
person Birthday then their birth year is a good Guess for a 4 digit pass code.
2 failed attempts reset when the user succeeds their login during the month.

There’s so many things people could do. Limiting passwords is a bad idea :/

------
Thriptic
What's odd to me about this post and all of the responses in this thread so
far is that everyone is only thinking about password length as a way to defend
against online bruting attempts when in reality long passwords mostly serve to
protect against offline bruting attempts. The reason you don't want 6 or 8
character passwords is that when your password hashes get dumped it's a lot
easier to crack them.

~~~
throwaway201606
"What's odd to me about this post and all of the responses in this thread so
far is that everyone is only thinking about password length as a way to defend
against online bruting attempts when in reality long passwords mostly serve to
protect against offline bruting attempts. The reason you don't want 6 or 8
character passwords is that when your password hashes get dumped it's a lot
easier to crack them."

This is: i) not accurate and ii) bad info

Password hash dumps are worthless if the password hashing scheme used is
i)crypto-hashing based and ii) uses salt.

6-8 char passwords are not an issue under this scenario. Current password
management best practice is to use both standard crypto-hashing algorithms and
salt.

[https://en.wikipedia.org/wiki/Salt_(cryptography)](https://en.wikipedia.org/wiki/Salt_\(cryptography\))

Almost all platforms use standardized crypto-hashing packages that come as
standard libraries in the language these days and those require salt. Further,
_almost_ all banks will all use these packages.

This is the reason you do not see rainbow tables these days, they are
worthless in face of almost any current acceptable crypto-hashing
implementation ... assuming one does break rule #1 of crypto and try to roll
their own crypto ...

[https://security.stackexchange.com/questions/18197/why-
shoul...](https://security.stackexchange.com/questions/18197/why-shouldnt-we-
roll-our-own)
[https://www.schneier.com/blog/archives/2015/05/amateurs_prod...](https://www.schneier.com/blog/archives/2015/05/amateurs_produc.html)
.. ad nauseam

Salting also has the additional benefit of making brute-forcing magnitudes of
difficulty harder. This is because salting rules can be implement that always
add non-standard chars..

[https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mis...](https://en.wikipedia.org/wiki/Salt_\(cryptography\)#Common_mistakes)

As others have said, the 6-8 chars limits are are a function of legacy system
somewhere in the application chain (online banking is never a single platform,
it is usually a front-end that talks to a standard backend that tellers,
operations etc also access, usually some type of _greenscreen_ app - which is
where the password hashes end up).

~~~
Thriptic
I'm not talking about rainbow tables or hash tables, I'm talking about
straight up bruting with GPUs and hashcat. You seem to be implying that using
a salt adds entropy, but the salt is known (plaintext) and it's added in a set
way so it doesn't. Sure your choice of algorithm and complexity factor will
definitely affect your guess rate and ease of bruting, and yes using a salt
prevents the use of precomputed hash tables, but it's not like it's impossible
to crack a salted 6-8 character password hashed with bcrypt if you throw
enough GPUs at the problem. The only question is if it's cost effective.

~~~
throwaway201606
Am confused here, is there something I am missing ?

Brute-forcing bcrypt-hashed passwords on GPUs has a ridiculously low success
rate even on most commonly used password data sets.

Failure rate on passwords outside the most commonly used list is more than 95%

[https://arstechnica.com/information-
technology/2015/08/crack...](https://arstechnica.com/information-
technology/2015/08/cracking-all-hacked-ashley-madison-passwords-could-take-a-
lifetime/)

~~~
drblast
So let's assume a 6 character alpha-numeric password with upper and lowercase.
36^6 possible passwords or about 2.1 billion.

The article linked is one guy and one machine who can do 156 bcrypt hashes per
second, with salted hashes.

That's ~161 days to hash them ALL.

If you have a dump of thousands of passwords it's extremely probable to get a
few of them in under a day. Which is what the article shows - common short
passwords were owned.

What's funny about the additional restrictions (you must use 2 upper, 2 lower,
etc.) is that they _reduce_ the complexity of this problem so there are fewer
possibilities the attacker needs to check for. So you're making it more
difficult for users while decreasing actual security against this kind of
attack.

Much better policy is something like, "at least 16 characters, whatever ones
you want." Easier for users because then passphrases are possible, easier to
implement because there's only a string length check on the client, and more
secure because it doesn't completely rely on users not choosing trivial
passwords.

~~~
FabHK
> common short passwords were owned.

> What's funny about the additional restrictions (you must use 2 upper, 2
> lower, etc.) is that they [...] decreasing actual security against this kind
> of attack.

Not necessarily - the additional restrictions might prevent even more common
short passwords from being used by the users, thus making it harder for both
the user and the attacker.

(If the bank says you can't use "Password" as your password, then yes, the
attacker only needs to check 62^8 - 1 passwords instead of 62^8, making it
insignificantly "easier" for the attacker, but at the same time a lot of
people must switch from "Password" to something else, making it much harder
for the attacker).

EDIT to add: Having said that, what you propose (at least 16 chars, no other
restrictions) makes perfect sense (maybe introduce a maximum of 32k chars).

------
yellowapple
Yeah, this is thoroughly disappointing - and alarming - coming from Troy Hunt.
"Secret" security mechanisms that may or may not actually exist (let alone
actually prevent attackers from successfully attacking) do not in the
slightest bit excuse banks from their abysmal password policies. That he would
not only accept that half-baked excuse at face value, but go so far as to
regurgitate it and present it as if it's in any way reasonable, means that my
perception of his trustworthiness now has a pretty substantial dent.

I'm glad he at least acknowledged that banks should modernize their password
policies regardless of their other security measures, but he's quite wrong to
claim that we end-users shouldn't be incensed by banks' bass-ackwards security
policies just because "well um uh they told me they're doing secret things so
I'm gonna totally take their word for it and you should too".

And no, account lockouts do not address the concerns caused by arbitrary
password limits. Arbitrary password limits - be they for length or which
characters can or cannot be used - are a rather bright red flag for storing
passwords in plaintext, which means that when - _not if_ \- that bank
inevitably has some kind of database leak, congrats, now the attackers don't
even have to go through the trouble of brute-forcing or rainbow-tabling or
whatever a bunch of hashes to get my plaintext password.

------
exabrial
My favorite is "locking the account after x number of password attempts".

Ever want to annoy the hell out of someone? Try their username or email a
bunch of times and lock them out of their accounts. Bonus points if it's one
of those super duper ultra secure banks that does password resets via snail
mail.

/s [I don't condone doxing anyone. My point is that an attacker should not be
able to modify the state of a system he's unauthorized to access]

~~~
SamBam
That seems to be the least objectionable to me. You need to have _some_
protection against brute-forcing. Whether it's limiting the rate of guessing
or whatever, the attacker is still "modifying the state of a system."

Indeed, that's a weird rule. When someone stole my credit card number and ran
up charges, my bank called me to verify them. How was that not "modifying the
state of a system?"

~~~
zAy0LfpBZLC8mAC
> You need to have some protection against brute-forcing.

Yes, that protection is called "password".

> Whether it's limiting the rate of guessing or whatever, the attacker is
> still "modifying the state of a system."

Which is why you should not limit the rate of guessing (or at least offer that
option--limiting the rate of guessing does help users who use terrible
passwords, after all).

> Indeed, that's a weird rule. When someone stole my credit card number and
> ran up charges, my bank called me to verify them. How was that not
> "modifying the state of a system?"

Which is exactly why that shouldn't be a thing. Being able to pay with a semi-
public number is just stupid. You should have to authenticate using a strong
password, and "stealing credit card numbers" simply wouldn't be a thing
anymore.

~~~
SamBam
> Yes, that protection is called "password". [...] Which is why you should not
> limit the rate of guessing

 _Any_ password can be brute-forced if you neither limit the number of guesses
nor limit the rate that you can guess them.

~~~
zAy0LfpBZLC8mAC
No, it can't. If you are willing to say that a cow can not jump over the moon,
then a strong password can not be brute-forced, even though it might
theoretically be possible for a cow to quantum-tunnel over the moon, and it
might theoretically be possible that an attacker guesses your password. The
probability is so vanishingly small that you would call it impossible in any
other context.

------
cm2187
Amazon really understands what security means. When it does 2FA, sends you a
unique code by email, it disables the option to paste that code back into the
login form, you have to type it. You know you are dealing with really
competent people when you see that!

~~~
jjoonathan
Ah, yes, messing with paste, the ultimate in security. /s

~~~
darkhelmet
Hence wonderful addons like "Don't f*ck with paste" to fix such stupidity.

~~~
jjoonathan
I've got it installed, and it's good, but the world built a better idiot:
sites that use flash, implement their own key event processing, etc.

------
mnm1
Good points, however this one is wrong.

> Banks typically use customer registration numbers as opposed to user-chosen
> usernames or email addresses so there goes the value in credential stuffing
> lists.

I've had accounts at most of the major US banks and I don't think I can think
of a single one that did this. Almost every single bank allows the user to
select a username or occasionally uses email for login. This is not a good
argument for Chase, Citi, Amex, Discover, Capital One, Barclays, and a whole
bunch more I can't think of off the top of my head.

------
lovehashbrowns
That whole blog post was sad, but this quote was particularly dumb:

> Banks like ING will give you your money back

Now, I don't have any experience with having my bank account hacked, but I
have had experience with my credit card getting used without my consent, and
it's NOT a fun process. I can't even imagine how that'd go with a bank and a
checking account. I can only guess that you have to 1. get the right customer
rep on the line and 2. wait a good while.

------
blackbrokkoli
People tend to get lost in mathematical technicalities in these discussion.
Yes, even really dumb limitations leave 100k+ possibilities open, much more
than you can brute force with a three-strike-lockdown. But that's not making
it ok. Even if some crafty hackers on the other side of the world find a way
to crack my account I'm confident the bank will look at the possible PR and
legal costs and just refund my money fully, yes, yes, wonderful. That is not
the problem.

The problem is _user inertia_. Let me speak as an averaged one, mixed with my
own deeds prior to being knowledgeable in cyber security.

If I'm forced to remember my password because my password manager gets shut
out or because of weird requirements, like uppercase letter + two numbers +
non-alphanumeric, I'm nudged to use the same variation of my "default
password" I used before, 27 times.

"DognameBirthyear&".

"+KeysThatAreCloseOnTheKeyboard1234+".

And of course, I use a slight variation of that for everything. Shady web-
server-under-the-desk web forum in 2007 three of my friends were on. Indie
game servers, another classic. Bank. Google. It also was my facebook password
which I gave to my bff once to check if that cute boy really liked me. It also
can be guessed by obtaining my ID and watching me super slowly type the added
non-alphanumerical at the end.

 _This_ opens the very real possibility of revenge of ex partners, witty
people at the coffee shop gaining access and the like. Crimes are committed
overwhelmingly by people knowing the victim. No fancy AI is gonna help you
with that, reasonable withdraws in the middle of the day in your time zone
from your own MacBook's IP address. Good luck with customer support. You are
enabling THAT with your dumb requirements.

And why?? You are a _bank_ , hire someone who knows their job and does not
just act on blog spam FUD or whereever you got the idea of exactly 5 digits
numbers only. No, I choose to be mad about this because there is no excuse for
such horrifying UX _and_ security.

Just enforce a minimum limit of like four characters to prevent breach by
putting down coffee mug on keyboard, enforce a maximum limit so you don't fall
victim to an embarrassing flavor of DOS attack. If you feel fancy, throw a
bunch of money at haveibeenpwned to check whether people are putting dumb
passwords and let your local RegEx wizard check against all other silliness.
There you go. I even waive you the $150k fee for that extraordinary piece of
consulting.

------
whitepoplar
Given the nature of HN, I'm sure many of you have had inner-contact with
financial technology infrastructure. Are there any banks that stand out for
their technical competence/incompetence? Which bank(s) would you
patronize/avoid?

------
pier25
Not sure why but banks seem to be consistently bad at web dev, at least on the
front end.

I have never used a good looking modern web app from a bank. Usually it's a
slow bloated crap that looks and works like a project from 10-15 years ago.

------
joeblau
I have USAA and they are pretty bad as well. Max password length is 20
characters. They only do MFA through cell phone numbers and email which allows
someone to Sim-Swap if they are able to get your username and password. To top
it off, they have a mobile app knock-off 2FA screen, but you _can not_ see it
when you're trying to log in to your account via the mobile app because the
modal doesn't let you leave the input screen.

I was going to write them an email, but they have no clear email to report
security concerns so I figured they don't care.

~~~
yellowapple
Extra stupidity: you literally can't use the USAA app on a rooted Android
device; it'll detect that the phone's rooted and refuse to let you login. God
forbid I assert control over my own goddamn device, right? It ain't USAA's job
to lecture me about my own device security; its job is to shut up and show me
information about my car insurance.

------
paulpauper
the money is in hacking bitcoin/crypto-related stuff anyway. Get the 12 words
and there is nothing than can be done to recover the $ and nearly untraceable.
hacking banks is overrated unless you can not onyl produce a facsimile of the
victim including ID and other docs but also get past all the restrictions and
then not be found and arrested in the process.

------
evanb
I recently lived in Germany and was impressed by the security mandated there.
In order to do anything of note (meaning where you could lose money) you were
challenged to produce a TAN, one six-digit number from a one-time pad of ~100
that the bank mailed you. You produce that number, cross it out, and never use
it again.

Also available were SMS TANs, where they texted you a code. I avoided these
after reading about SIM swapping.

But, further, was a photoTAN. The bank mailed me a private key that I entered
into a reader app. Then they would present me with a QR-code-like image that
the app could read and decrypt into a six-digit code via the secret key. Type
that in, good to go. The reader app and the banking app also had some message-
passing thing where if you were banking on your phone (and couldn't take a
picture of your own screen...) it could still work.

------
ineedasername
If the thesis of this article were correct then there really shouldn't be much
of any account hacking. I couldn't find anything that gives the prevalence of
this, but there's tons of "what to do if hacked" articles and lots of posts on
reddit/message board about "I was hacked! Will I get my money back?"

Also, if the first line defense with passwords is poorly designed, why would
these security-by-obscurity hidden ones be any different? Sure, you sign in
form a new computer (or one that had its cookies deleted) and the site says
"You haven't used this computer before, answer this security question: What is
you Father's middle name?" That isn't a high barrier. If you know my name and
a little about me, plenty of white-pages style sites show relatives etc.

------
daveFNbuck
Having 100k possible passwords and locking my account after 3 failed attempts
does a pretty good job protecting a single account from being brute-forced,
but you can still brute force access to some accounts if you can guess enough
usernames.

------
NotATroll
> Do you really think the only thing the bank does to log people on is to
> check the username and password?

Yes. Yes I do. If you're putting arbitrary limitations on a user's password
length, down to _6_ characters even. I see no reason why you wouldn't be
equally as insane with the rest of your system.

And, frankly speaking. The whole "you're locked out after 3 attempts" non-
sense is complete crap. What is this now? We're supposed to believe databases
don't get hacked into, and hashed passwords aren't leaked on the net for
countless people to hack at and break?

This sentiment leads me to believe the passwords are stored in plaintext.

------
shin_lao
When the accounts of our company started to be beyond the low 6 figures, we
got upgraded by our bank to a different online banking system with a smartcard
and a keypad for strong 2FA.

Our admin team is informed every time someone logs in the system, and wiring
money is a 2 phase process. If a transaction is unusual, the bank usually
contacts us.

So yes, I do think banks have additional protection measures, it's just not
worth it for smaller amounts where the insurance will just cover it.

------
atoav
I don’t see how a bank that in 2019 doesn’t manage to have a decent password
policy earns any trust on that front. If they allow for longer passwords with
more characters the perceived security rises and in the age of password
managers the usability gets better.

If these advantages don’t outweigh the disadvantages of a bank, one could read
this as a red flag regarding the systems behind that interface.

------
nitwit005
> banks aggressively lock out accounts being brute forced

This is good, because it means people can't brute force the 5 digit password
they forced you to use, but also bad, because if someone doesn't like you,
they can easily block access to your bank.

If the account numbers are sequential, or otherwise patterned, they may be
able to block access to all users without using all that much bandwidth.

------
te
Sure, three-strikes-and-out reduces probability of brute forcing any
particular account with forced 5-digit password, but if an attacker has a list
of just 25k usernames, odds are that at least one is going to get brute-
forced.

------
JulianMorrison
A bad short password is only protected against crude online guessing by
aggressive lock-outs. If those passwords leak in hashed form, having a small
search space means they can be broken offline with ease.

------
meuk
My bank allows arbitrary length, but enforces certain special characters while
disallowing others. Which means I can't use the (long and secure) password and
have to write it down.

Not sure what they hope to accomplish.

------
zAy0LfpBZLC8mAC
Sorry, but that article is just dumb. For one, obviously, the possible
existence of other security mechanisms is exactly no reason for intentionally
breaking password security. Either you store passwords as plain text, in which
case you have just failed, or you are storing a hash, in which case there is
no cost to doing the right thing and accepting arbitrarily long passwords.
There is no way to start with "we have other security mechanisms in place" and
end with "therefore, we should weaken password security". And if an
organisation is incapable of understanding that trivial piece of logic, I have
very little hope for their supposed magic security solution.

But even worse: The idea that locking users out after so many failed attempts
is a security mechanism. When a small bandwidth of unauthenticated requests
can disable a critical service, that is known as a denial of service
vulnerability and not a security mechanism. If you have proper passwords,
locking users out is completely useless for security, but it's still a DoS
vulnerability. A brute force attack will not crack a 128 bit random password,
no matter the rate at which it is tried. And while non-public user IDs can
help mitigate that risk, it is not at all a given that banks don't use
essentially public account numbers as user names, even ones that have 6-digit
password limits. Plus, the user ID at that point effectively becomes part of
the password, just that it's a password that you can't change, which isn't
exactly brilliant either.

And finally: It's quite a failure at assessing attack scenarios if you think
that user lockout actually solves a problem. Your typical bank has a failure
counter per account. A failure counter that is reset on every successful
login. So, the real number of attempts an attacker could make is the number of
attempts you have before lockout minus one, multiplied by the number of
successful logins by the customer. An attacker might not necessarily be able
to know very well when the user has logged into their bank account, which sure
will limit the exploitability somewhat, but then, that very much depends on
the circumstances. If you know someone pulls their transactions every 15
minutes, say (especially a business, which might even leak the time they pull
transactions by sending payment receipts in response, for example), then you
might very reliably be able to make 8 guesses per hour, or ~ 70000 per year,
without causing lockout. If you instead want to target the general public, you
might also just use a bot net to attempt login into accounts only
occasionally, risking some lockout, but statistically compromising a certain
number of accounts over time.

And all of that when proper passwords do solve all of those problems perfectly
reliably.

Oh, yes, and the idea that some banks will give you your money back?
Seriously? Now, if that isn't a failure at assessing risks, I don't know what
is. Who seriously believes that banks will give you your money back on your
word that you didn't authorize some transaction? Of course, they won't, they'd
be wide open to fraud if they did. If the attacker is good enough at making it
seem like the customer authorized the fraudulent transaction, obviously, the
customer won't get back a cent. Those claims by banks are marketing bordering
on fraud, and obviously not something anyone claiming to be an expert in
security should just trust to be something you can rely on.

~~~
gruez
>When a small bandwidth of unauthenticated requests can disable a critical
service, that is known as a denial of service vulnerability and not a security
mechanism.

But what's your threat model here? Some attacker who's targeting you that
somehow got your randomly assigned username but not your password? Or someone
hitting every account number for "the lulz"? In the first case, it can be
resolved with a 10 minute call to the bank to get your username changed
(although you have bigger issues if your attacker was able to get sensitive
information such as your banking username). In the second case, the attacker
will get ip banned/rate limited very quickly.

>If you know someone pulls their transactions every 15 minutes, say
(especially a business, which might even leak the time they pull transactions
by sending payment receipts in response, for example), then you might very
reliably be able to make 8 guesses per hour,

Sounds like a very non typical use case. Most businesses I know pull
transactions end/start of day. Considering most/all banking transactions (ie.
not done through a third party platform like venmo) are done daily, this isn't
surprising. Even then, this exploit only works if there isn't a persistent
login fail counter. Getting a password wrong twice before getting it right is
ususal a couple times a day. Doing that 10+ times a day is definitely
suspicious.

>Who seriously believes that banks will give you your money back on your word
that you didn't authorize some transaction? Of course, they won't, they'd be
wide open to fraud if they did.

AFAIK they're obligated by law.

~~~
zAy0LfpBZLC8mAC
> But what's your threat model here?

What do I know? DoS attacks are a thing, so that's the threat model?!

> Some attacker who's targeting you that somehow got your randomly assigned
> username but not your password?

You are assuming the username is randomly assigned.

> In the first case, it can be resolved with a 10 minute call to the bank to
> get your username changed

Wut? For one, how is being denied access to your capital for ten minutes in
any way "solving" the DoS risk? Then, how does that even solve anything if the
attacker simply disables your account again within a few seconds? If your
suggestion is that using the username as the password somehow is supposed to
protect you, I have bad news for you: You usually can't change your username,
so you can not change that "password" to something the attacker doesn't know.

> (although you have bigger issues if your attacker was able to get sensitive
> information such as your banking username)

You have it all backwards? The sensitive part is what is called the password.
If your username is sensitive, you are already doing it all wrong. Especially
because, see above, you can change your password, you can not (usually,
easily) change your username-pretending-to-be-your-password.

> In the second case, the attacker will get ip banned/rate limited very
> quickly.

You have heard of this thing called a bot net, right?

Also, congrats, you have just introduced the next DoS risk: If you happen to
use an ISP where your IPv4 connectivity is only through NAT, and given that
most banks are IPv4-only, suddenly, some random customer of that ISP, or the
malware on their machine, can disable your access to your account.

You know what would actually solve that problem? Wait for it ... it's
passwords! Like, proper, real, high-entropy passwords. Who would have thought?

> Sounds like a very non typical use case.

The idea that banks should only be secure for "typical use cases" primarily
sounds like a very bad design principle.

> Most businesses I know pull transactions end/start of day. Considering
> most/all banking transactions (ie. not done through a third party platform
> like venmo) are done daily, this isn't surprising.

Except other countries have a slightly more modern banking infrastructure. All
of the EU is currently introducing realtime money transfers with a guaranteed
payment delay of maximum 10 seconds between any two banks in the EU. Pulling
transactions only every 15 minutes seems like quite a massive delay in
comparison.

> Even then, this exploit only works if there isn't a persistent login fail
> counter. Getting a password wrong twice before getting it right is ususal a
> couple times a day. Doing that 10+ times a day is definitely suspicious.

Well, yes, sure. But for one, that there is a persistent login fail counter is
a big if. If you are lucky, maybe there is. If there isn't, the bank will
blame you. And also, regardless, the problem still remains: There definitely
is no permanent login fail counter. Customers occasionally do mistype their
passwords, and that does not lead to lockout. But whatever the real maximum
rate of failed attempts is: The total number of possible attempts is more than
the advertised supposed maximum number of attempts.

> AFAIK they're obligated by law.

They are obligated to do what? Give you back your money because you say so?
Certainly not. Be able to determine with 100% accuracy whether a transaction
was fraudulent? Yeah, sure?!

~~~
gruez
>What do I know? DoS attacks are a thing, so that's the threat model?!

It matters because you need to consider the attacker's motivations, goals, and
resources.

>You are assuming the username is randomly assigned.

So? If not randomly assigned, the best you can do is enumerate all users in an
unpredictable manner. It's not like sequential usernames allows you to easily
guess the username for a specific person.

>Wut? For one, how is being denied access to your capital for ten minutes in
any way "solving" the DoS risk? Then, how does that even solve anything if the
attacker simply disables your account again within a few seconds?

It solves the DoS risk because it makes subsequent attacks sufficiently hard
to perform afterwards. If your username can be leaked within seconds, the
attacker probably has access to perform more devastating attacks than a simple
DoS.

>You usually can't change your username, so you can not change that "password"
to something the attacker doesn't know.

You might not be able to change your username online, but support can probably
change it.

>You have it all backwards? The sensitive part is what is called the password.
If your username is sensitive, you are already doing it all wrong. Especially
because, see above, you can change your password, you can not (usually,
easily) change your username-pretending-to-be-your-password.

Yes, usernames are supposed to be identifiers only, but keeping it a secret
from your enemies isn't particularly hard. Please explain how the attackers
are getting a hold of your username in the first place.

>You have heard of this thing called a bot net, right?

Here's why you need to consider the threat model. If it's some guy out for the
lulz, using a botnet incurs a cost (both in terms of actual risk in terms of
detection, and opportunity cost in terms of other things he could be using it
for eg. credit card fraud, DDoS for fire, etc.). And the guy is willing to
expend unlimited resources, then all bets are off. He could use amplification
attacks to take down the bank's website by raw bandwidth alone. Worst case the
bank mails/emails everyone new high entropy usernames.

>Also, congrats, you have just introduced the next DoS risk: If you happen to
use an ISP where your IPv4 connectivity is only through NAT, and given that
most banks are IPv4-only, suddenly, some random customer of that ISP, or the
malware on their machine, can disable your access to your account.

Strange. I can log into my financial accounts while using VPN without a
problem. You'd think that a VPN service that anyone can sign up for
anonymously would invite more abuse than an ISP that you need to provide real
credentials for.

>You know what would actually solve that problem? Wait for it ... it's
passwords! Like, proper, real, high-entropy passwords. Who would have thought?

You seem to be misunderstanding Troy's position. He's not saying it's ideal,
or even good practice. He's merely saying it's not as bad as you think. ie.
having a 6 digit numeric password doesn't mean you're going to get you hacked
within minutes.

>Except other countries have a slightly more modern banking infrastructure.
All of the EU is currently introducing realtime money transfers with a
guaranteed payment delay of maximum 10 seconds between any two banks in the
EU. Pulling transactions only every 15 minutes seems like quite a massive
delay in comparison.

I have a feeling that businesses that need low latency transactions aren't
doing so by scraping their bank's web page. They're probably using some sort
of payment provider, or the bank has an API.

>Well, yes, sure. But for one, that there is a persistent login fail counter
is a big if. If you are lucky, maybe there is. If there isn't, the bank will
blame you.

If anything, having a weak password gives you more plausible deniability than
having a 256 bit entropy password.

>They are obligated to do what? Give you back your money because you say so?
Certainly not. Be able to determine with 100% accuracy whether a transaction
was fraudulent? Yeah, sure?!

That's the point of obligating it by law. It's consumer protection to give
them the benefit of the doubt. If you have an airtight case against the bank
you wouldn't need it in the first place. I'd think you understand this
concept, given that you're from the EU. In any case, here's a citation for
you:
[http://www.nbcnews.com/id/8915217/ns/technology_and_science-...](http://www.nbcnews.com/id/8915217/ns/technology_and_science-
security/t/know-your-rights-bank-account-fraud/)

~~~
zAy0LfpBZLC8mAC
> So? If not randomly assigned, the best you can do is enumerate all users in
> an unpredictable manner. It's not like sequential usernames allows you to
> easily guess the username for a specific person.

... or just use their account number that's on their website. Really, what's
your point? Yes, you can potentially use some usernames as passwords. Doesn't
mean it's somehow more sensible than using passwords as passwords.

> It solves the DoS risk because it makes subsequent attacks sufficiently hard
> to perform afterwards. If your username can be leaked within seconds, the
> attacker probably has access to perform more devastating attacks than a
> simple DoS.

What? Denying you service prevents denying you service because it makes
denying you service any longer sufficiently hard, except it doesn't, because
that's just another three requests?

> You might not be able to change your username online, but support can
> probably change it.

So, now you are just pulling stuff out of your ass? And in any case, how does
any of this make any sense? Having bad passwords is a good idea, because we
can use the username as a sort-of password? Sure you can, but why the heck not
use the password as the password?

> And the guy really does have resources for a botnet, then all bets are off.
> He could use amplification attacks to take down the bank's website by raw
> bandwidth alone.

Erm, yeah? And why should he do that if a low-bandwidth attack does the job
just fine? And in any case, how is the fact that there is one kind of DoS
attack vector that you can not prevent a reason to also add another DoS attack
vector, and to then use that to justify that you put in effort in order to
weaken password security? Like ... what's your point?

> Strange. I can log into my financial accounts while using VPN without a
> problem. You'd think that a VPN service that anyone can sign up for
> anonymously would invite more abuse than an ISP that you need to provide
> real credentials for.

Which is a reason for building weakened security how exactly?

> You seem to be misunderstanding Troy's position. He's not saying it's ideal,
> or even good practice. He's merely saying it's not as bad as you think. ie.
> having a 6 digit numeric password doesn't mean you're going to get you
> hacked within minutes.

Yeah, having a root ssh account on your server with password "test" doesn't
get you hacked within minutes. So, how is that an argument? There is real
security, which doesn't get you hacked in decades, and then there is
everything else that is pointlessly insecure, and in this case way less secure
than he suggests in any case.

> I have a feeling that businesses that need low latency transactions aren't
> doing so by scraping their bank's web page. They're probably using some sort
> of payment provider, or the bank has an API.

... and banks use the exact same idiocy on their APIs, correct. Why would they
not if they are convinced that that is how you are secure, as they seem to be?

> If anything, having a weak password gives you more plausible deniability
> than having a 256 bit entropy password.

Well, sure. But then, not ever having any unauthorized transactions means you
don't have to worry about plausible deniability?

> That's the point of obligating it by law. It's consumer protection to give
> them the benefit of the doubt.

Erm ... you do realize that that can not possibly be the case, right? That a
bank can not possibly be obligated to give money to a customer simply because
the customer demands it?

> If you have an airtight case against the bank you wouldn't need it in the
> first place. I'd think you understand this concept, given that you're from
> the EU.

You are completely missing the point. There are cases where the bank is at
fault (like, they simply handed your money to someone else for no reason) and
you can show it. That's the case where the bank's general liability would be
all you need.

Then, there are cases where the bank received an order to execute some payment
that was authenticated with your credentials. Now, as subcategories of that
you have the actual legitimate payment that you ordered, the somehow
fraudulent order where you were defrauded and the bank can tell, somehow, and
the somehow fraudulent order where the bank doesn't see any signs of fraud and
you can't demonstrate it either. Banking regulation and/or voluntary
guarantees usually (mostly) cover that second subcategory. But there is no way
to possibly cover the third subcategory: That is the category or fraudulent
transactions that are indistinguishable from legitimate transactions by anyone
but you, and you obviously have a conflict of interest, so your word that some
transaction was fraudulent obviously is worthless in determining whether it
was. Anyone who wanted to defraud a bank could submit a legitimate transaction
and then claim that is was fraud, so that alone can not possibly be sufficient
to get your money back.

~~~
NLips
In the UK at least, the regulations cover the third category i.e. where you
can't demonstrate fraud, but neither does the bank have reasonable grounds to
suspect you acted fraudulently. From
[https://www.fca.org.uk/consumers/unauthorised-payments-
accou...](https://www.fca.org.uk/consumers/unauthorised-payments-account),
explaining when a bank is allowed not to refund you (although they are allowed
to refund you and then ask questions and report you to the police).

""" Why a refund can be refused

Your bank can generally only refuse a refund for an unauthorised payment if:

\- it can prove you authorised the transaction – though your bank cannot
simply say that use of your password, card or PIN conclusively proves you
authorised a payment

\- it can prove you are at fault because you acted fraudulently or because you
deliberately, or with ‘gross negligence’, failed to protect the details of
your card, PIN or password in - a way that allowed the transaction

\- you told your bank about an unauthorised payment 13 months or more after
the date it left your account, so make sure you contact the bank as soon as
possible. """

[edit - remove block formatting]

~~~
zAy0LfpBZLC8mAC
Gee, what is your point? Whatever the exact rules are: There are cases where
the bank will not be able to distinguish an actually fraudulent transaction
from a legitimate one. In those case, you, the customer, will be stuck with
the loss, there just is no way around that, other than preventing the loss in
the first place.

~~~
NLips
"There are cases where the bank will not be able to distinguish an actually
fraudulent transaction from a legitimate one. In those case, you, the
customer, will be stuck with the loss"

No, that's contrary to the FCA regulations. In cases where you can't tell if
there's been a third party committing fraud, the benefit of the doubt must be
given to the consumer. If the bank cannot demonstrate that the consumer is
committing fraud, they cannot refuse the consumer their money.

It's obviously complete nonsense to say "_whatever the rules are_, in scenario
X the bank will be able to do thing Y"; in this case the rule is "in scenario
X, the bank is not permitted to do thing Y".

~~~
zAy0LfpBZLC8mAC
> In cases where you can't tell if there's been a third party committing
> fraud, the benefit of the doubt must be given to the consumer.

Which is why I obviously was not talking about that.

> If the bank cannot demonstrate that the consumer is committing fraud, they
> cannot refuse the consumer their money.

OK. Now, the bank demonstrates that you committed fraud (that you didn't). Now
what?

~~~
NLips
If the bank satisfies a court with evidence to show the customer committing
fraud, then the customer won’t get their money back. Just like if the CPS
satisfies a court that someone committed murder, prison will follow even if
the person didn’t kill anyone.

This thread is rapidly losing value to readers now, since you seem to be
dishonestly representing what you’ve previously said, at best guess because
you don’t like to be wrong. Quoting you:

“the somehow fraudulent order where the bank doesn't see any signs of fraud
and you can't demonstrate it either.”

“That is the category or fraudulent transactions that are indistinguishable
from legitimate transactions by anyone but you”

“There are cases where the bank will not be able to distinguish an actually
fraudulent transaction from a legitimate one.”

Only now have you changed this to apparently mean the bank can falsely prove
the customer committed fraud.

There’s nothing wrong with not being up to speed on recent banking regulation
changes in the UK. There is something wrong with pretending you were saying
something you weren’t, just for the sake of internet points.

~~~
NLips
I’ll add an example to help get across how the regulations have changed:

If someone calls me pretending to be my bank and tricks me into giving them
enough details (passnumbers etc) to move money out of my account, or persuaded
me to authorise transactions they’re making (because I think they’re the bank
saving the money from being stolen by someone else), then the transactions
will look real to the bank. Previously, that was my problem. Now it is the
bank’s - I may have divulged my details in good faith, but I didn’t give the
criminal any money. The bank, unwittingly, gave the criminal money. The bank
is no longer allowed to claim it was my money. Rather, the bank still owes me
my deposit - nothing has happened to change that.

This has been a more commonly occurring crime in recent years, and the
regulations are specifically there to:

Protect the consumer

Put the onus on the bank, to encourage them to do better protecting their
money.

------
mark-r
I haven't been able to log into my bank for something like 10 years, because
their password restrictions made me pick a password I couldn't remember.

------
systematical
Still waiting on two-factor authentication from my bank. Even just basic SMS
with a 4 or 5 digit code like Vanguard does would be nice.

------
htfu
I cannot believe _ANY_ banks are using passwords at all in this day and age.
Reading discussions like this makes my brain hurt - even a decade and a half
back we were on chip and pin card readers for login/signing verification, now
since a long time back there's a universal app-based 2fa equivalent (Mobile
BankID). That's not the case for "my bank(s)" but all banks here.

I wonder what makes the US/UK/AUS so special? It's all incredibly alien.

~~~
jbarberu
Moving from a country with Mobile BankID to the US, all I can speculate is
that it's not a big enough problem for the banks to make the investment.
Similar to the healthcare system keeping the status quo is "cheaper" until
you're one of the unlucky ones...

------
nsfyn55
They do matter but not for the reason you'd first think. It's about liability.
Imagine a bank testifying in a hearing about a recent data breach. They are
going to want to give the perception that they have done everything within
reason to protect their user's data. Password restrictions are a cheap feather
in one's due diligence cap.

~~~
zAy0LfpBZLC8mAC
So ... how exactly is "your honor, we didn't allow passwords longer than 5
chars" going to help them, you reckon?

~~~
nsfyn55
Easy. Civil law operates on a concept called "preponderance". It's not
absolute in nature it's a measure of likliehood as measured by non subject
matter experts(a judge and some randos). Imagine a person has fallen on your
property and injured themselves. If you are known in the neighborhood as a
person that takes care of your sidewalk(shovels, patches broken concrete,
etc.) and can produce evidence(character witnesses, testimonials, visuals) to
that effect your case is strengthened.

No one ever got directly hacked because their password was too strong, but
lots of people have had passwords guessed by brute force.

So put the two together. Its beneficial to have strong passwords because they
can be presented as evidence of due diligence and there is no security risk to
enforcing them. There may be some business risk(people fleeing because they
don't like your password policy) but someone needs to quantify that its a
problem for it to be considered in the calculus.

~~~
zAy0LfpBZLC8mAC
That is a lot of text for not addressing my point at all!?

~~~
nsfyn55
You asked how it would help and I explained exactly how it would help. I
directly addressed your point.

Your content free, one sentence response not withstanding. Is there something
specific you'd like clarification about?

~~~
zAy0LfpBZLC8mAC
How exactly you think preventing your customers from using secure passwords is
going to demonstrate due diligence?

~~~
nsfyn55
Look at that sally, a false equivocation right out of the gate. I'll just
change your text so that it represents what I actually said ....

>How exactly does taking steps that have previously been used in civil suits
to demonstrate due diligence such enforcing password requirements going to
demonstrate due diligence?

Well I'm glad you asked billy! The answer is tautology. Thanks for playing.

This argument is stupid. You want to talk about yak shaving, theoretical
nonsense. FWIW I agree with you and think that password requirements are dumb,
but you live in the real world. These are the legal realities of IT policy.

------
QuantenGhost
What I hate is the impression. You can have mitigation controls galore. I
trust that they all do. However, it's difficult for average customers to
understand that. When even NIST has longer password recommendations, people
who hear that "long passwords are safer" should have that option. Banks are
relatively arbitrarily depriving security conscious people of that nominal
opportunity to try to practice good password hygiene. The line is that
password resets increase with password length. I'd be fine with that.

I am an Information Security professional, customer of financial institutions,
and started my earliest engineering career for a large bank.

