Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
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). –  Adam Paynter Sep 12 '11 at 9:22
Every request is over https (to avoid exactly that issue). Thanks for the clarification! –  Riley Lark Sep 12 '11 at 14:17
add comment

2 Answers

up vote 23 down vote accepted

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.

  • Buy an EV cert. This gives users an extra cue (the green glow) that may help some alert users notice when they are under attack. However, it is not clear whether this will be effective in practice, for typical users, so there is some debate about whether EV certs add any value at all.

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.

share|improve this answer
EV is largely useless IMO, since it depends on users recognizing the absence of a green bar and using that absence as a signal NOT to visit the site they want to visit. lim(x->0)(x) users will do that. Besides, DigiNotar's EV root got owned too, didn't it? Rest of the advice seems right on to me. –  Steve Dispensa Sep 12 '11 at 5:48
@D.W. Pardon my ignorance, but is the fact that the plain text password still lives in the application logs, at least for a while, irrelevant? –  Júlio Santos Sep 12 '11 at 7:32
@Júlio Santo why do you log the password at all? –  Hendrik Brummermann Sep 12 '11 at 7:45
@Julio, Rails filters form fields with certain names from logs. By default, it includes "password" and "password_confirmation"—check your initializers. –  whitequark Sep 12 '11 at 9:56
@Julio that way the hash becomes the new password (you can use the hash from the client to access the application, thus you don't need to know the password to get in). It would only prevent hackers to retrieve your users' passwords when accessing your logs, not from accessing your application. –  Zidad Sep 12 '11 at 14:16
show 3 more comments

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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.