tags:

views:

90

answers:

1

Referencing this question asked in this forum about URL Design for SSL-Secured SaaS Applications, and assuming Option C is used, whereby each account has unique subdirectory under Common Domain Name; the question is: for a SaaS application that deals with highly sensitive data (banking or medical records application) which is a better approach to designing an entry point to a client's sign-in page for a particular company:

  1. Use a unique logical and keyable URL, for example for a company named ABC: https://saas.foobar.com/abc
  2. Use a more cryptic url that relies on a company key as a URL parameter, for example: https://saas.foobar.com/login?companykey="232323355AAc"
  3. Design the system to allow access using both above approaches, and allow the client to choose an approach that is consistent with the level of risk based on their own corporate security polices.

The trade-off using approach one verses approach two is simplicity over security. Additionally, is using approach one acceptable given that a guessed URL is potentially one less hoop a hacker has to jump through to gain access, and is possibly more vulnerable to social engineering practices?

A: 

You can offer a global login page that redirects users after authentication to the readable URL-path variant (something humans can read looks at least more trustworthy) - but always block access to the URL-path variant for requests without a valid session.

So you don't have to invest energy into some security to obscurity. You may think about additionally placing a web application firewall in front of your to-be-secured URLs.

(The companykey method btw. would have to be distributed somehow, via mail? It will be bookmarked and can't be easily remembered.)

initall
The problem with a global login page, is that the direction for this app is to allow userid's to be unique for a company, and not globaly within the system, so the company needs to be identified before allowing a sign-in page to be displayed. As far as distributing the URL in the case of compkey, two approaches: send it via email, or assume company will provide link on Intranet portal (if one exists). The fact that compkey is not easily remembered can be viewed as a level of security that really goes to the crux of this question.
Bill Griffith
A company I know does the very same and only asks the users to add their company identifier in front of their UID with a delimiter, like "`COMPANY/12345`". After that, redirecting is no problem. Note that if something is not easily remembered, it is put under the keyboard, written down on a sheet of paper next to the desk and so on. By using a web app firewall or a proxy you can return information hiding results or http stati of any kind back to the requesting unauthorized client.
initall
Your suggestion to prefix the userid with company is a good one, however, as part of the design, the sign-in page provides company specific information, so the global sign-in page has to be ruled out. Your point of writing complex URL's down is also a consideration worth noting. However, I'm not clear how a web app firewall or proxy can be applied to this design, can you point me to a case study or a white paper on this? Thanks.
Bill Griffith
Ok, there are quite a many. Here is one I worked with: http://www.artofdefence.com/dokumente/hyperguard_en.pdf For almost every request you can define rules or actions, mask your own session management with a cryptographically reliable one and so on. Haproxy http://haproxy.1wt.eu/ lets you define regexp-based header-control.
initall