Protecting passwords over the wire

rubyonrails-talk
#1

I've implemented acts_as_authenticated, the implementation went
surprisingly well.

Now I'm just concerned about the part where the password is sent from
the browser into my app. At this point the password has not been
encrypted or anything - it's going over the wire as clear text.

What have others here done to protect that exposure in their apps? Is
there any "Rails way" of doing this? Or is it just a matter of
getting a SSL certificate and running over https?

#2

bjhess said the following on 02/15/2007 02:54 PM:

I've implemented acts_as_authenticated, the implementation went
surprisingly well.

Now I'm just concerned about the part where the password is sent from
the browser into my app. At this point the password has not been
encrypted or anything - it's going over the wire as clear text.

What have others here done to protect that exposure in their apps? Is
there any "Rails way" of doing this? Or is it just a matter of
getting a SSL certificate and running over https?

You can if you want, but do a 'risk analysis'.
Determine what you are trying to protect and what you are trying to protect
it from. It sounds like you are concerned about password sniffing.

* Is the password being passed in the clear for for _every_ access?
* Is the password in the cookie? In the HTTP header (HTTP_AUTHORIZATION)
  Is it in the clear? or encrypted?
* Does the cookie pass a reference to the session instead?
  Is that encrypted? or can an attacker figure out the 'algorithm'?
* If someone hijacks the cookie can they impersonate the user?
* Where is the session information stored? Can it be hijacked?

* Encrypted cookies are a good thing :slight_smile:

* Don't try storing 'real' information in the cookie

* Expire your cookies and sessions.

And finally, there are many good books on the design of secure HTTP.
All SSL does it secure the link. Most of the attacks on, for example,
financial servers, don't involve 'man in the middle' attacks sniffing the
wire for passwords.

When I built a cookie based system for a banking application, the cookie
also contained an encrypted 'sequence number' and encrypted time stamp.

It comes down to "how paranoid are you?"

SSL only hides data on the wire. There are plenty of other ways of
hijacking an account or session. Search BugTrac, SANS and many other sites
that list vulnerabilities :slight_smile:

If you want to play with SSL, its possible to set up a SSL proxy or tunnel
without affecting your code-base.

#3

Thanks for the response, Anton.

As far as my understanding of acts_as_authenticated goes, I believe
the only critical point is when the user logs in. At that point the
password has to be arriving at the back end prior to being encrypted.
To the best of my knowledge the password comes through on a POST and
is pulled from params[] for encryption. From that point on, the
password resides in an encrypted cookie. (Someone please correct me
if I'm messed up here.)

I'm comfortable with the encrypted cookie. It's just that initial bit
of data being passed through upon login that I'm worried about. At
this point I'm not asking for any other critical data from the user.

Barry

#4

bjhess said the following on 02/15/2007 09:39 PM:

Thanks for the response, Anton.

...

I'm comfortable with the encrypted cookie. It's just that initial bit
of data being passed through upon login that I'm worried about. At
this point I'm not asking for any other critical data from the user.

I'd strongly suggest setting up a sniffer beside your machine and visiting
various web sites and see what they do as well. You'll be surprised how
some handle login and "basic HTTP Authentication".

By comparison the window of opportunity for that one event is much narrower.

However there are well established techniques to address your concern.
I'd still advise going though my list so you understand the boundary conditions.

The 'Right Way To Do It' is CHAP.

The user knows the password and so does the host.

The host sends a form with some javascript and a random string that is
pretty long. The host remembers that string.

The form uses the string as the key to encrypt the password.
(Or the other way round perhaps).
The encrypted string is sent to the host.

The host encrypts the password with its copy of the string.

Are the results the same?

Essentially this is the CHAP handshake used by PPP
and defined in RFC1994 and RFC2433
http://www.ietf.org/rfc/rfc1994.txt
http://www.ietf.org/rfc/rfc2433.txt
http://en.wikipedia.org/wiki/Challenge-handshake_authentication_protocol

Its strength is that random string - 'nonce' - is different each time, so
seeing it once doesn't help.

The downside is that the form has to have the javascript downloaded.

So, you ask, what if the sniffer intercepts the javascript and the nonce?
Well you need the password as well.

The real downside is that this STILL doesn't protect you from dictionary
attacks. You still need a "three failures and disconnect and don't connect
again for 30 minutes" type of policy to address that.

So, back to getting the user to visit a site that downloads a key recorder
.... what then? An on screen keyboard perhaps?

Yeee! This takes me back to the 1980s when I was hacking UNIX to talk to
Telebit routers!

#5

Thanks for all of your thoughts.

I'm starting to become of the mind that it's my responsibility to
protect the user's data when it gets to me and as much as I can within
the application thereafter, but up front I'm not going to worry too
much about traffic sniffing catching a user's password upon login.
Even if I protect the user, the other five apps she logs into during
the day probably won't protect her and invariably her password will be
the same for all of these applications.

Now I'm starting to get nervous about other things. For instance,
does Rails and Prototype handle escaping characters of parameters
before they go over the wire (in JavaScript terms, does it send the
parameters through encodeURIComponent before building the URI)?

#6

bjhess said the following on 02/16/2007 03:08 PM:

Thanks for all of your thoughts.

I'm starting to become of the mind that it's my responsibility to
protect the user's data when it gets to me and as much as I can within
the application thereafter, but up front I'm not going to worry too
much about traffic sniffing catching a user's password upon login.
Even if I protect the user, the other five apps she logs into during
the day probably won't protect her and invariably her password will be
the same for all of these applications.

That's reasonable.

You are not getting into the issue of confidentiality and integrity of data,
and quite possibly privacy issues.

This is where I'm professionally involved and its not rally on-topic for
this forum.

Contact me directly and we'll explore these issues.

#7

Alex Wayne said the following on 02/17/2007 01:46 AM:

SSL/https should give most of the protection you need.

A fallacy that a search of the security forums and buglists and books and
articles on attack modes will easily discount.

SSL only encrypts the traffic.
A 'man in the middle attack' can use other ways, for example spoofing the
original set up. There is hardware for sale that does that!

It doesn't protect the application, the data on the server or anything on
the client.

Perhaps the greatest security vulnerability is thinking that you have the
protection you need.

#8

I'm fishing here - has anyone out there done this in a Rails way yet?
Just figured I'd ask before figuring it out myself.

I'm planning on going the nonce route now. It's not going to
hurt. :slight_smile:

Barry

#9

Thanks for that link. It should come in very handy.

Now on to protect from dictionary attacks!