encrypt password on the browser

rubyonrails-talk
1

Hi

I was looking through my logs and I found that the password field in rails does not get encrypted. It is sent not encrypted from the browser. Is there anyway that I can encrypt the password field so if some one intercept the packets he will not be able to read the passwords

2

The best way is to simply use https. Definitely DONT use javascript for encrypting the password (unless you encrypt it again on the server).

To remove passwords from your logs use this option in your Application controller filter_parameter_logging :password

HTH

Shuaib85 wrote:

3

Shuaib85 wrote:

Hi

I was looking through my logs and I found that the password field in rails does not get encrypted. It is sent not encrypted from the browser. Is there anyway that I can encrypt the password field so if some one intercept the packets he will not be able to read the passwords

What is this password field that you are referring to ? Rails doesn't have one by default. If you want secure http use https. You could encrypt the password with some javascript before submission but that's easily reversible just by looking at the code (it would have to be a reversible algorithm for you to process on the server side).

4

Hi I am referring to the login page of the users. I noticed that the password travels unencrypted. So, I wanted to encrypt it on the user side

any other ways beside https and javascript?

thanks

5

The standard way to do is using HTTPS as noted above. If you use javascript or something similar on the client side (browser side) then you are just adding on unnecessary work. Bharat

6

I actually have seen a proper way to do form based password authentication via javascript which is mostly secure, even without https. It's a bit of work though:

1. On the login form, you have a hidden field initalized by the server set to a random value (aka a "nonce") On form submit the javascript: 2a. Converts the user password to the same format that is stored in the database (after this, the password string in the DB matches the password in javascript) 2b. Takes the resulting user password from 2a and concats it with the nonce in step 1 to create a longer string. 3. Java script then runs something like MD5 or SHA1 (sha-256 would be better) over this longer string to create a hashed value. I know open source md5 implimentations in javascript exist- just google for it. 4. This hashed value is then sent to the server

The server to authenticate takes the password stored in the DB and does steps 2b and 3 and then checks to see if the two hashed values match.

Note: It is VERY IMPORTANT that the random (nonce) is changed for each login. Failure to do this enables replay attacks. You could just use a monotonically increasing value using the database to store the last used value to prevent replay attacks.

Of course after all this, if your session cookie is open to replay attacks, then someone can just steal that and bypass your login altogether, so using https is really easier and safer. https also prevents man in the middle attacks which you can't stop with javascript.

Honestly, if it's worth going through all this effort to do the javascript thingy, it's probably easier to setup https and then you'll know it's secure.

7

What about asymmetric encryption algorithms? You could use javascript to encrypt password using public key, and then this information could only be decrypted only by using private key, which could be stored safely in server and used in model for authentication or registration. I think example of this is RSA.

8

I'm not a JS expert by any means, but I don't think it is powerful enough to work with the VERY large numbers necessary for RSA. Frankly, using RSA (or any security algorithm) properly is very difficult and it's easy to use it in a way which negates it's effectiveness. There are a number of attacks against RSA if you use it incorrectly.

Also, RSA is very CPU intensive- even compared to other encryption/hash algorithms.

If security really is a concern, then you should absolutely use HTTPS which has a lot of peer review and handles all sorts of security challenges that are not solvable via JS. Man in the middle (MITM) attacks are especially difficult to stop via JS since you have no realistic way of authenticating the server you're talking to.

Btw, using the monotonically increasing nonce like I suggested in the last email is very open to MITM attacks because it's easy for someone to pretend to be the server and choose a nonce in the future, capture your reply and keep connecting to the server until it sends the matching nonce value and then use the response it cached from you. Hence you may want to include a timestamp in the nonce, but of course that's open to timing attacks. :slight_smile: Or you could go with a truly random nonce, but that tends to be difficult to implement in real life (again, you can not EVER repeat this value!).

Here's a cool little tool a buddy of mine wrote show casing how easy it is to do MITM attacks over wireless at a security conference:

http://airpwn.sourceforge.net/Airpwn.html

My point is that security is hard. Don't try to do it yourself. Stand on the shoulders of giants. Use SSL/TLS.