Forum: Ruby on Rails encrypt password on the browser

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
408a4e38946d3aa2fca0450ec357d06a?d=identicon&s=25 Shuaib Zahda (shuaib85)
on 2008-10-23 08:27
(Received via mailing list)
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
A45f650cce5746dd89aafb3176b47b02?d=identicon&s=25 DyingToLearn (Guest)
on 2008-10-23 09:14
(Received via mailing list)
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
613340c5fef56ad6fc3bf8cc617266ae?d=identicon&s=25 Andrew Porter (Guest)
on 2008-10-23 11:57
(Received via mailing list)
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).
408a4e38946d3aa2fca0450ec357d06a?d=identicon&s=25 Shuaib Zahda (shuaib85)
on 2008-10-23 14:15
(Received via mailing list)
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
D3fc5887a2f39f2e0c8989d39ce5e6f9?d=identicon&s=25 Bharat Ruparel (bruparel)
on 2008-10-23 15:01
(Received via mailing list)
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
3b1756d05466b4a78afd9aea7bb845c2?d=identicon&s=25 Aaron Turner (Guest)
on 2008-10-23 18:29
(Received via mailing list)
On Thu, Oct 23, 2008 at 12:13 AM, DyingToLearn <phylae@gmail.com> wrote:
>
> 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

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.

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.  -- Benjamin Franklin
97f7778bd994b7e4c5ad025be0640bde?d=identicon&s=25 Andrius Chamentauskas (Guest)
on 2008-10-24 15:45
(Received via mailing list)
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.
3b1756d05466b4a78afd9aea7bb845c2?d=identicon&s=25 Aaron Turner (Guest)
on 2008-10-24 18:18
(Received via mailing list)
On Fri, Oct 24, 2008 at 6:45 AM, Andrius Chamentauskas
<sinsiliux@gmail.com> wrote:
>
> 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.

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. :)  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.

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.  -- Benjamin Franklin
This topic is locked and can not be replied to.