views:

116

answers:

2

I'm working on developing a page that pulls data down only via ajax: http://itprojectguide.org/projectmatrix/itprojectguideprojectmatrix.html

the page currently pulls a status json data file.

To authenticate I'll be adding a preliminary signin (user name/password) and I'm thinking about doing the following to ensure a valid logged in user is present:

  1. when signing in, send the user ID, and md5 hased password - the server will return a encrypted string containing User ID, signin date, level
  2. I will pass this encrypted string to all pages, each page will send the string and page type to the server - the encrypted string will be validated to ensure valid user and that the user has signed in within the last 24 hours (based on the date). Data will be returned based on the user's level and the page that the user is on + any page specific data (say date range or company ID depending on the date)

Will the use of the encrypted User ID, signin date, level ensure proper security? I'm looking not to use cookies...is there a better way?

Part of this effort is to use ajax/json only interaction to retrieve data for each page instead of rendering it on the server..

+3  A: 

Since you are rolling your own session management logic, you need to ensure the following:

  • The string returned by the server after authentication is not guessable. You might be encrypting it to prevent tampering, but you also have to account for replay and hijacking attacks. It is for this purpose that most session IDs are generated using PRNGs.
  • The string is protected during transmission. It depends on what value you (or rather your customers) assign to the data in the application. If the string can be snooped from the wire leading to significant business damage, you should look at HTTPS.
  • Sessions eventually should expire. The longer the session is active, the greater the chance for it to eventually be discovered.
Vineet Reynolds
+1  A: 

You might consider using a One Time Password:

http://en.wikipedia.org/wiki/One-time_password

Also, if you can't run things over https you might piggyback on top of various OpenID providers' HTTPS, at least for the initial login to get the session cookie.

Jared Updike