BlackBerry Forums Support Community

BlackBerry Forums Support Community (http://www.blackberryforums.com/)
-   BES Admin Corner (http://www.blackberryforums.com/bes-admin-corner/)
-   -   Security risk with enabling "Support HTTP Authentication"? (http://www.blackberryforums.com/bes-admin-corner/134803-security-risk-enabling-support-http-authentication.html)

imercado 06-12-2008 11:40 AM

Security risk with enabling "Support HTTP Authentication"?
 
I am in discussion with my BES admin about enabling the "Support HTTP Authentication" flag so we can access data on our sharepoint sites that need to authenticate us with our domain ids. However, he believes that there is a security risk associated with this, stated as follows:

"there is a security risk involved with including domain credentials within http headers"

"When you include domain credentials in the http headers it can be read by any browser. So for example now your pin information is passed to any site you go to via http headers."

Based on the collective wisdom of this group, is there general agreement that indeed a security exposure is enlarged by enabling BES's support for HTTP authentication? I certainly don't want to expose our organization to any security concerns, however, I would have thought that the BES infrastructure would have done a good job of masking credentials that are passed to it via HTTP authentication so that this would not be a concern.

Thanks!

Ian

T-Roy 06-15-2008 10:01 PM

It will depend on the support authentication type by the web server. If the web server only supports BASIC authentication, the BES will be more than happy to send along Base64 encoded version of the users supplied username and password. This is no different than any desktop web browser. It is important to note that this is considered secure only in event that the session is secured by encryption (such as SSL).

The MDS Connection Service also supports other, secure means of authentication without the use of SSL (again, just like a typical desktop web browser), including Kerberos and NTLM (which you would be using most likely for Integrated Windows Authentication with Internet Explorer and Sharepoint).

NTLM - Wikipedia, the free encyclopedia
Kerberos (protocol) - Wikipedia, the free encyclopedia

imercado 06-23-2008 08:30 AM

Thanks. So if I am to understand this correctly, security when having Support HTTP Authentication enabled is no different between the blackberry and the web server than it is when my desktop browser is connecting to the web server.

So to pick a particular "for instance", I know we have Windows Authentication enabled that will send our domain userid and password to an HTTP server (NOT HTTPS) that we use for several commonly used activities. Is there any ADDITIONAL exposure that's created by having this authentication occur from the Blackberry device that would exist in addition to the exposure that currently exists authenticating from my desktop web browser to the HTTP server?

I'm drawing a rough model to help clarify what the potential concern is:

Normal (no Blackberry) Browser:
Browser <-> HTTP Server (supporting windows authentication)

Blackberry Browser:
BB Browser <-> MDS Server <-> HTTP Server (supporting windows authentication)

In the "normal browser" instance, it seems we have an issue with weak encoding of domain passwords between the web browser and the HTTP server. In the "blackberry browser" instance, it seems we have the same between the MDS server and the HTTP server, however, we also have the added ability for some weak security between the BB browser and the MDS server. However, I am under the impression that security between BB Browser and MDS Server is pretty tight and should present no additional concern.

Seems to me if the security risks are identical to those that we currently have between our desktop browsers and our HTTP servers, that there shouldn't be any additional security concern about enabling Support HTTP Authentication on the BES server. I want to be sure I have the facts straight before proposing changes to our server administration group, though.

Thanks!

imercado 06-30-2008 08:11 AM

> Is there any ADDITIONAL exposure that's created by having HTTP
> authentication occur from the Blackberry device
> beyond the exposure that currently exists when I authenticate from my
> desktop web browser to the HTTP server?

Just bumping this question again since it's pretty important. I'm hoping that somebody who understands better than me the security model around BES and MDS server will answer. Thanks!

kjarrodc 07-13-2008 02:31 PM

Let's see if I can assist here. First of all, let's start from considering the desktop browser and the webserver.

IIS is configured for "windows authentication" and http: This limits your browser support to IE. If you try to access the site with firefox, or any other browser that is not native to windows, 'windows authentication' cannot be supported.

From what I understand in this configuration, the credentials are encoded - NOT encrypted. So, if one were to access your intranet and intercept the packets, your windows credentials could be compromised. Though, I don't think it could be done as easily with 'basic authentication' configured. If I recall correctly, the credentials are not in the HTTP header with the IIS server configured this way.


IIS is configured for "basic authenticaion" and http: This will allow support for the blackberry browser and firefox.

There's a plugin for firefox called live headers. The credentials are in the HTTP headers and one can actually see the credentials being passed in encoded format.


So in either circumstance, your credentials are exposed because they're not encrypted. As a general practice, our (government - read: goes to ridiculous lengths to secure things...) organization states that if a website requires authentication ( whether it be 'basic' or 'windows' ), HTTPS (SSL) is mandatory. As such, we configure our IIS servers to be 'basic' authentication configured with HTTPS so that other browsers like firefox, blackberry browser, safari, etc ... can authenticate with the site.


Now - let's talk about the blackberry browser accessing your intranet sites. I don't think they're currently working because 'windows authentication' is turned on. If you turned on basic authentication, you should be prompted for your domain credentials and get access to the site.

I'm running an internal mobile version of a website for our organization that requires authentication and basic authentication with HTTPS is working without any problems. Support HTTP Authentication is turned off. Though, I've recently been investigating what exactly this setting does. From what I understand, if this setting is turned off, then the blackberry device authenticates with the IIS server directly. If it's turned on then the MDS service will authenticate on behalf of the device.

The Administration guide states the followin when configuring the "Support Http Authentication" setting:

If you want BlackBerry devices to authenticate with content servers directly, click False.

If you want the BlackBerry MDS Connection Service to store authentication information and perform HTTP
authentication on behalf of BlackBerry devices, click True.


To answer your question directly, I don't think enabling "Support HTTP Authentication" would expose any additional security risk. But, my guess is changing this setting to 'true' will not ultimately solve your problem.

I'm investigating this setting because my hope is to turn on single sign on for the BlackBerry browser. I would like the blackberry users to visit my site without having to type in their domain credentials more than once. I have not tested this yet, but am hoping to this week.

Hope this helps ...

Frank Castle 07-14-2008 08:26 AM

MDS traffic shares the same Triple DES/AES encryption as an email so the likelyhood of anything being read is remote. Your biggest concern is how long your password policy waits before auto-lock if security is a big issue.


All times are GMT -5. The time now is 09:17 AM.

Powered by vBulletin® Version 3.6.12
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.