Fog Creek Software
Discussion Board




Web site authentication

We're developing a site which involves a manager appointing someone to their team - entering their email address and name, etc.  At this point we insert a randomly-generated password into the db. Then, when that team member comes to the site they click the "email me my password" button and we send the password to the specified email address - they can then log in and change their password to whatever they like.

OK so email's not exactly the most secure medium in the world, but I feel that "it'll do".

Now the customer feels this is insecure for a different reason - they reckon that "what if someone leaves their PC logged in, with their email open? Someone in their office can go to the site - click email me my password - and then get the password from the victim's logged in PC"....sigh.

So we're considering storing a "password hint" of the user's choice in the db and only emailing them that. But then what if that doesn't work for them? -- resetting a password is normally done through email like above ("click this link to reset your password") -- but then that suffers from the same "loophole" envisaged by the customer. (I can just imagine them saying - "well they'll have to give us a call if they want thje password reset" - to which I'd reply - how are you going to authenticate their voice???)

What do you feel is an effective mechanism for managing web-based authentication?

Dunc
Friday, September 13, 2002

Explain to them that without physical security, nothing else works. Leaving a machine with the Web site logged in and the e-mail open is akin to telling your neighbor the password -- they wouldn't expect you to somehow code against the latter, would they? So how can they expect you to code against the former?

Troy King
Friday, September 13, 2002

A suggestion to consider:

Have 2 different password fields in the database - a user-selected/entered password and a system-generated password, and a boolean flag to indicate which of the 2 password fields should be used. NOTE: The user does NOT need to know both of these passwords at the same time! Also store a few fields of information that should, to some extent, only be known to the end-user and the person creating the account (hire date, employee number, home phone number, etc, etc).

When the account is first created (and also later if the user forgets his/her password), the system would generate a random password, store the hashed value of that password in the 2nd password field, set the password flag to "system", and send the new password in email to the end-user. When the end-user reads the email and attempts to log-in, the system would know that this is a generated password, and ask the user to answer 2-3 additional questions based on the other stored information, and if all is correct, then allow the user to connect, but also ask the user to enter a user-selected password (which would then erase the generated password, store the hashed value of the user's password, and switch the boolean flag). [Note - I believe passwords should always be stored in non-reversible hashed form, not plain-text.]

Once the user has connected and set a password, only that password (which should then only be known to the user) should be used when logging in the user - the system-generated password should no longer be used.

Later, if the user forgets his/her password, there should be a link to generate a new password in the 2nd field and email that password - and the process above can be repeated to allow the user to connect and set a new password.


This still does not provide "absolute security", but it is a little better than the "standard" practice of "email me my password because I forgot it" that is commonly used.

Philip Dickerson
Friday, September 13, 2002

It's very important to understand what the consequences of a break-in are. If your service is managers appointing players to a team, it sounds to me like there is little negative consequence of a break-in so I'd go with something very low-grade as far as security is concerned. Generally, the trade-off is between usability and security. Email is fine for sending out a new password. We do it and you can print money with our passwords!

pb
Friday, September 13, 2002

Well, if authentication is really important to your customer, you could use a system like SecurID:
http://www.rsasecurity.com/products/securid/

That's probably the most secure Web sign-in system you're likely to see. Unfortunately, it requires (suprisingly-expensive) hardware for each end-user.

They also have two-factor authentication systems that don't require the hardware. In particular, they've got a new product that uses mobile phones to distribute the one-time keys.

-Mark

Mark Bessey
Friday, September 13, 2002

If the manager has contact with the new team member he could send you an initial password and tell the team member the password.  The initial password could be used to request the data base password or could be the initial data base password.

If the team members are from a known pool such as employees you could have the team members register and pick a password before they are chosen for a team. You would then require that password when they asked for the db password.

John McQuilling
Saturday, September 14, 2002

The security problem you describe has been faced by almost all web sites containing login information. So don't reinvent the wheel, but just look how others solve it.

1) I get the impression that you store plain text passwords in a database. You should never do that. Storing the hash values only is both trivial and greatly increases security. Linux, PHP, etc. all contain standard commands to do this.

2) Force a password change the first time any user logs in. This will make sure that passwords sent by emails won't work. Also put a time limit on any password send by email. Expire them within 24 hours.

3) Ask a secret question when a user has forgotten its password. This fixes the loophole you describe.

4) Notify the system administrator when the secret question is not answered correctly. He can contact the client by phone in case he lost his password and forgot the secret question. The other possibility is that a cracking attack might be taking place.

The system described above isn't unbreakable either but will cover many of the trivial exploits.

Jan Derk
Monday, September 16, 2002

*  Recent Topics

*  Fog Creek Home