61

When a user's logging in to my site, they send their username and password to me over https. Besides the ssl, there's no special obfuscation of the password - it lives in memory in the browser in the clear.

Is there anything else I should do? Should I keep it hashed somehow, even in RAM?

Riley Lark
  • 977
  • 1
  • 8
  • 10
  • 9
    FYI: Is you entire site `https` or just the authentication? If it's just the authentication, you may run into other problems because the session cookie becomes the new "password", so to speak. Wireless users can have their sessions hijacked because they share the same IP address as the attacker if they are on the same wireless network (see [firesheep](http://codebutler.github.com/firesheep/)). – Adam Paynter Sep 12 '11 at 09:22
  • 2
    Every request is over https (to avoid exactly that issue). Thanks for the clarification! – Riley Lark Sep 12 '11 at 14:17

2 Answers2

50

This is fine. You don't need to do anything else. There is no need to hash it or obfuscate it in RAM.

You should be careful to hash the password appropriately on the server side before storing it in persistent memory (e.g., in a database), and you should take care to use proper methods for password hashing. See, e.g., How to securely hash passwords?, Which password hashing method should I use?, Most secure password hash algorithm(s)?, Do any security experts recommend bcrypt for password storage?.

If you want to provide additional security for your users, here are some steps you could take:

  • Use site-wide SSL/TLS. Any attempt to visit your site through HTTP should immediately redirect to HTTPS.

  • Enable HSTS on your site. This tells browsers to only connect to you via HTTPS. Paypal uses it. It is supported in recent versions of Firefox and Chrome.

I'm not saying you need to do these things (though site-wide SSL/TLS makes a big difference). But these are some options that can help strengthen security against some common attack vectors.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 1
    @AndréDS, I see you proposed an edit where you added "EDIT: This answer was written in 2017, such-and-such part is incorrect now, here is why." For future reference, in the future I think it would be better to either leave a comment or to edit the question to remove that part of the answer (and put your justification in the revision comment line). I don't think anyone is served by having a post that says "Do X. EDIT: Don't do X, that's no longer relevant". Instead, it's better to just get rid of the "Do X". – D.W. Mar 06 '19 at 18:01
  • 1
    Regardless, thanks for improving my answer and bringing it up to date! I really appreciate it! – D.W. Mar 06 '19 at 18:09
7

One additional thing you could do would be to use client certificates. The server can only guarantee to itself that there is no MitM by requiring a client cert. Otherwise, he has to trust the client to properly validate the absence of a MitM. This is more than a lot of services should be willing to trust.

Steve Dispensa
  • 3,441
  • 16
  • 20