13

I am trying to learn how a secure web application is developed. Particularly, I am unsure of how passwords are sent from the client to the server. For a typical user/password login form. If the client sends a plaintext user/pass in a POST request over HTTPS. Is this secure enough? Considering the server hashes the plaintext pass with the stored salt using something like bcrypt, with enough iterations.

Is this scenario secure enough? Ignoring other attack vectors such as SQL injections, XSS etc. I am simply looking to see if sending plaintext password over SSL in a POST request is secure enough, or if some other security might be necessary, on the client side.

marcwho
  • 874
  • 1
  • 10
  • 19

4 Answers4

14

Yes, sending the information using POST over HTTPS is the typical way of doing things. 

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
13

To complete @Terry's answer: sending the user name and password in a POST over HTTPS is not only the typical way it is done, it is also the correct way to do it. This will bring you the best security you can hope for. I did not write "good security", but you would have a hard time doing any better; indeed, anything you would do on the client side, in a Web context, would have to use some Javascript... which comes from the server itself. And, similarly, once authentication has been performed, you still have to transmit whatever data which was sensitive enough to warrant authentication in the first place. So you would still have to rely on HTTPS being secure enough to prevent hostile eavesdropping and tampering.

You will still want to make sure that the password entry field is "hidden", i.e. displays bullets or stars instead of the characters entered by the user, in order to discourage shoulder surfers. Additional gimmicks that banks are fond of, such as "visual keyboards" to deter basic keyloggers, are usually not worth the effort.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Isn't [SRP](http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) technically better? Or are you considering that, in typical browser contexts, Javascript can't be trusted for such kinds of operations? – Stephen Touset Apr 06 '13 at 06:39
  • 1
    SRP is good because it avoids having to trust the certificate-CA thing; but this works only if the browser supports it natively (and, right now, they do not). If you use a Javascript implementation of SRP, then you have to trust the Javascript code you obtained, which came, at best, over a necessarily non-SRP HTTPS tunnel... – Tom Leek Apr 06 '13 at 15:10
2

Yes for securing the user credentials over the transmission channel post and HTTPS are enough.but identity management is a very big topic and there are many other attack vectors which you will need to consider see this for some additional information

Community
  • 1
Shurmajee
  • 7,335
  • 5
  • 28
  • 59
1

It is actually practice to use HTTPS, but i think it should not replace cryptographic functions in order to save the user and his very own password!

Against SQLi, XSS, XSE i would recommend you to read on https://owasp.org/

santa
  • 103
  • 4
Dr.Ü
  • 1,029
  • 8
  • 16
  • my two cent: there should be no need for the login-process to know the plaintext password at all. a hash should suffice. it IS best practice to store salted hashes of passwords in your database (so that a possible intruder can't get your users plaintext-passwords and e.g.: try to use them somewhere else -> identity theft) since the hashing has to be done somewhere -> do it as early as possible. the hash is worth less than the plain password. avoid transporting sensitive data when it's not needed. your users would thank you if they knew that you actually care about them ;) – santa Apr 05 '13 at 21:57
  • and also, this: http://stackoverflow.com/questions/1774876/password-hashing-at-client-browser – santa Apr 05 '13 at 22:30
  • @santa - You seem to be suggesting that the client should hash the password and send that to the server. I think that you should do the hashing on the server. If your server is expecting a hash from the (untrusted) client then the hashes in the DB effectively become the passwords which defeats the main point of hashing AFAIK. Happy to be corrected on this if that's wrong. – Dan Apr 06 '13 at 10:24
  • @dan - depends what you use the hash for. if you use the hash so the users plaintextpassword is protected it's fine to do it on the client. on the other hand if you want to safe your users from ppl logging in with their accounts after someone slurped your database - you must do the hashing on the server - if you want both - i guess hashing twice could be an answer :) haven't thought about the implications of hashing twice yet - but it seems legit – santa Apr 06 '13 at 12:30
  • @santa Hashing on the server has an added advantage I suppose. When the user supplied password (or whatever data entered in the password field) is input-ed in the hash function, you don't need to worry about SQLi, XSS or any other anomalies at the server end since everything will become part of the hash input that is going to product a fixed size output. – void_in Apr 06 '13 at 12:50
  • 1
    @void_in relying on hashing against SQLi, XSS and so forth sounds pretty darn stupid to me - since we're only talking about the password itself - there's always more fields to that, and you need to handle them right anyway... so it's "just" one more field to handle right in the first place... – santa Apr 08 '13 at 09:09