I have a web application which is developed using vb.net.
My web application uses Windows authentication mode.
Security team scanned the application and reported one issue.
Steps followed to produce the issue:
1. Type the url in browser (url - https://sample/applicationname) and press Enter
2. Analyze the response using proxy tool 'Fiddler' - which shows that authentication method in NTLM which is insecure.
Recomendations given by security team:
Change authentication method to a more secure one such as Digest, client certificates or similar. Otherwise use an encrypted channel to protect information by implementing HTTPS.
Note: HTTPS is already implemented.
Kindly let me know how to solve the issue.
Thanks in advance.
Digest is less secure than NTLM, so you may want to mock your security team. Digest uses MD5 (in a weak manner) and requires reversible passwords. If you really want to go more secure than NTLM, your may want to configure kerberos. The options vary depending on your version of IIS. Google will have your answer.
Related
I have a server with SSL certificate and would like to implement a WCF service with username authentication. Can anyone point me to a simple current example?
I find lots that use the 509 certificate and I don't understand why that additional piece would be needed. I don't think I want to give the certificate I have for the SSL to the client either.
I think to use SSL is just setting up the web.config appropriately with wshttpbinding and using https: in the uri that calls the service.
In this case I will have only one or two users (applications at the client actually) that need to use the service so I don't see the overhead for building a database for the store for lots of login credentials or anything like that. I've read you can pass the credentials in the request header. I hope I can just have the service itself check them without tons of overhead.
I'm really struggling to get how a simple authenticate can work for a service but I know I need something in addition to the service being SSL encrypted.
Edit: Hummm having read more I get the impression that using https binding for the message circumvents any notion of username credentials without something mysterious with certificates going on. I hope I haven't wasted money on the ssl certificate for the server at this point.
Can the IP of the requestor be used to allow the service for a known client only?
If you only need a couple of users, then use the inbuilt Windows authentication - create Windows user accounts, put the right security option in your binding config and you're done. If you're using SOAP from a non-windows client you'll have to perform some tricks to make it communicate properly (typically we found using NTLM authentication from PHP client required the use of curl rather than the PHP SOAP client library, but I understand that if you use AD accounts this becomes much easier).
WCF docs have a full description of auth options for you.
This is probably a dumb question but can I do away safely with just basic HTTP auth or do I still benefit from digest auth even if the server is already on SSL?
The only advantage you would gain by using HTTP Digest authentication over SSL/TLS is to prevent the disclosure of the user password to the server itself, if your sever is capable of being configured with passwords in "HA1 format" directly (i.e. if it doesn't need to know the password itself, but where the user password can be configured with MD5(username:realm:password), without requiring the password in clear, see Apache Httpd for example).
In practice, this isn't really a big advantage. There are better alternatives if protecting the password itself from the server is required (in particular because MD5 isn't considered good enough anyway nowadays).
The other features of HTTP Digest authentication (over form/HTTP Basic) are already provided by the SSL/TLS layer.
Across ssl basic auth is secure enough for most needs.
I've been searching for a bit now, but I can't find an answer. WCF Security Best Practices say to use Windows Authentication when possible. Can this provide non-repudiation and data integrity if you require signing?
(The most important question here is non-repudiation. I'm using TLS but trying to determine if I can provide non-repudiation through Windows Auth with TLS or MLS. Theoretically, the TLS provides hop-to-hop data integrity.)
Yes, for first question. Check this:
Chapter 4: WCF Security Fundamentals
Windows Authentication does not provide data signing.
Windows Authentication is preferrable and suggested by the best practice guide because it is built in all Microsoft machines. It doesn't like the certificate that requires a lot of infrastructure setup. If your machine is joined to an Active Directory domain, it should just work.
Windows Authentication is using SPNEGO to negotiate to use which authentication method, Kerberos or NTLM. Whenever possible, client and server will try to pick Kerberos first. Otherwise, NTLM will be used.
To answer your question of whether the message can be sigend or not, both Kerberos and NTLM can be used to sign and encrypt messages. As a WCF programmer, it should be transparent to you. All you need to do is to set the ProtectedLevel to EncryptAndSign. If you don't believe me, you can look at the network trace after setting up the Windows Authentication. You should see the messages are encrypted.
When using the Windows Authentication, WCF will call SSPI to do authentication and message encryption. I won't cover the detials of SSPI. Here is the SSPI call for NTLM to encrypt message and here is the SSPI call for Kerberos to encrypt message. You can set a break point in Windbg to prove that.
Although it's not explicitly stated in the above links, this link clearly states that the above mentioned EncryptMessages methods can provide data integrity (signing) and privacy (encryption).
Back to your original question about whether Windows authentication support non-repudiation, this is actually a bigger question. Data signing is necessary for non-repudiation but not sufficient. WCF is also providing the auditing feature to record operation or transaction. This is to guarantee that a user cannot deny performing an operation or initiating a transaction. So, in order to support non-repudiation, you should also set SuppressAuditFailure to false to make sure auditing is always functioning properly.
How to secure WCF service which an Android app will use?
Currently we are building an android app that will connect(by using SOAP) with a WCF service (made on another pc in console host)...
We actually want to secure this server so only people with right credentials can access the app?
How do we do this??? Do we need to use transport or message security... And can transport only use SSL or not??
And also is it better to use IIS for this or not..
Please help
Thnx
Start by configuring everything to use HTTPS (i.e., HTTP over SSL) so that your communication channels are encrypted. Then add some sort of login credential scheme so that clients authenticate to the server. The simplest is username and password. You can use Basic or Digest auth styles; both should be supported by both ends so the choice is up to you (and it's not so important which you choose since it is all inside HTTPS anyway).
All this is independent of which clients you use and which servers you use. (There's also various XML Security things that you can use with SOAP, but that's adding a lot more complexity for very little extra advantage; the big gain comes from going to HTTPS.)
I have created a REST API that uses Basic HTTP authentication. Is is restricted to SSL only. Now that it is implemented I am hearing criticisms that Basic HTTP over SSL is not secure. It would be detrimental to the project for me to "stop the press" and it would be outside the scope of some of my clients skill set to use OAuth, etc. I need to understand the risk and rewards of this methods. Any examples of big names using Basic HTTP auth would be helpful as support also.
Basic HTTP authentication over SSL is basically secure, with caveats. Security issues predominantly arise from the use of Basic auth without SSL, in which case, the username and password are exposed to a MITM. In a browser, there are also problems with expiring credentials, but this isn't so much of an issue for REST services.
perhaps I am mislead but I don't see a problem with SSL only BASIC... esp. not with a stateless API.
If the callers are forced to use a SSL-sniffing proxy then BASIC means that the password is available in cleartext to the proxy... in this specific case Digest would be better (even with SSL) because the proxy wouldn't know the password (digest means challenge response...).