[thelist] Usernames and Passwords

[Bill Moseley]

Sorry, this ended up longer than I intended.

I'm interested in how others design their login and password setup,
and comments or suggestions about the system described below:

I realize there's quite a bit of research (and opinions) on the web
about password management -- and that the implementation depends a lot
on what's being protected.  I'm curious how people here are
implementing this.

Lately, for sites that are not high security (credit cards numbers are
not stored in user accounts), but also not free (i.e. usage might
incur costs) I've been using:

- email + password are the unique combination that identifies an
account.  Often the application sends emails to users so everyone
needs an email address in the database.  People don't have to remember
a separate "login" if email address is used.  Email addresses are not
unique over time, so email cannot be unique in the database, so use
unique( email, password ) instead.


- On systems where users create their own accounts I generate the
passwords automatically.  That makes the sign up form simpler (two fewer
fields) and decreases the tendency that people have to use the same
password everywhere.[1]  Then a confirmation email is sent with a
special URL.  The user must reply to this email withing a set time and
their account is activated and their password is emailed to them.


- Users can change their own password.  They must supply their current
password along with their new password (entered twice).[2]


- Passwords are stored in the database as plain text.  This allows
users to get password reminders via email.  Users are not forced to
change their password in this case.  (If login is their email address
may need extra information to identify the user.)

If someone can gain access to the database (to see the plain-text
passwords) then security is compromised regardless if passwords are
encrypted or not.


Comments:

One problem is that in this setup passwords (and account
confirmations) are sent over email, which is not very secure.  So, if
someone can sniff the user's email they can see their password.

I'm not sure if that's more likely a risk than someone walking by
their office and finding their "post-it" with their password written
on their screen or just using their browser with the password saved.

Another common setup is where passwords are never sent over email, and
there's a password "reset" feature where a single-use password (or
URL) can be used to reset the password with the requirement that the
password cannot be the same as a previous password.

I'm not sure if that's much more secure than sending passwords in
plain text in email.  If someone can sniff their email they can
also use that password reset procedure.  It does reduce the window of
time that a emailed password can be used, though.

This also forces people to come up with a new password which does
increase the chance of post-its-on-the screen security problems.


I suppose the trick is finding a system where there's good security
practice on both the server side and the user side.  Don't want a
system that's so strict on the server side that it forces the uses to
be insecure in their own password management.




[1] I can't find it now, but I once read a paper on research that showed
that people often tend to use the same, easy to remember password on
multiple sites and this was considered a poor practice.

[2] That paper also suggested that enforcing too strong of passwords
resulted in users sticking "post-its" on their screens with their
passwords.


-- 
Bill Moseley
moseley at hank.org