[thelist] Usernames and Passwords

Lee Kowalkowski lee.kowalkowski at googlemail.com
Tue May 1 10:36:03 CDT 2007


On 01/05/07, Bill Moseley <moseley at hank.org> wrote:
> - email + password are the unique combination that identifies an
> account.

Have I understood this right?  Are you allowing two accounts with the
same email address but different passwords?

I think email address alone (as a synonym for username) should be your PK.
If someone gets their password wrong, which user is this recorded
against?  If you wanted to lock out a user (perhaps due to repeated
failed authentication attempts), which would it be?

> 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.

True, but they do need to remember which email address they used.

> Email addresses are not
> unique over time, so email cannot be unique in the database, so use
> unique( email, password ) instead.

Is anything unique over time?  (Rhetoric, I think...)  People who
forfeit their [important] email addresses should understand the
consequences.  I think your system would be far simpler if you
dismissed this assumption.

> - 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]

Only if you don't offer a change password function.  Otherwise you're
just making your system less convenient.  Users who tend to use the
same password everywhere will change it to be the same as everywhere
else.

> 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.

Yes, security on your system is compromised, depending on what an
attacker is after, they will probably go straight for the data itself
rather than passwords, but if people tend to use the same email
address and password on many systems, security is compromised for all
the other systems too.  Now, is that completely the user's fault?
Maybe ultimately, but your once-loyal users aren't going to be too
happy about that.

I think "security is compromised anyway" is a feeble excuse for
storing passwords as plain-text.

> 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.

Yes, and people tend not to delete their email completely.  Let the
user choose their own password over an SSL connection.

> 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.

No, but that's not your responsibility, and should not be in your
arsenal of excuses.

> 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 don't see why the new password cannot be the same as the previous
one, but anyway...

Whether or not the password is recoverable depends on whether the
password is hashed or encrypted.  I'm not sure of the accurate lingo,
but I mean in such a way that the password cannot be deencrypted, like
SHA (Secure Hash Algorithm) - but can still be cracked with a brute
force dictionary or the like.

If you want to be able to show a user their password, it'll need
two-way encryption.  Otherwise you can just hash / one-way it.

> 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 don't think it necessary to insist the new password differs from the
old.  Not for the password reset scenario, (perhaps not even for
change password).  The typical user has forgotten their password, so
they can't be asked for their old password, if they accidentally
"remember" their password when using password reset, what difference
does it make?

Strange logic results in strange user experiences.  If the user is
served a "password must be different than the existing password" they
will probably abort anyway, they know their password now, therefore,
the validation is redundant.

> 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.

Let the user choose a password from the outset.  Hash it.  Never tell
them what it is.  Consider a user-defined password hint function.

When the user registers, make sure you capture enough additional
information that can be used to confidently verify a user's identity
during the password reset flow.  E.g.  Name, Email address, Date of
birth, Place of birth, name of pets, whatever you think it takes,
perhaps even a user-defined question/answer pair that the user thinks
only they would be able to answer correctly (hmm, isn't that what a
password is?).

-- 
Lee



More information about the thelist mailing list