HN Explorer

Ask HN: Storing Credentials Securely

9 points by Davertron ↗ HN
I know that storing plain-text passwords in your database is a no-no; for login credentials, the typical solution is to store a hashed password (preferably with some entropy or salt). But what about sites that store your credentials for other services or sites? I'm thinking about things like Mint (www.mint.com). Since hashing is a one-way function, they can't hash my credentials. So are they encrypting it, and hopefully somehow keeping their encryption algorithm/data safe? Is it even possible for the encryption algorithm to be REALLY safe? What's the best practice for doing this sort of thing?

I'd really like to hear your thoughts, since I'm a little nervous about giving people my banking credentials, but also because it seems like this sort of thing is going on more and more with aggregator-type services (things like Friendfeed).

6 comments

[ 2.9 ms ] story [ 24.5 ms ] thread
mattmanser
I have no experience of mint, but I used to use egg.com which accesses other bank accounts. That does it by installing an application on your computer that stores the passwords locally. I wouldn't trust anything else and even then there's still a certain amount of trust there that they're not lying to you about how it works.

As for another site storing your passwords, I'd at least hope they'd store it encrypted, but trusting someone else is a matter of, um, trust. Who knows, it could be in a text file called passwords on the root.

dryicerx
I am not sure how mint does it, but several ways to store highly secure data is since you asked for it

  * Boxes have no direct internet connection
  * Spread the Ciphertext, Decryption Keys, and Algorithm
    across multiple yet different machines (each with unique
    distributions/operation systems and data storage 
    solution). 
  * Instead of a global salt, use a separate salt per each 
    user (login name / account creation time)
  * Generate the encryption/decryption keys for storing the 
    credentials using a newhash(login+password) and use it 
    only when the user logs in (this hash is never stored,
    it's hashed, generate the encryption/decryption keys, 
    decrypt the data, use the data, and destroyed). So this 
    key only awailable for a short period of time when the 
    user logs in.  
  * Use something strong to encrypt like PGP as the base 
    and roll-your-own obscure one on top of it (which is a
    non-standard algorithm)
There will always be holes and weaknesses, it's just making it really really hard, never impossible.
Davertron
Yeah, "security by obscurity" seems like the only way to do it really. It's sort of like DRM; a DVD is encrypted, but your DVD player needs to know how to decrypt it, and since you have both items, the information for HOW to decrypt is in there somewhere, so you just need to figure it out...
[deleted]
(comment deleted)
abyssknight
Use OAuth. http://oauth.net/

That's what I'm using on FragTweet.com. To be clear, the service has to let you use it, but its still better than storing passwords. You get an authorization token from the target service that lets you authenticate as that user for certain actions which you can then store. At any time the user can deactivate the token through the service's control panel. Very slick, although not quite finished.

gojomo
Mint actually doesn't store your credentials. Rather, as I understand it [1], you essentially delegate to them certain read-only privileges for your accounts. Then, they use their own highly-authenticated channels to the financial providers to request only what they've been authorized to see.

They don't retain your own credentials; they've even said they don't retain exact knowledge of who you are -- just how to get your transaction stream and attach it to your Mint reports.

Apparently, they leverage the preexisting service for doing this established by Yodlee, a company that dates back to the first net boom and initially had a multi-account dashboard that did login for you, but evolved to a service for doing this in a more secure way.

[1] my understanding based on the link timf provided in this prior thread -- http://news.ycombinator.com/item?id=412715 -- and other research around that time