Most people will not bother to install Google authentication and just not use 2FA (who wants to steal their account anyways /s). Even if they did install it, recovering their authentication codes if they have lost their phone is incredible hard (because too many won't use backups – even if it is as simple as apples iCloud backup).
What I think companyies should do is give their users a choice not to use SMS authentication. Power users (and hopefully most high profile users) will make use of that and normal user can just use SMS.
In the end it is always a trade off between convenience and security and sadly convenience almost always wins for most users even for easy solutions. So we (the developers) should provide them with the most convenient way they accept which offers the maximum security and SMS does just that.
- Requires a telecom provider in the first place (in some countries, that legally requires a passport/national ID tied to the phone number)
- Offers no means of backup
- Forgot to disable 2fa on that one account you log into once a year, before changing your phone number? have fun with that
Nevermind Google Authenticator. Android and iOS should have a high quality TOTP app installed by default. One that permits backups. "Users won't install it" should NOT be a factor and if Apple/Google want their users to start using 2FA it's in their own interest to do this anyway.
On most of my accounts the probability * cost of getting hacked is much smaller than the probability * cost of loosing access.
If someone is changing their opinion, that's a good thing. It means they are taking on board new information and not blindly following their original opinion.
If someone appears to have an inconsistent view, perhaps their position is simply more nuanced than the simple "for or against" buckets the debate actively tries to lump all participants into?
I don't care that his view is inconsistent, I just think the complaint of people disagreeing with him (in a comment format which encourages disagreement more than agreement) was kinda ridiculous :)
True, Red Hat has made FreeOTP which is available for Android and iOS and works really well.
I don't think Microsoft is patent suit immune, but they are certainly capable of handling patent suits without disrupting user capabilities/security. Unless you are suggesting Microsoft owns patents in using the standards and somehow might sue users over that, but both OATH and IETF have patent grants in place regarding the standards.
Open source under any particular license (esp. and inc. the GPL) is orthogonal to it being immune to patent suits and/or lock-in/EOL. It's also orthogonal to security and/or privacy you can have secure apps both with and without open source. Certainly there are reasons where technically inclined users would prefer to have access to the source, but within the larger context of this discussion where the question is if there is an app available in any app store that matters that you could point a non-technically inclined friend/relative to, Microsoft Authenticator is one option and whether or not it is open source, it's still a better cross-platform option than SMS (and Google Authenticator which isn't as cross-platform, but has as many risks as you mention here as Microsoft's option).
Exactly what I'm suggesting. Both Microsoft and IBM regularly file plenty of patents pertaining to about anything they create. They also regularly sue companies over them with Android alone producing hundreds of millions in revenue from such suits. So, one shouldn't use anything from Microsoft that might need to be cloned or ported later unless having a copyright and/or patent license. The risk with them is too high.
"Open source under any particular license (esp. and inc. the GPL) is orthogonal to it being immune to patent suits and/or lock-in/EOL."
A number of OSS licenses specifically include a patent license for use of that tech. It's implied by GPL for forks, too, which is not the case for OSS clones of a closed but free product. So, it's not orthogonal but directly involved via creation of patent licenses & protection of forks. It eliminates a good chunk of the type of liability that Microsoft likes to create.
"It's also orthogonal to security and/or privacy you can have secure apps both with and without open source."
I've made the claim myself & my background in high-assurance security lets me know the difference. This app isn't high-security or evaluated to it by any trusted party. So, we have to assume it's not secure by default like anything else. Nonetheless, this tangent doesn't matter at all to my point that Microsoft + closed-source offering poses risks that Microsoft + GPL offering don't. And that Microsoft makes such risks real for companies often enough for it to matter.
"it's still a better cross-platform option than SMS (and Google Authenticator which isn't as cross-platform, but has as many risks as you mention here as Microsoft's option)."
I don't use these products at all. So, I can't evaluate their features, UX, portability, etc. I'll take your word for it as a user that it might do a good job or offer advantages. My starting point based on comments here would probably be FreeOTP as it's free, open-source, and Apache includes patent provisions. I can imagine it not having Microsoft or Google's features to point I'd use them for overall cost-benefit analysis but I'd certainly have fall-back option.
FreeOTP looks like a good option. It doesn't support every platform yet, and it doesn't have a mainstream recognizable brand name. Yes, it's a great fall-back option, though, for folks that want to "graduate" from the Google/Microsoft/other options.
I am just pointing out that of the mainstream brands that the public in general knows (and trusts to any degree) Microsoft's option has the best cross-platform reach and is the easiest to find in the respective app stores. That carries a lot of weight in getting a security feature that everyone should be using into more hands. I realize a lot of technical folks are still highly suspicious of Microsoft and feel there is a lot of risk in Microsoft's name.
Yes, it would be better if it were open source, but it is patent unencumbered, as much so as open standards typically get. I realize it might not be your preferred option. I was hoping, however, to point out to people that is a good option (not a perfect one, but a good one) to spread the gospel of Real Two-Factor Authentication.
(«I don't use these products at all.» You probably should be using at least one by now, if not several. OATH TOTP (RFC 6238) and OATH HOTP (RFC 4226) are the best options we have right now for Real Two-Factor...)
There's patents that cover a specific tech, for its uses, for underlying mechanisms, and for vague extensions. These are the risky types that show up the most with most of it obvious to point it shouldn't be patented. Expensive to fight, though. Microsoft goes for all three. So, either IETF would have to own patents for all use cases and underlying techs or Microsoft would have to issue patent license for all such categories if they have any. A patent license for the whole product to be used or cloned however, as in the open licenses, is still safer.
"There's no greater risk with a Microsoft option than a Google option"
Unbelievable. You've looked at the court histories to find that Microsoft and Google have caused about equal damage to companies with patent suits, lock-in, or obsoleting core products. They haven't. Google doesn't even compare, esp the billions Microsoft extracted with legal suits, except on encouraging lockin where Google at least stays ahead of most competition in terms of capabilities instead of stagnating. Virtually no comparison in actual damage done although I'll concede Google is becoming more like Microsoft every day in terms of sneakiness & lock-in strategies.
" I realize a lot of technical folks are still highly suspicious of Microsoft"
You should try the non-technical folks who've been burned by them with Windows activation failures, forced upgrades of hardware, forced ads on their paid Xbox Live, BSA developing snitches in organization, licensing schemes, lawsuits over nonsense patents, and so on. You don't have to be technical to be suspicious of an organization that pulls as much BS as Microsoft. I've met many non-technical people using Mac's (or enterprise Linux) because they didn't want the trouble of dealing with Windows or Microsoft. Worst horror stories I hear from Apple users in terms of company are the "Apple tax" and issues with non-Apple hardware. Also the PPC to Intel transition at one point. Collectively not in same ballpark as Microsoft's behavior, esp in financial risk.
"Microsoft's option has the best cross-platform reach and is the easiest to find in the respective app stores."
This could be true. Again, if it's usable, better than others, and you can avoid lock-in, then sure go for it as it's best option. Also, go for it if others are so bad they wouldn't use them anyway. Better than nothing. These are potential use-cases.
"You probably should be using at least one by now, if not several. "
It usually means they hit two targets instead of one. My opponents can do that. I just don't trust the accounts at all. I assume my machine is compromised then work from there. Far as riff raff, I use a Linux desktop, update my software, secure the wireless, make randomish passwords, and so on. I could improve it but the few times I've had to change something was when online service itself was compromised. Yahoo and LinkedIn being only ones I know recently. I'm not saying other people shouldn't do it necessarily but little benefit for me given threat profile.
My bank in Poland has a scheme where it sends me a one time password together with some details on every mutating operation I do (e.g. on a transfer it sends the amount and account number of the target account).
Personally I consider the transaction description a pretty killer feature of Mobilt BankID compared to the hardware tokens.
I'm not sure what the backup situation is with Android.
I've started backing up the actual strings that the app uses to generate the codes in an encrypted vault. You usually have to manually have these strings shown to you in lieu of a QR code. While creating another avenue for someone to hack you, at least I have a backup as well as a way to add a second device go show me codes. This is definitely beyond the capacity of the average user.
I think there might be online services that handle keeping codes for you? Like you can install an app on your phone, log into an account, and it presents you with all of your codes. Anyone have a recommendation for one of these that works well for them?
Let's pretend I'm a dummy user and I print all my backup codes out and throw them in a drawer somewhere. Now the only situation that locks me out of my account is both my home becoming damaged/unavailable AND my phone at the same time.
While a house fire or something could reasonably accomplish both (although I imagine most people would grab their phone before running out!), I think this reduces the risk to a point well below the "I dropped my phone in the toilet." level of not having backup codes.
Some may consider that a feature rather than a bug.
It's even worse because with offline 2fa. Just reinstalling the phone means loosing the secret keys. I know it's possible to back them up but nobody does that.
Yeah that is a problem and that's why I'm arguing a high quality TOTP client should be shipped out of the box with Android/iOS and be synced with the Google/Apple account by default. A lot of the friction and backup issues would disappear.
But... how do you authenticate to this backup of your codes? It can't be through the same method that these codes unlock for you. Right?
That depends who you're warding against. Any attacker sufficiently motivated has access to everything you have access to, so in theory, nothing is safe. If you're warding against MITM for example, logging in with an OTP code is enough, you don't even need a password. If you're warding against malware, then the OTP seed should be on a different (airgapped) machine. In both those scenarios, assuming you don't have a webcam, a post-it note with your backup codes is sufficient.
But yes, ideally the codes should be on a different machine, or at the very least in a different safe (eg. two separate KDBs with a different passphrase). And to answer your other comment, yes, they'll usually be safer on paper under your mattress.
I have a waterproof, fire resistant chest that important papers live in. In the event of a disaster like a house fire, where my phone and tokens would likely be destroyed, it's a "Plan B" option. In the event of an accident or other event that results in my untimely demise, my wife or other loved ones can also access that chest and get backup credentials to access accounts with critical information.
The other nice thing about the analog world is that the legal path is well worn and understood. An online, service-based resource could be shutdown at any time and custodial disputes are either impossible or driven by some arbitration process on the West coast (I live on the east coast). Accesses to physical goods is clearer, and disputes get resolved by a local judge.
Cool thing is that there's less laws of physics trying to break your security model if you take transistors, wires, and wireless comms out of your implementation. Paper without a line of sight has excellent security properties against remote attackers. :)
Note: Your point on the legal angle is wise and rarely made. I probably need to bring it up more often myself with these ridiculous rulings on privacy & data protection.
That really opened my eyes to the often ignored downsides of electronic media. In the US, we have constitutional protections around our "papers" in our homes, but third party doctrine dramatically weakens the protections around all sorts of things.
In fact, you should use a dumb phone for SMS-tokens if you want be on the safe side. (It would make more sense if the vast majority of Android phones wasn't insecure due to running an old OS with no updates, but that's not the case.)
Isn't that BETTER compared to anybody getting a phone number and using it to hack into your 2FA account?
>-Offers no means of backup*
That has nothing to do with SMS for 2FA. There are websites using SMS for 2FA that DO offer a backup way to authenticate in case you have an issue with your phone.
Huh? Are we talking about the same thing?
> There are websites using SMS for 2FA that DO offer a backup way to authenticate in case you have an issue with your phone.
A backup is not the same thing as a master key (even if we call those "backup codes"). I'll grant you that those are usually enough.
What I'm saying is that a potential attacker that might divert PINs to their mobile phone, would at least have to be registered to get that phone account in the first place.
Microsoft will release prefixed support of the draft spec in Edge in the upcoming Windows 10 Anniversary update on August 2: https://blogs.windows.com/msedgedev/2016/04/12/a-world-witho...
If your mobile phone links to an account somewhere (e.g. Google account) that you can also access from the other device (e.g. a PC), and security-related settings can be changed from the other device, too, then that's insecure out-of-the-box.
A problem with sms though is that you need cell phone coverage. I have been in situations where my transaction has timed out while waiting for the sms text to arrive.
Fun story about this: When Blizzard introduced TOTP, I wrote a Blizzard Auth library and client so that I could use their 2fa on my desktop (https://github.com/jleclanche/python-bna). Why? Because I was sharing my Blizzard account with someone else, but still wanted to use 2fa. And people kept telling me "2fa must be on a different machine otherwise it's not secure", so I was using 2fa wrong and shouldn't use it at all.
Well that's bollocks. Same-machine 2fa is more secure than no 2fa at all. There's another comment below that talks about "perfect being the enemy of good" and that's exactly it.
So we absolutely should start promoting the fact that you can use TOTP on desktop, even if it's less secure. A lot of users don't use 2fa because they either don't have a phone, or don't have their phone constantly with them.
SMS just works. (except when it doesn't)
Steam is SMS, and I heard they now have a shitty custom 2fa but what you're describing is services that don't use an established standard, which is compatible with hundreds of established clients. SMS isn't merely nonstandard (and now deprecated), it's more expensive for both the user (requires an active sim card) and the server (requires sending SMS to numbers all over the world).
The custom component makes sure that marketplace activity is valid (somewhat like the custom banking dongles you get that require both your pin and some transaction identifier).
They'd be better off allowing the option of standard TOTP auth for login, so users can use a standard authenticator app, and then layer on a custom app for trading if needed.
If the token's seed is secure (YMMV), it doesn't matter if it's on the same machine.
An attacker can then compromise both factors at the same time.
To me, this weakens the point of 2FA a lot.
If you are able to use a second device for your 2FA, great but it is not always possible and 2FA on the same device is still better then no 2FA at all. I don't want to carry around a key just for all my 2FA passwords but still want to use my phone for common tasks that require 2FA.
Additionally, the keylogging threat is severely reduced against most 2fa (because the login has to happen before the user sends the OTP) and can be eliminated completely by ensuring the token code is on a separate screen and creating a 30 second lock on the account while the user is entering the code.
In what world is malware which has full control of the PC stopped by having the token code on a separate monitor but the same logical system (if that's what you're talking about).
An attacker with control of the PC can just get access to any app. on that PC...
This is fun, I have a tablet here on my desk I was given to repair a couple days ago. It's a mainstream tablet here in greece, sold for 70-90€, the sort of thing you'd buy if you are an "ordinary user" who doesn't know any better.
Well it's running a 4.x android with a custom marketplace and it is FULL OF ADWARE. Seriously. There's fullscreen porn popup ads on the OS itself. There's hundreds of spam notifications, a "fake" screenlocker which captures your taps into ads, etc, etc. Seriously, this thing is like a Windows XP SP0 PC from 2005 after heavy adblockless porn usage with flash and java on. I actually haven't seen anything like that this decade.
This is what you get if you buy an off-the-shelf tablet or phone here. This is what "ordinary users" get. We gave up control of our own devices in the name of security, yet shit like this can still happen.
(Sorry for the OT rant. Seeing that tablet pissed me off.)
The convention is that the chances of two devices getting stolen together are smaller. That's why offsite backups are a thing.
When Battle.net authenticators were introduced, the primary threat was keyloggers and leaked passwords (from reuse). Both of those threats are eliminated by TOTP, wherever it is.
But this discussion was more about if the machine was stolen and the bad guys logged in to your online accounts from it.
In that case it is true they would have your OTP, but they shouldn't have your Blizzard password.
Passwords (on the OS account and on the Blizzard account) mitigate against the machine being stolen.
OTP mitigates against the password being stolen.
It is what you know and what you have so that if someone gets one they don't automatically get the other.
When both the password and the TOTP seed are on the same machine - assuming you autogenerated your password - they are both autogenerated and out of your sight so they really are just two things you have, and you have them in the same place. The difference is, it's impossible to capture the TOTP seed from the TOTP token being input - passwords are vulnerable to that.
Am I crazy or does that make the password completely redundant?
If your password database is not encrypted with a strong passphrase, then you are right, they both become "what you have".
Or, are we treating the ephemeral 1-time-use token as something the user has?
edit: I don't know. Maybe your implementation meets the definition of 2FA. Regardless, it certainly reduces the security
Should Blizzard support multiple users of the same account? Perhaps, but that's out of scope here.
Forget to pay your bill this month? No logging in for you.
Switch providers and forget to change all your services over? Oh well, all your data is lost, make new accounts.
Don't have a roaming on and go overseas? Guess you aren't accessing your travel plans. Even if it's on many ISPs charge 0.50+ per SMS. Why should have to pay just to log into unrelated services?
Go overseas and get a local sim? Welcome to swapping sims anytime you want to login (have had to do this for certain things that currently require SMS verification)
It is disheartening that in an area of mass-surveillance by governments and advertisement networks alike, the notion of separate identities for separate purposes is seen as obsolete and suspicious.
At least with hard-token 2FA technologies such as FIDO U2F, services you access with that key cannot correlate it with other services accessed with it (by design).
And once they have your texts, getting a CSR to reset the password on all of your important accounts is super easy. By far the biggest security vulnerability on major services is the customer support representatives.
It is entirely appropriate that the NIST and Governments lead the way in information security as they have the biggest threat landscape. Therefore they should be the ones to constantly raise the security bar, and lead the way. In many ways that has been the saddest impact of the Snowden leaks is that the Government has abandoned that philosophy. That no longer can government recommendations be accepted in good faith.
At least that was my impression a while ago. That might be completely wrong though :)
Should we call that 1.5 Factor Authentication? :)
And anyone with SS7 access.
They should be calling for secure, validated SMS.
Thinking that "Joe and Jane Six-Pack" are going to use Google Authenticator, is frankly laughable to anyone who does end-user support. But everyone understands "get a text and enter the code here"
For _them_ easy phone number porting, customer service reps being able to "fix" a paying customers message problems, and making it as easy as possible to have their customers send and receive more SMS messages are all directly bottom-line positive things.
Making any of that _harder_ for their customers will only reduce their profits and increase their support costs - at zero benefit to the Telco.
Your bank or ISP or email provider's security is not the Telco's problem - and they can't be expected to invest effort into it on behalf of non-paying 3rd parties...
This is what my local Telco Alliance told the banking industry here in .au back int 2012 (and 've kept it bookmarked ever since for all these discussions...):
"Stanton told iTnews that the telcos have decided not to extend the security mechanism protecting the mobile number portability database for reasons of competition and database performance.
Apart from making the porting process more time-consuming and less convenient for hundreds of thousands of Australians every year, additional ‘security’ may be seen as a tool to lock in customers, hinder number portability and thus be deemed to be anti-competitive," he said"
It also introduces yet another 3rd party reliance and avenue for attack - Brazil and Turkey have blocked Whatsapp recently, and India and the UK have discussed it as well. I doubt Id want to rely on my Whatsapp 2FA tokens arriving in China either...
Almost all the newspapers in Germany have WhatsApp newsletters, and you can get TV news as video message every hour via whatsapp, and so on.
WhatsApp announced some API for those use cases though.
Nope, this is the answer to the recovery question ;-) which amounts to a password anyway. I wish recovery questions would just die finally.
A pattern I've seen often is people not remembering their password and just resetting it via SMS each time, making SMS 1FA. Although very real, taking the real-world risk of SIM cloning is pragmatically still better than reused, ridiculous passwords and/or ones that end up in leaked lists which amount to no auth.
TFA has been empirically proven to be effective, why is this recommendation being made? I can't find the answer in the article or the Github.
Phone 2FA is, to me, a bad idea as SMS was never designed as a secure transmission and there's a number of known unfixable weaknesses as a result
1) many OS's are allowing SMS to be viewed on the user's computer. so a standard malware attack can get both the password and access to SMS
2) Web sites exist to provide access to a users SMS messages for a number of providers. So an attacker who compromises the PC gets access to SMS messages as well.
Whilst app based 2FA (e.g. google authenticator) isn't perfect, it's better than this, and should be what companies are aiming at in 2016...
Sure Google allows you to port authenticator data with an easy 5-step process. Almost nobody else does even this.
Without portability, it means losing access to your Facebook, Instagram and Pokemon Go when you change your device? People would revolt if you do that.
So what's the alternative? We either use SMS, or we use email (which will have like order of magnitude higher failure rate with no added security) or we don't use 2FA at all. Or we think really hard and invent better 2FA than SMS that works on every mobile device and is simple for the user. Then we can deprecate SMS.
Proper implementations of TOTP do not just rely on expiring the codes. From chapter 5.2 of RFC 6238: "Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP."
If it accepted the same token more than once, it couldn't possibly be called a "one-time password".
Oh wait, what was this article talking about again?
That said, Authy is pretty convenient for most users as far as backups are concerned, and I'd imagine its at least as secure as storing the database in iCloud/Google Drive. They at least do ensure two factors (albeit a soon-to-be deprecated SMS factor) to get the raw data.
For my phone, at least, I can get a program that does all the rooting for me with a click.
Does such a think really exist?
More to the point wouldn't adding an (optional) standard push notification API to TOTP clients be a better solution. You login, your phone pops up a notification, you hit accept on the notification, done. Way less annoying than even SMS.
How would that work when you're trying to login on your desk/laptop?
For banks, for example, I already have a banking app on my phone (which was originally authenticated via, ahem, SMS), so they could very easily put the OTP generator there.
Secure to-device messaging over IP would work. Perhaps if you narrowed it to authentication the telco providers wouldn't see it as a threat to the very, very profitable SMS feature.
It was a bit of a hassle, but not enough to be a showstopper.
I wonder how this is implemented - when Apple sends me an SMS 2FA code, do they pay extra because I'm abroad?
That's mainly a texting fee since that only gets you unlimited SMS, not data or voice. If you don't get the Passport plan in advance, sent texts go from free to 50 cents each.
When I travel Europe, when I'm in the country that issued the SIM in my phone, sending texts are maybe 3 cents, if I leave that country they're maybe 9 cents. Receive was always free.
I'm thinking of a high-profile example when an attacker tried to take over h3h3's YouTube account by requesting his SIM card from T-mobile by pretending to be a T-mobile employee: https://youtu.be/caVEiitI2vg
So now I'm at an impasse. How do I get the code? Well, Github has a backup -- it will SMS the code to your phone! When it said this I just kind of chuckled to myself as I also had seen the h3h3 video. Sure enough, it texted me the GA code and I got back in control of my account.
Github actually provides a list of emergency codes that you can print out and use as a last resort. I had printed these before and actually had them available, but forgot about that process.
Github is trying so hard to have your account secure, but yet the SIM card cloning threat is still there.
I just don't use an authenticator app at all. Some password managers (e.g. 1Password) have support for storing TOTP. So, as long as I can access my 1Password vault (use a strong password!), I can access my TOTP codes.
Besides that, I prefer U2F, which is supported by GitHub.
Oh that's a great idea! Never thought of that, thanks for sharing.
Protip: Don't allow your TFA app/hardware to be a single point of failure. Don't upgrade your reserve TFA device/apps until you're 100% sure the upgrade on your primary TFA device/app has worked smoothly.
Anyway, I have one time codes for all accounts I use 2FA with. Google generates these one time codes as TOTP substitutes, LastPass generates them as a one time master password that's TOTP exempt. Amazon you have to send an email and they'll call to verify and then unset 2FA on the account.
(It's a little telling that none of the downvoters attempted to refute any of the facts…)
It's important to separate out two separate things that we've seen happening - and the media has done a bad job distinguishing these two things - 2FA and account recovery.
If you use SMS 2FA, then to gain access to your account someone needs your password and to hijack your phone number. That's harder than just having your password, but perhaps not much harder if you are a prominent target. The advice I would give to popular youtubers and streamers would be to have very strong passwords using a password manager, and use a TOTP app for 2FA.
What most of the news stories have been about, however, is not 2FA but account recovery. If an attacker can gain access to your account using _only_ your SMS number then you do not have 2FA: It's 1 factor authentication! A lot of websites do a bad job of explaining why they are asking for your phone number - there are competing aims here, to both add security but also ensure you can still gain access to your account - but if you are a high profile target you should take care of the latter (access) yourself, and _not_ enable a backup phone number for account recovery purposes.
Furthermore, I'm not too in favour of using SMS... I have two numbers and when I don't have both phones with me, it's a huge hassle. I end up setting up my phones to auto forward such smses.
I use 1Password OTP support and love how it works seamlessly across my phones.
(Edited for clarity)
So yeah, now I have 2FA enabled on my origin account, but I still wish I received a text message telling me my password was changed.
Maybe? Email requires a data connection but SMS can reach more places on more phones in worse conditions. I mean sure if you have a terrible or no internet connection then you won't be able to address it anyway but SMS at least in my anecdotal experience has given me much better notifications than email (occasionally I've had issues even with my Nexus 6P where I have to manually refresh my email).
This came to mind because I just read a great PDF with a detailed history and technical description of WWV and its sister stations WWVH and WWVB:
Not directly related to 2FA, of course, but that PDF is recommended reading. These people were hardcore hackers before any of us were born!
Ironically/coincidentally, nowadays I run several stratum 1 and stratum 2 time servers.
Is that possible to do this reliably in any country right now? I know you can easily migrate numbers and the oldschool block assignments don't mean anything in a few countries.
I worked for an international Telecom whose SMS gateway would just broadcast messages to the two other national providers if the number wasn't there's (the other providers would drop messages that didn't belong to them). That was one of my first assignments; writing a task that would check the ported number database and only send the SMS to the correctly ported provider.
Issue tracker (discussion/request for comments):
Now this bothers me. I deliberately use a service (RingTo, discontinued for new users) to park a handful of numbers and be able to exchange SMS and MMS with them. One of the things I do not do is give out my actual mobile number to every random web service that wants it for "2FA," primarily because that now opens me up to even more phone spam. With RingTo, I just set that number to always go to voicemail but am still able to use SMS through their app.
It is arbitrary to say "one number type is acceptable for SMS verification but another is not." I'm actually more concerned that my mobile carrier will cough up my account to an arbitrary attacker than I am about some out-of-the-way number parking service that I log into using credentials that are not able to be easily discovered (an alternate e-mail address and such). My mobile carrier is a much larger target and has scores of fallible humans working for it just waiting to be socially engineered.
Ideally they'd support the standards so I could just use one of the many standard OTP apps
It's a shame because in general, I've never had any problems with Namecheap.
For example, if your web browser or password manager is syncing your passwords to your mobile phone, and that's the same phone the SMS codes or TOTP app runs on, is this completely circumventing the whole concept of "two factors"?
Asking for a friend, because I'm sure no HN readers would be dumb enough to do this...
(also, The Register covered this same story yesterday, here's my dupe submission: https://news.ycombinator.com/item?id=12157529)
> Multi-factor authentication (MFA) is a method of computer access control in which a user is only granted access after successfully presenting several separate pieces of evidence to an authentication mechanism - typically at least two of the following categories: knowledge (something they know); possession (something they have), and inherence (something they are).
So as long as your phone is sufficiently password-protected, that is is still 2fa.
Many physical security systems utilize multiple factors of authentication for access that are tied into a single reader. They often have a badge reader (something you have) and a fingerprint/eye scanner (something you are) or a PIN pad/digital combo dial (something you know) all built into the same device stuck on the wall. Sometimes they'll use separate systems for this, but the combo units are very common.
That being said, several companies  have in fact made software authenticators that run on J2ME.
The trouble is with the user (the user is always the problem). What happens if they lose their hardware token? You must have a way to recover that is not exploitable by bad guys but usable by the good people just trying to get back into their account.
SMS fills this pretty well despite its security flaws. I'm not convinced hardware fixes this, at least not in any current form I've seen.
Until you make good security dead simple it'll never be used by the majority.
Now that's a name I've not heard in a long time.
How do you verify that the SMS is really from your service?
The way the phone system works I don't think there is an actual way. It's inherently insecure from multiple angles. Unless there is a way to verify it, reliably, that I don't know about but I tried looking into this before and found essentially nothing useful.
That said, anyone with a SIM card able to get messages for your phone number can download the encrypted database and attempt offline passphrase recovery. It might take a while to brute force, they seem to use a lot of hashing rounds as it takes a couple of seconds to verify the passphrase on a 2014 Moto X.
I prefer OTP... hopefully there aren't any other RSA-type hacks in the future.
And if it comes down to using public/private keys, there's no reason an open source SMS app couldn't authenticate encrypted text messages or something.
If SMS in the clear is bad (and it probably is), then whatever is okay needs to be broadly accessible, open, and usable.
TOTP and HOTP are both open OATH moderated standards. You can use any app or dongle of your choice with any provider that follows the standards. This is a way better alternative than SMS.
In this case it was a land line, but it's still a relevant empirical data point for those weighing options.
Other than the SMS-based 2FA work, see:
- Identity and Access Management for Smart Home Devices
- Multifactor Authentication for e-Commerce: Online Authentication for the Retail Sector
For some services, I would much rather have a key-ring-ful of these devices rather than an app on my phone which I also use for reading websites.
- Google two-factor
- Service-specific two-factor (e.g., Steam authenticator, which provides other features beyond TOTP)
- Non time-based authenticators; Yubikeys are great, and appear to be made of some indestructible material that survives multiple trips through the wash.
If SMS is problematic for 2FA, why isn't it problematic for account recovery?
How much of an affect will this have on companies providing such a service.
Ironically, GitHub uses SMS-based 2-factor authentication...
(Try owning a domain name with the word "anonymous" in it, and watch the skript-kiddies descend en-mass...)
Do you seriously think you're more capable of securing your mail server than Google/Microsoft/Apple?
Is the time/effort you'll spend maintaining it worth the privacy tradeoffs?
How are you dealing with outbound mail? Where are you hosting your email that isn't already on half the spam blacklists already?
(That last one was the killer for me last time I ran a mail server of my own, neither my home ip address, nor any of the Digital Ocean/Hertzner/Linode/AWS vpses I could easily use/afford to make outbound mail connections with were ever trusted by the big email providers. A self hosted mail service that couldn't reliably get mail into the inboxes of 80+% of the people I correspond with didn't end up being of much use... I've ended up back with Gmail and hating myself for it.)
I don't know about Apple, I stay away from them.
I also stay away from Microsoft, but I had to go through some of their
products in my time, so there's good chance that I'm more capable.
And Google? Extrapolating how they interact with the rest of the world, it's
not improbable, too.
 Did you know, they were a source for backscatter for several years?
> Is the time/effort you'll spend maintaining it worth the privacy tradeoffs?
Wrong question. The correct one would be: why would I give up access to server
logs (yes, I use them sometimes) just to give up my privacy on top of that?
> Where are you hosting your email that isn't already on half the spam blacklists already?
In a place that is not a known spam source? (Yes, this excludes AWS and
Examples? Shall we take turns guessing the names of these elusive spam-free providers? Your non-answer reads to me as, "Just don't use any providers that you can actually afford, and you'll be fine!"
(Sorry if this comes across as grouchy--I can't sleep, and I have to get up early tomorrow.)
I use one in my country (Poland), and I use it since a little longer than
Amazon entered our market. I don't think such a regional provider would be of
much use to you, unless it operates in your region, of course.
What my comment boils down to is to avoid big hosting places.
As for the time, after setting it up and later configuring DMARC, I don't ever touch it. And despite not having almost any volume, I've never had problems getting received by Gmail (though, to be fair, most of my outgoing email are replies, which might help).
Government bodies frown heavily on end-to-end encryption, but also frown heavily on authentication methods that are less secure.
Why, whichever directive shall I adhere to? The more secure behavior or the less secure behavior?
Maybe I should just do whatever benefits everyone else but me.
The government plays a weird dual role. NIST gives good advice, but you need to understand what you're doing. Part of that is data classification and risk assessment, which is always art and science.
When they get real explicit about guidance, that means the thing is broken.
NIST is a political organisation more than a scientific one.
Here come the down votes.
NIST is legally required to collaborate with NSA on crypto. It was widely reported that NIST people fumed about NSA undermining heir standard and they removed the offending crypto from the stNdard quickly.
Nobody is impressed by your edgy downvote invitation.