The fact that Intuit owns Mint was a big part of the reason I finally caved and signed up. They're not inexperienced with dealing with private information.

Yes, on the "banks should be required to provide a secure, open feed" (though good luck in the one chosen resembling any modern format).

But... securing information of this kind is not rocket science. Sharding secrets into multiple tokens split across minimal service machines, etc. It's just that best practices are so rarely followed.

Why does Mint have to store your bank password in plain text?

They don't have to store it in plain text, but they do need to store it with reversible encryption (as opposed to hashing) so that they can use it to login to the bank's website.

Right, that's my point. There is no technical requirement to be stored as plain-text.

Though I would imagine that encryption, by definition, is two-way (encrypt, decrypt).

As an aside, do merchant account API services provide a secure-token service to store credit card information? That is, I enter in my VISA credit-card, click "save" and Amazon.com gets a unique token back that identifies this credit card. When I later go to purchase an item, Amazon uses this token to with VISA to charge my card? IIRC, that is how Stripe works, but I wonder if each credit card manufacturer now supports this, as part of PCI compliance.

Because there's no API, so they have to scrape your transactions off the bank's sites, and they have to log-in using your credentials for that.

Okay. So they have to store your password, but it doesn't have to be plain text. They can encrypt it.

Translatable to plaintext without user provided information is still plaintext.

When a website stores the hash of your password on their servers for you to authenticate against they have no way to recover your plaintext password without brute-forcing the hash. They can verify that the password you sent them is correct but they can't tell you your password.

If, Mint say, encrypts your password on their servers with their own key then they still have the plaintext password because the process is reversible to them.

To do this right, Mint would be given a piece of information, say an OAuth token, which would allow them to authenticate to your bank without them knowing the password you use to log in.

We're arguing semantics of "storing."

They're not storing "plaintext." They're storing the "ciphertext." The fact that you can decrypt ciphertext to obtain plaintext, does not mean you are storing plaintext. You can certainly derive plaintext from it, but the actual plaintext, that is, the input to an encryption algorithm, is not stored.

If an attacker gets a database, but does not have access to the encryption key, they do not have your plaintext password.

-----

I agree, a more preferred way would be for MINT to use OAuth type data delegation. However, they're beholden to what the banks themselves support, and most do not support anything other than account impersonation via username/password.