3 ms·

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

breischl 11y ago
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.
- balls187 11y ago
  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.
yvesmh 11y ago
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.
- balls187 11y ago
  Okay. So they have to store your password, but it doesn't have to be plain text. They can encrypt it.
  - Spivak 11y ago
    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.
    - balls187 11y ago
      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.

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.

balls187 11y ago
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.

yvesmh 11y ago

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.

balls187 11y ago
Okay. So they have to store your password, but it doesn't have to be plain text. They can encrypt it.
- Spivak 11y ago
  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.
  - balls187 11y ago
    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.