4 ms·

In this age of single-page web apps, it's preposterous to suggest that one needs to navigate to a second page to do something as simple as entering one's passwo

by kijin 7y ago

In this age of single-page web apps, it's preposterous to suggest that one needs to navigate to a second page to do something as simple as entering one's password -- regardless of what's happening under the hood. Add some AJAX to that damn thing. You don't need to pull off a microsoft and redirect without notice. It can be as simple as hiding the password field and showing a button for the 3rd party auth provider instead as soon as the user enters their email. Payment forms have perfected this kind of technology a long time ago; they can rearrange the form to suit the card type as soon as you enter the first few digits of your CC number. There's no reason login needs to be any more clunky.

goguy 7y ago
Isn't that all done on the client? Soon as you require a HTTP response on potentially a slow connection it's no longer instant and a poor user experience.
- kijin 7y ago
  The default should be to show the password input for normal users. Chances are, most corporate users are 1) using a fast connection paid for by their employer and/or 2) used to shitty stuttering UI, so it will be less of a problem if it takes a couple of seconds to load their 3rd party auth provider. If the number of auth providers are small and tied to specific domains in the email address, perhaps you could speed up the process by pre-loading a hash table of domains => auth providers.
jkaplowitz 7y ago
As another commenter said, that solution leaks security information - it says "this domain is a customer of ours and is configured to use a special authentication setup." Some big and lucrative customers will object to this leakage. Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. An AJAX solution can still be the right tradeoff of user experience vs security for some sites, and the article gave a couple of examples of major sites that have followed your suggestion. But the security downsides mean it's not right for every case.
- kijin 7y ago
  That information is leaking anyway. Besides, a smart attacker ain't waiting for page loads, he's got scripts. It's all security theater. If a corporate customer insists on objecting, maybe you could charge them $$$ to add a special case for their domain.
- isostatic 7y ago
  > Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. You could rate limit based on IP, or even in the javascript, if you're that concerned -- .onblur sends the request, which typically responds quickly with a "password not needed" flag. You're just trying to stop casual snoopers, as for scripts it's not much different to sending the request as part of the entire form (and seeing if the response is a page or a redirect)
- tracker1 7y ago
  Agreed... My plan is to wait 1/2 second before processing any login, and add a bit more for failed attempts before lockout. Random amount of time between windows. I've thought about doing a client-side challenge token and subtlecrypto to pbkdf2 that to generate a key, then sign the login request with the generated key. I could use a pool of precomputed keys on the server and associate the key source sent via http-only cookie for the key's id in the DB. Unfortunately still have to support the non-chrome edge browser which seems to have some gaps in browser crypto support.
hirsin 7y ago
Many corporate clients don't want you passing their users passwords through your backend, so full page navigation is required. You're also working with on-premises Auth servers that likely don't support whatever fancy front channel protocol you'd propose to make this happen.
- kijin 7y ago
  There is no correlation between "full page navigation" and "not passing users' passwords around". Full page navigation is only needed for on-premises auth servers that require a redirect, and the server can easily tell which users need it as soon as the username is typed in. Give them the redirect they want. Everyone else gets a better UX.
  - hirsin 7y ago
    Ah, yes, figure out which ux the user needs before they tell you who they are. Please, let me know if your genie is for rent. Otherwise, see other comments for how the detection ux with a default password entry caused issues for us.

by kijin 7y ago

goguy 7y ago

Isn't that all done on the client? Soon as you require a HTTP response on potentially a slow connection it's no longer instant and a poor user experience.

kijin 7y ago
The default should be to show the password input for normal users. Chances are, most corporate users are 1) using a fast connection paid for by their employer and/or 2) used to shitty stuttering UI, so it will be less of a problem if it takes a couple of seconds to load their 3rd party auth provider. If the number of auth providers are small and tied to specific domains in the email address, perhaps you could speed up the process by pre-loading a hash table of domains => auth providers.

jkaplowitz 7y ago

As another commenter said, that solution leaks security information - it says "this domain is a customer of ours and is configured to use a special authentication setup." Some big and lucrative customers will object to this leakage. Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. An AJAX solution can still be the right tradeoff of user experience vs security for some sites, and the article gave a couple of examples of major sites that have followed your suggestion. But the security downsides mean it's not right for every case.

kijin 7y ago
That information is leaking anyway. Besides, a smart attacker ain't waiting for page loads, he's got scripts. It's all security theater. If a corporate customer insists on objecting, maybe you could charge them $$$ to add a special case for their domain.
isostatic 7y ago
> Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. You could rate limit based on IP, or even in the javascript, if you're that concerned -- .onblur sends the request, which typically responds quickly with a "password not needed" flag. You're just trying to stop casual snoopers, as for scripts it's not much different to sending the request as part of the entire form (and seeing if the response is a page or a redirect)
tracker1 7y ago
Agreed... My plan is to wait 1/2 second before processing any login, and add a bit more for failed attempts before lockout. Random amount of time between windows. I've thought about doing a client-side challenge token and subtlecrypto to pbkdf2 that to generate a key, then sign the login request with the generated key. I could use a pool of precomputed keys on the server and associate the key source sent via http-only cookie for the key's id in the DB. Unfortunately still have to support the non-chrome edge browser which seems to have some gaps in browser crypto support.

hirsin 7y ago

Many corporate clients don't want you passing their users passwords through your backend, so full page navigation is required. You're also working with on-premises Auth servers that likely don't support whatever fancy front channel protocol you'd propose to make this happen.

kijin 7y ago
There is no correlation between "full page navigation" and "not passing users' passwords around". Full page navigation is only needed for on-premises auth servers that require a redirect, and the server can easily tell which users need it as soon as the username is typed in. Give them the redirect they want. Everyone else gets a better UX.
- hirsin 7y ago
  Ah, yes, figure out which ux the user needs before they tell you who they are. Please, let me know if your genie is for rent. Otherwise, see other comments for how the detection ux with a default password entry caused issues for us.