
Why Canada’s banks have weaker passwords than Twitter or Google - uladzislau
http://theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-twitter-or-google/article18325257/
======
erichurkman
Their line of "it's for user experience" doesn't make sense. There's nothing
stopping them from saying they require a 6 character password, but also
allowing much longer, with symbols or other 'forbidden' characters.

More worrisome to me is the bank with case-insensitive passwords. I'd like to
think they are just .lower()ing the password before proper hashing, but I'd
wager they are storing it in clear text (and possibly showing it to bank
support agents).

~~~
nchlswu
I've worked on the UX team @ a Canadian bank and briefly touched a project
that dealt with passwords.

Based on the bank I've worked at and the limited information I've received, it
really isn't about the customer experience. It's likely related to legacy
systems (someone alluded to this in another comment mentioning COBOL) and some
outdated security practice in some of these systems. I think the security
teams ideally would like to increase password strength, but costs (and non
progressive technology teams) can tend to get in the way of making that
change. As the article mentions, they try and mitigate this with reactionary
measures and stricter restrictions when it comes to invalid login attacks.

For what it's worth, two-factor is being explored by banks and if I'm not
mistaken, the banks do have existing two-factor authentication schemes -- just
not for retail banking customers.

~~~
derefr
It seems to me that by taking a good KDF-hash of the user's password, then
"compressing" it (either by truncating or re-hashing it to a new output
length), you could get it down to a size where the _base32 representation of_
those bytes, would both A. fit into the legacy password field, and B. obey its
alphanumeric-only restrictions.

Naively, you'd think the compression would make the password field much more
prone to preimage attacks (e.g. JtRing a hacked DB dump), but calculating each
attempt would still require a full KDF series, even if large amounts of the
KDF's output keyspace are getting conflated at the end. You'd likely have a
lot of _accidental_ collisions between passwords that happen to hash to the
same value in your restricted keyspace, but they'd be no help in finding a
purposeful collision, because the _input_ keyspace would be unlimited.

Of course, if you only have 40 bits of output keyspace available (i.e. a field
with a capacity for eight base32 characters), you "only" need to KDF 2^40
passwords to generate a probabilistically-complete rainbow table. So, make
sure to salt _the compression step_ with something user-specific, e.g. The
UID. One simple method of achieving this would be to have the output look like

    
    
        base32(trunc(40, kdf(pw)) XOR trunc(40, kdf(pw ++ uid)))
    

This basically means that a successful preimage attack on your compressed KDF
be would require a unique collision between the salted and unsalted hash
outputs—effectively doubling the output keyspace one would have to search, as
well as giving you the regular benefits of per-user salts.

\---

...or you _could_ just put the hash of a random opaque token in the password
field; stand up a modern, separate server that runs a "password service" (in
the SOA architecture sense) to keep a map of full (UID, KDF hash) pairs to the
opaque tokens; and then have your web service hit the password service to
(potentially) return it a token to use as the password in the conversation
with the legacy auth system. You know, either way.

~~~
joesmo
You are assuming that the passwords will be hashed and salted, something I
doubt happens in most of these systems.

------
kohanz
_Toronto-Dominion Bank allows case sensitive 8-32 character passwords with
special characters._

Unless TD recently changed their requirements, this is not true. TD Easyweb
(lol) stores a password of 5 to 8 characters.

What's worse is that while TD does allow you to enter passwords greater than 8
characters long and will let you happily believe that it stored the password
you entered, it actually only stores the first 8 characters and validates
against those. That is to say if when you created your account you entered a
password of "Aardvark123zxcv", Easyweb will not mention anything about your
password being too long, but your actual password is truncated to "Aardvark".
When you log in, Easyweb will accept "Aardvark<anything else>" as a valid
password [0].

It took me a year before I accidentally discovered that my 15 characters
password was actually being truncated to 8 and I didn't need to type in those
last 7 characters as all. There was absolutely no indication from the UI that
the extra characters were unnecesary.

[0] [http://forums.redflagdeals.com/td-online-banking-should-i-
wo...](http://forums.redflagdeals.com/td-online-banking-should-i-
worry-1165939/)

~~~
otoburb
Whoever gave the Globe and Mail journalist the information about TD's password
restrictions didn't differentiate between TD Bank USA ("TDB") and TD
CanadaTrust ("TDCT"). TDCT is the Canadian corporate entity (and parent
corporation). TDB is TDCT's US banking operation.

TDB has password restrictions listed in the article (8-32 characters with some
special characters). TDCT restricts one to the 8 character restriction (!), as
you pointed out. EasyWeb is the name of the TDCT (Canadian) online banking
site. There is no corresponding brandname for the TDB (US) online banking
site.

The highly restrictive TDCT password is why I have to keep changing my TDCT
password rather often compared to other online banking accounts.

~~~
MAGZine
This is simply not true. My TDCT password is 32 characters long, and 8 of the
32 will not cut it. TDCT needs at LEAST 8 characters, one letter, one number,
but no longer than 32 chars. I think some symbols are restricted.

~~~
kohanz
Thanks for the update. As I said _Unless TD recently changed their
requirements_ , which it seems they have.

------
tomasien
Bank security for online banking is in a sad state, but (kind of like credit
cards) they have ENOUGH protocols in place to stop virtually all fraud. They
do this by being ultra aggressive though - they just CLOSE bank accounts that
have weird activity. You probably don't know this, but if you travel to India
for example and try to log into your online banking, banks outside the top 4
in the US may actually close your account if you don't respond when the fraud
team calls you. Close as in, here's a cashiers check, you need a new account.

That's a UX problem that's hidden from most of us, so to them it's a win. To
me, it's a disaster. We spend a lot of time working to improve this
experience, and hopefully the banks will start to change the way they think
too. We're seeing some movement from them.

~~~
kalleboo
I wonder if that's why banks in Sweden enforce far better security[0] since
Swedes in general seem to travel a lot more than north americans (gap years
backpacking through asia, india etc) so that the solution of "just shut down
any suspicious activity" would affect too many customers. I travel a lot
(including to places like Cambodia, China, etc) and my banks have only
triggered on fraud twice, and both times it seemed legit as it was in periods
when I wasn't traveling (they simply proactively issued new debit cards).

[0]
[https://news.ycombinator.com/item?id=7864991](https://news.ycombinator.com/item?id=7864991)

------
ufmace
The funny thing about this issue is that while many banks have ridiculously
bad authentication systems from a network security point of view, they
generally seem to suffer almost no negative consequences from it, as far as
people actually getting hacked and losing money. Perhaps it's the level of
secondary checks in their systems making it tough to actually monetize a
hacked account without leading the law straight to your door.

Maybe there's a lesson here - a broader approach to security, like
implementing checks at every level of operation to make sure nothing bad
happens even if an attacker is deep into the system, is better than a singular
focus on password length and other login details.

~~~
FigBug
I think you are correct. Even with a hacked account, it's very difficult to
move the money into another account without leaving a trail. Either the money
will have a hold for days or the transaction can be reversed.

There are also consequences, steal money and you'll probably go to jail. Hack
somebodies email, law enforcement probably won't do anything unless it's a
high profile case.

Compare to BitCoin. Irreversible anonymous transactions. Far better security
and coins are constantly getting stolen. I really don't think BitCoin will
succeed since computer security in general is still kinda amateur hour.

------
kalleboo
Both my Swedish banks require two-factor authentication - you get a physical
PIN pad when you sign up, and you can also set up a 2-factor app on your
phone. All transfer amounts and account numbers have to be signed on the PIN-
pad, securing you from man in the middle attacks that are possible with one-
time-codes. They both also have password-only login, but it's read-only, you
can't do transfers.

I wonder what makes the banks in the two countries have such different views
on security?

~~~
eli
Out of curiosity, if someone does hack a Swedish bank and steals money, who
takes the hit? The bank or the customer?

~~~
callesgg
If the bank is hacked they, if you lose your hardware key generator and don't
report the loos to the bank you. (The thief must have the device pin code to
use it.)

Here is the device my bank uses.
[http://www.vasco.com/Images/DP%20260_DS201109-v1.pdf](http://www.vasco.com/Images/DP%20260_DS201109-v1.pdf)

------
joesmo
Lax security by banks is certainly nothing new, nor unique to Canada. I've
always wondered about sites that do not allow "special" characters. What could
they possibly be doing to not allow that other than storing passwords in
plain-text? After all, any secure crypto hash (and even regular hashing
algorithms) will not care about special characters in the source content. I
suppose it could be any number of components between the user and storage, yet
I can't think of any system off the top of my head that's that shoddy.

~~~
eli
Writing new software is easy. Maintaining large, existing codebases for
mission-critical software is hard. Banks were early adopters; there's _fifty
year old_ code that does some things extremely well, but also sometimes
results in user-facing quirks like oddly limited password fields.

~~~
joesmo
Good point. Assuming that the offending code is the actual password storage
rather than an intermediary subsystem, one can safely make the assumption that
such password storage is insecure. Which isn't much of a revelation,
considering the article.

~~~
eli
Maybe true, but I've learned not to make assumptions about how large & complex
systems work based only on the little piece I can see from the outside.

------
gorhill
Based on the article's description of password limits, normalizing maximum
password strength into bits for easy comparison:

Toronto-Dominion Bank: 210 bits

Royal Bank of Canada: 195 bits

Bank of Nova Scotia: 83 bits

CIBC: 71 bits

Bank of Montreal: 36 bits

Tangerine: 20 bits

------
zAy0LfpBZLC8mAC
One thing that tends to be more or less ignored: The defenses that banks
deploy to protect themselves against the bad passwords that they force their
customers to use are not intended to help the customer, very much the
opposite, they are a vulnerability in themselves.

Specifically, the tendency to lock an account after a few wrong login attempts
is effectively a DoS vulnerability for the customer, as it allows anyone who
knows your username (which often even is just the account number, so
essentially public information) to trivially prevent you from accessing/using
your money.

Their only focus is on preventing third parties from accessing my money, but
my interest is not that third parties can not access my money, my interest is
that I can access my money, which means both not having it taken by third
parties, but also not having it taken temporarily by the bank who want to
protect themselves (if the bank locks me out from my account, that's
functionally equivalent to them taking all my money out of my account for a
day or two (or however long it takes to reactivate the login) - while I am
locked out, I can pay just as much as when there is no money in the account).

~~~
eurleif
>while I am locked out, I can pay just as much as when there is no money in
the account

Being locked out of online banking doesn't disable your debit card or your
paper checks, does it?

~~~
zAy0LfpBZLC8mAC
True, but mostly besides the point? I mean, not only can you not freely
substitute debit cards or paper checks for wire transfers, but also you
potentially cannot even access funds in some savings account, say, through any
of those, plus there obviously are many more services that banks provide that
have nothing to do with payment, but which are affected by the same problem.
Read some bad news and want to sell some stocks before the price plummets? Not
today, you have been locked out for security reasons!

------
Mister_Snuggles
It's ultimately a tradeoff, and for an organization like a bank it's a really
interesting one.

Every added security requirement limits the size of the customer base that's
going to use the online system. For myself, a two-factor system with an app or
SMS to provide the second factor would work fine, but for my parents it
wouldn't. Every increase in security requirements has a tradeoff between
customers that will use it and customers that will abandon online banking
because it's become "too hard".

For the bank, when a customer abandons online banking, that means that there
are longer lines at the branch, which means they need more people to provide
the same level of service.

Note that I specifically said "security requirement". If two factor
authentication was optional (not a requirement), then some accounts would be
more secure than others. This would potentially make the less secure accounts
more of a target since attackers may avoid the more secure accounts. There is
also all of the development and testing and maintenance efforts required when
you make different customers have different authentication methods.

The bank knows all of this and more. They balance their risk (reimbursed
customers due to poor security) against the costs (people abandoning online
banking, people switching to an easier-to-use competitor, implementation
costs, etc).

~~~
kalleboo
Despite all major banks in Sweden strictly requiring 2-factor authentication,
82% of Swedes between the age of 16-74 use internet banking[0]. Are there
really that many users who are scared away by it? Perhaps Canadians are less
tech-savvy in general than Swedes?

Personally I'd be scared away from internet banking if my bank had a weak
password scheme - and I remember that was the kind of comparisons made between
banks by the consumer magazines when internet banking showed up in the late
90's - "which is more secure".

[0] And between 65-74 years, the number is still 60%!
[http://epp.eurostat.ec.europa.eu/tgm/table.do?tab=table&init...](http://epp.eurostat.ec.europa.eu/tgm/table.do?tab=table&init=1&language=en&pcode=tin00099&plugin=1)

------
cbhl
As far as I can tell, these limits apply to passwords, but not to security
questions. Maybe we should just put passwords into the security answer field
as well (since the bank will almost always ask for a security question/answer
if you're logging in from a different computer than normal).

------
vauth
I've been working on a prototype to allow authentication via your voice,
instead of a types password. You must know the password phrase, and only if if
_you_ say the phrase will it pass. It isn't infallible, but generally more
secure than any typed password.

I'm curious, would anybody rather use that vs a typed password? It works via
browser (using getUserMedia) or phone call, but the user most enroll first.

~~~
err4nt
Unless you're ready to have a conversation with the person and have all the
answers to verify in advance, how can you differentiate between a live voice
and a recording?

It wouldn't be easy for somebody to obtain a recording of my pass phrase, but
it's possible.

Also, with all the phone related surveillance going on I would rather put
money on the fact that my calls HAVE been recorded rather than that they
HAVENT been recorded. I know you can encrypt web traffic, but right away the
idea of saying something in ~~plaintext~~ plain voice over the phone seems as
secure to me as tattooing my email password on my hand. I'm genuinely curious
and not trying to shoot your idea down, but those are questions I would need
before trusting it with anything more than a 'login of convenience'. I would
use it for Skype let's say, but not my email. I might use it for Hacker News
but not banking.

I had the idea of protecting client websites behind a Twilio-powered login to
impress clients, but I never did it. I pictured sitting down with a client,
opening a laptop to a giant lock with NO obvious text entry. You press the
'login' button and immediately your phone rings in it's pocket. "alpha forest
forty five" and suddenly the lock opens and he page refreshes before their
eyes. Now want to see the latest designs we have?

~~~
vauth
>Twilio-powered login to impress clients

Sure, would love to see the designs. That is actually a very similar idea,
based on two factor authentication.

>> but it's possible.

Anything is possible.. but if security is your concern, bioauthentication is
much more secure than a password. Or proving you are you by.. replying to a
text. Anybody could reply to a text, nobody can fake your voice, even if they
know your password. Recordings don't generally work (low signal) and are much
harder to attain, unless you are the NSA. In which case.. they don't need this
anyway.

Security isn't the issue.. usability is. You have to enroll, and there are
false negatives... and mainly it is just harder to use than typing.

------
RobotCaleb
When will secret questions go away? It's much more likely that someone will
know my mother's maiden name than figure out my password.

------
arb99
related: [http://www.snipe.net/2008/12/warcraft-security-better-
than-b...](http://www.snipe.net/2008/12/warcraft-security-better-than-banking-
security/)

(i think i actually remember a better article about that, that went into more
detail why WoW has better security than banks, but I can't find it. I probably
saw the article that I am thinking of on Hacker News)

------
JimmaDaRustla
Many banks have security questions and force them as a second factor when the
IP address is not associated with the account.

------
jagger27
It's news to me that TD allows for good passwords. I sent in a scathing
support ticket not 6 months ago.

~~~
Pxtl
Now I'm wondering if this is a TD puff-piece in celebration of updating their
security software.

~~~
lstamour
Doubtful, I think the reporter was either lied to or was given an answer for a
different system.

~~~
jagger27
It's true. Just updated my EasyWeb password to something about 20x stronger.

~~~
lstamour
Funny how they didn't send out a "Please change your passwords" email then ;-)

------
iLoch
TD requires that you know a single security question in order to initiate a
password reset. _One._

