I need some help on the best way to secure this situation.
Here is the background
This all runs on the internal network.
there is several small web sites with classic asp that runs on iis. they all pass username/pw through a form and call this class that is a dll on the server. Which then authenticates against active directory and returns back. now obviously it is not secure passing through the form to the dll. is it then not secure as well from the dll to active directory?
what would be the easiest way to secure this. ssl? any other ideas and please answer that other dll question if you know
thanks
The problem with the word "secure" is that it ia a highly subjective term. What is or isn't "secure" really depends on the type of app and the damage that could be wrought if security measures are breached.
In some sense it isn't "secure" to have the password appear in memory in its unencrypted or even encrypted form. However I will risk the wrath of the security fanatics and suggest that having a users password in your servers volatile memory is not going to risk thermo-nuclear war and therefore an acceptable risk.
As to communicating it to the AD well that doesn't actually happen, the password does not leave the servers memory to go elsewhere. Instead AD formulates a challenge that the security API running locally in your server is able to build a response to armed with the password. The response to the challenge is sent back to AD, this response does not carry the password but carries proof that the correct password was present.
Having said that, in an intranet environment going to all this trouble (and troubling the user to yet again enter their username and password) seems a bit execessive. It would be better to just rely on Windows Integrated Security.
I've read your commens to SLaks re the "advised not to use NTLM". Yes its true that with modern machines NTLM is not as secure as we might like but is it really too lax for your requirement? Perhaps it is but integrated security can also use Kerberos.
So my suggestion would be ditch your dll, turn off NTLM in IIS leaving only Kerberos to handle the authentication. This way you never transport the password anywhere, the user isn't troubled to re-enter their password, you need do nothing in code and you avoid using NTLM.
Related
Dear StackOverflow community,
======================================
TL;DR VERSION:
Before we proceed further in our relationship with a cloud web portal provider, I'd like to insist that they provide us a secure way to obtain a copy of our data from their web server.
Secure for authenticating ourselves without leaving ourselves vulnerable to having our credentials stolen or spoofed and
Secure for the file in transit on its way back to us.
I suspect I might have to point them in the right direction myself despite my own inexperience in the field. What kinds of simple-yet-secure approaches to authenticating us could I ask them to look into?
======================================
FULL POST
BACKGROUND:
At work, we are evaluating a cloud-based portal through which our current and former customers will be able to network with each other (we have customers who interact with us in cohorts).
The user interface of the portal is well-designed, which is why we're thinking about buying it, but the company providing it is young. So, for example, their idea of "helping us integrate our portal data with SalesForce" was to have a link within the administrative control panel to a page that returns a CSV file containing the entire contents of our database.
"Fetch a CSV" actually is fine, because we already do it with other CSV files from our ERP (pushing to SalesForce with a data loader and scheduled Windows batch scripting on an always-on PC).
I said we could work with it as long as they provided us a way to fetch the CSV file programmatically, without human intervention, at 5AM. They did so, but the solution seems vulnerable to exploitation and I'd like guidance redirecting their efforts.
A DIVERSION ABOUT THE HUMAN UI:
The link one sees as a human using the web interface to the portal under consideration is http://www.OurBrandedDomain.com/admin/downloaddatabase
If you aren't already logged in, you will be redirected http://www.OurBrandedDomain.com/Admin/login?returnUrl=admin/downloaddatabase , and as soon as you log in, the CSV file will be offered to you.
(Yes, I know, it's HTTP and it's customer data ... I'm planning to talk to them about turning off HTTP access to the login/signup forms and to the internals of the site, too. Not the focus of my question, though.)
THEIR PROPOSAL:
So, as I said, I asked for something programmatically usable.
What they gave us was instructions to go to http://www.OurFlavorOfTheirSite.com/admin/fetchdatabase?email=AdminsEmail#Domain.com&password=AdminsPassword
Please correct me if I'm wrong, but this seems like a really insecure way to authenticate ourselves to the web server.
HOW I NEED HELP:
Before we proceed further in our relationship with this portal provider, I'd like to insist that they provide us a secure way to obtain a CSV copy of our data.
Secure for authenticating ourselves without leaving ourselves vulnerable to having our credentials stolen or spoofed and
Secure for the file in transit on its way back to us.
However, I don't get the sense that they've really thought about security much, and I suspect I might have to point them in the right direction myself despite my own inexperience in the field.
What kinds of simple-yet-secure approaches to authenticating us could I ask them to look into, knowing nothing more about the architecture of their servers than can be inferred from what I've just described here?
The solution doesn't have to involve us using a browser to interact with their server. Since we'll be downloading the file in a Windows scripting environment without human intervention, it's fine to suggest solutions that we can only test programmatically (even though that will make my learning curve a bit steeper).
(I suppose the solution could even get away from the server providing the data in the form of a CSV file, though then we'd probably just end up rebuilding a CSV file locally because we have infrastructure in place for CSV->SalesForce.)
Thanks in advance.
Yes, that is insecure.
You should insist on using TLS. For this they need to install a certificate from a Certification Authority to verify that they own the domain OurFlavorOfTheirSite.com. This will enable the URL to use HTTPS which means communication is encrypted, and authenticated (i.e. another website cannot spoof OurFlavorOfTheirSite.com without a browser warning being displayed).
Although the email=AdminsEmail#Domain.com&password=AdminsPassword parameters will be encrypted, these should be submitted via POST rather than GET. The reason is that GET query string parameters are logged in browser history, logged in proxy and server logs by default and can be transmitted in the referer header when resources are included from other domains.
Here is my requirements:
Usable by any mobile application I'm developing
I'm developing the mobile application, therefore I can implement any securing strategies.
Cacheable using classical HTTP Cache strategy
I'm using Varnish with a very basic configuration and it works well
Not publicly available
I don't want people be able to consume my API
Solutions I think of:
Use HTTPS, but it doesn't cover the last requirements because proxying request from the application will show the API KEY used.
Is there any possibility to do this? Using something like a private/public key for example?
Which fits well with HTTP, Apache, and Varnish.
There is no way to ensure that the other end of a network link is your application. This is not a solvable problem. You can obfuscate things with certificates, keys, secrets, whatever. But all of these can be reverse-engineered by the end user because they have access to the application. It's ok to use a little obfuscation like certificates or the like, but it cannot be made secure. Your server must assume that anyone connecting to it is hostile, and behave accordingly.
It is possible to authenticate users, since they can have accounts. So you can certainly ensure that only valid users may use your service. But you cannot ensure that they only use your application. If your current architecture requires that, you must redesign. It is not solvable, and most certainly not solvable on common mobile platforms.
If you can integrate a piece of secure hardware, such as a smartcard, then it is possible to improve security in that you can be more certain that the human at the other end is actually a customer, but even that does not guarantee that your application is the one connecting to the server, only that the smartcard is available to the application that is connecting.
For more on this subject, see Secure https encryption for iPhone app to webpage.
Even though it's true there's basically no way to guarantee your API is only consumed by your clients unless you use a Hardware secure element to store the secret (which would imply you making your own phone from scratch, any external device could be used by any non official client App as well) there are some fairly effective things you can do to obscure the API. To begin with, use HTTPS, that's a given. But the key here, is to do certificate pinning in your app. Certificate pining is a technique in which you store the valid public key certificate for the HTTPS server you are trying to connect. Then on every connection, you validate that it's an HTTPS connection (don't accept downgrade attacks), and more importantly, validate that it's exactly the same certificate. This way you prevent a network device in your path to perform a man in the middle attack, thus ensuring no one is listening in in your conversation with the server. By doing this, and being a bit clever about the way you store the API's parameters general design in your application (see code obfuscation, particularly how to obfuscate string constants), you can be fairly sure you are the only one talking to your server. Of course, security is only a function of how badly does someone want to break in your stuff. Doing this doesn't prevent a experienced reverse-engineer with time to spare to try (and possibly succeed) to decompile your source code and find what it is looking for. But doing all of this will force it to look at the binary, which is a couple of orders of magnitude more difficult to do than just performing a man in the middle attack. This is famously related to the latest snap chat flurrry of leaked images. Third party clients for snapchat exist, and they were created by reverse engineering the API, by means of a sniffer looking at the traffic during a man in the middle attack. If the snapchat app developers would have been smarter, they would've pinned their certificate into their app, absolutely guaranteeing it's snapchat's server who they're talking to, and the hackers would need to inspect the binary, a much more laborious task that perhaps given the effort involved, would not have been performed.
We use HTTPS and assign authorized users a key which is sent in and validated with each request.
We also use HMAC hashing.
Good read on this HMAC:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
I know it is possible to encrypt the connection-string stored in the web.config,
And I know you could never be too safe, but since the web.config cannot be viewed or downloaded, why is it needed? in what way is it more secure?
[EDIT:] I'm not using a shared-hosting server.
If you deploy your website to a customer's web server and want to keep the credentials secret.
If someone breaks into your server, he is not able to see all sensitive information without any further work. And if you deploy your application to some "cloud" service your credentials won't be exposed to everyone maintaining the service.
Edit: Also some Administrator or users that have access to the Server won't be able read the clear text credentials.
I think you have answered your own question by saying "you could never be too safe"
The fact that web.config cannot be viewed or downloaded is not a guarantee that an attack from inside your organization could not occur. Someone with the right access could breach the security and get the data if it is visible in plain sight. While as you said, attack via Http is unlikely to get this file, others who have right access could still access through other means such as remote file access, remote desktop, etc. Encrypting + assigning proper access/authorization are making a tad more difficult for the attacker to try to break your system.
In security, you simply have to be paranoid and took every measure you think possible in order to make the data as safe as possible and it's your job giving the attacker a hard time to retrieve any information. I don't think there is such thing as 100% secure. In some sense, you would always be vulnerable to a security threat, all we could do is try to minimize it as much as possible.
Is it a huge security flaw to allow user to connect to your server via Remote Desktop? Right now i have a setup where i only allow a couple of ip-addresses to connect via the RDP port but i am thinking of removing this and allow all IP's to connect so i can RDP with my iPhone if there is some problem when I'm not at home.
So as long as i have a secure password do you guys think this is a bad idea? Is there anything else i can do to make it a bit more secure but still be able to connect from "wherever"? Is it for example possible to setup a page that i must visit that "allow anyone to login for 2 hours". Some kind of security by obscurity thingy?
Thankful for any help i can get.
Maybe you should post this question to serverfault. But anyway.
If you are using only user/password as the access method. Then it will be very easy for an attacker to lock your user ( or all users, thay don't even have to have terminal access rights ). So yes, it will be a huge security flaw. There are lots of way to protect from this treat and make rdp available from wherever. But I am not familiar with any of them.
It's very common to implement two-factor authentication for any remote access to corporate servers. In many companies you'll see the RSA tokens used as a second factor, albeit I prefer to use SMS --- it doesn't matter as long as you have two factors in play: something you know, something you have, something you are.
If your company doesn't want to implement a second factor then I still wouldn't recommend a publicly exposed RDP interface. It's open to brute force attacks, OS exploits or just plain old Denial of Service (if I blast your public interface with traffic then it will slow down legitimate machine use within your company). At a minimum I would look into tunneling over SSH, maybe with a client-side certificate authentication, or I would implement port knocking to get at the server interface in the first place.
It is a security flaw, but not so huge. Traffic is encrypted and reading user or password from it is not immediate as in text based protocols as in say ftp. It is just a little bit less secure than ssh.
It obviously has the same flaws as any other remote access (possible brute force or DOS attack). You should also use non a default account name to avoid simplifying task for attackers.
Your idea of opening access only after visiting some page is not bad either. Looks like it's a variant of the classical port knocking mechanism (but beware avoid opening a bigger hole).
I've been doing a fair bit of work with OAuth recently, and I have to say that I really like it. I like the concept, and I like how it provides a low barrier-of-entry for your users to connect up the external data to your site (or for you to provide the data apis for consumption externally). Personally, I've always balked at sites that ask me to provide my login for another website to them directly. And OAuth "valet key for the web" approach solves this nicely.
The biggest problem I (and many others) see with it though, is the standard OAuth work-flow encourages the same type of behaviors that phishing attacks use to their advantage. If you train your user that it is normal behavior to be redirected to a site to provide login credentials, then it is easy for a phishing site to exploit that normal behavior but instead redirect to their clone site where they capture your username and password.
What, if anything, have you done (or seen done) to alleviate this problem?
Do you tell the users to go and login to the providing site manually, without automatic links or redirection? (but then this increases the barrier of entry)
Do you attempt to educate your users, and if so, when and how? Any lengthy explanation of security that the user has to read also increases the barrier of entry.
What else?
I believe that OAUth and phishing they are inexorably linked, at least in OAuth's current form. There have been systems in place to prevent Phishing, most notability HTTPs (pause for laughter...), but obviously it doesn't work.
Phishing is a very successful attack against systems that require username/password combos. As long as people use usernames and password for authentication phishing will always be a problem. A better system is to use asymmetric cryptography for authentication. All modern browsers have built in support for smart cards. You can't phish a card sitting in someones wallet and hacking the user's desktop won't leak the private key. The asymmetric keypair doesn't have to be on a smartcard, but I think that it builds a stronger system than if it where purely implemented in software.
You have an account with the site you are being redirected to, shouldn't they be implementing anti-phishing measures such as a signature phrase and image? This also leverages any existing training the users have received from e.g. banks who commonly use these measures.
In general, the sign-in page should present user-friendly shared secrets to the user to confirm the identity of the site they are logging into.
As Jingle notes, a ssl certificate could be used for authentication, but in this case couldn't the user load a certificate directly from the site into their web browser as part of the OAuth setup process? If a trust relationship has already been established with the site, I'm not sure further resort to a CA is necessary.
There are some techniques that can be used to avoid or diminish phishing attacks. I made a list of cheap options:
Mutual identification resources. E.x. icon associated with a specific user shown only after user input his username.
Use of usernames not deterministic and avoid emails as usernames.
Include option to user see his login history.
QRCode that allows authentication in device pre-registered like smartphones. Like whatsapp web.
Show authentication numbers in login pages that the user can validate in the official company site.
All options listed above highly depends on user education about information security and privacy. Wizards that appears only on the first authentication can helps achieve this goal.
To extend the valet analogy: how do you know you can trust the valet, and that he/she is not just someone trying it on? You don't really: you just make that (perhaps unconscious) judgement based on context: you know the hotel, you've bene there before, you might even recognise the person to whom you're giving your key.
In the same way, when you sign in using OAuth (or OpenID), you are redirecting the user to a site/URL which should be familiar to them, seeing as they are providing their credentials from that site which is known to them.
This isn't just an OAuth problem, it's OpenID's problem as well. Worse of course with OpenID you're giving a web site your provider, it's easy to automatically scrape that site if you don't have a bogus one already and generate one which you then direct your user too.
It's lucky that nothing serious uses OpenID to authenticate - blog posts, flickr comments just aren't a juicy target.
Now OpenID are going somewhere to mitigation as they start to develop their Information Card support, where a fixed UI in the shape of client side software will provide an identity "wallet" which is secure, but MS appear to have dropped the ball themselves on Information Cards, even though it's their (open) spec.
It's not going away anytime soon.
What about to certify the oAuth provider just like the ssl certification? Only certified oAuth provider is trustworthy. But the problem is, as with ssl certification, the CA matters.