← Back to context

Comment by mcherm

10 years ago

More likely it is to prevent your having to say your password to the person on the phone. This protects you from a malicious bank employee.

Right, but my point is the backend to make this work must be terribly insecure. I just did some reading, and apparently they take your password and just store the keypad equivalent (or more likely, a hash thereof). So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

  • > So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

    I'd have to see this to believe it. I would hope that they would at least store it as two separate entries, and only use the phone one during the phone process. And the person on the phone will likely still ask you some less-sensitive verification questions.

    • I had googled just now and read that somewhere else, but you are right, I just tested it, and it does not work as I described on the website itself.

  • > they take your password and just store the keypad equivalent (or more likely, a hash thereof)

    That's… not exactly more likely. These are commonly systems predating the internet, from a time when connected networks were trade-specific and Very Expensive, storage security was a lesser concern (and CPU-expensive) when the system could only be accessed on dedicated lines only accessible to employees.

That'd certainly make sense — a lot of what we see now are fossils like that, frozen in the amber of legacy systems.

That would be a reasonable precaution in the era before recording devices became cheap, tiny and ubiquitous (or capable of doing signal processing in real-time) – just as changing passwords monthly made more sense in the 1970s when shoulder-surfing was the major threat and lack of remote access throttled guessing rates even more than slow CPUs. (Repeat for plastic ID cards before you could buy a printer at Costco, etc.)

I don't know what Fidelity does, but I work at a bank and if we were to implement such a feature we handle it securely. When you set your password we store a hash of the password, but we also store a hash of the keypad version of your password.

So logins to the website still use the full character set -- only logins via the phone are verified against the keypad mapping. That one has less entropy (because of the reduced character set) but attempts to brute-force it will QUICKLY be recognized and stopped, since each attempt is visible to a human being who is handling the phone call.