The spam-to-ham ratio on my phone number is now far worse than any other channel for me. The traditional phone network is at risk of going the way of the fax machine if we don’t do something about the spam problem like we did with email.
If I’m on a call, even with family, it’s now almost exclusively on FaceTime/zoom/meet/etc. I can’t remember the last time I talked on the traditional phone network or received a legitimate call. Which isn’t great because those aforementioned platforms are all proprietary walled gardens with terrible incentives — once they capture the market fully they will eventually dump ads all over your calls. Don’t believe me? Just look at what Gmail did to monetize the lock-in on your inbox.
Doctors and dentists.
Most of the calls I get are spam, but then the MOST important calls I get are from doctors, labs, and dentists. I do as much as possible online of course, but not all of these professionals have good online systems and phone calls are often required.
Sometimes you know what number they're going to be calling from ahead of time, but often you don't... especially if you're in a large medical network that has different offices for different specialists, etc. It's a really sad situation if you get sick and you're trying not to miss these important calls, especially when it's a long wait for a specialist and then you miss their call when they get to your name on the waiting list.
This will literally cost some people their lives and legislators need to act on making spoof calls impossible -- there's no reason why anyone should be allowed to spoof a number that they can't receive calls at.
It sounds like a lot of work, but when I started doing this about two years ago it took about two weeks for the calls to just... stop. Now I get a spam call maybe once a month. It's glorious.
My theory is this is the only route to get put on the _real_ do-not-call lists - the ones that spam companies in India have labelled "unprofitable numbers.txt". Seems like once you're on those, you're good.
Every minute they're listening to you use them for rubber-duck debugging is a minute they're not scamming Granny out of her 401k. Be prepared to get called bad names in foreign languages. Bonus points if you learn some phrases in their language to really get under their skin.
I really don't get that. I don't get these, on neither of my phones (I've got two numbers). When it rings, it's virtually always friends or family. Sometimes the bank/insurance/doctor. Very exceptionally do I get a commercial or scam call.
I think it's not an argument good enough to excuse to excuse Authy here: "my phone already leaked, so what's one more leak!?".
> Which isn’t great because those aforementioned platforms are all proprietary walled gardens with terrible incentives
Oh I fully agree. I'm using Telegram for chat but zero FaceTime/meet/WhatsApp here. People want to call me, they usually phone me. Once in a rare while Telegram.
Yes, and this is the slope that we keep sliding down with these data breaches not being taken seriously. First it was your name and email. Now phone numbers. What's the next bit of our private info that we'll normalize leaking?
This is why I have my own mail server and domain. Full control over mail, and access to features that you pay for (ie, unlimited e-mail aliases, control over mailbox size). No more worrying about “google decided to shut your free account down for whatever reason. Bye bye decades of emails and loss to services that use email based OTP or magic link login.
I wind-up using the phone because so many organizations malevolently misfeature they websites - doing what you want to (pay basic bill or whatever) is hard but upselling and new features, those you can do instantly.
Doing it the opposite way - tying all outbound school/camp calls to a single callerID - risks blending the important with the automated reminders. LAUSD abuses their automated calling system to the extent that my wife and I have both screened calls from the front office involving an injured child, more than once.
The real issue here is getting to the root cause, which is carriers and their intermediary aggregators having incentives to carry large volumes of spam.
In a number of markets, operators have increased the cost of SMS messages to deter spam, only to find a massive increase in traffic pumping fraud that mysteriously appears in the system of trusted intermediaries. Everyone's making a goddamn fortune off it, and no one actually cares to fix it.
> Why does Authy require I provide my cell phone number and email address? Why do I have to have a user account? This is completely ridiculous. I do not need nor want cloud syncing or backup. You are making Authy a potential target for attacks by associating a user to cloud stored 2FA information.
> This is not in the spirit of 2FA.
Unluckily sooo many give zero or negative fáck among their potential and existing customers. This includes businesses providing medical services sending all the clien't data and medical results in clear text email and even declaring for their own convenience that "The property and copyright or other intellectual property rights in the contents of any document or images provided to you shall remain our property", for your ultrasound results. Your medical results are their property for those use their services. So they do as they plase with their data, not your data, not your concern if it is protected or not. And people go there and rate this service 4.8 on google, insane. Of course no-one really reads TOC, not even for sensitive medical services. People do not learn.
https://www.twilio.com/docs/sendgrid/ui/account-and-settings/two-factor-authenticationIt took them two years to fix it.
I’m trying see if the issue is some unanticipated issue with the iOS client app itself, or if it is only affecting people who created online accounts with Authy to sync their 2FA credentials across devices.
How do I avoid such problems in my own app? Force authentication for all requests with row-level security? Rate limiting?
Any testing frameworks that would catch this? Something like "given endpoint /user/phone-number-validate make sure only <user> can access it".
Today they have incidents almost every week, and now data breaches.
Our digital data must be recognized as human rights but lately the world has been vocal about it but silent when it comes to action and enforcement.
More and more reason why people no longer trust cloud hosted solutions. Offline-first, local-first with optional data sync is the only path forward to combat violation of our rights to our own digital data.
Case in point, feeding haveibeenpwned with a bunch of HN user handles reveal a good chunk of you aren't even aware your data has been leaked, especially ironic since I see comments from those handles are very anti-regulation when it comes to user data ownership.
Exporting the raw totp tokens can only be done from the desktop version that is currently deprecated and scheduled to be nuked from existence later this year. It requires getting the tokens loaded into the desktop app, then downgrading to an older version so you can use the chrome remote debugger to run a javascript function against the desktop app (embedded chromium) which pulls out the raw tokens and gives them to you.
It’s bizarre to me that Twilio decided to get into the Authenticator business at all, especially while SendGrid had plenty enough problems to keep them busy.
If you need a cross platform authenticator, do check it out.
FOSS, optional e2ee backups.
https://support.apple.com/guide/iphone/automatically-fill-in...
This is truly unacceptable for an authentication product.
An authentication product that doesn't implement authentication correctly in their own APIs?
I used this project for exporting: https://github.com/alexzorin/authy
EDIT: it appears this project was actually using the unauthenticated endpoint (used in breach, too) to facilitate exporting, lol. Good luck to anyone trying to get off of Authy, Twilio really doesn't want you to export your data for "security" reasons.
In general, after that I started poking, and discovered a lot of things I hadn't bothered looking into before that make me extremely suspect of Authy's general security.
For those looking for an alternative, I use 2FAS and Yubico Authenticator with a Yubikey now. Yubikey only allows you to store up to 32 TOTP slots, which is very limiting (I have more than 60 TOTP accounts for 2FA), so I use two apps and "tier" my 2FA.
Tried to do the same on an android phone and it didn’t work.
You can also port your phone to google voice or Fi and give away all your call information to them. Very few spam calls get through their filter.
I like the change phone area code to out of area and block all phone calls from that area that some call services provide.
If there are any high-profile victims in this list SIM Swapping those phone numbers should be a very attractive approach.
I think security cautious companies should consider turning off multi-device support and start planning for a migration. This leak feels way riskier to me than what media reports it to be.
Like if I crawl hackernews and download all the somethings am I a "hacker"?
To me a hack is some kind of escalation of privilege beyond what I'm truly entitled to (such as stuffing passwords, tricking software to run a payload, crafting a payload for service A so that it tricks Service B) ...
Not using curl on a loop.
It's been possible for a very long time now.
Yet, companies keep leaking. And people keep sleeping.
The issue is starting the migration out of Authy. Assuming Authy has no easy export, I suggest you migrate over a few entries at a time (maybe from top down) while keeping account of transfers somehow. You can have authenticators live side by side in the meantime!
then, a misconfigured endpoint (or a zero day etc.) can't be exploited by any_actor_on_the_internet - actors need to first complete the provisioning process you choose to enforce to be authorized to use the private overlay.
*not one size fits all, e.g. bad option if endpoints need to accept requests from unknowns.
however, many endpoints only need to accept requests from known (identified, authenticated, authorized) endpoints, and the added friction to id/authN/authZ get use the private overlay is not a business impediment.
there is a stigma here due to the horrors of NAC on private enterprise WANs. but NAC goals can be accomplished without that baggage via internet overlays and modern cryptography.
to be clear, i am by no means advocating to abandon traditional methods of endpoint auth - this it is just another layer which recognizes that single layers are rarely airtight (e.g. what just happened to Authy and Twilio).