Re: Correct Session Authentication

["Dean H. Saxe" <dean () fullfrontalnerdity com>]

A few issues here:

The salt should not be hard-coded.  A new, random salt is created for  
each and every password.  The salt only needs to be a few bytes in  
length, I usually recommend 2 bytes, though more is certainly  
acceptable.

Session hijacking is best prevented by using highly entropic session  
ID values, the defaults for modern web application servers are fine.   
Tying a session to an IP address is not necessary and will often  
cause issues, like you said, with AOL users.

If a timeout value is not set on the cookie then it is known as a  
"session cookie" and will be retained only in memory on the client  
until the browser is closed.

-dhs



Dean H. Saxe, CISSP, CEH
dean () fullfrontalnerdity com
"What difference does it make to the dead,  the orphans, and the  
homeless, whether the  mad destruction is wrought under the name of  
totalitarianism or the holy name of  liberty and democracy? "
    --Gandhi


On Jul 29, 2006, at 12:12 PM, Balazs Attila-Mihaly (Cd-MaN) wrote:

> This method is fairly secure. My suggestions would be:
> -use a salted hash (this means that if the users password is  
> 'password', then you make a hash from '<somesecreetstring>password'  
> and store that in the database. Of course <somesecreetstring> is  
> hardcoded in the application. This guards against the scenario when  
> somebody gets the hashes from the database and tries to do a  
> dictionary attack - meaning that the attacker has precomputed the  
> hash values for a set of common passwords and compares them to the  
> ones got from your database. And use a long string (32 chars+))
> -Read about session hijacking (and try to tie the sessions to a  
> specific IP or user agent string - and be aware of the problems:  
> users behind proxy servers and users who dinamically change proxies  
> - this includes AFAIK AOL users who access the net from a few fixed  
> ip addresses which can chenge during the browsing session)
> -Timeout your sessions (mark when it began and timeout after a  
> given period or after a given period of user inactivity - e.g. no  
> pages requested)
> -The session data is stored on the webserver, in the user cookie  
> only the session ID is stored. You should be avare that if a shared  
> host is used, the directory where the session data is stored is  
> most probably available to all users, so other sites hosted on the  
> same host can access your session data. You can either: encrypt the  
> sessiond data before written to disk or better yet store it in the  
> database
>
> ----- Original Message ----
> From: xbennx () hotmail co uk
> To: webappsec () securityfocus com
> Sent: Saturday, 29 July, 2006 4:14:42 PM
> Subject: Correct Session Authentication
>
> I've been developing a shopping cart for my friends company and  
> have just started using sessions to authenticate people. After  
> reading many tutorials on the internet about sessions and PHP I  
> coded a login page. I keep hearing about session id's but all the  
> tutorials I read didn't mention them.
>
> When a user logs on, the username and password are sent via SSL and  
> the md5 hash is then checked against a hash stored in database. If  
> the credentials are found in the database, the users id is return  
> and stored in a session. If the credentials are not found this  
> session value is 0. Every page that a user needs to be  
> authenticated to see checks to see that the user id stored in the  
> session is greater than 0, if not the user is classed as not  
> authorised as 0 is not a valid user id.
>
> Is this method secure or can it be easily bypassed?
>
> Another thing I was wondering is where are sessions values actually  
> stored? I've read that they're stored in cookies but I always  
> thought there was a seperate function in php to create cookies?
>
> Sorry this is so long, any help will be much appreciated.
>
> Thanks
>
> ---------------------------------------------------------------------- 
> ---
> Sponsored by: Watchfire
>
> AppScan 6.5 is now available! New features for Web Services Testing,
> Advanced Automated Capabilities for Penetration Testers, PCI  
> Compliance
> Reporting, Token Analysis, Authentication testing, Automated  
> JavaScript
> execution and much more.
> Download a Free Trial of AppScan today!
>
> https://www.watchfire.com/securearea/appscancamp.aspx? 
> id=70150000000CYkc
> ---------------------------------------------------------------------- 
> ---
>
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Sponsored by: Watchfire
>
> AppScan 6.5 is now available! New features for Web Services Testing,
> Advanced Automated Capabilities for Penetration Testers, PCI  
> Compliance
> Reporting, Token Analysis, Authentication testing, Automated  
> JavaScript
> execution and much more.
> Download a Free Trial of AppScan today!
>
> https://www.watchfire.com/securearea/appscancamp.aspx? 
> id=70150000000CYkc
> ---------------------------------------------------------------------- 
> ---


-------------------------------------------------------------------------
Sponsored by: Watchfire

AppScan 6.5 is now available! New features for Web Services Testing, 
Advanced Automated Capabilities for Penetration Testers, PCI Compliance 
Reporting, Token Analysis, Authentication testing, Automated JavaScript 
execution and much more. 
Download a Free Trial of AppScan today!

https://www.watchfire.com/securearea/appscancamp.aspx?id=70150000000CYkc
-------------------------------------------------------------------------