
Can you store password safe and still send it to your users in cleartext? - Kevindish
Hi hackers<p>Just a question i have, which I think i have the answer to but I would like to hear your opinion!<p>Can you store the users password in a safe way and still be able to send it to your users, if they use a "forgot password" function?<p>I am asking this because a danish company send it to me in clear text, and when i confronted them that they should hash password, they said in a rude way that they did that, but had a kode when they decrypt it.<p>First of all I know that you can not decrypt a hash, that is the whole purpose that it is a one-way, right?<p>Second, i can see that you can not use the password for anything if you find a way to fish the passwords out of the mysql db, but what are the chance that not already have the files already?<p>Thanks for your help!<p>I will use this as a prove, because i have not found any other pages that can prove what they say is bullshit.<p>Happy weekend, hackers!
======
struppi
They are talking bullshit.

Here's an interesting article about password security:
[http://www.codinghorror.com/blog/2007/09/youre-probably-
stor...](http://www.codinghorror.com/blog/2007/09/youre-probably-storing-
passwords-incorrectly.html)

Even better is the linked article from matasano.com, but the link at
codinghorror.com is broken. This should work:
[http://chargen.matasano.com/chargen/2007/9/7/enough-with-
the...](http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-
tables-what-you-need-to-know-about-s.html)

To quote from that article: "We learned that the correct choice [to store
passwords] is Bcrypt." (which is definitely one way)

------
brudgers
> _"i confronted them that they should hash password"_

Maybe they should. Maybe they don't need to.

My bank needs to encrypt may password because of their fiduciary duty to
protect my money.

HN does not because the consequences of unauthorized access are relatively
trivial and there is no duty.

In other words, passwords should be encrypted if it is a better alternative
than not encrypting them and customer service concerns can easily outweigh any
benefit encryption provides.

------
pwg
In order to send a user a plain text password that has been stored encrypted
(as this company apparently claims) they must also have the key to the
encryption stored somewhere as well.

Which means that an attacker must: 1) obtain the encrypted PW from their
database and 2) obtain the key to the encryption from their database.

But if the attacker obtains their database, it is likely that he/she obtains
both the encrypted passwords and the key (or keys) to the encryption.

A real world analogy would be locking a document into a lockbox, then storing
both the lockbox and the key to the lock on the lockbox, together in the same
safe.

If someone cracks the safe, they have both the lockbox and the key, so the
lockbox becomes ineffective.

------
bdfh42
Hashing a salted password is definitely the way to go - and of course if your
hash algorithm is worth anything you should not be able to "unhash" it again.

It would, I suppose, be possible to salt and encrypt a password before storing
it and thus be able to retrieve the original but you would have to be very
sure that no 3rd party could get hold of your encryption key.

~~~
tonyarkles
I was just thinking about this too. You could do the normal hash approach, but
also encrypt the password with asymmetric encryption (public/private keys).
The public key goes on the server to encrypt the password, the private key
gets kept somewhere else securely.

When a user forgets his or her password, you use the private key to decrypt it
and give it to them. Depending on how securely you keep the private key (say,
on a USB key, kept in a lock box), it might be a hassle, but I'm pretty sure
it'd be a secure way to still have access to the cleartext passwords.

