Jump to content
Larry Ullman's Book Forums

Recommended Posts

Hi Larry,

 

I'm Greg and I wrongly addressed some question on the "comments" section of your book. Apologise. At your suggestion I address my questions here.

 

You created and refactor several times the registration, login, logout scripts… however, there is not even one page to serve as example of page for authenticated users. The solution suggested is to check for the presence of a session variable. Will this be safe enough? Should we change the default name for the session or regenerate the session it? Will help to have a nonce system implemented? Will help to encrypt some session variable (with salt) and check for that value? In my opinion such a sample page should have been present, namely: restrict access to a page for authenticated users. I would be interested of what you’re thinking about this subject. I’ve noticed the common way of thinking is to check for a session value like “first name” (not the ID or email as these could provide important information to an attacker). If there is no session value for first name than the user is not logged in. It seems very simple to me. Somebody may easily guess the first name’s session name (could be something like $_SESSION['first_name'] and generate a PHPSID=something and it looks the attacker have got access to the page without being in fact authenticated. In my opinion you should have finished what you’ve started (user authentification module) and create a good script tackling this matter (with session timeout, regenerate session id at minimum).

 

Thank you,Greg

Link to comment
Share on other sites

you want to give attackers a hard time add 2 fields to your user table

make one a char or varchar of 32 for md5 and a timestamp

 

then when they login do an update query that adds the server time and an md5 hash then create a function in the page that checks the sessions md5 and timestamp against what was in the database that way even if they can guess the session name they can't guess the time the user logged in and a 32 xharacter hash

  • Upvote 1
Link to comment
Share on other sites

You created and refactor several times the registration, login, logout scripts… however, there is not even one page to serve as example of page for authenticated users. The solution suggested is to check for the presence of a session variable. Will this be safe enough? Should we change the default name for the session or regenerate the session it? Will help to have a nonce system implemented? Will help to encrypt some session variable (with salt) and check for that value?

 

Hello Greg. I think you're over-thinking this. First of all, the issue of whether something is "safe enough" really depends upon the site. For most purposes, checking for a specific session variable to represent being logged in is safe enough. Changing the session name isn't a security feature, really. Regenerating the session ID is a good idea for added security, but isn't always necessary.

 

In my opinion such a sample page should have been present, namely: restrict access to a page for authenticated users. I would be interested of what you’re thinking about this subject. I’ve noticed the common way of thinking is to check for a session value like “first name” (not the ID or email as these could provide important information to an attacker). If there is no session value for first name than the user is not logged in. It seems very simple to me. Somebody may easily guess the first name’s session name (could be something like $_SESSION['first_name'] and generate a PHPSID=something and it looks the attacker have got access to the page without being in fact authenticated. In my opinion you should have finished what you’ve started (user authentification module) and create a good script tackling this matter (with session timeout, regenerate session id at minimum).

 

The specific session variable you check for to validate whether someone is logged in or not has no bearing on security whatsoever. It is simple, yes, but highly effective. As for "Somebody may easily guess the first name’s session name", that's not meaningful. Like, right now, this forum may have a $_SESSION['first_name'] and you can probably guess what that value would be for me, but that doesn't matter at all from a security standpoint. Because what could a hacker do with that information? Nothing. As for generating PHPSESSID=something, you could do that, but you'd have to guess the "something" that points to a valid and live session, which is unlikely, as the session ID is 32 hexadecimal characters. And the ability (or inability) for a hacker to predict a valid, current session has nothing to do with what values are stored in the session and what values are checked for authentication.

 

I can see that you would have preferred to see an example of authentication in the book and I'll consider that for the next edition, but it really is very easy. In fact, I'd be surprised if there wasn't something 95% close in the book already. Sessions timeout automatically and I think I mention regenerating IDs in the book, too.

 

Thanks for your questions and your input!

  • Upvote 2
Link to comment
Share on other sites

 Share

×
×
  • Create New...