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.

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.

share|improve this question

4 Answers 4

up vote 11 down vote accepted

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

share|improve this answer

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.

share|improve this answer
    
Isn't SRP technically better? Or are you considering that, in typical browser contexts, Javascript can't be trusted for such kinds of operations? –  Stephen Touset Apr 6 '13 at 6: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 6 '13 at 15:10

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

share|improve this answer

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/

share|improve this answer
    
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 5 '13 at 21:57
    
and also, this: stackoverflow.com/questions/1774876/… –  santa Apr 5 '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 6 '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 6 '13 at 12:30
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 8 '13 at 9:09

Your Answer

 
discard

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.