Hello, my signup form uses multiple pages where I POST the info into hidden fields from one page to the next. Even though the password field uses md5 and a salt, is it safe for me to pass that info through a hidden input field as well or just use a session? I am using multiple pages so that after the user enters their signup info they will be directed to a PayPal or 2CO page afterwards. Thanks!

I would store the password as an MD5 in the session. That way if you need to re-authenticate for any reason you can.

Never store the password from POST in a SESSION though.

Kind Regards

Hmm I don't really understand since how else am I suppose to have the user's password passed if it is not collected from POST? Remember this is the signup page where the user enters his password for the first time.

The question you need to ask is - Once the user is logged in and the md5 hashes have been compared why do you need it? All you really need to do is check if the session exists. Else redirect.

Do you use the hash(password+salt) combination as a session ID?

Ok this is what I am doing. I have signup page 1, page 2, page 3. The user does not have an account yet. When they complete the info from signup page 1, it POSTS basic info to the next page like their account type and other minor options. Then on the second page has fields with their username, password, email, etc. The last page will be where they pay so I basically want to securely pass the password+salt and was wondering if I should use a hidden field or a session.

I would say store it in a session. This way people cannot view its contents. With a hidden field people can always view the contents from view source...

Well, the only difference if you propagate it through the forms, is that the owner of the password will see his own hash. Using this, he maybe can re-use the same hash later in order not to log in or register again, depending on the quality of your code.

Whatever the reason, keeping the hash on the server side is a more stealth design.

Also, you should use SSL for these things.

When using hashes, always make sure that the hash results from a salt that varies with each use. In other words, one time hashes.
This is how you defeat or at least hinder hash reuse.

As others have said, simply create a session (maybe have the session ID associated with their specific browser (USER_AGENT) and IP (REMOTE_ADDR)), so once they've provided (submitted) the fields, it's stored safely on the system, and they only continue to pass that one single session ID (hopefully via SSL as well). I also recommend generating a session ID so it constantly changes for each new signup session, rather than relying on any static hash, regardless of length, and there are some existing routines for that if you don't want to roll out your own.

Store in session instead of hidden field.

I once coded a 5 page registration, and I stored all data inside a database ;) You just need one more database table, "registerstep" which you increase after each page submit.

I have done something similar but here was my approach:

Page 1 is the account info. Only the username, password and e-mail address are asked for and are inserted into the database.

I do this method because the account is considered created at that moment. So if the user loses a connection in the middle of registration, their account exists and they can login to finish the registration. It doesn't mean the account is active for use, it just means they can finish their registration.

Page 2 has all the personal info and other registration requirements.

You should never store a password in a session. I just can't think of a reason to do so.

It could be in a database or a physical session file, either will be fine (depending on the read permissions of your views from other users on the same server or via a potentially insecure script you might have on your own site (we have to be realistic about that possibility)), so a database storage is probably better (depending) and that data there or in a file can be encrypted and decrypted by the end resulting signup script that actually adds and verifies the information once payment has been verified on paypal's end, at the point where it actually makes them active.

That all said, I always even make a habit of putting in hidden HTML fields for the elements such as the session they'll use if it's not something they need to see or modify, so even if you're doing a secure SSL connection with only a session ID (and not the password), keep that field hidden anyway. It really all comes down to how secure your program and signup script is as well, but this is a good start. Since there's no reason to keep the username, password, etc. from page to page, simply store it somehow and use a session and encryption where necessary (or where you benefit from a security stand point (and the users do as well)).