2

I'm involved in the development of a SaaS application. We host the application for different customers. A customer is a company. Each customer gets access to their hosted instance of the application via a URL https://example.com/customername.

We already got one instance where a customer tried different other companies (potentially competitors) for the customername in order to see if someone else is using our product as well. I personally don't think this is too much of an issue but I recognize that it could both be a problem for some potential customers as well as a security issue so I'm interested in mitigation strategies.

Possible solutions so far are

  • Add an unguessable string to the customername: https://example.com/acmeinc-8a4f. I think this a) looks ugly (and yes, we already got a customer who insisted on a particular spelling in the URL for CI reasons) and b) absolutely requires all users to have a bookmark or remember one more mostly irrelevant thing.
  • Just show a login form regardless of what's used as the customername and just reject any user/password combination. This looks promising at first but already we are implementing different login mechanisms including password-less login via SSO so customers will get different login screens. This also prevents a version of a login screen where the customer name becomes part of the user/password form. I'm sure sooner or later the login screen will have to match a customer's CI as well.

Is it even possible to mitigate this problem in a user-friendly way?

  • Why dont you just use example.com, without customername for initial login, and then redirect the user based on the login credentials? – Michael Feb 21 '15 at 17:04
  • Two reasons: User databases are distinct for security and legal reasons and logins are not guaranteed to be unique. – musiKk Feb 21 '15 at 17:10
  • What is "CI" in this context? – Bill Weiss Feb 22 '15 at 4:15
1

Adding a hard to guess string would only be security through obscurity (but somewhat effective in this instance to protect against enumeration).

You can state the security / convenience tradeoff (when using /customername) in your Terms & Conditions

You can also ask the customer to make a choice (when signing up or registering).

  • With the default option (using customername in the URL), anybody (including competitors) can easily go to the same URL and thus confirm that they are using your service.

  • If they wish to hide the fact that they are using your service, they must use an obfuscated URL (which would essentially serve as secret for that customer).

Before you implement the above, it would be useful to find out if your customers really care about it.

My guess is that they couldn't care less and the above choice would just be a source of confusion (depending on who does the actual signup at that company).

Your goal is to keep the process as simple as possible.

A better way perhaps, is to state the potential issue in your T&C and the customer can request to have their access URL obfuscated.

If they care about security, they will be reading the terms.

  • 1. I disagree that it is security by obscurity because we'd rely on a (shared) secret. 2. Customers are very weird. I heard of companies that didn't get—say—Volkswagen as a customer because they already had Mercedes (just an arbitrary example). I will propose your solution to management, though. Maybe this is really a solution to a non-existent problem. – musiKk Feb 21 '15 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.