Hide the a saved password from the source

I have a login form and an option to remember the password. The password is encrypted in a cookie on the users computer. At the moment it is decrypted and placed in the pas开发者_运维技巧sword field. This isn't that flash as you merely view the source to see the users password.

Whats the best way to secure the password from the source?

Don't do that. ANY secure implementation of a login form will not make the password readble EVER.

You have two options:

• Use the cookie to log-in the user automatically. Very convenient, that's what most people want to have.
• Let the user save his password in the text field. Every browser can do that in a more or less secure way and skip the cookie.

Let me say it again: Displaying the clear text password in the code is a security risk. However, you knowing the user's password or being able to recreate it (symmetric encryption instead of hashing - what you should use) is a complicated thing, since I mistrust every website which knows my password in clear or stores it anywhere unhashed.

So, you'd go with taking the password from the user at registration time, hash it and store it in the database or whereever you like. Then, take the cookie to remember the user (means the identity, not the credentials to verify that identity).

1. Don't have an option to remember the password. Browsers can do that on their own, securely. Instead, use an option to keep the user logged in. In that case, you set a cookie to maintain the user's session between server sessions that's based on a session token (usually including an encrypted username), not a password.

2. You should never be able to decrypt a user's password to readable plain text. Use hashing instead of encryption. Instead of sending plain text to the server, you can hash the password on the client-side with an algorithm like SHA1. A lot of apps skip this first step, but it's preferable never to even transmit the password in clear text. Then, on the server side, hash the "password hash" again with an algorithm like HMAC-SHA1, using dynamic salt as a key. You should use different, random salt for each user's password. That way, even if two users have the same password, the salt ensures each password is saved differently. You store the password and the salt in your database for each user, so it can be used again when comparing to the user's password on each login.

3. Whether you store a session token that includes a username, or a user's password (which should only be a hash of the password, and is still inadvisable) in the cookie, you should encrypt the cookie (as you state you already have) and decrypt the cookie on the server side, not the client side. If you decrypt client side, then you've given away the algorithm and key to do so, which would make the encryption a pointless exercise. Additionally, if you decrypt server side and then send the password back down the pipe to preload your login form, you expose the user's password during transmission to the browser, and do so again when they resubmit the login form from the browser.

4. When the user makes the first request after returning to your site, you will get the cookie in the HTTP header, so if you use a session token instead of a password, you can immediately decrypt the cookie, verify the session token is still valid, log the user in, and take the user to a content page. This is what every site that allows a persistent session cookie does.

5. If you store the password in a cookie, I assume you're also storing the username, or sending the username from the server to the browser. When you then preload the username and password in your login form in clear text, you give a thief credentials to use on your site and potentially others. You leak information about the user. If you store a session token in the cookie (which contains a username and an expiration timestamp instead of a password), and only decrypt the token on the server, then you haven't leaked any user information. Additionally, you can use an HttpOnly cookie as your client script doesn't need to read the cookie.

From your perspective, both methods accomplish essentially the same thing for your users, but an encrypted session token that includes only the username poses far fewer risks for the user than a password that is stored (encrypted or not) and/or decrypted to preload your login form.

To create a session token, create a cookie and add the username and your choice of an issue date and/or an expiration date. If you set the issue date, then you can always calculate the expiration date based on your current expiration policy on the server. If your policy changes, then it always applies to old tokens as well. If you only set the expiration date and verify the current date is less than the expiration date, then you are using whatever expiration duration policy you thought up at the time you stored the cookie. Session tokens often include the following:

• Username - so it's specific to a user account you can verify
• Issue Date - the current timestamp
• Expiration Date - current timestamp + expiration window
• Persistent - A property indicating whether the cookie should stay persistent or expire at the end of the current server session
• Any custom data (sans any passwords)