Second-Guessing a Password

Every now and then a password doesn’t work. I’ve copy/pasted them wrong, wrote down the wrong version when creating an account, and sometimes annoying websites actively prevent me from pasting into or autofilling the password field. Very rarely a password doesn’t work until I reset it. I usually chalk this up to having the wrong one written down, but sometimes I suspect the password requirements have changed from when I created it in an incompatible way. Recently, I was able to capture an instance of this in the wild.

For many years I’ve used KeePass to store most of my passwords. I like it a lot! There are many open-source clients for different platforms, it isn’t stored on a 3rd-party server waiting to be breached, and the database is a single file I keep updated on my devices with Syncthing - I don’t need to run any servers myself. Any sync conflicts from edits on multiple machines are quickly resolved with the builtin database merging tools.

Anyways, I have to login to Citibank every month to reauthorize it with my finance manager through Plaid. I’m not very happy with either of them, and there are some notable concerns about how Plaid stores your bank account’s username and password. I’d like to switch to something more privacy-respecting, but haven’t put in the effort to try that yet. Last month instead of getting Plaid’s usual man-in-the-middle window, an OAuth-looking popup for Citi appeared, served from auth.citi.com. Great! I’d really prefer to stop giving Plaid complete access to my accounts, so I copy-pasted my randomly-generated 64-character password, and the login failed with no clear error. I tried it a couple different ways, but it still wouldn’t work, so I went to Citi’s website directly to update my password and see if the requirements had changed.

They hadn’t, but I made a new one anyways and tried the OAuth window again. This time the KeepassXC browser extension offered to autofill it for me, and when it did it gave a warning that the password was too long for the field. The form itself still said nothing.

So I popped open the developer tools and selected the password input:

Here’s the HTML for the password input:

<input _ngcontent-idg-c167="" cdsinput="" size="large" id="password_input" name="password" type="password" maxlength="50" minlength="6" required="" aria-invalid="false" class="cds-input ng-untouched ng-pristine ng-invalid" placeholder="Password">

Sure enough, while the password requirements allow up to 64 characters, the maxlength of the input is set to 50! I removed the attribute in Firefox’s developer tools, submitted the form again, and logged in successfully.

One of my banks consistently fails when I login from their main page, but the login error redirects to an older-looking login page where the same id and password work. Maybe I’ll figure that out one day.

Update 2024-01-31

This is still broken. Generally, I don’t like the trend in software development of removing QA and relying on telemetry and user feedback to catch bugs. It’s sort of analogous to stores pushing self-checkout machines: cutting costs by moving work to customers and automation, with predictable results. But I’ve spent this much time investigating it and it hasn’t changed in a month, I think I should try to let them know.

How do I report this? The “Help” page on the Citi website only serves up articles about using the website, no mention of reporting errors. There is no email address or form on the website that I could find. They do have a bug bounty system for security vulnerabilities through a third party, but I wouldn’t clarify this as a vulnerability thus far, it doesn’t fit into any of the categories on the site (Password Policy Bypass?), and it requires agreeing to a lengthy set of terms, including not disclosing the issue publicly. They do offer phone support…

After 30 minutes of navigating Citi’s phone tree and talking to some very patient customer support representatives, I think a ticket was created.