tags:

views:

187

answers:

10

My website doesn't contain too sensitive data. I'm thinking about storing passwords as is because if a user wanted to receive their password by email (if they'd lost it) then I'd be able to send it to them rather than doing anything cumbersome and grueling to users like sending them a new password I created (it's also ineffective).

Should I just store them as is?

+6  A: 

The passwords are sensitive data - people use them across sites, you don't want it to leak, or to be visible - not even to you or your programmers.

Kobi
+20  A: 

No, you should hash them. Most users have the same password on multiple sites, so even if your site is not too sensitive there could be other sites with the same username and password that are more sensitive.

If users forget their passwords, send them a new one.

Emil Vikström
In general I agree with hashing the passwords, though as a web site owner I can't be help accountable (and frankly shouldn't care) if a user wants to use the same password on multiple sites.
Jason Snelders
I think most users expect you to hold their information secret, including the password. It's in your interest to keep your users happy. It isn't that hard to keep passwords safe.
Emil Vikström
@Jason - I don't know if you worked with users, but you **cannot get away** with holding them responsible after a leak is found in *your* site. Even if their password was 1234567. No way. They will blame you, and they'd be right to do so.
Kobi
The thing with users using the same password everywhere is key to me
Jaco Pretorius
As I see it, with OpenID there's no real reason to force users to create a separate account on your site. Blaming users for using the same password for multiple sites is a cop-out when you're part of the problem (every dinky little site wanting you to create a new account).
Michael Borgwardt
But what if someone hit the "forgot my password" for another user malevolently? The user would not know about this and would evidently try to log in with his no longer valid password. I imagine that would be a nuisance.
sombe
+2  A: 

No. The password might not be important from your site's perspective, but naive users tend to reuse their passwords. You might be holding, say, a user's bank account password. You should even apply a random salt that is stored with the hashed password (usually as a prefix string), so that the same password can't even be identified across sites or accounts.

Marcelo Cantos
not-naive users do it as well...
dionadar
+7  A: 

The default answer is YES, HASH (AND SALT) THE PASSWORDS, in screaming caps.

The reason for this is that the majority of users use the same password for all sites that they log on to, so if your site is ever compromised, then all those passwords are out in the open.

David Hall
+4  A: 

I ran a website sometime ago and I can suggest: do not store plain text passwords. Many users use same password for several applications and, if your site is compromised, they will blame you.

Hash your passwords and send a new one, with expiration time, if your user lost it.

Rubens Farias
A: 

Atleast encrypt them and then decrypt when needed. There are quite a number of encryption techniques. Eg DES, Triple DES, TRIPLE_DES etc. Or you can create some simple technique yourself.

I am not sure in what language you are coding but most of the modern programming languages like c#, java already have libraries for encryption. You can use them also.

Aseem Gautam
You should never encrypt passwords with a two-way cipher; it should be impossible to recover the original. One-way hashes are the established norm.
Marcelo Cantos
I know. But sometimes the business requirements need the password send back to the user. So my sugesstion was towards a scenario when the password needs to be send back to the user.
Aseem Gautam
if business requires them to send passwords back, it is the developer's task to explain them why this should under no circumstance be done.
martinus
If a website sent me back my original password when I lost it (additionally, in a plaintext email), I'd immediately unsubscribe from it because it would mean they're storing it insecurely and handling it irresponsibly.
axel_c
Well, I am not saying or suggesting that encryption is better or an alternative to hashing. But its better than storing passwords as they are.
Aseem Gautam
So you would use the same passphrase for encrypting all the passwords, basically giving an attacker the chance to hack _all_ user passwords at once? And where do you store the passphrase? And how do you secure it?
axel_c
+8  A: 

Why the dilemma? You should probably not be developing account management system yourself. Take some standard component of password management, and save yourself debugging and security bugs.

Pavel Radzivilovsky
Good idea. To take this further - I don't know how normal people react to OpenId, but that would be my favorite.
Kobi
@Kobi - I'm technically savvy and I don't like OpenID. Why? First of all it's slower to log in as it requires page redirects etc. rather than just an SSL post. Second as I don't really want any OpenID providers tracking all the sites I log in to, and don't want all my site credentials in one basket, I have to go and create a new OpenID for each site I join anyway which is typically slower than registering on a new site. In any case, due to the added complexity over a basic reg form there's no way I'd use OpenID on a consumer-oriented site.
Greg Beech
@Greg - defiantly. *I* like to login with my openid, but if the users are consumers, this is mostly out of the question. As for "all eggs in one basket" - if someone has access to your mail, they can reset your passwords. In that regard, using your google profile is just as save.
Kobi
+1  A: 

NEVER EVER store your password in clear in the database. And please tell what other websites you developped so I never create an account on them.

chburd
lol again lol and lol goes on
Deepak Singh Rawat
no need to go overboard dude, I was just asking.
sombe
well, i think i forgot some smileys in my messages ;-)
chburd
A: 

Definitely hash them, there is no reason not to. You can even encrypt the password in the user's browser and just transmit the hash, e.g. with the code used here.

martinus
A: 

use openid (http://openid.net/) and dont worry about password management.

Numenor