The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Security vs. convienence: forgotten password emails

I'm currently writing a web application and it occurs to me that if I were responsible I'd be hashing passwords.

However, I see myself as being at a disadvantage if I'm less convienent than any competition by not allowing the user to get a 'forgotten password' email.

Anon to protect the guilty
Monday, April 03, 2006
Many sites will generate a new, random password when they send a Forgotten Password email.  Or, they'll send a single-use link to a page where the user can enter a new password of his/her own choosing.  Both of these strategies allow you to assist users who've forgotten their passwords, without needing to obtain the original cleartext password.
Ryan Send private email
Monday, April 03, 2006
what's wrong with the password reset feature?  They provide their name, account id, birthdate and you reset their password for them to some random alphanumeric string?

As a user, I get very uneasy everytime I see my password in clear text.  Although, maybe that's partly because it's an ex-girlfriend's name and I'm afraid my wife will stumble upon it.

Monday, April 03, 2006
Storing the password in cleartext on the server side is baaad! (and sending it in cleartext via email too!)

Of course it depends if it's just a password to read the NY Times or an online banking password, but still...

Anyway my technique to fight this is to use extremely obscene and offending passphrases. If an operator or DBA ever sees it, he/she will be so offended that he/she will immediately drop dead. (Think Hannibal Lecter's passphrase).

I hereby suggest to start a contest for the most obscene and offending passphrase.
Parisian developer available for cute geek girls
Monday, April 03, 2006
People tend to share passwords between different apps. Even if you app is very low security, you should still try to go out of your way to ensure the password remains secure.

As one of the posters said, plain text passwords are bad.
Event Horizon
Monday, April 03, 2006
Ignoring the whole sending password as plaintext in email, what's to stop you using a two-way crytographic hash when storing them, if retrieval is so important?
Monday, April 03, 2006
Other than the fact that the password needs to be stored somewhere in either the source code or in a configuration file. Whoever has access to either of those will be able to decrypt the passwords.

Other than that - nothing
Event Horizon
Monday, April 03, 2006
If it's two way then it's not a hash (by definition a hash is one-way). It's a ciphertext. Sorry, just some Monday nitpicking :)

But, like the poster above me just said, someone could gain access to the plain text password: the decryption key has to be stored somewhere; by using that key and the ciphertext, you can obtain the cleartext.

The nice thing about the hash is that there is no way
for anyone to get the plaintext.

Call me paranoid, but I don't like it when a site sends me a welcome email that says, "Thanks for registering, AND YOUR PASSWORD IS XXXX". But they almost all do that!

Heh heh... reminds me of that joke about the guy whose password is "*******" .
Parisian developer available for cute geek girls
Monday, April 03, 2006
Remember, to make hashing passwords more than a gesture, always salt* your hashes, and get the salts from a good source of randomness. Storing passwords as unsalted or predictably salted hashes isn't much better than storing them in plaintext.

Aapo Laitinen Send private email
Monday, April 03, 2006
Last place I worked did something like this:

1- Passwords were hashed/encrypted by the logon control in the client's page and never transmitted in the clear.
2 - Something like a site-specific salt appended to the cleartext, then hashed. I forget. sha-1? md5?
3 - The encrypted/hashed pwds were stored encrypted in the database.
4 - If/when the customer forgets a password, they'd type in their email and click ok. The server adds a guid to to the server's session/application state, and fire off an email to the customer with a link (and that guid as part of the url). The guid would expire from the server-side state within, oh, 30 or 45 min, so the url couldn't be used as a replay attack. The url would take them to the "type in your new password here" page.

Of course, this requires that email addresses be unique within the database.
Monday, April 03, 2006
Security vs convenience.

I thought this was going to be about how I don't lock my car.
Lance Send private email
Thursday, April 06, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz