A question...

I'm no security expert but I can still see that the rise of web-services is going to lead to some serious vulnerabilities.

Any developer worth their salt hashes passwords when storing them on a server. Ideally this will be a one-way has so that even if someone cracks the database they still can't see the password.

What happens though when your website also accesses data from several other websites - perhaps it provides an interface to your del.icio.us or flickr accounts. Being a helpful sort of chap the designer of aforementioned tertiary-service lets you save your passwords for these accounts so that you don't have to log in again every time you open up his new uber-site.

There's a problem though. When he stores your Flickr and del.icio.us passwords, he can't do a one way hash because he's got to use them to get back into your Flickr/del.icio.us accounts. Normally you might MD5 a password but the whole point is that md5_password isn't much help when you need to actually login. Solution - a two way (and hence fairly pointless) hash that makes it less obvious that a database column contains passwords.

Not a great solution though is it? I've been mulling this over for ages and have come to another solution. I'm sure this is a time-tested security technique but since my knowlege of security is less than others, I'd be grateful for confirmation.

Could passwords be securely stored by using the unhashed password for the tertiary service (all-my-accounts.com) as a salt to encrypt the third party passwords? Doing this means that a password is never stored in its entirety. On login to all-my-accounts.com the server then breifly decrypts the stored passwords, despatches them to flickr/del.icio.us to get a cookie/session id and flushes all unencrypted info.

Passwords are only ever on the server in an unencrypted form during the initial login and even then they're never written to a file or database.

Does this work or is there something I've missed?