> it's extremely unusual to see the same email address with multiple different passwords in a legitimate data breach as most systems simply won't let an address register more than once
I've actually built a system which did this years ago, over our initial protestations, and the reasoning went like this:
Our client (this was a white label product) has lots of elderly couples as customers, these are our end users and although they're on the Internet (makes sense, this is after all a web site you've white labelled so if you have customers without Internet that's a red flag right there) they only have one email address between them. So some end users want two accounts, but with one email address.
This made the login procedure a bit hairy and obviously there are scary corner cases for things like change password (Alice decides to use the same password as her husband Bob, now we can't tell their accounts apart!) but we felt that arguing with clients about why they should do Single Sign On (and thus eliminate the separate login for our white label product altogether) was more valuable than trying to change old people's minds about what constitutes a reasonable thing for two people to share.
Microsoft has their notorious "is this account personal or issued by company it department" (or something like that) question when you login. Which is the reason it very often takes two tries and several minutes to get logged in as I never seem to guess the correct answer to that question...
Extra credits for when Azure DevOps Server requires you the other kind of login compared to actual Azure, or for when you log in with one kind and the next time you access the service you are randomly switched over to the other.
Also the fact that when you ask your login to be remembered the will just show you the email at the next login, without telling you if it's the personal or work account.
It is the worst login experience Iv've ever had, bar none, I am constantly amazed how they could ship that and always wonder what hellish dungeon of reasons there must be behind the decision to keep it as it is.
I think the difference is between Microsoft online accounts where you can register an account with them using any email address and Azure AD accounts (e.g. for Office/Microsoft 365). The catch is that you can register for a Microsoft online account using an account that is also in Azure AD - so you end up with two accounts of different types with the same email address as username and (hopefully) different passwords. So hence the question asking which one of your accounts you want to log in with.
That's a confusing and annoying UI, to be sure - but for these systems, the email adress is not the identifier. The (email,account issuer) pair is the identifier.
So you can have two accounts, say for (vimslayer@contoso.com, Microsoft Account) and (vimslayer@contoso.com, Contoso AD) - and there is no collision and no possible confusion on the system end. All the confusion is on the human end.
And there is a lot of confusion on the human end :)
You can create a personal account with Azure or Microsoft more generically with your work email address, eg you@work.com. Because this was set up by you, you could conceivably change it to you@freemail.com.
However your organization may then do a deal with MS for Azure, or MSDN subscriptions, etc. And they’ll issue a login with the same email* address you@work.com — you now have two accounts tied to the same email, one which you created by yourself and one which your IT department created for you. There’s no way for you to change this second one. Typically authentication for the second one will happen via your org’s single sign on.
So the answer to “is this account personal or issued by your IT dept” really means — did you create the account yourself? Or was it provisioned for you by IT?
* Many orgs by default don’t use email to log in. Instead a “username” like jsmith is used instead. However while interfacing with Azure it seems to be a best practice to use email.
And some B2B+B2C SaaS products (Box/Dropbox/etc), when encountering this situation, only let 1 account exist. When the IT department tries to provision a conflict, instead of being provisioned, the personal account goes into an "invited to assimilate" status. The end user gets an email asking them to allow their account, which was created personally, to be converted to one managed by the enterprise admin. The user gets an opportunity, before the IT admin has control, to migrate personal data out (if they want the account converted) or change the email address to something that wouldn't conflict (if they want 2 accounts).
I've also seen it happen when a system changes its email parameters, like switching from considering the TLD to ignoring it. Suddenly john@email.com and john@email.net are sharing the same account, or have two different accounts and usernames linked to the same address.
I had a family tech support session on this exact issue last week. A relative cleared her cookies and found her saved email and password for Facebook were logging her into a profile she'd never seen before. At some point Facebook had decided name@netzero.net and name@netzero.com were the same thing. We got around the issue by logging in using her account name gleaned from someone on her friends list.
The number of websites that prevent me from doing this, because somebody wrote a shitty regex to invalidate most punctuation in an email address, is infuriatingly high.
Not really. I'm assuming the reason you'd share an email is so that you only need to be logged into one account in your mail client.
Easier to remember than a username because it's guaranteed to not be taken, so you can use the same email everywhere: email+name@provider.tld. Where as "alice" probably is taken.
Also should work with any email provider, it's part of the standard.
The only mail provider I ever heard of this working with is Google. And if you already support multiple usernames per email address, why not support using the same username for different email addresses? It's not like leaving it blank couldn't be valid, too. After all, it's the combination of email + username that is the actual DB key, just like it is with email+name@provider.tld
If the intent is to allow two people to have independent accounts even while using an email they both control, offloading that to the email protocol seems broken to me. It's the exact same email address from the perspective of security. Anything coming after the plus sign should be ignored for the DB key, but kept around for sending emails, so it can still be used for filtering those emails (for convenience, not security). So they could sign up either as
alice <couple@notgoogle.com>
bob <couple@notgoogle.com>
or as
alice <couple+alice@notgoogle.com>
bob <couple+bob@notgoogle.com>
but that difference should only ever matter for their email filtering, not for identifying them.
They do. I used that "feature" by accident recently. I think one of the accounts was a shopping account, the other started as an AWS account. Both accounts have the same name, same billing address, same credit card.
I think the logical next step is to give them the same password and see how bad my foot hurts afterwsrd.
I did this in the past. Aparently I forgot I had an account, setup a new one, then found my older account, after some email migrations, they ended up on the same email with the same password. I think it was pretty consistent about which account I logged into, but changing the email (or the password, I guess) of that account let me access the otherwise hidden account. They still have no merge feature, but at least they let you change your email address, unlike some sites.
I've actually built a system which did this years ago, over our initial protestations, and the reasoning went like this:
Our client (this was a white label product) has lots of elderly couples as customers, these are our end users and although they're on the Internet (makes sense, this is after all a web site you've white labelled so if you have customers without Internet that's a red flag right there) they only have one email address between them. So some end users want two accounts, but with one email address.
This made the login procedure a bit hairy and obviously there are scary corner cases for things like change password (Alice decides to use the same password as her husband Bob, now we can't tell their accounts apart!) but we felt that arguing with clients about why they should do Single Sign On (and thus eliminate the separate login for our white label product altogether) was more valuable than trying to change old people's minds about what constitutes a reasonable thing for two people to share.