philnash

Ah, time zones. This is a real thing that happened to me so I wanted to share so that no one else ever finds out their date calculations are off by 9 months.

It’s a calculator to help you hit your financial goals by breaking down the formula showing you:

- how many sales you need per day - how many sales you need per month - monthly traffic

Here's an idea about how to start with the mailbox sensor: https://www.twilio.com/blog/iot-mailbox-sensor-m2m-to-sms-fu.... This one sends an SMS when triggered, but you could certainly add it into Home Assistant too.

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.

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.

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.

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.

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!

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.

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

Absolutely correct, I've even given talks on this. Check out slide 52, I think we're in strong agreement here: https://speakerdeck.com/philnash/2fa-wtf-at-pycon-singapore?....

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.

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

It is to do with SSO. I will pass off to my Twilio colleague Kelley to answer this with a post she wrote last year: https://www.twilio.com/blog/why-username-and-password-on-two...

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

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.

SMS 2FA is still stronger than no 2FA.

I'm going to be following this post up with how to do the same in Firefox and how to put that all together for as much support as possible.

That's an interesting question, depends on the support you're expecting.

In this case the desktopCapture API was introduced in Chrome 34 but arrow functions only turned up in version 45 onwards.

You can set a minimum Chrome version in the extension manifest though, which would mean you can set a version that guarantees the JS support that you want.

I spoke at PolyConf in 2015 and had a great time. I'm excited that it's moving to Paris and I'll be putting a proposal in soon!

Out of the box browser features that have been removed/destroyed by the quest for 60fps:

* Copy/paste (holding on an article gives the options to email or report)

* Pinch to zoom

* Double tap to zoom (opens links instead)

* iOS swipe forwards and backwards (renders the page swipe animation twice, at 60fps I guess)

* iOS Reader View (go on, try it, I laughed)

And most importantly

* Any sort of accessibility

60fps doesn't matter to someone who can't see the screen.

60fps doesn't matter to someone who relies on assistive technologies to surf the web.

60fps doesn't really matter.

I really like this idea. The major downfall to me of other connected light/plug systems was that if you turned the physical switch off the whole system was offline until you turned it back on again. Integrating the physical switch in the connectedness could see a lot of support for this.

I'm a little disappointed. Not that it was a marketing stunt, that was clear from the outset, and it worked well.

I'm disappointed they're dropping the Raptor name, it just sounds so much better than "Phusion Passenger".

The best part of the game, bookmarked for future nostalgia too!

Very self aware, I wish more people on Twitter (or in real life) realised this. Or at least read this post.

But you set it up with your smartphone. Will you be the one with the smartphone that sets up each of those people's printer?