Can you store password safe and still send it to your users in cleartext?
5 comments
They are talking bullshit.
Here's an interesting article about password security: http://www.codinghorror.com/blog/2007/09/youre-probably-stor...
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...
To quote from that article: "We learned that the correct choice [to store passwords] is Bcrypt." (which is definitely one way)
Here's an interesting article about password security: http://www.codinghorror.com/blog/2007/09/youre-probably-stor...
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...
To quote from that article: "We learned that the correct choice [to store passwords] is Bcrypt." (which is definitely one way)
>"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.
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.
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.
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.
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.
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.
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.
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.
Just a question i have, which I think i have the answer to but I would like to hear your opinion!
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?
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.
First of all I know that you can not decrypt a hash, that is the whole purpose that it is a one-way, right?
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?
Thanks for your help!
I will use this as a prove, because i have not found any other pages that can prove what they say is bullshit.
Happy weekend, hackers!