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.
Related
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.
I ask this because I work on an application where the X-AUTH-TOKEN can be copied from one request to another and impersonate another person. This makes me nervous, but I'm told since we're going to use HTTPS we don't have to worry about anything.
So, my question is: Is it good enough trust SSL to protect against stealing headers used for auth/sessions?
Thanks,
Using HTTPS encryption will indeed prevent someone from stealing your authentication token if they can intercept the traffic. It won't necessarily prevent a man-in-the-middle attack though unless the client enables peer certificate checking.
This question from the security stackexchange describes how to implement MITM attacks against SSL. If I can convince a client running HTTPS to connect to my server, and they accept my certificate then I can steal your authentication token and re-use it. Peer certificate validation is sometimes a bit of a pain to setup but it can give you a higher chance of whomever you are connecting to are who they say that are.
"Good enough" is a relative definition and depends on your level of paranoia. Personally I would be happy that my connection is secure enough with HTTPS and peer certificate validation turned on.
Presumably also your authentication token times out so the attack window would be time limited. For example the OpenStack authentication token is by default valid for 24 hours before it expires and then you are required to obtain a new one.
The HTTPS standard implements HTTP entirely on top of SSL/TLS. Because of this, practically everything except for the DNS query is encrypted. Since headers are part of the request and response, and only sent after the secure-channel has been created, they are precisely as secure as the implementation of HTTPS on the given server.
HTTPS is an end-to-end encryption of the entire HTTP session, including the headers, so on the face of it, you should be safe from eavesdropping.
However, that is only part of the story: depending on how the clients are actually connecting (is this a website or an API service?), it may still be possible to trick them into sending the data to the wrong place, for instance:
Presenting a "man in the middle" site with an invalid SSL certificate (since it won't be from a trusted authority, or won't be for the right domain) but convincing users to by-pass this check. Modern browsers make a big fuss about this kind of thing, but libraries for connecting to APIs might not.
Presenting a different site / service end-point at a slightly different URL, with a valid SSL certificate, harvesting authentication tokens, and using them to connect to the real service.
Harvesting the token inside the client application, before it is sent over HTTPS.
No one approach to security is ever sufficient to prevent all attacks. The main consideration should be the trade-off between how complex additional measures would be to implement vs the damage that could be done if an attacker exploited you not doing them.
I am asking myself. What is the best way to send personal information from your iOS device to the server.
At this moment I encrypt the password in the app ( sha1 salt password pepper ) then I send post data using from iOS to the server.
What is the best way to protect the user and secure for any MITM attacks. Is my way secure enough?
UPDATE:
I added the SSL certificate. To make sure the user only has to login once I store a key generated when the user registered. I fetch them when the user logins for the first time. In oombination with the username and user id. Is this a good way? Only jailbroken users can read it and have risk.
Hashing the password on the client side will help prevent the password itself from being detected in eavesdropping, but it really doesn't provide any security on its own, as the credential then becomes the hashed version of the password, not the original password itself. An eavesdropper could just grab the hashed version, and then send the hash themselves.
By far the easiest solution is to simply use SSL/TLS. Since you mentioned 'post', that means you're probably using HTTP. Instead, you could just connect via HTTPS and post the data, exactly the same as you're doing already. Long as the certificate is checked for validity (I believe the iOS framework already does such by default), then the connection should be largely secured.
That should be good enough for most situations. There are some more complicated and involved techniques you can use to harden further, but SSL/TLS does a massive amount on its own.
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...).
I'm looking for an existing HTTP protocol for securing authentication but not the payload that follows. I want the server to store the username, hashed password and different salt per user.
HTTP Digest Authentication fails these requirements because all accounts use the same salt. SSL fails because it encrypts the entire connection.
Edited to add:
This is for a desktop client talking to a web service (no browser involved)
The popular scheme is to have login form protected by SSL, while rest of the site doesn't use SSL. See for example popular social networking sites.
Why not just have your authentication mechanism protected by SSL and then forward to the rest of your application which runs under normal HTTP?
How about OpenID? Is there a reason that you have to store authentication information?
Edited to add
Sorry didn't catch that it was a desktop app. How about OAuth?
Is there a way that you could structure the original request URL to indicate the user? Then, the server could respond with a different different realm (acting as "salt") for every user in the HTTP digest authentication response. For example, request URLs of the form http://user.y.com/service or http://www.y.com/user/service would result in a challenge response like:
WWW-Authenticate: Digest realm="user#y.com", nonce="oqa9hvq49krprkphtqc"
Can you explain what's driving the "no encryption" mandate? If you are subject to man-in-the-middle attacks, you need to protect the integrity of the entire request. There, SSL would be very helpful. If you absolutely cannot have encryption, would SSL using an unencrypted cipher suite be acceptable?