Is My Login Script Is Secure ?

[ankur0101]

Hi guys,

I have created a login script. Well, actually its in Codeignier but I would like to ask whether it is secure or not.

 

I have a database with table USERS having columns as

id----username----password----token

 

example ... 1--john.p---81F2DFDBC1DB6362CFDE9CF6310F9B61---29A5D7EA71557AA13F6E2F8863E15F22

 

Password and token fields are VARCHAR(32) which actually stores MD5.

 

Logic for login.php

===============================================================

Checks for entry in DB using after converting $passbox = md5($password)

SELECT * FROM users WHERE username='$userbox' and password = '$passbox'

 

If number of rows for above query == 1, then

1. Set Randomly generated cookie in users browser (e.g. 29A5D7EA71557AA13F6E2F8863E15F22)

2. Update USER table, update token field in front of john.p as 29A5D7EA71557AA13F6E2F8863E15F22

2. Forward user using header() to privatepage.php

===============================================================

 

 

Logic for privatepage.php

===============================================================

At first, it will check whether $_COOKIE['token'] ( which we set above ) exists or not.

If($_COOKIE['token'] == NULL || !isset($_COOKIE['token'])),

{

then forward user to logout.php

}

else

{

// Now token exists in users browser and now checking whether that token exists in our table or not

$token = $_COOKIE['token'];

Now searching in DB using

$token_chk = SELECT * FROM users WHERE token='$token'

if(number of rows for $token_chk == 1)

{

// Do nothing , because user has logged in and is a valid user

}

else

{

header('Location:logout.php');

}

 

 

 

}

 

===============================================================

 

In this scenario, when a VALID user logges in, we are setting a random MD5 in that users row under token and same MD5 in users browser.

In Private ie. login protected pages, at the top of page, we are matching the user's browser cookie TOKEN with the one which we set in database.

If user removes cookie token OR changes its value to something else by manually editing, he will get forwarded to logout.php where all token cookie gets deleted from users browser and that user's token column updates to new random MD5.

 

Is this secure ?

Is this good ?

 

In other words, system recognizes user using a $_COOKIE['token'] (user's browser based token cookie)

[Muddy_Funster]

Script security is a bit like religion - it meens more to some than it does to others and everyone has their own oppinion on what's right and wrong about it.

From my point of view the biggest issues here are the use of MD5() is kind of dated, there are a lot of rainbow tables out for brute forcing it. Your not setting any advanced options on the cookie, so it could be carried accross browser sessions depending on the default setup and expose other parts of your site needlessly. And your script is running a select * against the users table, which, assides from being crap coding practice, meens that a packet sniffer watching your SQL server could get access to all the data recorded for that user - including the md5() version of the password.

 

All you need to do is SELECT id FROM and SELECT token FROM, set some specific cookie options and I would probably include the HTTPOnly setting as well Do that and change your hashing algorithm to be somthing a little more advanced and it should be ok (assuming your sanitaziation and validation are sound that is).

 

That's my opinion anyway, although it's seldome worth much.

[requinix]

$_COOKIE contains user-editable values. You're open to SQL injection.

[The Letter E]

You should consider storing your hash as binary, md5($mystring, true) ... to save bytes.

Then you would just change your query to:

[i]SELECT * FROM users WHERE username='$userbox' and hex(password) = '$passbox'[/i]
[i]

[/i]

[The Letter E]

You also want to escape any user input as requinix hinted at. you may possibly want to check out mysql_real_escape_string()

[requinix]

You should consider storing your hash as binary, md5($mystring, true) ... to save bytes.

Saving 12 bytes per hash just isn't enough in my eyes to deal with binary data. Disk space is cheap.

[ankur0101]

$_COOKIE contains user-editable values. You're open to SQL injection.

Yes, but if any hacker changes MD5 of cookie token, then he will get redirected to logout.php where all cookies will get deleted.

 

@The Letter E - I am thinking about using SHA1 for storing passwords in DB and token in cookie How is SHA1. Off course, I am already using mysql_real_escape_string()

 

My concern is I am storing token in user's database. Lets take an example.

user1 loggs in and random SHA1 get stored in his cookie token. So if any other person(hacker) grabs that cookie token from his browser and sets the same in his (hacker's) browser cookie, then he will get automatically logged in as user1.

 

Means anyone who is having that user1's cookie will get entry in system. How to stop that ?What I want to do is if hacker optains user1's cookie and even he stores the cookie in his browser, then he should not get logged in in system.

[PFMaBiSmAd]

but if any hacker changes MD5 of cookie token, then he will get redirected to logout.php

 

Nope. By injection sql with something like ' OR id=1, a hacker can make your query match any row in your table. Your query would become -

 

SELECT * FROM users WHERE token='' OR id=1

Edited December 12, 2012 by PFMaBiSmAd

[ankur0101]

But I am applying mysql_real_escape_string() everywhere.

[PFMaBiSmAd]

That's not shown in the code you posted and we only see the information that you post.

[ankur0101]

I am using codeigniter. It uses mysql real escape string everywhere.

I am also using for filtering cookies. My post just give an idea how logic is working. I am sorry, I did not mentioned regarding that.

[Muddy_Funster]

...@The Letter E - I am thinking about using SHA1 for storing passwords in DB and token in cookie How is SHA1...

Thanks for the blank sha1 is not much different than md5 in terms of they are both fairly dated algorthims which have been superceded. I did see a simple password hash using a combination of whirlpool and blowfish algorithms someplace...where was it....oh yeah, in my sig. just tweek the number for blowfish passes and the number of characters returned and it's job done, you can even use something other than whirlpool for the salt if you preffer, I only picked that one for the example because I liked the sound of it, it's not what I personaly use.

[mrMarcus]

Thanks for the blank sha1 is not much different than md5 in terms of they are both fairly dated algorthims which have been superceded. I did see a simple password hash using a combination of whirlpool and blowfish algorithms someplace...where was it....oh yeah, in my sig. just tweek the number for blowfish passes and the number of characters returned and it's job done, you can even use something other than whirlpool for the salt if you preffer, I only picked that one for the example because I liked the sound of it, it's not what I personaly use.

 

sha1() would easily suffice for his project.  The chances of a hash collision on a strong password are slim to none (for experienced crackers even).  Just be sure to use salt, always.

 

I'm aware there are stronger techniques for hashing passwords; however, md5/sha are not obselete.  They are deemed to "less secure" against passwords such a "abc123", "password", etc.  But we're not allowing our users to use such elementary passwords upon registration, are we?  If so, that's the root cause of a site being compromised... not the hashing function they used.  A site is only as strong as its weakest point.

 

@ankur0101

 

As a start, any 1 IP gets x tries to login.  Same goes for any single username.  Once they've exhausted those tries, they are locked out for 24 hours and/or must call/email for a password reset.  That's just very simple, yet effective, logic.  And just the tip of the iceberg.

 

Create guidelines for users while creating login credentials (min 1 digit, 1 upper/1 lowercase, 1 special char, absolute min length 8 when creating password), add brute-force control to login area forms as well as monitor traffic and ban IP ranges when fishy users start hammering your site.

 

And don't use mysql_real_escape_string() on your passwords.

Edited December 12, 2012 by mrMarcus

[Muddy_Funster]

sha1() would easily suffice for his project. The chances of a hash collision on a strong password are slim to none (for experienced crackers even). Just be sure to use salt, always.

 

I'm aware there are stronger techniques for hashing passwords; however, md5/sha are not obselete. They are deemed to "less secure" against passwords such a "abc123", "password", etc. But we're not allowing our users to use such elementary passwords upon registration, are we? If so, that's the root cause of a site being compromised... not the hashing function they used. A site is only as strong as its weakest point.

 

@ankur0101

 

As a start, any 1 IP gets x tries to login. Same goes for any single username. Once they've exhausted those tries, they are locked out for 24 hours and/or must call/email for a password reset. That's just very simple, yet effective, logic. And just the tip of the iceberg.

 

Create guidelines for users while creating login credentials (min 1 digit, 1 upper/1 lowercase, 1 special char, absolute min length 8 when creating password), add brute-force control to login area forms as well as monitor traffic and ban IP ranges when fishy users start hammering your site.

 

And don't use mysql_real_escape_string() on your passwords.

Cool,I had no idea you would know so much about the project, but yeah, just do enough to get by and everything will be fine - great mantra. I don't think the question was anything to do with IP addresses, limited login atempts or telling end users what to do or how to do it, I'm pretty sure it was directed at the script provided. Great talk down though.

[mrMarcus]

 

Cool,I had no idea you would know so much about the project, but yeah, just do enough to get by and everything will be fine - great mantra. I don't think the question was anything to do with IP addresses, limited login atempts or telling end users what to do or how to do it, I'm pretty sure it was directed at the script provided. Great talk down though.

 

Quite curious to understand how using sha/md5 is simply doing "enough to get by".  However, I'm not here to argue.  Just to offer up valid points to the OP in regards to other points that were made.  If you didn't find my posted information to be useful to you, then simply discard it.  It wasn't a personal attack.  Just that the hashing of a password is not the most significant step in regards to the overall security of a system and its applications.

 

The pitfalls regarding cookies as part of a user-authentication system were already addressed as the content of said cookies can be manipulated.

[ankur0101]

But CMS like wordpress n joomla use md5

[Christian F.]

If they use MD5, and especially unsalted MD5, to hash the users' passwords, then that might explain why there has been so many reports about leaked passwords, hijacked accounts and so forth from these systems.

 

Personally, I doubt that they're still using MD5 to do this. However, I haven't looked at their code in a while, but I would sincerely hope that they've moved on to properly secure method as of late.

[cpd]

You'll probably find they don't merely md5 something but rather go through a series of steps and md5 it at the end. Take a step back and look at the bigger picture before drawing a conclusion.

Edited December 22, 2012 by CPD