I would like to deploy my great new ASP.Net app to my internet facing web server. I would like to use windows authenticaion over the internet, so that I.E. automatically prompts for windows login credentials. I want to make sure it is adequately secure.
Some parameters around this are:
- I do not wish to implement SSL at this stage.
- We only have one server to authenticate to.
I’ve read a lot about man in the middle attacks redirecting authentication information to a third party server, but in my case there is only one server – the one they are logging on to. - I’ve been reading about IIS Windows Authentication Extended Protection, but I’m still uncertain of it’s benefits
So basically if I enable IIS Windows Authentication Extended Protection, and I can be certain no one gets phished, can I be pretty certain that this is going to be secure?
Our server regularly suffers attacks – I think a few mistakes in the early days have got it on to an ‘easy target’ list.
Basically, no. WindowsAuthentication(blargh) only works for authentication stage. That is, it replaces HTTP-Basic-Auth for your website and is responsible for checking whether the user’s so called login-password is valid and acceptable. Of course it is not about password. That’s just example for simplicity.
So long, this part may be considered safe. However, after the user finishes the logon part, he is bounced to the target webpage, the webpage now knows his identity and thanks to the Windows-blargh the website knows it has not been cheated, but afterwards now the user just uses the page.
And how does he do it? As you “don’t have SSL implemented at this stage”, he uses plain HTTP to browse the site. This means that everything is now sent in plaintext and that it is quite easy to peek over or to inject/modify something. As long as you use only HTTP, you are “open” to some forms of attacks, as the HTTP does not provide any forms of securing the communication. This is why most sites that need some security are made available through HTTPS, thus, SSL.
SSL is nothing hard to implement. For the most basic uses, the only thing you need to do is to check few checkboxes in the IIS configuration, and sometimes you also need to generate your own certificate. For free. Takes ~5 minutes max and you have SSL up and running, and noone peeks and noone injects. [of course unless they break the key, but that takes time and determination..]
Note: I say WindowsAuthentication-blargh, because the ExtendedProtection thing is only related to WindowsAuthentication process that precedes the actual use of the page. “Old” WindowsAuthentication was relatively unsafe, so it has been fixed with additional security means to thwart some forms of attacks. You may assume that wih WA+EP it is now less probable that someone else logs-in as you. However, it does not protect your page contents. WA never did that, so WA+EP does not either.
That’s the basics of the subject. Please however note that I’m no expert at Windows-Authentication-blargh. If enabling that feature in fact turns on some secret IIS module that sends some PGP-hashes in the website headers that cause InternetExplorer to turn on some other secret module that reads those hashes and starts to verify the web page contents – well, awesome, we have a bit of protection in plain HTTP. It’d work on IE only anyways. But I very doubt. I’m almost sure that Win-Auth is only about the auth phase, not about connection security.