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).
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.
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
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.
US banks require you call from the phone number on the account and have you enter your SSN after they match the # to their records. No separate pin needed.
Also, the cost of the "convenience" of not having 2FA is that they have to be hyper-vigilant about looking for fraud. I've had my RBC account locked twice this year because I use a VPN sometimes.
Also, saying that longer password are more difficult to remember is not true. If you let me type a longer password including the space character, I'll use a sentence that is easy to remember for me.
If a hacker gets into a bank's systems, they're not going to bother to steal passwords. Passwords have little value (except to blackmail the owner) and hacking into a bank is a very serious crime.
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.
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.
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.
I stand corrected. I just checked my "change password" option on TDCT and it now allows 8-32 characters. A year ago, this wasn't possible for my TDCT account as I distinctly remember the difference between the US and Canadian online banking experiences. I should read the fine print more often.
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.
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).
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.
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.
> making it tough to actually monetize a hacked account without leading the law straight to your door.
Nope, monetizing a hacked account without doing that is trivial (at least here in Europe where money transfers are an everyday occurrence for everyone and few people remember what a "check" is):
Send out spam promising a way to make $$$ from home without qualifications as a "financial agent". Transfer money from hacked accounts to the gullible, desperate schmucks who respond, tell them they can keep 10% as commission and have to transfer the rest via Western Union to someone in Russia.
> Maybe there's a lesson here - a broader approach to security
Defense in depth, should be a widely-known concept by now.
Indeed, a multi-layered approach, while more expensive, provides some advantages. It is also interesting to compare this system to the one applied in countries where security is more of an issue.
In Brazil, for instance, where hackers get quite creative, some non-business accounts offer 2FA via authenticators.
Some banks even require you to install some "security" Windows software before enabling you to use your home computer. Needless to say, such software is not always easy to remove (as most trojans). I'm not sure how it would work on a Linux (if it would work at all).
And sometimes they also limit online transfers to ridiculously low amounts (e.g. 100$/day).
Despite all that, they only allowed numeric passwords for the online system, consisting of 8 digits (chosen by the user) + 3 characters (chosen by the system). I believe this is to ensure the same password can be used in ATMs as well.
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?
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.)
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.
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.
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.
For Canada specifically, they might be worried about people creating a password using a Canadian English+French keyboard (which has a good few accented characters etc.), then trying to type it in on an American English keyboard, and finding those characters unavailable. (Both keyboard types are commonplace here.)
Should never have to give out your password over the phone, but for security questions the reason why its often alphanumeric is you will have people entering security questions like "how much did your first car cost" and they enter something in pounds sterling and pence which the Philippines call center phone script reader who deals in dollars all day isn't going to be able to interpret.
Or "what street name did you grow up on" could include some UTF-8 glyphs from Asian immigrants.
I have a Canadian bank account which requires [0-9] for your password, but it is only enforced in Javascript. If you disable Javascript, you can use any password you want. At least in their case, it is not a technical limitation.
Mainframes are the usual culprit. I've worked on them, and its an interesting experience. Such as running programs that are 30-40 years old and the customer doesn't have the original source code anymore. I enjoyed COBOL, but the condition of old stuff poorly maintained is frustrating.
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).
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!
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).
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".
There is also a herd immunity as the bank is highly unlikely to post two lists on their website, one of low security users and another of high security users. So outside attackers have to break the first ring of security before knowing there exists a second ring.
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).
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.
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?
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.
Probably not. While any additional factor makes authentication more secure, a voice line allows anyone nearby (or farther away with a unidirectional mic) to compromise that factor. Further, the false negative rate would concern me. What is wrong with TOTP 2-factor?
Losing your phone effectively locks you out of all your 2-factor accounts. If it's stolen by the wrong people and unlocked/unencrypted, they'll get access to pretty much all of your accounts through a password reset. I'd say that's pretty bad and we have yet to find a good, secure way to authenticate users.
I if somebody (or some machine) knows your password, they can use it. Just type it in. Voice authentication, knowing the password is not enough, the right person must say the phrase. Recordings don't work (low signal), and previously used recordings can be detected.
(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)
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).