Page 1 of 1

login security opinion?

Posted: Sat Nov 27, 2004 7:11 am
by bradles
Hi All,

I have developed a simple login script for my site so my clients are able to login to view their portraits. I wanted a login system as most clients don't wish their portraits to be available for the whole world to see.

I understand very few login systems are 100% fool proof and I am not trying to keep out super wizz kids but does this sound like a secure enough system?

1. Client enters username + password in login form.
2. Script checks database to ensure username and password is correct.
3. If correct, starts a new session and sets session variable 'logged_in' = true.
4. if incorrect script goes back to login page.


As I am still fairly new to sessions and have not yet delved into cookies, does this sound secure enough? What potential problems do you see with this script?

Brad.

Posted: Sat Nov 27, 2004 10:08 am
by John Cartwright
1. Client enters username + password in login form.
2. check if what they enter is text and numbers only
3. Script checks database to ensure username and password is correct.
4. If correct, starts a new session and sets session variable 'logged_in' = true.
5. if incorrect script goes back to login page.
6. after 2-4 failed login attempts add to db their sesh id and IP, and set a cookie on their system that will block them from logging in (you may not want to let them know that they have been blocked for 24 hours or whateve....secrecy is your friend)
7. have a lost password function that will generate a new password and email it to them (make them insert their secret answer.. or email or something and verify it to the db..(use steps 1-6) )

Posted: Sat Nov 27, 2004 2:44 pm
by Roja
You've left a few key things out.

Make sure that the password is stored as a hash - not as the value - and passed that way too. You can read up on using md5 (or SHA1) for doing password transmission (and why its important) in the tutorial I wrote: viewtopic.php?t=25624

Generally, I let the user pick their password. I then have the site generate a confirmation code, which is sent to their email address. They open the email, get the code, and confirm their account with it - which sets the account active.

That way, I have a valid email address for the user, they have a password they can remember, and there is an easy method for password changes - when they change the password, they have to reconfirm their account.

Passwords should be able to be *anything* - not just letters and numbers. By hashing it using md5/sha1 on the client side, it BECOMES just letters and numbers, which are safe for the db.

Thats just the low-hanging fruit I see.. I might think of more later.

Posted: Sat Nov 27, 2004 4:18 pm
by John Cartwright
the reason i say just letters and numbers is to not allow for sql injection.

Also just a quick note when you have the hashed value in the database you when the user logs in simply hash it and see if the hashes are the same.

You also raise another valid point, have the users confirm their email addresses by sending an email it it.

this is generally done by by having a link in the email with their confirmation code (which is generated when the user is registered) and have the file update the a column in the users row that will allow him to begin login in once he is considered "active"

Posted: Sat Nov 27, 2004 4:26 pm
by Roja
Phenom wrote:the reason i say just letters and numbers is to not allow for sql injection.
Yeah - I figured. Thats one of the benefits of hashing with md5 and SHA1 that few people realize.

For most db access, I use adodb, which has functions like qstr to help ensure quoting is handled correctly. (Plus, it only allows one sql command per execution, which prevents the majority of sql injections without any effort for the programmer). Its really an excellent library - to the point where I've even contributed patches to it myself.

Posted: Sat Nov 27, 2004 6:04 pm
by John Cartwright
Thats some good info, glad that you have made us aware of it. Gonna go check it out :)

Posted: Sat Nov 27, 2004 6:22 pm
by hedge
You also should have some 'gatekeeper' code at the top of each of your scripts that in it's simplest form should check for your 'logged in' session var to avoid direct script execution by entering the URL.

As discussed in another post you should protect your other 'non-script' content somehow (pics, pdf's, etc.)

Posted: Sat Nov 27, 2004 7:00 pm
by Archy
Phenom wrote:You also raise another valid point, have the users confirm their email addresses by sending an email it it.
I normally just let the user to login, and then make them enter an activation code which I sent them in their confirmational email. If they "lost" the activation code, enable them to resend them a new random number password (has to be a new password since you cannot resend them their orriginal password since it is encrypted into the database).

I will have to look into adodb - I am always on the hunt to tighten my security for login scripts, you can never be too carefull these days.

There is (nearly) always more than one way to skin a cat