Hacker News Reader

Comment by isostatic | Hacker News Reader

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)

View on HN

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.

What if it worked the other way and the password field was revealed when required vs hidden when not?

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.

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.

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.

You're forgetting the SSO use case.

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?

"Why do I have to enter my password twice?"

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...

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.

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

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.

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

Option 2 in the article

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.

"dont send password to server if sso radio box is checked"

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.

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

They show an example of that in the article.

Not with the blanking (to prevent password leakage)

Reply on news.ycombinator.com