Jump to content

Is My Login Script Is Secure ?


ankur0101

Recommended Posts

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by PFMaBiSmAd
Link to comment
Share on other sites

...@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 :P 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.
Link to comment
Share on other sites

Thanks for the blank :P 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 by mrMarcus
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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 by CPD
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.