> You can use more than one autocomplete value at a time too. If your username is also an email address you can give the browser and any associated password managers a hint with ‘autocomplete="username email"’.
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.
What this write up on 2fa is missing is that rather than using proprietary solutions like authy, we should be moving towards what we’ve now standardised as webauthn. If we had platform authenticators or we had a google/apple first party implementation of something like Krypton, we would be in such a better place security wise.
While Twilio does a lot right, they still only offer SMS and their own proprietary Authy solution for 2FA for their website. No TOTP (and still no plan to offer the industry standard) means that this has a whiff of hypocrisy.
Perhaps, but you still cannot use this to authenticate to Twilio itself. Twilio requires either using unsafe SMS or some version of EEE[1] in their console.
The argument then goes back to, why pick up an external dependency and cost for open standard authenticator when you could just include a library and generate it yourself.
This allows a developer to have all the benefit of the Authy API, including enhancing the experience using push authentication or dropping back to SMS if needed, as well as allowing users to use an authenticator app of their choice. It's the best of all worlds in this case.
But if building and maintaining app based TOTP using a library is good enough for you, then go for it. I'm certainly not going to make you use Twilio's APIs, but plenty of businesses do see the benefit.
Twilio seems to have some great engineers and I'm often impressed by the quality of their technical writing, but you'd never know it from their console horrowshow UX.
These are all super nice and I really wish more developers made use of these, but my main complain is not having username and password fields on the same page :/
>my main complain is not having username and password fields on the same page :/
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.
Of course there is, it can be on the same page (even hidden) up until the point it recognises a different mechanism is needed. Then browser autofill still works if the password is used.
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.
It recognizes that when the user confirms they've finished entering their username by clicking some kind of button.
At which point either a password box is shown or the alternative mechanism is shown.
There's no way to know in advance. And it's a UX problem if a password box is shown by default, because then users who don't have passwords think there's a bug in accessing the resource (because they don't have a password).
If your password manager has a problem with filling in the username, then the problem is with your password manager, not with the login flow. Starting with username-only is an industry standard for any product used in enterprises.
> And it's a UX problem if a password box is shown by default, because then users who don't have passwords think there's a bug in accessing the resource (because they don't have a password).
Hence why I said it can be hidden.
> If your password manager has a problem with filling in the username, then the problem is with your password manager
For sure not filling username only is a problem/missing feature with Firefox, I didn't claim otherwise. My main use for this feature is not dealing with what I consider to be bad UX, but logging in to sites that for security I don't want FF remembering my password.
> Starting with username-only is an industry standard for any product used in enterprises.
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.
Further to this, it is also why I suggested the pattern workaround for older browsers.
You shouldn't find yourself in too much trouble in a browser if you add an attribute to an element that it doesn't understand though, it will just ignore it.
I’m actually paid to say that too ;) . In fact, SIM swapping isn’t the only weakness of SMS, take a look into the SS7 network and how that allows for a rogue operator to redirect SMS messages too.
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.
I'm not advocating for poorly implemented 2FA, just that SMS 2FA is more secure than just a password.
If a site required you to have a 32 character length password, but kept the passwords in plain text, that wouldn't make your password any less strong. It just opens a different attack vector. If a site implements 2FA via SMS, but allows password reset via SMS it doesn't make SMS 2FA less secure, it makes that sites implementation incorrect.
SMS 2FA isn't more secure than just a password. It actually opens up holes.
When my gf lived in Malaysia, she added her phone number to FB and forgot about it. Years later, after having moved back to Vietnam, the number was recycled and someone was able to use that number to gain access to her FB account and reset the password.
Had she never added her number to FB (and you can extend this to any service which offers SMS 2FA), her account would have been safe.
I'd argue that Twilio should remove SMS 2FA as an option. Period. Just move on from it. Please.
The security hole there is using SMS as an account reset, which makes it a one factor solution (see other discussions of this in the thread). The error was in that implementation, not in SMS 2FA in general.
* Applications that take a phone number for one reason (2FA or otherwise) and also use it as a single factor for account reset are less secure in the case of number recyling.
* Applications that do 2FA via SMS do not necessarily do account resets via SMS
* 2FA over SMS is more secure than just having a password to secure an account.
I am sorry your girlfriend had this problem. I would have hoped a business like Facebook would better understand phone number usage. Their penchant for taking as much data as they can and using it however they like clearly burned some of their users here. I hope they have tightened up this hole and that this didn't affect too many people.
Ok, makes sense. Thank you for the kind response and I approve of most of it. I think we will have to agree to disagree on the last * though. I think that statement is very much 'it depends.'
I apologize for going in circles one more time... but by not providing 2FA SMS, it is impossible to f'ck it up or be abused. Right?
I shy away from any rules that say you can’t mess something up simply by avoiding one thing, especially in this sort of case. Consider also that avoiding 2FA by SMS may avoid sim swap or recycle attacks, but it could also eliminate 2FA for users who don’t have a device capable of running an authenticator application (a feature phone).
There’s a lot more at play here, and “just don’t” isn’t a nuanced enough answer to 2FA by SMS.
But as I said towards the end of the previous comment, if you deem the threat to your users great enough that targeted SMS attacks are a problem, you can turn off that fallback.
The article is about how to improve a UI/UX using lesser known HTML properties. The article does a great job: these tags are helpful and not everyone reads the spec for fun.
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.
> Reality is telcos have user enrollment almost on par with bank KYC, where everything else has great authN but with user asserted identity.
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.
It's the credit check part of the KYC for telcos that makes them like banks. The pay as you go SIMs, absolutely arbitrary, but there are back end id verification services offered by telcos that have been in design a very long time. Not sure their current status, but they have the KYC data.
Authy’s iOS app still doesn’t have an actions/app helper, so every time you need to switch to the home screen, find & launch it, search for the site, close the keyboard (the copy button is obscured by it), hit copy, then switch back to Safari/wherever and paste. So much friction.
Kind of implies the engineers who build it never ever use it?
Is type supposed to be "text" instead of "number" in the inputmode snippet? Wouldn't it still strip leading zeros the way it is now (with type set to "number")?
Not really, it becomes very difficult to remove a phone number from an account and anyone who gains access can use various account recovery mechanisms which rely heavily on access to that number for authentication.
Sure, everything that has a backdoor is bad. But what does that have to do with SMS 2FA?
Surely SMS 2FA (without a backdoor) is better than nothing. Sites should still offer something better than SMS for 2FA as it has widely documented issues. But as an end user presented with SMS 2FA or no 2FA; SMS 2FA is the safer option.
Is there a reason to assume an arbitrary SMS 2FA implementation would have a back door? That would be news to me.
The back door is either automatic or human account recovery tools.
These tools generally put way too much trust into the phone number and allow someone who has compromised that number to take control of anything it has ever touched.
Phone numbers are very public and easy to steal in ways which are difficult to defend against.
Imagine someone in a domestic abuse situation having their phone taken, with sms 2fa, how hard would it be for that person to recover and retain access to their accounts and services?
With SMS 2FA someone who knows you personally and has control of your phone number is nearly impossible to escape.
All the adversary has to do is say "oh this was linked to my old number" and account support is super likely to just give access away.
You would have to be somewhat of an opsec expert to escape that hell, and even if you know everything it becomes impossible to defend yourself against the owners of your accounts giving access away.
The only real defense is to never associate your phone number with personal accounts which even then is often not possible.
You're talking about account recovery, not 2FA. A website can use my phone number for account recovery even if I'm not using SMS as 2FA.
I agree with everything you said about SMS for account recovery.
Account recovery that uses a phone number is weak. There was a paper on HN this week that detailed this.
However, if we are going to compare SMS 2FA (I.E. password plus code sent over SMS) against just password, SMS 2FA wins. In both cases I need to steal your password, the SMS part is an added challenge although it's easier to bypass than many people want.
Given SMS 2FA and any other 2FA option, SMS 2FA loses.
In an idealized sense, sure. But not for a practical situation.
SMS as an authentication factor weakens the security because of all of the additional behaviors associated with the account provider which are inescapable.
> The only real defense is to never associate your phone number with personal accounts which even then is often not possible.
Yes that's exactly right. If I don't trust a website to not use my phone number as the sole factor for recovery, then I should not use SMS 2FA on that site and I should not add my phone number to any part of my profile. If I know (how?) that the website won't use SMS for recovery, then SMS 2FA is better than nothing.
As a website owner, if I offer SMS 2FA auth and use SMS in isolation for recovery, then I'd want to stop using SMS for recovery. After that, removing SMS 2FA and not offering any second factor would weaken my security. I.E. SMS 2FA is weak but better than nothing. SMS single factor recovery is terrible, fix that ASAP.
It's one of those things which, technically, can be done correctly. However, it isn't. It provides an incentive to do bad security which is bad for providers because their security will have a tendency to devolve into bad-factor recovery and it's bad for users because it makes them comfortable with a security factor which is easily defeated.
It might be good for your use case, but systematically SMS is bad for security in a global society sense.
Depending on how abusive you are thinking, that sounds like rubber hose cryptanalysis. That's a hugely powerful approach and I think all 2FA can be bypassed with that, if not most of modern cryptography.
Keep in mind that other 2FA methods also are phone based, like TOTP / Google Authenticator. Those also fail if your unlocked phone is taken. SMS is even weaker than those, but still better as a second factor versus nothing.
It is, in many ways, a worse vulnerability than rubber-hose cryptanalysis. When you run away from the person with the hose, you can change your passwords and they won't be compromised any more.
If somebody has your phone, a physical address associated with you, and some basic biographical information, they can continue recovering access to your accounts in a way which is difficult to escape, especially because of the misplaced trust in using phone numbers for security.
The threat in that situation is being vulnerable and having to digitally escape as well as physically escape, and if you don't do both simultaneously you can be continuously compromised in a way which is very difficult to succeed.
Taking over accounts is mainly American thing, the rest of the world is using same method to identify yourself to a telecom company - by providing your ID card or passport.
I want a one-step-login. Not two step (first username, then password) and certainly not three step (username, password, 2fa, all in seperate pages). This braindead concept needs to die.
If no 2fa is active on the account, just accept anything (including empty strings) in that field.
This is a really cool and informative article. I had head of the 'pattern' attribute before, but I hadn't come across 'inputmode' before. This will solve a ton of headaches for my future development work.
SAASPASS has a much better 2FA user experience on the mobile phone than SMS including URL callback to the 2FA app and app to app with SDK. For desktop environments configurable MFA methods include scanning encrypted barcodes and push login. More on the developer environment is here:
developer.saaspass.com
I work for an IAM consultancy/reseller and work on SAASPASS implementations.
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.