Is this best way to handle logins?

[133794m3r]

Ok since one of the things that i'm sure will always come up is logins and what's the best way to make sure that someone's logged in. well since i am using php i'm going to use the start_session(); code and thus have $_Session['username'] stored in there for the user that's currently logged in along with the authorized part in there too. But the other thing i was going to do is to on page refreshes just allow the the cookie that's stored to just accept whether someone's authorized.

The thing i was going to do as an extra thing is to store an unique token in said cookie and also store one in the database. This would help to prevent someone from just well willy nilly messing with the cookie and maybe seeing something they're not supposed to such as acessing someone's inventory if they change the username. My question about all of this is this the best way to handle the logins and making sure that they're not messing with things that they're not supposed to.

I was planning on using something such as this for my unique token. And it'll be stored in a table that stores when someone logs in along with some other basic information. That's how i'm planning on doing it and now whether or not the code works exactly or if i have to change a bit on the $token part is still up for grabs but the syntax doesn't apparently have any problems. Also this unique token will be set for each login of course, and each one will be different(or should be) due to the use of microtime instead of time. And if a user does happen to login at the same exact time down the microsecond then well... i guess i'm doomed to failure.

Code: [Select]

function unique_token(){
$now = microtime();
$token = (hash('sha256',$now)+hash('sha256',$user));
}


[Chris]

i am using php i'm going to use the start_session(); code and thus have $_Session['username'] stored

And that's it Everything else in your post is a useless fat. No paranoia, OK? There is one method to handle logins. There is no such thing as "best method to handle login" because there is only one method. And that is the method you described in the sentence above

No half page post about such simple thing as login, please, please, please

[raestlyn]

If you are using sessions why do you need cookies? If an user manages to edit the session data you have plenty of other things to worry about than user seeing someone elses inventory, as the sessions are stored in the server..

[Topazan]

Thanks, I was also wondering about this.   

[133794m3r]

i am using php i'm going to use the start_session(); code and thus have $_Session['username'] stored

And that's it Everything else in your post is a useless fat. No paranoia, OK? There is one method to handle logins. There is no such thing as "best method to handle login" because there is only one method. And that is the method you described in the sentence above

No half page post about such simple thing as login, please, please, please

hmm ok i thought the session itself though created some sort of cookie... ok, and i'm one of the most paranoid people around... i look at every potential player as a truly gifted hacker, so thus i try to think of everything i need to do to attempt to thwart their attempts as best as i can. I've always been paranoid and i just though that the session itself was storing some type of cookie due to this....

"creates a session or resumes the current one based on a session identifier passed via a GET or POST request, or passed via a cookie."
from the php page. I thought that by getting data from such things as $_Session['username'] it might've been using a cookie since i read cookies and cookies are a dangerous thing to me...

[AcidicOne]

A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.

Php Manual Ftw


edit:

And so I dont seem like a RTFM person, i only displayed that because I find myself personally with a copy of the php manual on the pendrive i carry my work on, therefore if I am unsure of a command usage or exactly what it is and how it works, its a quick search through the manual and tada.

[Chris]

ok, and i'm one of the most paranoid people around... i look at every potential player as a truly gifted hacker, so thus i try to think of everything i need to do to attempt to thwart their attempts as best as i can. I've always been paranoid and

Wrong forum, for the best help go to paranoia-therapy-board.com

The thing with "Cookies that store session" thing:
- session is a file on your server, you can not access it via HTTP (and can not access it via FTP either unless you have root access). Only server can access it.
- each session file is named "745856gdht5dj643zd43j5k66.session", the first part is callen a session identifier
- when you click any link on your .php page it has login.php?PHPSESID=43634hgfaj53g2efjs35 so the php page know which session it should use. In some cases, when passing theoug URL is not possible cookie is used instead.
- then PHP reads session identifier (from url or cookie) and knows which session file holds that user information.

In short, modyfying session identifier do not let you hack session or see what is inside, you can only pretend you are some other already logged in user.
The chance of quessing the session identifier by chance is like getting hit by meteorite a few times in a row on your way to work.
Also, you could make an IP check on session (so only those who has the same IP AND guessed identifier can use it) (note: this will cause some mobile users with highly dynamic IP (chaniging every few seconds) problems, so there should be an option to disable IP check for specific user)

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[Chris]

Yep, there is one and only one way of handling login, which is putting username/userid in session. The way session is stored is irrelevant (server can even carve the data in stone, it won't change even one line in the login script ).

[133794m3r]

Yep, there is one and only one way of handling login, which is putting username/userid in session. The way session is stored is irrelevant (server can even carve the data in stone, it won't change even one line in the login script ).

O_o how so... i figured that the login script specified how it was going to handle the login itself. Such as if it was going to use a cookie or just put it up there in the url. And so then, what's the "safest" way then to handle the login data ONCE the login has occured. I guess that might've been my question then, since the server itself has to get the data from somewhere, and using urls or cookies both present security risks. Urls unless completely hidden from the user(which i'm sure can happen or atleast php said it was possible to do so) they could still malform the url and thus do things with it once they figure out certain items. And a cookie would be a bit easier i think, b/c the cookie itself is just a clear text file.

[dsheroh]

Yep, there is one and only one way of handling login, which is putting username/userid in session. The way session is stored is irrelevant (server can even carve the data in stone, it won't change even one line in the login script ).

There is an important distinction here that should be emphasized, though:  User name/id has to go in the stored server-side session data, not in the session cookie (or a session id in the URL).  It's very easy for someone not used to working with that distinction to misread "there is one and only one way of handling login, which is putting username/userid in session" to mean that the username goes into the session cookie, which is absolutely wrong and utterly insecure.

The session id, whether transmitted as a cookie or placed into your URLs, should be a random value with no way to derive any meaningful information from it directly.  Its sole purpose is as a key which can be used by the server to look up stored session data in a database/file/cache/stone tablets and that stored data is where the username, access level, etc. belong.

As a side point, going back to the initial post on this thread, basing your session ids on the time, even if you use a high-resolution timer, is generally considered bad practice because it makes it possible for a determined attacker to guess someone else's session id based on when they logged in and then hijack their session.  Generate a random number, then md5 or sha hash it instead.

[133794m3r]

Yep, there is one and only one way of handling login, which is putting username/userid in session. The way session is stored is irrelevant (server can even carve the data in stone, it won't change even one line in the login script ).

There is an important distinction here that should be emphasized, though:  User name/id has to go in the stored server-side session data, not in the session cookie (or a session id in the URL).  It's very easy for someone not used to working with that distinction to misread "there is one and only one way of handling login, which is putting username/userid in session" to mean that the username goes into the session cookie, which is absolutely wrong and utterly insecure.

The session id, whether transmitted as a cookie or placed into your URLs, should be a random value with no way to derive any meaningful information from it directly.  Its sole purpose is as a key which can be used by the server to look up stored session data in a database/file/cache/stone tablets and that stored data is where the username, access level, etc. belong.

As a side point, going back to the initial post on this thread, basing your session ids on the time, even if you use a high-resolution timer, is generally considered bad practice because it makes it possible for a determined attacker to guess someone else's session id based on when they logged in and then hijack their session.  Generate a random number, then md5 or sha hash it instead.

so which would be a better function to use then.

Code: [Select]

function create_token{
$random = rand(1,100000); //i think this is the correct way to display this number here since commas are already reserved
$token = hash('sha256',$random);
}
or should i do something different such as using a random string of some length then hash that and use that as my $random?
}

[dsheroh]

As a side point, going back to the initial post on this thread, basing your session ids on the time, even if you use a high-resolution timer, is generally considered bad practice because it makes it possible for a determined attacker to guess someone else's session id based on when they logged in and then hijack their session.  Generate a random number, then md5 or sha hash it instead.

so which would be a better function to use then.

Code: [Select]

function create_token{
$random = rand(1,100000); //i think this is the correct way to display this number here since commas are already reserved
$token = hash('sha256',$random);
}
or should i do something different such as using a random string of some length then hash that and use that as my $random?
}

Allow me to amend my earlier statement:  You shouldn't base your session ids solely on the time, username, or other guessable details.  PHP is not my primary language and I had forgotten that, on some platforms, its rand() may be limited to producing as few as 32k distinct values, so using that alone would also be unacceptably easy to guess.

Given this, I think I'd combine your original and rand-based versions and perhaps go with something like

Code: [Select]

function unique_token(){
$random = mt_rand() + microtime(true);
$token = hash('sha256',$random);
}

mt_rand() provides better randomness than the default rand() on some systems and calling it with no parameters will give you a number in the range from 0 to mt_getrandmax(), then adding the microtime() value shakes it up a bit more, in case you're on a system where mt_getrandmax() returns an undesirably low number.

But it's entirely possible that someone who knows PHP better than I do may have a better suggestion.

[lolninja]

All you need to so is within your auth code do a session_regenerate_id(); this basically issues the client a new session_id upon auth. Which basically stops someone from stealing there session.

For example say I sent you a link to superrubbishbank.com?phpsesid=123456789 you logged in and started doing your banking, as soon as you have authed with the server your session data represents your logged in account. Me being the evil hacker that I am can now just press F5/Command-r, my browser sends a request to superrubbishbank.com using the same session_id and opps, I how have full access to your banking account.

If superrubbishbank.com had code kinda like this...

Code: [Select]

function auth($username, $password){
    $user::authWith($username, $password);
    if (!($user instanceof User))
      //http redirect to bad login page
    session_regenerate_id();
    $_SESSION['uid'] = $user->id;
    //http redirect to home page
}
When I send you the superrubbishbank.com?phpsesid=123456789 url, and you login during the login process the server will send you an updated session_id, so your phpsesid will not be 123456789, but maybe 573954038, so when me the evil hacker hits F5/Command-r I see the same login page that you saw prior to logging in, and not your banking details.

You cookie only stores your session_id, so its easily modified, so regenerating the Id upon login is super super important.

And when Chris recommends using a non-time-based random number generator its worth remembering that the rand function seed's its random number generation with the current time-stamp, which is not ideal for crypto stuffs.

PHP's session_id is pretty strong afaik, the main method for stealing session_id's being the method I discussed above, adding addition security is often a mistake, as any bugs in your code can be exploited by a hacker, whereas the php method is pretty optimal.

Just my 2p, I'm faily certain I'm correct, but if JGadrow could double check that would be cool

**edit**
Oh yeah forgot to mention 'uniqid()' that returns a unique value based on the current timestamp

**edit**
mt_rand is better than the basic rand function, but both are by default seeded by the current timestamp, and not idea for crypto work, as they can be reverse enginerred, if you need to send a pretty unqiue id back don't forget to salt it, doing...

Code: [Select]

return sha1($random.'_my_kick_arse_salt');


[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[AcidicOne]

Following the theme of paranoia are there any other viable options to md and sha seeing both *can* be brute forced.
(clarification sha and sha-1)

[133794m3r]

Following the theme of paranoia are there any other viable options to md and sha seeing both *can* be brute forced.
(clarification sha and sha-1)

well anything can be brute forced it's just about how long until it's proven to be so. Currently afaik sha256 hasn't been discovered to be acceptable to collision attacks so i was using it b/c it's a)not too large and b)is currently extremely safe.

Also hmm never knew about that mt.random thing. And i usually do add some random salt to it. Since that's how i was going to do the passwords themselves. I was thinking about making it so that, there'd be a rotating list of salt that could be added to it. I'm thinking about making it be 20 strings that are 40 characters long, and they'll be made by a random string function. This'll be Changed up every time i do maintenance i'll add in the new strings and update it then. Also of course i'd make sure that the strings are unique each time before actually accepting them and updating them in the login script.

Is that/would the be secure "enough"? I just really wanna make it to be something that'll be 1/1,000,000,000 chance that someone'll be able to reverse engineer the exact session id. And of course i was going to update it with eachlogin. And to check and see if someoen's logged in or not i'd just do a simple check based upon teh username and see if it's supposed to be logged in and also if the sessionid matching the one if they are for the current day.

And i think it's best to be extremely paranoid and worried about everything. Afterall, you are running a game and your users expect you to keep their information safe. Or if you're running a forum whatever, they expect it to be secure.

[lolninja]

Hey with cycling salts you need define your salt list once, otherwise how do you re-hash someones password? To hash it remember you need the original plain text password, unless your rehashing upon login, then its all good.

[AcidicOne]

Could you not just do a simple salt+hash and like for example the BBG tutorial if the hash off simply redirect them to a change password page?

[133794m3r]

Hey with cycling salts you need define your salt list once, otherwise how do you re-hash someones password? To hash it remember you need the original plain text password, unless your rehashing upon login, then its all good.

this is for session id atm. And yes for the salt i'm goign to add to the passwords it's going to be something like.... $uber_awesome_static_salt.$password.$uber_awesome_random_salt

and the random salt is just going to be chosen randomly upon registration. Then that value is stored into the database. And when they login, the script will pull that value out of the database or well the one that matches the username they're attempting to login with. Then it'll look up there and get their random salt string, and set it accordingly, then that'll be added in as such and all of that'll be hashed. Then that value will be compared with the one in teh database.
(edit below here)

Could you not just do a simple salt+hash and like for example the BBG tutorial if the hash off simply redirect them to a change password page?

NO i sadly can't, i'm too paranoid i guess. I'll be doing it as i had said up there with the static salt+random salt values. Since i have to do a database query to see a user exists with the username they're trying to login with i don't see why it's that big of a hassle to also pull the value to figure out which salt they've been assigned. 


Also, i'm probably going to only end up having like 20 random salts at the maximum b/c honestly i don't see the need to have mroe than that.

[dsheroh]

Following the theme of paranoia are there any other viable options to md and sha seeing both *can* be brute forced.
(clarification sha and sha-1)

I don't know where to find a PHP implementation, but:  bcrypt.

The great failing of using message digest hashing algorithms (such as md5 and sha) for storing hashed passwords is that they're designed to be fast and efficient, with lots of simple mathematical transformations, many of which are parallelizable.  With the right hardware, you can easily process a million or more md5 hashes per second.

Which means that, if the bad guys get their hands on your password database, they can make a million brute-force attempts per second.

Bcrypt, on the other hand, is based on the construction of Blowfish encryption frames, which is complex, state-dependent (so you can't do multiple sections of the transform in parallel), and, as a result, slow.  Bcrypt also includes a tunable "cost" parameter which can be used to slow it down even further if necessary by running the value through more Blowfish iterations to counter increases in CPU speed.

If you use bcrypt and tune it to, say, take a tenth of a second to process each password attempt, then legitimate users (who will only make one attempt at a time, then have to wait a second or two to retrieve and render the page anyhow) won't even notice a difference, while attackers will be slowed down by a factor of 100,000 - each minute that they would have required to crack a password with md5/sha becomes 70 days with bcrypt.  What they could have learned in an hour now takes 11 and a half years.

Is that sufficient to satisfy your paranoia? 

[JGadrow]

I'm going to play the devil's advocate here... keep in mind there are multiple forms of access control. You probably won't find it necessary to utilize much else, but just remember there is never a single solution when it comes to programming - else we'd all be out of a job.

[Chris]

each minute that they would have required to crack a password with md5/sha becomes 70 days with bcrypt.  What they could have learned in an hour now takes 11 and a half years.

What if they use time machine to crack passwords? No, it is still not secure enough!

[AcidicOne]

Here is some food for thought, reading through some various crypto articles at work(yes i was that bored) The most common weakness for all sorts of hashing/encryption is of course the user. Now I did some research in bcrypt and dsh was correct you can slow down bcrypt to a crawling 7.7 hash tries a second which would take 10,000 times more time to crack then say sha1. A small but simple factor came to mind wondering through all these articles, why not simply create your own dictionary file like a would be cracker would use, I am more then certain you can find hundreds on the web, and using php and I am assuming Ajax to check each users password on account creation and password change against such list,Thus forcing users to not use dictionary based passwords. Or a more Simple route i would imagine to simply to require a minimum of say 6 Alpha based characters and 4 Numeric totaling in a minimum password length of 10, or I am sure the paranoia committee can come up with what they would be happy with for a minimum password standard

Now running under the rule of " No System is Totally Secure" which is fact, the eliminating dictionary based attacks and the obvious SQL injection and so forth, and your huge list of ever changing salts. You would be seriously limiting any would be attacking shy of attacking the web host itself,lol

[133794m3r]

Here is some food for thought, reading through some various crypto articles at work(yes i was that bored) The most common weakness for all sorts of hashing/encryption is of course the user. Now I did some research in bcrypt and dsh was correct you can slow down bcrypt to a crawling 7.7 hash tries a second which would take 10,000 times more time to crack then say sha1. A small but simple factor came to mind wondering through all these articles, why not simply create your own dictionary file like a would be cracker would use, I am more then certain you can find hundreds on the web, and using php and I am assuming Ajax to check each users password on account creation and password change against such list,Thus forcing users to not use dictionary based passwords. Or a more Simple route i would imagine to simply to require a minimum of say 6 Alpha based characters and 4 Numeric totaling in a minimum password length of 10, or I am sure the paranoia committee can come up with what they would be happy with for a minimum password standard

Now running under the rule of " No System is Totally Secure" which is fact, the eliminating dictionary based attacks and the obvious SQL injection and so forth, and your huge list of ever changing salts. You would be seriously limiting any would be attacking shy of attacking the web host itself,lol

when i registered my first copyright with teh US govt, they required my password not exist in any dictionary of any language, and that no character can be within 3 characters of itself. Also it had to be at least 10 characters long and contain atleast 3 numbers, 1 special character and the rest is fill in the blank. Personally i doubt i coudl require such an insane thing from the average user. I will be however, doing a simple making sure that no two characters are within eachother, and also require them to have atleast 1 number and be 6 characters long. It shouldn't be that hard for anyone to make. And that's about what i was planning on doing. And i'm also now going to be using teh twofish encryption algorithm with a key that'll be some random sha256 hashed version of some string.