5 ms·

Once they enter their login, couldn't you check if it's a delegated login, and hide/replace the password field before they start to enter it? (i.e. replace it

Once they enter their login, couldn't you check if it's a delegated login, and hide/replace the password field before they start to enter it? (i.e. replace it with a div saying "you will be redirected to your corporate login page to complete authentication" to avoid the "without any hint" issue)

lazyasciiart 7y ago
Yes, they could. I can't remember where I've seen that - maybe okta or oneLogin?
- basch 7y ago
  Option 2 in the article
  - isostatic 7y ago
    Not quite. That still has the field open, which could still be filled in. The ajax call could blank the field (even if it's been filled in already), preventing the password from leaving the browser even accidentally.
    - basch 7y ago
      "dont send password to server if sso radio box is checked"
deleted 7y ago
[deleted]
ViViDboarder 7y ago
They show an example of that in the article.
- isostatic 7y ago
  Not with the blanking (to prevent password leakage)
tomp 7y ago
Probably the solution is the other way around. Start with a password field, but keep it hidden - that way, password managers can autocomplete it (and submit the form with username & password immediately), but humans won't see it, so won't be entering passwords from different sites...
- cheerlessbog 7y ago
  If it's not a password my code should see, I would rather it not be entered into even my client side code. That makes it potentially accessible should I have a bug, eg XSS.
jimm 7y ago
Yes, but if they did they are giving away security information: they are acknowledging that the entered email address is a legit delegated login. That's a bad thing to do, security-wise. You don't want bad guys to start trying email addresses and be able to see which ones are good email addresses.
- dmurray 7y ago
  The bad guys can do exactly the same in the workflow where you redirect them rather than update the page.
Someone1234 7y ago
This doesn't play nicely with password managers. They instantly populate both fields, and then you hide/replace one of the populated fields.
tracker1 7y ago
This really borks in terms of accessibility, as the huge change as a result of an onblur event will be awkward. Also, it will require JS to do so, so simple post is no longer an option. Of course the system I'm working on won't work without JS and a modern browser anyway.
- stcredzero 7y ago
  What if password fields had a "bitbucket" mode where they swallowed all input and overwrote it with "xxxxxxxxxxx"? Then instead of "a huge change" from an onblur event, when the email is checked for login type, conventional username/password users just have their password field turn off bitbucket mode. No one reveals their password to the provider. Everyone is happy -- but only in this hypothetical future world where browsers have this new functionality.
  - tracker1 7y ago
    You're forgetting the SSO use case.
    - stcredzero 7y ago
      How? In that case, some people come along and manage to enter their password, perhaps because they didn't enter their login or email first. The bitbucket entry field soaks the information up, and it's never revealed. Most of the time, when they enter the login, the password field can disappear in that case. Or is there something I'm missing?
      - tracker1 7y ago
        "Why do I have to enter my password twice?"
hirsin 7y ago
We (Microsoft) did that for a while. It doesn't work as well as the paginated flow. Users without a password get to the page and leave, claiming they don't have a password and are stuck, because they don't try to type in their email.
- azundo 7y ago
  What if it worked the other way and the password field was revealed when required vs hidden when not?
  - hirsin 7y ago
    As others have mentioned, this isn't great for accessibility. And most password managers would be smart to ignore hidden password fields, since that's a decent attack vector for skimming.
tbrownaw 7y ago
Here's a really fun edge case: My federated (AAD) login for msft work things (Azure portal, O365, some VSTS) is <username>@<company>.com. My non-federated login for other msft work things (down to a couple old VSTS accounts that aren't migrated yet) is <first.last>@<company>.com. So when I enter my username for non-federated things, it has to ask me whether to forward to AAD or prompt for a password. Because my login ID looks like it should be federated, but doesn't actually exist in their upstream.

lazyasciiart 7y ago

Yes, they could. I can't remember where I've seen that - maybe okta or oneLogin?

basch 7y ago
Option 2 in the article
- isostatic 7y ago
  Not quite. That still has the field open, which could still be filled in. The ajax call could blank the field (even if it's been filled in already), preventing the password from leaving the browser even accidentally.
  - basch 7y ago
    "dont send password to server if sso radio box is checked"

deleted 7y ago

[deleted]

ViViDboarder 7y ago

They show an example of that in the article.

isostatic 7y ago
Not with the blanking (to prevent password leakage)

tomp 7y ago

Probably the solution is the other way around. Start with a password field, but keep it hidden - that way, password managers can autocomplete it (and submit the form with username & password immediately), but humans won't see it, so won't be entering passwords from different sites...

cheerlessbog 7y ago
If it's not a password my code should see, I would rather it not be entered into even my client side code. That makes it potentially accessible should I have a bug, eg XSS.

jimm 7y ago

Yes, but if they did they are giving away security information: they are acknowledging that the entered email address is a legit delegated login. That's a bad thing to do, security-wise. You don't want bad guys to start trying email addresses and be able to see which ones are good email addresses.

dmurray 7y ago
The bad guys can do exactly the same in the workflow where you redirect them rather than update the page.

Someone1234 7y ago

This doesn't play nicely with password managers. They instantly populate both fields, and then you hide/replace one of the populated fields.

tracker1 7y ago

This really borks in terms of accessibility, as the huge change as a result of an onblur event will be awkward. Also, it will require JS to do so, so simple post is no longer an option. Of course the system I'm working on won't work without JS and a modern browser anyway.

stcredzero 7y ago
What if password fields had a "bitbucket" mode where they swallowed all input and overwrote it with "xxxxxxxxxxx"? Then instead of "a huge change" from an onblur event, when the email is checked for login type, conventional username/password users just have their password field turn off bitbucket mode. No one reveals their password to the provider. Everyone is happy -- but only in this hypothetical future world where browsers have this new functionality.
- tracker1 7y ago
  You're forgetting the SSO use case.
  - stcredzero 7y ago
    How? In that case, some people come along and manage to enter their password, perhaps because they didn't enter their login or email first. The bitbucket entry field soaks the information up, and it's never revealed. Most of the time, when they enter the login, the password field can disappear in that case. Or is there something I'm missing?
    - tracker1 7y ago
      "Why do I have to enter my password twice?"

hirsin 7y ago

We (Microsoft) did that for a while. It doesn't work as well as the paginated flow. Users without a password get to the page and leave, claiming they don't have a password and are stuck, because they don't try to type in their email.

azundo 7y ago
What if it worked the other way and the password field was revealed when required vs hidden when not?
- hirsin 7y ago
  As others have mentioned, this isn't great for accessibility. And most password managers would be smart to ignore hidden password fields, since that's a decent attack vector for skimming.

tbrownaw 7y ago

Here's a really fun edge case: My federated (AAD) login for msft work things (Azure portal, O365, some VSTS) is <username>@<company>.com. My non-federated login for other msft work things (down to a couple old VSTS accounts that aren't migrated yet) is <first.last>@<company>.com. So when I enter my username for non-federated things, it has to ask me whether to forward to AAD or prompt for a password. Because my login ID looks like it should be federated, but doesn't actually exist in their upstream.