[thelist] Usernames and Passwords

Ken Schaefer Ken at adOpenStatic.com
Wed May 2 00:48:04 CDT 2007

-----Original Message-----
From: thelist-bounces at lists.evolt.org
[mailto:thelist-bounces at lists.evolt.org] On Behalf Of Bill Moseley
Sent: Tuesday, 1 May 2007 11:49 PM
To: thelist at lists.evolt.org
Subject: [thelist] Usernames and Passwords

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

I don't think this is a very good way of developing an authentication system.
An authentication system needs two components: an identifier, and an

The identifier should be unique, and the password is the authenticator
(shared secret) that allows the system to know that you are indeed who you
claim you are (the identity contained in the identifier).

Just look at every other security system. Does your OS allow you to have two
usernames that are the same at any one point in time? Does your NoS (AD, NDS,
whatever)? No. And there are good reasons for that.

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

This is a decision that really needs to be made on a case-by-case basis.
Maybe for small little websites, it's not an issue. For any sort of large
application, you need to get a set of detailed requirements from your
customer. Most large enterprises also have fairly detailed security
requirements around how this sort of informaiton is treated, stored,
archived, accessed etc.

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

Encrypting stuff in a database is definately problematic. Where do you store
the key? What's to stop the attacker just getting the key an decrypting

Instead, for sensitive applications, you hash the password. Then it can't be
decrypted. That's how most applications that need to be "more secure" work
(e.g. your password is not stored in plain text, or reversible 2-way
encryption) in Active Directory or NDS

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

That is why some applications use the password reset question, or similar.
Effectively the question and answer are a second shared secret
(authenticator) between the user and application.

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

This is a perennial problem - usability -vs- security tradeoff. There is no
single answer - it needs to be decided ona case-by-case basis.


More information about the thelist mailing list