2

I am interested in the intersection of account enumeration and single sign-on. Often, there will be SSO-only and non-SSO users alongside each other in an application, and in terms of improved usability the SSO users will need to be redirected to their specific login portal.

One example I have found is with Office365 redirecting based on the domain name of your email address. Whilst no particular usernames are leaked, an attacker is now aware that a particular company uses Office365, and can narrow their searches.

For example:

  1. Go to https://login.microsoftonline.com/
  2. Enter one of the folllowing email addresses-
    • "abcd@microsoft.com"
    • "abcd@exxonmobil.com"
    • "abcd@walmart.com"

Expected: Microsoft and Exxon email address redirect to their login portals, Walmart email address stays with default login.

My questions:

  • How could this information leaking be avoided?
  • This redirection is at the domain level. If you had SSO-only and non-SSO users with the same domain (e.g. bob@microsoft.com and bill@microsoft.com have different login pages), how can you balance usability with security against account enumeration?
Spongeboy
  • 151
  • 3
  • It looks like this is a feature that Microsoft offer, that enables organisations to allow SSO users to login to a custom homepage by syncing their internal domain AD, with their azure management portal. Not only does it look like a option, but a premium option. I would guess the easiest way to avoid it, it by not enabling the feature. If you look at the link at the bottom, you will see an example of this using the microsoft training domain 'contoso.com'. http://azure.microsoft.com/en-gb/services/active-directory/ https://login.microsoftonline-int.com/?whr=contoso.com – TheJulyPlot Aug 24 '15 at 08:11
  • 1
    Just add, in terms of usability, they could just use the standard login page? Other than having a vanity login would it make any difference to the end users? – TheJulyPlot Aug 24 '15 at 08:19
  • @thejulyploy - The standard login page would not work, as with the SSO pattern, the website does not know the user's password, and instead defers this to the authentication provider (in Office365, this would be a company active directory). I guess it should be possible for the website to pass the password onto the provider in a back channel, but the implementations i've seen do not allow for this. – Spongeboy Aug 24 '15 at 12:21

0 Answers0