Live data from Hacker News

HTML attributes to improve your users' two factor authentication experience

twilio.com

71–80 of 82 posts

Re: HTML attributes to improve your users' two factor authentication experience

#71

Earlier quoted context omitted.

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.

The point being that had it been 2FA, it would have been the same hole.

There are a numbers of things here that are true.

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

Re: HTML attributes to improve your users' two factor authentication experience

#72

Earlier quoted context omitted.

The point being that had it been 2FA, it would have been the same hole.

There are a numbers of things here that are true. * 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…

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?

Re: HTML attributes to improve your users' two factor authentication experience

#73
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?

Re: HTML attributes to improve your users' two factor authentication experience

#74
post #46

Earlier quoted context omitted.

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 passwor…

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

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

Re: HTML attributes to improve your users' two factor authentication experience

#75

Earlier quoted context omitted.

Is it though? Implementing SMS 2FA often means a site will never bother implementing anything better.

Not implementing SMS 2FA doesn't mean a site would implement anything either.

No, but it's increasingly becoming the expectation that 2FA should be available.

Going from no 2FA to some 2FA is a more likely transition than going from bad 2FA to good 2FA (since bad 2FA still checks the 2FA box).

Re: HTML attributes to improve your users' two factor authentication experience

#76
post #24

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.

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. See also: AWS.

THIS 10x!

Re: HTML attributes to improve your users' two factor authentication experience

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

Re: HTML attributes to improve your users' two factor authentication experience

#79
post #64
post #49

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.

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.

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.

Re: HTML attributes to improve your users' two factor authentication experience

#80
post #24

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.

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

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.

[1] https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...

Post reply on HN