Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: phranque
After several heated debates it's been decided that I'm the overly paranoid of the group. :) But then, I'm also the webmaster and don't wanna see our site up at attrition.org or worse. ;)
One person argued that users should be emailed their password, with the arguement "Everybody is doing it, just check your bank!" I'll admit, for some reason, that makes my skin crawl. I hate the concept of plaintext emails with passwords zippin' around the 'net. Besides, the encryption scheme our programmer uses isn't (theoretically) reversable (tripleDES for the curious...)
Another person suggested a Question/Answer that would give you your password if you got it right, but, of course, it can't because of the encryption scheme....
Yet another person suggested a password hint, but anyone who knew someone elses user ID, could also get that hint, and then make a more educated guess at the password. I suggested an additional layer (an account number) but was shown the door on that idea 'cause it required the user to actually know their account number. :P
Been steamin' and stewin' over this one all day. I know whoppin' loads of e-commerce and banking sites email passwords, but that just sounds sooooooo bad to me. What are other sites doing? No doubt people here have had to deal with this before (our site is a tad...*ahem*...behind the times.)
1. Have them register with a specific email address, username and password combo... then when they forget their password, they have to enter the correct email address & username in order to get a password retrieval hint, and then correctly respond to the hint/question in order to have their password emailed to them.
That would mean a mischief-maker (I wouldn't even use the term "hacker" in this situation) would have to a) Know the person's registration email address. b) Know that person's username c) Know the answer to that person's hint/question & d) Have access to that person's email account.
All possible, but highly unlikely.
2. Switch to an encryption system that will allow this to happen.
3. Don't worry about emailing passwords. In my understanding, most of the attrition.org stuff happens because of server security holes which only your host/server admin can control, not compromised passwords.
Can you imagine the level of attention someone would have to pay to your server traffic to pick up ANY passwords out of your outgoing data packets? Odds are, whatever you're hiding on those servers isn't worth the trouble... ;)
joined:Apr 13, 2001
1) You should issue a new password to each new account from a list of semi-phonetic, randomly-generated nonsense words. Make it clear that once the password is issued and e-mailed, then it has been one-way hashed on your server and you no longer know what the unhashed password was. That means that you no longer have a record of the password in the form in which the user now has it, and it is not recoverable by you.
2) Also make it clear that the user should change the password as issued, so that it is removed an extra level from recoverability. The change password routine need not use e-mail, it just returns instantly on the form.
3) "I forgot my password" is the same thing as "I lost my account." You have to start a new account if you lose your password, because the password isn't even on the server anymore.
4) If, after a two-week waiting period or so, the old password has not been accessed, and if the new account e-mail address is the same as the old account e-mail address, then the admin will assume that the person with the new account and the person with old account are the same person. At that point, this person has the option of reverting to the old username using the new password.
The old password/account is then deleted from the system.
You shouldn't even be keeping passwords on your server in a form that's used by the password holder, any more than you keep credit card numbers on your server. Credit card numbers are a bigger problem, because you need the original form for the credit card company. But passwords, once issued, should be replaced on the server with a one-way hash using crypt() or something similar.
Do not put unhashed passwords in cookies. They can be stolen from Explorer 4.0 through 5.0 due to a cross-comain cookie leak bug.