Is there any way to have persistent (regardless of how small) client-side storage via the web?

Question

Okay, since none of you guys like my question, let me rephrase it.

User logs into an HTML form. With JavaScript, their password is hashed locally (salted too). The server knows what the password + salt should be, user is already registered, blahblahblah. Now the user requests a page. The server sends a random ID to the user. When the user loads the next page, this random ID is appended to the key they have locally stored, it's hashed, and THAT is sent to the server. The server knows what they key is and the random ID, performs the same hash, and compares. If they match, congrats, it came from the proper computer. If not, then someone's been sniffing your TCP/IP traffic.

All of this is obviously without SSL, otherwise this would be highly redundant.

My question - HOW DO I STORE THE KEY ON A CLIENT PC?

Original Post:

Hello;

I'm working on developing a PHP Content Management System, and came up with a secure login system. The only problem is that it would require some form of client-side storage (for a very small key, 40 characters in length) - otherwise the user would have to type in their password on every page load.

Is there a way that, using either PHP or JavaScript, I can store a small 40-character string on a client's PC an retrieve it later?

EDIT: COOKIES ARE NOT AN OPTION. This 40-character string can NOT leave the client's computer, and all set cookies are sent with each HTTP header.

I REPEAT - COOKIES ARE INSECURE AND NOT A VIABLE OPTION FOR THIS.

Let me rework it like this - client submits an HTTP form. With some scripting language (e.g. JavaScript), the password is stripped from the form, NOT sent to the server, encrypted, and is kept CLIENT-SIDE, which I can retrieve and verify (by hashing it with a key sent to the user from the server). This verification is sent to the server, never the key.

Answer 1

http://en.wikipedia.org/wiki/HTTP%5Fcookie

Answer 2

Cookies are the way to do that, but you won't store any password in a cookie, that's (almost) an order ;-).

You could use session to store information between page load on the server side. http://fr.php.net/manual/en/book.session.php

Answer 3

I'm not a PHP developer but I would advocate that you search for pre-existing authentication systems. They will more often than not be a bit more secure than what you would write (as that would be their primary purpose). It would also allow you to review the code and see how they did it and figure out why.

Edit: You almost always want to handle authentication on the server. It's acceptable to transfer session information to the user in the form of a cookie or url param but the actual processing should be done on the server. You are opening yourself up to major risks otherwise.

Answer 4

Use a cookie if you want to save it between browser visits. It'll be stored on the client's machine.

Use a session if you want to save it for a shorter duration. It'll be stored on the webserver.

Answer 5

If you wanted to create something that never traveled over the internet, you would basically have to do it all in JavaScript.

First, create a piece of code that starts something like Google Gears. Use the database in Google Gears to store the key.

Next, on the rest of the pages, have a piece of javascript that checks the key in the Google Gear database. If the key is not valid, delete the key, redirect the user, and make them log in again.

Answer 6

First I'll answer the question of "can I store client side data without using a cookie":

• You could use a Flash SharedObject, but of course requires Flash, and the user has to click a confirmation box to allow it.
• HTML5 features client-side databases, so there's another emerging option for you.
• Use Google Gears on the client side and use their local database API

BUT - for your purposes you could engineer a login form which doesn't transmit the password but sends a hash of it. Your PHP script would send a form which included a secret salt value, and then you have some javascript which hooks into the submit event and replaces the password entered with the salted hash.

Answer 7

There's already a browser-based system that uses keys to secure data transfer. It's called SSL.

Answer 8

Adding to what Bryan says, if you can use the HTML 5 spec, then you can take advantage of local storage.

http://ajaxian.com/archives/webkit-does-html5-client-side-database-storage

Answer 9

I see problem with your approach. First load of initial JavaScript can be sniffed, so salt algorithm is not protected from hacker. Then ID is also "public". I.e. seems like you have next schema (please correct me if I'm wrong) :

password + SHA1 => hashed password
hashed password + (ID from server) + (salt from server) => mega hashed password

I really have a problem to see why "mega hashed password" is more secure than hashed.

Answer 10

You can use a couple of different tricks to keep state on the client, you can keep a top level frame and store a javascript variable there.

You can use Flash local "SharedObject",

Silverlights' IsolatedStorage

or the equivelant in Google Gears.

but..

Don't follow this line of thinking. You need SSL. You are not going to build something secure, you are going to build something that shoots you or someone using your app in the foot.