
HTML attributes to improve your users' two factor authentication experience - ecaron
https://www.twilio.com/blog/html-attributes-two-factor-authentication-autocomplete
======
mnoorenberghe
> 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.

~~~
philnash
You are absolutely right and I don't know where I read that (or why I believed
it, given I had the spec open at the time too).

I've updated the post, thank you for your help!

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

------
stockkid
> In a sign up form, make sure to use the "new-password" value as it triggers
> password suggestions in some browsers.

Nice. I didn't know about that.

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

~~~
philnash
The Twilio 2FA API actually allows you to generate secrets and QR codes for
generic authenticator applications now. Check out the documentation here:
[https://www.twilio.com/docs/authy/api/one-time-
passwords#oth...](https://www.twilio.com/docs/authy/api/one-time-
passwords#other-authenticator-apps)

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

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

------
ayberk
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 :/

~~~
crazygringo
That happens whenever certain usernames trigger different authentication
pathways.

There's just nothing you can do about it if some users have passwords but
other users have different authentication mechanisms.

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

~~~
crazygringo
> _up until the point it recognises_

But that's the point... how?

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.

~~~
OJFord
> But that's the point... how?

Focussing on the next field or button.

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

That's the complaint.

------
philnash
Hello! I’m the author of this article. Thanks for posting! Here’s to the power
of HTML attributes and better sign in experiences for everyone.

~~~
Zardoz84
why recommend inputmode if isn't well supported by other browsers that aren't
Chrome ?

~~~
johneth
It's supported in iOS Safari and Chrome / Chrome for Android[1].

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

[1] [https://caniuse.com/#feat=input-
inputmode](https://caniuse.com/#feat=input-inputmode)

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

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

------
motohagiography
Dealing with 2FA ux right now. There is a massive gap between threat intel
people, product owners, and end users.

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.

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

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

------
amatix
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?

------
skunkworker
I wish more sites would follow these protocols. When you have a numeric 2FA
with a regular keyboard it feels less polished.

------
akersten
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")?

~~~
philnash
Oops! Thank you for pointing this out, it is supposed to be "text". I have
updated the post.

------
daveFNbuck
I didn't know about the one-time-code autocomplete. How do they prevent this
from being used to steal one-time passwords sent by other sites?

------
QuinnyPig
I’d give a lot to be able to forcibly delete Authy-specific 2FA accounts from
the app. Today I’m stuck with old dead account tokens.

------
tobyhinloopen
Didn’t we just learn you shouldn’t use SMS 2FA?

~~~
reaperducer
A lot of people say that. But SMS 2FA is better than nothing.

~~~
hombre_fatal
Nope, not if it introduces common customer support backdoors.

~~~
zulln
If it is enough with access to the phone number, no password needed, then it
is no longer 2FA.

~~~
Thorrez
Sure, but 17 websites do this. For those websites you introduce significant
weaknesses if you enable SMS 2FA.

[https://www.issms2fasecure.com/](https://www.issms2fasecure.com/)

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

~~~
aurbano
I get the point, but I’d be afraid that non-technical users would be confused
to the point of not even trying...

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.

~~~
gsich
If people want to use the service, they will figure it out. You can't create
services with the dumbest user in mind. Sometimes a little nudging helps.

Besides you can always dynamically hide (or show) the 2fa option if the email
or username doesn't have 2fa enabled.

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

------
duxup
If I'm doing verification I usually need more than"pattern" will allow,
usually providing more feedback or something more complex.

------
homero
Twitter has the worst one where they don't trim whitespace so pastes can fail.
How hard is adding trim()

------
hk__2
> For older browsers there is another trick to trigger the numeric keyboard
> and include a bit of extra validation for free.

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.

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

