This whole paragraph is incorrect. While the attribute value does allow multiple tokens there is a very specific syntax defined in the HTML standard and it doesn’t support multiple field names (types) i.e. autocomplete="username email" is invalid. If you access ‘input.autocomplete’ on an input with that attribute value “” will be returned indicating this.
I've updated the post, thank you for your help!
Nice. I didn't know about that.
[1] https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...
See also: AWS.
This!
Our new Linux login has username and password entry fields in separate (and successive) windows, and they look quite similar.
Since I enter my password much more often (to unlock) than my username, I built up a reflex of entering the password, and the rare times I have to enter my username I often type in the password instead, visible to anyone looking at the screen.
I see this new design as a security issue.
There's just nothing you can do about it if some users have passwords but other users have different authentication mechanisms.
I also have the opposite problem - sometimes I want Firefox to remember my username but not password; the only way seems to be to have it remember a dummy password (1 char so I recognise it as such) and then decline to 'update password' every time I change it in order to login.
> You definitely want to consider using these attributes if you are building a login form with the username and password on different pages.
The nice thing about using autocomplete with username and current-password is that it can help your password manager auto fill these fields across pages if they are implemented like this.
I'd say that's well supported, especially for the problem it's trying to solve (displaying the best keyboard for the input on mobile devices).
At Twilio, we have APIs for two factor authentication and we recommend implementing via push notification to the Authy app with “approve” and “deny” buttons. This is more secure and a better experience than SMS. The API also allows for regular app based 2FA, with a TOTP code, which is more secure than SMS. But it also allows you to fallback to SMS, which is still more secure than no 2FA.
You do have to consider the threat model for your own application when considering these sort of security measures. If the value of an account takeover is high then a targeted attack can, and will, break SMS 2FA. Which is why the Twilio 2FA API allows you to turn off SMS 2FA if you choose.
Ultimately I’d prefer SMS over nothing when it comes to 2FA, but I also encourage developers to use more secure options that can also have a better experience.
The article is NOT about the merits of 2FA across SMS: that discussion is happening in about 10,000 other threads on Hacker News. Please go talk about it there.
From an identity assurance perspective, SMS is the best available. From an authentication perspective, it's increasingly dodgy.
Reality is telcos have user enrollment almost on par with bank KYC, where everything else has great authN but with user asserted identity.
Critics of SMS are technically correct, but 9/10x I don't think they have had to solve identity in an open or federated environment.
Are you sure? I don't mean that to sound hostile, genuinely asking. Because, at least in the States and Canada, I can get all of the +1 numbers I want on real SIMs for around a dollar apiece--or less if I work at it instead of just trotting down to Walgreens--and attach any name I want during the sign-up flow. In point of fact, I have a vanity 212 number I've owned for years. It is currently parked on a SIM registered to the name George Crabtree (that name even shows up on CID/CNAM).
Best part? The MVNO that provisioned the SIM is using a white-label service from one of the big four. Even the ICCID prefix is from the actual carrier and not the MVNO. That means that all of the automated API checks show it as a "normal" phone number provisioned on a "regular" SIM...and owned by Constable Crabtree.
Kind of implies the engineers who build it never ever use it?
If no 2fa is active on the account, just accept anything (including empty strings) in that field.
You could obviously add some info message below or above, but people tend to be terrible at reading.
Maybe if the 2FA input field is below the login button, after some text explaining it’s function..?
I’d love to see some UX test results on this with a bunch of real users of varying tech skill levels.
Besides you can always dynamically hide (or show) the 2fa option if the email or username doesn't have 2fa enabled.
A simpler one that the pattern attribute, but more hacky-er, is using input type="tel", which I’ve also seen used for credit card number inputs.
developer.saaspass.com
I work for an IAM consultancy/reseller and work on SAASPASS implementations.
