4 ms·

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 mu

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

dorfsmay 12y ago
Absolutely! 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.
nchlswu 12y ago
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 12y ago
  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 12y ago
    You are assuming that the passwords will be hashed and salted, something I doubt happens in most of these systems.
UnoriginalGuy 12y ago
Right now they use a single password for online and telephone banking. That's why it is numbers only, so people can enter it over the phone. If they did what you suggest their users would need to setup one pin for telephone and a different password for online access. So it is in fact for the user experience, but that only makes sense if you remember telephone banking is still a thing.
- aroch 12y ago
  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.
  - gefh 12y ago
    Which is way less secure. Caller id is spoofable, your ss# is known by hundreds of people.
  - deleted 12y ago
    [deleted]
paulgb 12y ago
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.
alextgordon 12y ago
It's a bank. 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.

dorfsmay 12y ago

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

nchlswu 12y ago

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 12y ago
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 12y ago
  You are assuming that the passwords will be hashed and salted, something I doubt happens in most of these systems.

UnoriginalGuy 12y ago

Right now they use a single password for online and telephone banking. That's why it is numbers only, so people can enter it over the phone. If they did what you suggest their users would need to setup one pin for telephone and a different password for online access. So it is in fact for the user experience, but that only makes sense if you remember telephone banking is still a thing.

aroch 12y ago
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.
- gefh 12y ago
  Which is way less secure. Caller id is spoofable, your ss# is known by hundreds of people.
- deleted 12y ago
  [deleted]

paulgb 12y ago

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.

alextgordon 12y ago

It's a bank. 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.