I am considering installing SSL/TLS for my domain. There are two questions that have been bothering me:
Is there any scenario where a https connection can fallback to http? So, for e.g. if my ajax looks something like this
$.post("https://foo.com", function(){
});
Is there any chance this could change to
$.post("http://foo.com", function(){
});
and even if it does would my domain be still accesible at http://foo.com ?
Next I have read extensively about using SSL/TLS and from what I have read it seems to be fairly accurate to assume that if I have this enabled and even if I send the user credentials in plain text, it's still secure (There would be encryption with salt and everything on the server of course). To what extent is this true and would creating a hash on the client and then sending it over https be any more secure?
Update: If sending plaintext over SSL is secure enough, then what really is the point of using things like cnonce ? Isn't it just unnecessary overhead on the client?
No, HTTPS never falls back to HTTP automatically. It would take deliberate action by the user. If you're just going to a web page by putting its URL into the address bar, this is easy; for form submission it's harder.
Yes, sending plain text over SSL is fine. In fact, sending a hashed password doesn't really increase security much at all -- if someone manages to sniff the connection and gets the hashed password, that's all they need to be able to login to the site. It has one small advantage: if the user uses the same password at multiple sites, learning the hashed password for one site doesn't help them get into another site that uses a different (or no) hash. And it's not likely to be feasible to send salted hashes, since the client doesn't know the salt.
A cnonce adds an extra level of protection. If, somehow, someone manages to crack the SSL encryption, the cnonce prevents them from getting a usable password from it. This basically addresses the point I made above about why sending a hashed password doesn't help: what you need is something that changes from session to session, and a cnonce provides this.
See https://security.stackexchange.com/questions/3001/what-is-the-use-of-a-client-nonce
Related
I am reading about various algorithms in javascript to encrypt username and passwords before sending to the server (so they cannot be read on the network).
I have seen demos where plain text is used for the password and the author has simply said 'in production I would use https as I would never send plain text'.
Not being a web developer, should I think about https or think about encrypting the information (username/password) I send?
Are the costs involved in setting up HTTPS that forces users not to use it? I know that once https is in place, everything is secure.
I guess I a missing some theory on the benefits of https and how it ties in with encryption for username/password.
I'm trying to understand something. When I implement PBKDF2 in a server and client, it is my understanding (could be way wrong, sorry), that the server keeps the encrypted/hashed password in the database, and the user sends his or her password over the net and then it is checked by the server for validity.
What Im curious about is, exactly how do I prevent the users submission over the net to be seen and the users password exposed? do I Just depend on the networking library or SSL to protect this information?
How do i make sure the the password that's being sent over the net is in a way that cannot be exposed easily, but can still be read by the server to check against the hash?
Would it be wise to perform an SHA2 hash on the password client side, and then send that to the server and then check the sha2 has against the PBKDF2 hash? The server will never really even know the users password, the only possible recovery option is to reset it. Is this type of system acceptable?
What kinds of these things are done normally by the professionals?
When I implement PBKDF2 in a server and client, it is my understanding (could be way wrong, sorry), that the server keeps the encrypted/hashed password in the database, and the user sends his or her password over the net and then it is checked by the server for validity.
This is basically correct. When setting up an account the user sends user and pass to the server. The server stores user and PBKDF2(pass) and then discards pass. When logging in the server looks up against the user column and compares PBKDF2(pass_as_submitted) to the value stored when the account was set up. If they match, the user is authenticated.
Do I just depend on the networking library or SSL to protect this information?
In the sort of situation you're talking about, yes.
Would it be wise to perform an SHA2 hash on the password client side, and then send that to the server and then check the sha2 has against the PBKDF2 hash?
No. The problem here is you're just changing the thing you're keeping from the user's password to a hash of the user's password. It's still known to an attacker who can read the database.
(There are reasons this is marginally better than knowing the password, most particularly in case of password reuse. However, these do not justify such an approach.)
It's worth pointing out as well that SHA2(password) will not match PBKDF2(password).
What kinds of these things are done normally by the professionals?
First, use TLS (aka SSL). Having a good, encrypted connection between client and server is first priority. For a website, you should use TLS on every page, not just when sending the password. At the very least it must be used on the login page and on the request that receives username and password information.
Your TLS connection should be set up properly: it should use HSTS if appropriate (and it's a website). It should avoid outdated algorithms (only support TLS 1.1+ if possible). It should use appropriate cipher modes.
Beyond that, it depends on your use case. Perhaps it's worth implementing two factor authentication - be it using TOTP or SMS codes or similar. Perhaps you should be looking at logins without passwords, for example using client-side TLS certificates or OAuth2 tokens. Maybe you should use an existing authentication library like Kerberos. Maybe you need to look at password policies to ensure users are setting good passwords or pass phrases.
These questions are complex and depend on your use case. Thinking about them is the big first step most people don't take. Using PBKDF2 is a great start but there's no universal answer. If possible, get an expert to do your security analysis. If not, open source plus some promo can often get people to look at it. Worst case scenario, read up on security, check out the OWASP Top 10 and think about every part of the system. Where possible use existing libraries made by experts. If you have to roll your own, you're probably doing it wrong.
For username/pwd verification - the good websites use https - to avoid sending cleartext password over the wire. If I have a site where I want to do this - i.e. login over https. However - after logging in the rest of the stuff should be over http. Is this possible - if yes, why don't we see too many websites doing this. If not, why not?
You might want to read up on Firesheep. The short form is that this technique allows malicious people to hijack the session.
if yes, why don't we see too many websites doing this
The usual excuse for not using end-to-end TLS/SSL is that it causes the web app to take a performance hit, slow response times etc. This is a very flawed argument for https-sometimes security policy. Not entirely unfounded, but still unjustifiable.
If not, why not?
The thinking is that the only inherently vulnerable aspect of user access control is the authentication phase, i.e. where you supply your username and password to prove you are who you say you are. Organizations are aware of the risk of transmitting the credentials in clear text. After this process however, authorization is carried out server side and the web app trusts you from there on out and there are no credentials to protect any more.
Or are there?
As jszakmeister pointed out very succinctly, the session cookie is every bit as security critical as a username/password pair. Should someone get a hold of that, they might as well have seen the password and username on post-it.
Scenario:
I have a ASP.Net / Silverlight website with webservices for supporting the Silverlight apps with data. The website uses forms authentication, and thus the webservices can also authenticate requests.
Now I would like to pull some data from this system to a Android application. I could implement code for running the forms login, and storing the authentication cookie, but it would actually be much simpler to send the username and password in the webservice url and authenticate each call. I don't really see a big problem with this as the communication is SSL encrypted, but I'm open to be conviced otherwise ;)
What do you think ? Bad idea / not so bad idea ?
Conclusion:
After reviewing the answers the only really valid argument against name / pass in the url request string is that it's stored in the server log files. Granted it's my server and if that server is hacked the the data it stores will also be hacked, but I still don't like passwords showing up in logs. (Thats why they are stored salted and encrypted)
Solution:
I will post the username and passord with the request. Minimal extra work, and more secure.
See Are querystring parameters secure in HTTPS (HTTP + SSL)?
Everything will be encrypted, but the URLs, along with the query string (and thus the passwords) will show up in the server log files.
Bad Idea: The contents of your post are encrypted and though the URL parameters may be encrypted as well, they could still be visible to third-party trackers, server logs or some other monitoring software that can directly sniff your traffic. It is just not a good idea to open up a potential security hole in this way.
Users do tend to copy-and-paste URLs straight from their address bar into emails, blogs, etc., and save them in bookmarks, and so on.
And things like plugins, or even other software that reads, for example, window properties (alternate shells, theme managers, accessibility software) could end up with the info. And they might, for example, crash and automatically send crashdumps back to their developers.
And worms far less sophisticated than keloggers - like things that take screendumps - can get passwords this way. Sometimes even security software, for example if deployed in a corporate network.
And if the user has a local proxy, then they might be communicating in plaintext with the proxy which in turn is talking in SSL (not the way it's supposed to be done, but it happens).
And for these and more reasons, URLs with usernames and passwords, that used to be standard - such as ftp URLs with the username and password in the authority segment - are now typically forbidden by browsers.
https://www.rfc-editor.org/rfc/rfc3986#section-7.5
So, an emphatic NO, DO NOT DO THIS.
It is always good programing practice to not provide delicate info like username and password
in the URL. No matter how good a site is it can be compromised. So why provide with more info?
Is there any way (apart from HTTP authentication, which I gather is inherently insecure over the Internet?) for a "real life" website to handle logins and authentication rather than the traditional way, using session cookies?
HTTP digest authentication (which is quite a different beast from HTTP basic authentication) is quite secure over straight HTTP, and not at all difficult to implement on the server. Nothing is sent over the wire that could reveal what the password is, just information that allows the client to demonstrate to the server that they have the correct password.
If you want a decent explanation of how to implement HTTP digest authentication in your application, Paul James has an excellent article on it.
The only real problem with HTTP authentication is in the browsers themselves: the UI is terrible, but that can be overcome with some Javascript.
Addendum: This answer is almost a decade old. These days, you should really be using HTTPS regardless of any other considerations.
HTTP basic authentication is perfectly safe when used with a SSL (https://) website since all HTTP traffic including the credentials will be encrypted. One subjective drawback though is when using this method your users will need to interact with their browser's authentication popup in order to log in to your site.
To be clear, the only REAL way to do this is through HTTPS.
But, since I assume this is not an option, and I also assume you are looking for a "fully managed login" system, I continue:
Other than HTTPS it is possible to use JavaScript to do secure hashing of passwords on the client side, to prevent revealing plain text passwords over-the-wire, but this is only a half-solution.
The problems with this approach are:
A replay attack is still a viable option.
Only users with JavaScript enabled would be able to auth in this way.
Another approach is a more complicated challenge / response mechanism:
Send a "Challenge" along with the login page.
Calculate the hash of the Password + Challenge client side.
Submit the login.
Calculate the hash of the Password + Challenge (which MUST NOT be trusted in the page request) on the server side, and compare.
And the problems with that:
Only users with JavaScript enabled would be able to auth in this way.
The PLAINTEXT password must be stored on the server to validate the challenge response, and must be encrypted on disk or otherwise protected.
Now, to be fair, problem #2 is not as big of a danger as it sounds. In fact when you instead use HASH authentication, the hash itself is raised to the level of "key".
At this point it is fairly secure to use a cookie to store a randomly generated login ReferrenceID, similar to their session ID, but the server may want to encrypt using the referring IP as part of the IV or KEY to prevent other users from Hijacking the ReferrenceID.
Anyways, I hope that provides a little bit of direction in the way of your design.
HTTP authentication is not insecure when using HTTPs.
Firstly, HTTP Auth is secure over SSL other than the fact that you can't implement a true "Logout" functionality. User need to close their browser, which is pretty bad.
Secondly, It you need to use HTTPS in all cases to make it secure, after that you got Basic Auth similar stuff such as "Digest" and "NTLM Auth".
When you're using https, you can also install a certificate in your client's browser and verify that. myopenid offers this for their OpenID accounts. I have one and it works really well (from the client-side point of view).
Using SSL for encryption in combination with HttpOnly Cookies to help prevent XSS is your best bet for using cookies. I'm not going to say it is bullet-proof, though.