Fwd: [UPHPU] User Login suggestions

[Tierra]

Ugh, did it again... I know the mailing list header isn't a standard,
but could we please still have it?

---------- Forwarded message ----------
From: Tierra <etierra at gmail.com>
Date: Thu, 2 Sep 2004 14:05:19 -0600
Subject: Re: [UPHPU] User Login suggestions
To: David Smith <davidsmith at byu.net>

On Thu, 2 Sep 2004 13:52:01 -0600 (MDT), David Smith <davidsmith at byu.net> wrote:
> PHP makes setting up logins using both sessions and cookies pretty easy.
> However, if you have some specific functionality in mind, I would
> recommend you investigate the many pre-existing solutions for this
> problem. There are many CMSs (content management solutions) out there, and
> most (if not all) support user logins and permissions and such. They may
> even provide the functionality you need for the user area of your site.
>
> If you just have a simple need and your security requirements aren't
> extreme, then writing your own login code may be easier than grokking a
> new CMS.
>
> Anyway, as long as I'm typing let me just spew a few tips for user logins:
>
> 1. Store passwords as MD5 hashes. Don't store them in clear text.
>
> 2. Use sessions if possible, as it takes a little more effort to secure up
> cookie-based logins.
>
> 3. Make sure your code prevents duplicate login names (sounds obvious, but
> you'd be surprised).
>
> 4. You might try out some of the PEAR authentication classes to make your
> system more modular. I haven't used it, but LiveUser[1] looks pretty cool.
> Another one you might look at is the PEAR Auth package[2] to really make
> things flexible on the back-end.
>
> That's all I can think of for now. :)

Let me add to Dave's advise:

5. Only let users know the login failed if anything goes wrong, do not
show why it went wrong. (Hackers find valid usernames that way).

6. If using cookies, make sure the cookie can't be faked. I guess that
goes along with 2, but Dave didn't point out the reason cookies are a
little less secure (PHP sessions already take care of that problem for
you).

7. If also possible, code in an account lockout mechanism for more
than at most 5 login attempts. It can expire in an hour or a day, but
that prevents being able to brute force a password.

I could go on about RSA encryption, SSL, and others as I've coded up
my own very secure login system.

Bryan