19 ms·

Getting 2FA Right in 2019

260 points by dguido 7y ago

jandrese 7y ago
I'm a little confused on this risk factor: Use the same QR to provision multiple TOTP applications Poor understanding of what/where their second factor is. Documentation: Tell users to only provision one device What is the risk here? If I have two phones and only one of them on me at a time, why is it dangerous to configure my authentication app on both phones so it's available regardless of which one is in my pocket?
- irishsultan 7y ago
  Because if you do not know where your other phone is then you do not know who has access. The same issue exists with a single device as well, but to a lesser degree, because it's less likely to be out of your control.
  - jandrese 7y ago
    It's in a locked box. And I'm not too concerned about someone breaking my phone security, and then the TOTP app security to get at my second factor. If I'm being targeted that hard they're probably just planning to kidnap me and hit me over the head till I login to my accounts anyway.
- DownGoat 7y ago
  It better to add two different devices with different secrets to the account, than both sharing the same secret. This reduces the chances that something goes wrong when a device is lost, or removed. The user can the remove the other device with much less risk of locking themselves out of the account. It also might provide some info in the cases where a secret is leaked, as it can be tracked to the specific device. There is no real security risk of the devices having the same secret, or in adding a backup device. It is really a usability thing, the biggest pain point a user will experience with TOTP is when they are switching phones, or when they lose one. Decreasing the friction here can greatly improve the security of the system.
  - jandrese 7y ago
    If the service supports that then it's fine. A lot of services only support a single TOTP key per account though. There's a small risk in provisioning multiple TOTP keys on one account too. Each one reduces the search space for a brute force attack. Add in allowances for drifting clocks and a lack of account lockout for missed attempts and you might open up the window just enough for a brute force attack to be successful.
- phillipseamore 7y ago
  I always use the same QR code to provision more than one OTP app on my (1) phone, since I've had some of them fail on me after updates or OS upgrades.
jandrese 7y ago
Any idea of when HackerNews will support 2 factor authentication?
- kogir 7y ago
  I actually wrote code for this ages ago when I worked on HN. It’s probably still there, if only in git. But it really only makes sense for the internal, secret parts that are YC related. For the forum just use a unique password.
rmbryan 7y ago
TIL : https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_a...
deleted 7y ago
[deleted]
Dayshine 7y ago
The main problem I have with TOTP (What you're using when you use Google Authenticator) is that the migration path doesn't exist when you get a new phone. This article complains that users are trying to mitigate this problem, but doesn't seem to give any solutions. It's entirely plausible you might have 20 accounts set up using TOTP on your phone. If you now buy a new phone (which users might be doing once every 18-24 months), you need to log into each account and generate a new TOTP key and void the old. That's a couple of hours work. Now, what if you lose your phone? You now have to recover 20 accounts, which will take several days, and it's very possible you won't be able to recover at least one. The common response is "Oh, you should keep one-time keys somewhere". Right, 20 * 10 one-time keys in a single centralised location, and make sure to update them to keep them valid. I thought we were trying to stop people writing their passwords down and storing them next to their computer? Edit: I'm not sure "treat your TOTP keys like passwords and store them" is setting a very good example. Why are we developing systems that use TOTP if we are encouraging users to treat them like passwords, undoing the vast majority of the security benefit?
- Operyl 7y ago
  There are services, like Authy, that let you back them up encrypted. Whether that is appropriate, when considering the security ramifications, is up to you. I, in the past, have printed out the QR codes and put them in a safe as backups.
  - danShumway 7y ago
    Just a heads up, but the last time I checked, Authy did not have secure defaults for 2FA. Authy supports two standards -- the Google Authenticator method, and their own internal standard. Any tokens that go through their internal standard can be recovered on a new phone using just SMS verification, which defeats the entire point. Your encryption password only applies to Google Authenticator tokens. https://twitter.com/DanielShumway/status/1092095395478556674 https://twitter.com/DanielShumway/status/1092095395478556674
    - PuffinBlue 7y ago
use-authy 7y ago
The blog writer doesn't seem to be even remotely familiar with Authy. Most of the issues he discusses have been resolved with Authy.
- jessaustin 7y ago
  Please provide more details about how your service resolves these issues.
deleted 7y ago
[deleted]
scotchio 7y ago
I wish all 2FA worked like when logging in with your Apple ID. - 2FA by default - Push notifications for the token to all your devices instantly - Not a text message
- SketchySeaBeast 7y ago
  I'm trying to figure out what exactly Google 2-Step Verification is, and whether to trust it or not. It doesn't appear to be a text, and provides a push notification to your device - it's super convenient, I just don't know if it's particularly strong.
  - AgentME 7y ago
    Google 2-Step Verification is vulnerable to phishing just like TOTP is. You can go to a phishing site without realizing it's not Gmail, you enter your username and password, the phishing site gives those to Gmail on your behalf, the phishing site causes 2-Step Verification to happen, and Google sends a push notification to your phone for you to let the attacker into your account. (I believe Apple's default 2FA mentioned by GP works the same way.) Security keys (and the newer project from Google to let your phone act as one over bluetooth) don't have this vulnerability because they connect right to your computer and talk to your browser (and not the attacker's) to verify the domain you're accessing.
    - SketchySeaBeast 7y ago
      But it's still better than SMS, right? How does the security key/browser pair communicate without involving the site? Does it involve more of Google's interference then? While I know you're not saying "yes" to the site, isn't the key doing roughly the same thing?
      - AgentME 7y ago
        >But it's still better than SMS, right? Right, with Google 2-step verification you don't have to worry about number porting attacks. It's just vulnerable in the sense that a phishing site you've entered your username and password into can still trigger the prompt. >How does the security key/browser pair communicate without involving the site? Does it involve more of Google's interference then? While I know you're not saying "yes" to the site, isn't the key doing roughly the same thing? When you use a hardware security key with a browser, your browser tells the security key the page's domain, a user id, and a random challenge token if I remember right. The security key signs a message containing all of these things and gives that back to the browser. If you're on a phishing site, the page will have a different domain than the true site, the message signed by the security key will have the phishing site's domain instead of the true site's domain, and the signed response generated by the security key won't be valid for the attacker to use on the true site.
Avamander 7y ago
I wish someone made a way to securely sync two hardware tokens - for example I agree before setting up any accounts on my tokens that two or three of them agree to sync data. I only have to make sure I do it once in a while. Right now if I lose my TOTP or U2F device without setting both up on all my tokens, I lose access. That's super bad.
- floatboth 7y ago
  Bitwarden, 1Password, Authy etc. have encrypted sync/backup of TOTP secrets. With hardware tokens.. unfortunately the real solution is "enroll a backup one to all services".
  - Avamander 7y ago
    It's not 2FA when you have your password and the TOTP secret in the same place.
Alex3917 7y ago
Every time my leg accidentally hits by YubiKey, everyone on Slack thinks I'm having a stroke. I already set it to require a long press so that it takes a couple seconds, but that doesn't help if my laptop is just at the wrong angle. Anyone else come up with a good solution to this issue?
- louis-paul 7y ago
  Try this: https://support.yubico.com/support/solutions/articles/15000006461-swapping-yubico-otp-from-slot-1-to-slot-2 https://support.yubico.com/support/solutions/articles/150000...
  - Alex3917 7y ago
    Already did that. It doesn't do anything if the side of the laptop is pushing into my leg or the side of the couch or something, which is where it usually happens.
- gtsteve 7y ago
  I just don't have it plugged in unless I need it. Admittedly I only use it for mail and password manager. What do you do that requires you to authenticate that frequently? Could the authentication state not be cached for a while?
  - jrootabega 7y ago
    Keeping it plugged in also increases the chances you'll forget it there when you go to the bathroom. The NFC version of the keys is the best solution to this, imo. You can keep the key attached to your body and not worry about ripping it out when you walk away
- billpg 7y ago
  You accidentally send one-time passwords to other people? Good job that's not the only factor.
- jmalicki 7y ago
supernova87a 7y ago
This article may be right for a corporate environment where you can go to the IT department and prove physically that you are who you are, and get your account recovered should anything go wrong with 2FA. However, if you (like me) use Google 2FA for your personal accounts, you must (if you are sane) keep printed / screenshot copies of the QR codes, backup codes, etc. to be able to recover your account. With Google or any number of services who don't feel they need to get involved in human-being operations, you have nowhere to go for help if you turn 2FA on and then for any reason lose all access to your codes. What if your only phone dies, gets stolen, lost, etc? That is the tradeoff -- security at the expense of having absolutely no way to circumvent it. So the only alternative to not lose your entire online life is to keep several backups and not implement the rules that this guy lays out (which would be appropriate elsewhere).
tptacek 7y ago
Recovery codes should not be mandatory. Recovery codes are not second factors — they circumvent the 2FA scheme. You should, of course, allow users to configure recovery codes. However, the default behavior for a two-factor scheme should always fail closed: if a client cannot produce a valid second factor and hasn’t voluntarily weakened the 2FA scheme by adding an escape hatch, they should not be allowed to continue. This is unrealistic. Users lose 2FA credentials regularly. Think of recovery codes not as a defense for the user, but for the service --- they're keep some number of customers out of your terrifying, manual account recovery flow.
- toomuchtodo 7y ago
  > they're keep some number of customers out of your terrifying, manual account recovery flow. What is the ideal, secure manual account recovery flow for users? Having worked at a SaaS startup previously (where application login 2FA was mandatory for staff initially, but providing it to end users was discussed extensively internally before eventual roll out), it doesn't seem like there is an easy solution to have random user prove who they are if their 2FA auth goes south (no recovery codes, access to TOTP lost).
  - Dayshine 7y ago
    I like the approach some MMOs use: - Provide the printed CD-Key from the game box in full - Provide details about the transaction used to purchase the game (address, date/time, name) - Provide names of characters on the accounts They're not impossible to get if you've compromised someone, but they're far from trivial. In fact, it's actually very similar to the algorithm-based verification my bank uses...
    - popotamonga 7y ago
      Namecheap just asked me a bunch of questions that anyone with access to my mail could answer (all in invoices)
    - pvg 7y ago
      Curiously, Blizzard had hardware tokens (and later phone authenticator apps) 10+ years ago, before most banks and I kind of want to say 'before most consumer online services in general'. And they had the exact same account recovery hellflow problems everyone else has, just earlier.
bjt2n3904 7y ago
> W3C and FIDO finalized the Level 1 WebAuthn specification back in March. Chrome and Firefox already have mature support for it, and Safari is expected to follow. > Upcoming Android releases will allow users to use their phone as a security key, and iOS is expected to do the same. This does not make me happy. Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. I have the same issue with hands free keyless entry/ignition for cars. The feature is solely for convenience, and exposes far too much. The way things work now is the best. When setting up 2FA, I write down my key, and import it into Google Authenticator, or oathtool for the command line. There is no integration, no automation. It works just fine. In the future I'm imagining my 2FA secrets being stolen from my browser, or being used to track me. Google "for my convenience" automatically logs me in so it can track me? Or perhaps, my bank checking my battery level, WiFi hot spots, and the model of phone when it pulls the 2FA tokens to verify my location. Also, I can only log on with their app on my phone, because the tokens are hidden, further making my desktop useless. Maybe a website figures out how to use JavaScript to generate another logins tokens. It takes an hour of tokens, and feeds it into hashcat on AWS to break my key. No thank you. The rest of it though is great. SMS 2FA can die.
- woodruffw 7y ago
  Hey! Author here. > Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. WebAuthn doesn't specify key storage in the browser. It specifies a common JavaScript API for registering and generating assertions via an authenticator, which in turn stores keys internally. Wanting offline 2FA is perfectly reasonable, and I don't begrudge you that! TOTP is perfectly fine for that purpose, so long as you understand the tradeoffs you make in terms of symmetricity/phishability/replays/etc.
  - bjt2n3904 7y ago
    Thanks for the reply. Despite my gripe about this one aspect, your article was very complete and well written. I've bookmarked it to revisit when I need to implement 2FA in projects I'm working on. That being said, I do not like a JavaScript API that provides access to this. JavaScript, JS developers, and the web in general has a horrific track record for security and privacy. To me, this is like the API that provides access to the battery charge state, or my accelerometer for device orientation. Why? Entirely unnecessarily! But it's a cool feature, so let's include it. Suddenly, my keyboard typing is being exfilled through the browser, and I'm being tracked by my battery charge state. Do not want! EDIT: I've maintained this position for "WebBluetooth" too -- a similarly terrible idea. The less my browser does, the better!
kogir 7y ago
I think this article conflates two very different motivations for using 2FA: 1) An organization has valuable resources it wishes to protect and secure from understandable but avoidable user mistakes, like phishing. For example: an employer. Notably, in most of these cases there’s an authority to which the user can appeal to recover account access if 2FA access is lost. It makes sense to be more strict. 2) A user wants to protect something they value, but the provider loses nothing if the user’s account is compromised through user error. For example: personal email. In this case the onus is on the user to ensure they don’t lose access, and the provider may be unwilling or unable to accept the liability of enabling account recovery. The threat models for the two are very different, and in the second case, it’s in the user’s best interest to favor availability of access over all else. I secure my email with TOTP. I have the key stored in 1Password. In all cases 1Password (native app, not web version) is compromised, I’ve lost the battle already. However, I’m not worth burning a zero day on or otherwise targeting specifically. I also have backup codes saved in my personal disk backups. Anyone willing to break into my house to get them could just threaten me more easily. Be very aware why you’re offering 2FA to your users. Are you 1, or 2?
exabrial 7y ago
> Major sites have begun to discourage the use of SMS and voice codes, which are thoroughly broken as second factors Thank goodness. Cell phones and carriers are very soft targets.
- DGAP 7y ago
  Agreed - but for non-technical consumer 2FA, there's really no other option that users are actually going to use. And SMS 2FA is still orders of magnitude better than just passwords when your threat model is credential stuffing and weak passwords - not attacks on specific accounts.
idlewords 7y ago
I don't understand the prohibition against having the same TOTP seed across multiple devices. Seems like a very useful feature (tap phones to sync TOTP seeds). This feels like a case where religious belief about 2FA has won over real-world usability, especially when people migrate phones.
- saxonww 7y ago
  I think the answer is that if you share seeds and lose a device, then you really need to invalidate and reprovision all of your remaining devices. If you use separate seeds and lose a device, you just invalidate the one device and move on. From a user's perspective, it seems like a good feature; I'm fine with reprovisioning my 2-3 devices, no big deal, I'm in control of that. From an admin or business perspective, it's less acceptable because if I see something weird and need to invalidate a device, I'm actually preventing my user from authenticating altogether - and that could require more work to recover from depending on where my user is and what my provisioning process looks like.
  - idlewords 7y ago
    Why does losing the device require invalidating seeds? If I lose my phone or its stolen, those seeds are still behind a lock screen, and even if they get out, an attacker would need my password.
    - saxonww 7y ago
      Maybe 'requires' is too strong a word. It's hardly mandatory, but I'd argue you should invalidate a lost or stolen seed for the same reason you should reset a lost or stolen password. Of course it is not possible to access something protected by MFA if you only have one factor. But I don't think it follows that making it easy for an attacker to obtain a factor since you have two is OK; the whole point of MFA is that single factors are too easy to guess or steal. Solutions that encourage seed export and sharing make it easier to steal the seed, and leaving a seed active if a device it's on has been lost or stolen is like saying you don't care.
danielpal 7y ago
Founder of Authy here. I've been thinking a lot about this lately and came to the conclusion that the only sensible way to do 2FA are U2F hardware key's. Here's why: First, SMS 2FA. People think SIM port is uncommon, its not (i saw thousands of cases). Your cellphone number its public information - pretty much - and its not a technically difficult attack, you just need to convince a carrier to do it. Once the your SIM is migrated to the hackers possession he will hack into all your accounts before you even realized what happened. Second, TOTP. I founded Authy with the idea that TOTP was strong enough and it is, technically, but in the wild deployments have lots of issues. Biggest one is people constantly change/loose their phones. So you end up with a update issue. At Authy we solved it by encrypting the seeds and storing them on the cloud. But today most users just copy the QR-Code, or store their TOTP key along with their passwords in the password manager. Storing your TOTP in your password manager completely defeats the point of TOTP, it just provides you with a false sense of security. Lastly, because it generates a lot of support issues when people loose their phones, services have added ways to bypass 2FA in their account recovery flows. You'll see backup codes or simply SMS as a recovery mechanism. This means your TOTP is as safe as SMS if your recovery allows it. TOTP today is so misused its just providing a false sense of security. Third, U2F Hardware tokens. Its finally possible to do U2F to the iphone via Bluetooth and Feitan now has a key that supports it (Google sells one for project Titan). You can buy 2 keys for $50 dollars. It's impossible to missuse U2F tokens - you can't unsafely back-them up, you can't "screenshot them", etc, hardware enforces their security. They are 100% un-phishable, its impossible to trick a user into signing a login on a fake site - the key will simply not sign it, and there is no way for the user to make an "exception"(like you can if the SSL cert is invalid.). Also given the price and form factor is easy to buy 2 or 3 and have a few stored as backups. In my case I have 4 keys, 2 that I use on daily basis, and 2 I stored as safe backups. If I were to loose 2, there is no way of knowing they belong to me and tie them back to my account and I would just use the backup keys to logon, remove the lost keys and buy 2 more. No unsafe recovery keys, no unsafe backups. All my 4 keys are the exact same level of security. Lastly, now Android allows you to use your android as 1 U2F key(new androids have secure hardware enclave specifically for this), so essentially all that users would need to do is buy 1 hardware key as backup. If you are a service provider, I hope you consider about offering the ability to use U2F keys as secure login mechanism and enforce minimum 2 keys need to be registered - then you disable any other recovery mechanisms. THIS IS THE RIGHT WAY TO DO 2FA in 2019.
peterwwillis 7y ago
Could we not all agree that the only reason we don't like passwords is because people try to remember them, they are reusable, they are simple, and once stolen we have a hard time telling if the user is genuine? If that's the case, can't we default to sending an out-of-bound request (e.g. push to phone, or fall back to TOTP) for authorization, and if that's not available, require a long, random, website-and-account-unique password be entered that is kept in a browser's password manager? The last case, "user lost everything", is more sticky. Can they still log into their e-mail? If so, they can initiate a password reset (and we'll assume that one day e-mail will be secure) and store a new random password in a browser password manager, and register a new external device for push-auth. The hinge point here is the e-mail account, which may need more robust protection. This scheme should work with existing systems without new standards, be resistant to password reuse & cracking, default to a second factor, allow somewhat reasonable recovery, and not require a hardware token. (The idea that the hardware token is needed to defeat phishing is bogus imho; the browser password manager can auto-fill the password field for the correct site, and refuse to do so for phishing sites)
justnotworthit 7y ago
When I see 2FA/password discussions, I check to see if anyone is talking about Gibson's SQRL. They never are. I don't know if it's the best, but I have a feeling we'll see each other in the "Getting 2FA Right in 2029" comment thread too. https://www.grc.com/sqrl/SQRL_Explained.pdf https://www.grc.com/sqrl/SQRL_Explained.pdf
- tialaramex 7y ago
  SQRL isn't able to square the circle on Phishing. The exact formula changes (the document you linked was last updated this month though SQRL started many years ago) but this remains true. The idea in SQRL is that surely if we show the user what they're about to do (e.g. sign into mybank.example), they'll realise they're being phished (e.g. by "notmybank.example") and abort. But the whole _point_ of phishing is that humans don't work that way. In one of Microsoft's early experiments with this stuff they asked users to put their own _real_ bank credentials into obviously bogus sites with a variety of warning conditions to try to understand what's effective. _Nothing_ was effective, ordinary users click past the warnings of imminent doom in order to complete the task. I've written here before about "Brick Wall UX" the practice of designing security systems where there is no way to press on into danger. The reason for Brick Wall UX is that it _works_ and that's what WebAuthn/ U2F deliver for phishing. In other respects SQRL isn't much different than other 2FA options like TOTP, although it has more moving parts. But because it can't fix phishing, it's not worth another look, if you decide phishing isn't scary enough to warrant extra work, TOTP already exists. If TOTP isn't good enough because you're (not unreasonably) scared of phishing, buy some Security Keys and do WebAuthn.
  - BoppreH 7y ago
    I've done research on this, and I'm working on a SQRL alternative. The solution we came up with is an optional browser addon. Websites tag their QR codes as 2FA codes via HTML, the addon captures it and validates against the expected domain (HTTPS assumed), and if it matches then the QR code is promoted as part of the browser's UI or even sent directly to the phone. The goal is to automate away the domain verification. Since the addon doesn't have to know any secrets, it should be installed in as many devices as possible and eventually be included in the browser itself. Also note TOTP is not an equivalent alternative because it has terrible UX in migration/restoration/revocation scenarios.
jsgo 7y ago
I don't know the security ramifications to what they've done, but as a user, I find Blizzard's current implementation to be the golden standard that everyone else's implementation leaves me feeling bummed by. I login, I get the "hey, we just sent the code VH3Z (making it up) to your phone/watch/whatever" and then on both my phone and Apple Watch, I get a prompt saying the Authenticator has that code and do I approve or reject. I tap approve on either device and then the current window I'm in within whatever Blizzard app (whether web or Battle.NET) switches to the actual content. So long as the phone or watch are present and charged, this is such an easy experience.
- deif 7y ago
  Same with Monzo banking app (UK). You buy something from Amazon that goes over a certain threshold: Browser: "Waiting for third party auth". Phone: "Hey did you approve this purchase? Yes/No". Very user friendly, intuitive anti-fraud measure.
a-dub 7y ago
I've always thought that Bitcoin multisig was the best implementation of 2FA. 2 of 3 keys, one you keep hot, one pay someone to hold and sign/log on your behalf (and let you know if something seems off) and one you file away in case the person you're paying to co-sign with you disappears...
ChrisCinelli 7y ago
FIDO2 - https://fidoalliance.org/fido2/ https://fidoalliance.org/fido2/ That seems the state of the art at the moment. I wonder why the article does not even mention that.
ken 7y ago
> with sufficient warnings for users who prefer their accounts to fail-deadly This is unfair. A service, in general, can only know if it's fail-open or fail-closed. Unless you're running a nuclear weapons service (where this term came from) or the like, you don't know which way is "fail-deadly". I love promoting security as much as anyone but let's not throw around scaremongering terms. I'd like my GitHub repos, for example, to be fail-open. If I can't get in, nobody benefits from my junk there being lost forever. Certainly, nobody will die. GitHub doesn't really support that, but at least they don't require 2FA.
rkagerer 7y ago
That long list of ways users subvert 2FA guarantees shows this technology isn't yet user-friendly. (In a sense, passwords aren't either, as seen by all the folks who keep theirs on a post-it note). I'd like to see web developers implementing this also put some effort into ensuring their sites are password manager compatible. Even more kudos if you adopt a sensibly layered approach, allowing more innocuous functions with a traditional login, then prompt for 2FA the first time more sensitive activity is requested.

260 points by dguido 7y ago

I'm a little confused on this risk factor: Use the same QR to provision multiple TOTP applications Poor understanding of what/where their second factor is. Documentation: Tell users to only provision one device What is the risk here? If I have two phones and only one of them on me at a time, why is it dangerous to configure my authentication app on both phones so it's available regardless of which one is in my pocket?

irishsultan 7y ago
Because if you do not know where your other phone is then you do not know who has access. The same issue exists with a single device as well, but to a lesser degree, because it's less likely to be out of your control.
- jandrese 7y ago
  It's in a locked box. And I'm not too concerned about someone breaking my phone security, and then the TOTP app security to get at my second factor. If I'm being targeted that hard they're probably just planning to kidnap me and hit me over the head till I login to my accounts anyway.
DownGoat 7y ago
It better to add two different devices with different secrets to the account, than both sharing the same secret. This reduces the chances that something goes wrong when a device is lost, or removed. The user can the remove the other device with much less risk of locking themselves out of the account. It also might provide some info in the cases where a secret is leaked, as it can be tracked to the specific device. There is no real security risk of the devices having the same secret, or in adding a backup device. It is really a usability thing, the biggest pain point a user will experience with TOTP is when they are switching phones, or when they lose one. Decreasing the friction here can greatly improve the security of the system.
- jandrese 7y ago
  If the service supports that then it's fine. A lot of services only support a single TOTP key per account though. There's a small risk in provisioning multiple TOTP keys on one account too. Each one reduces the search space for a brute force attack. Add in allowances for drifting clocks and a lack of account lockout for missed attempts and you might open up the window just enough for a brute force attack to be successful.
phillipseamore 7y ago
I always use the same QR code to provision more than one OTP app on my (1) phone, since I've had some of them fail on me after updates or OS upgrades.

jandrese 7y ago

Any idea of when HackerNews will support 2 factor authentication?

kogir 7y ago
I actually wrote code for this ages ago when I worked on HN. It’s probably still there, if only in git. But it really only makes sense for the internal, secret parts that are YC related. For the forum just use a unique password.

rmbryan 7y ago

TIL : https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_a...

deleted 7y ago

[deleted]

Dayshine 7y ago

The main problem I have with TOTP (What you're using when you use Google Authenticator) is that the migration path doesn't exist when you get a new phone. This article complains that users are trying to mitigate this problem, but doesn't seem to give any solutions. It's entirely plausible you might have 20 accounts set up using TOTP on your phone. If you now buy a new phone (which users might be doing once every 18-24 months), you need to log into each account and generate a new TOTP key and void the old. That's a couple of hours work. Now, what if you lose your phone? You now have to recover 20 accounts, which will take several days, and it's very possible you won't be able to recover at least one. The common response is "Oh, you should keep one-time keys somewhere". Right, 20 * 10 one-time keys in a single centralised location, and make sure to update them to keep them valid. I thought we were trying to stop people writing their passwords down and storing them next to their computer? Edit: I'm not sure "treat your TOTP keys like passwords and store them" is setting a very good example. Why are we developing systems that use TOTP if we are encouraging users to treat them like passwords, undoing the vast majority of the security benefit?

Operyl 7y ago
There are services, like Authy, that let you back them up encrypted. Whether that is appropriate, when considering the security ramifications, is up to you. I, in the past, have printed out the QR codes and put them in a safe as backups.
- danShumway 7y ago
  Just a heads up, but the last time I checked, Authy did not have secure defaults for 2FA. Authy supports two standards -- the Google Authenticator method, and their own internal standard. Any tokens that go through their internal standard can be recovered on a new phone using just SMS verification, which defeats the entire point. Your encryption password only applies to Google Authenticator tokens. https://twitter.com/DanielShumway/status/1092095395478556674 https://twitter.com/DanielShumway/status/1092095395478556674
  - PuffinBlue 7y ago

use-authy 7y ago

The blog writer doesn't seem to be even remotely familiar with Authy. Most of the issues he discusses have been resolved with Authy.

jessaustin 7y ago
Please provide more details about how your service resolves these issues.

deleted 7y ago

[deleted]

scotchio 7y ago

I wish all 2FA worked like when logging in with your Apple ID. - 2FA by default - Push notifications for the token to all your devices instantly - Not a text message

SketchySeaBeast 7y ago
I'm trying to figure out what exactly Google 2-Step Verification is, and whether to trust it or not. It doesn't appear to be a text, and provides a push notification to your device - it's super convenient, I just don't know if it's particularly strong.
- AgentME 7y ago
  Google 2-Step Verification is vulnerable to phishing just like TOTP is. You can go to a phishing site without realizing it's not Gmail, you enter your username and password, the phishing site gives those to Gmail on your behalf, the phishing site causes 2-Step Verification to happen, and Google sends a push notification to your phone for you to let the attacker into your account. (I believe Apple's default 2FA mentioned by GP works the same way.) Security keys (and the newer project from Google to let your phone act as one over bluetooth) don't have this vulnerability because they connect right to your computer and talk to your browser (and not the attacker's) to verify the domain you're accessing.
  - SketchySeaBeast 7y ago
    But it's still better than SMS, right? How does the security key/browser pair communicate without involving the site? Does it involve more of Google's interference then? While I know you're not saying "yes" to the site, isn't the key doing roughly the same thing?
    - AgentME 7y ago
      >But it's still better than SMS, right? Right, with Google 2-step verification you don't have to worry about number porting attacks. It's just vulnerable in the sense that a phishing site you've entered your username and password into can still trigger the prompt. >How does the security key/browser pair communicate without involving the site? Does it involve more of Google's interference then? While I know you're not saying "yes" to the site, isn't the key doing roughly the same thing? When you use a hardware security key with a browser, your browser tells the security key the page's domain, a user id, and a random challenge token if I remember right. The security key signs a message containing all of these things and gives that back to the browser. If you're on a phishing site, the page will have a different domain than the true site, the message signed by the security key will have the phishing site's domain instead of the true site's domain, and the signed response generated by the security key won't be valid for the attacker to use on the true site.

Avamander 7y ago

I wish someone made a way to securely sync two hardware tokens - for example I agree before setting up any accounts on my tokens that two or three of them agree to sync data. I only have to make sure I do it once in a while. Right now if I lose my TOTP or U2F device without setting both up on all my tokens, I lose access. That's super bad.

floatboth 7y ago
Bitwarden, 1Password, Authy etc. have encrypted sync/backup of TOTP secrets. With hardware tokens.. unfortunately the real solution is "enroll a backup one to all services".
- Avamander 7y ago
  It's not 2FA when you have your password and the TOTP secret in the same place.

Alex3917 7y ago

Every time my leg accidentally hits by YubiKey, everyone on Slack thinks I'm having a stroke. I already set it to require a long press so that it takes a couple seconds, but that doesn't help if my laptop is just at the wrong angle. Anyone else come up with a good solution to this issue?

louis-paul 7y ago
Try this: https://support.yubico.com/support/solutions/articles/15000006461-swapping-yubico-otp-from-slot-1-to-slot-2 https://support.yubico.com/support/solutions/articles/150000...
- Alex3917 7y ago
  Already did that. It doesn't do anything if the side of the laptop is pushing into my leg or the side of the couch or something, which is where it usually happens.
gtsteve 7y ago
I just don't have it plugged in unless I need it. Admittedly I only use it for mail and password manager. What do you do that requires you to authenticate that frequently? Could the authentication state not be cached for a while?
- jrootabega 7y ago
  Keeping it plugged in also increases the chances you'll forget it there when you go to the bathroom. The NFC version of the keys is the best solution to this, imo. You can keep the key attached to your body and not worry about ripping it out when you walk away
billpg 7y ago
You accidentally send one-time passwords to other people? Good job that's not the only factor.
jmalicki 7y ago

supernova87a 7y ago

This article may be right for a corporate environment where you can go to the IT department and prove physically that you are who you are, and get your account recovered should anything go wrong with 2FA. However, if you (like me) use Google 2FA for your personal accounts, you must (if you are sane) keep printed / screenshot copies of the QR codes, backup codes, etc. to be able to recover your account. With Google or any number of services who don't feel they need to get involved in human-being operations, you have nowhere to go for help if you turn 2FA on and then for any reason lose all access to your codes. What if your only phone dies, gets stolen, lost, etc? That is the tradeoff -- security at the expense of having absolutely no way to circumvent it. So the only alternative to not lose your entire online life is to keep several backups and not implement the rules that this guy lays out (which would be appropriate elsewhere).

tptacek 7y ago

Recovery codes should not be mandatory. Recovery codes are not second factors — they circumvent the 2FA scheme. You should, of course, allow users to configure recovery codes. However, the default behavior for a two-factor scheme should always fail closed: if a client cannot produce a valid second factor and hasn’t voluntarily weakened the 2FA scheme by adding an escape hatch, they should not be allowed to continue. This is unrealistic. Users lose 2FA credentials regularly. Think of recovery codes not as a defense for the user, but for the service --- they're keep some number of customers out of your terrifying, manual account recovery flow.

toomuchtodo 7y ago
> they're keep some number of customers out of your terrifying, manual account recovery flow. What is the ideal, secure manual account recovery flow for users? Having worked at a SaaS startup previously (where application login 2FA was mandatory for staff initially, but providing it to end users was discussed extensively internally before eventual roll out), it doesn't seem like there is an easy solution to have random user prove who they are if their 2FA auth goes south (no recovery codes, access to TOTP lost).
- Dayshine 7y ago
  I like the approach some MMOs use: - Provide the printed CD-Key from the game box in full - Provide details about the transaction used to purchase the game (address, date/time, name) - Provide names of characters on the accounts They're not impossible to get if you've compromised someone, but they're far from trivial. In fact, it's actually very similar to the algorithm-based verification my bank uses...
  - popotamonga 7y ago
    Namecheap just asked me a bunch of questions that anyone with access to my mail could answer (all in invoices)
  - pvg 7y ago
    Curiously, Blizzard had hardware tokens (and later phone authenticator apps) 10+ years ago, before most banks and I kind of want to say 'before most consumer online services in general'. And they had the exact same account recovery hellflow problems everyone else has, just earlier.

bjt2n3904 7y ago

> W3C and FIDO finalized the Level 1 WebAuthn specification back in March. Chrome and Firefox already have mature support for it, and Safari is expected to follow. > Upcoming Android releases will allow users to use their phone as a security key, and iOS is expected to do the same. This does not make me happy. Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. I have the same issue with hands free keyless entry/ignition for cars. The feature is solely for convenience, and exposes far too much. The way things work now is the best. When setting up 2FA, I write down my key, and import it into Google Authenticator, or oathtool for the command line. There is no integration, no automation. It works just fine. In the future I'm imagining my 2FA secrets being stolen from my browser, or being used to track me. Google "for my convenience" automatically logs me in so it can track me? Or perhaps, my bank checking my battery level, WiFi hot spots, and the model of phone when it pulls the 2FA tokens to verify my location. Also, I can only log on with their app on my phone, because the tokens are hidden, further making my desktop useless. Maybe a website figures out how to use JavaScript to generate another logins tokens. It takes an hour of tokens, and feeds it into hashcat on AWS to break my key. No thank you. The rest of it though is great. SMS 2FA can die.

woodruffw 7y ago
Hey! Author here. > Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. WebAuthn doesn't specify key storage in the browser. It specifies a common JavaScript API for registering and generating assertions via an authenticator, which in turn stores keys internally. Wanting offline 2FA is perfectly reasonable, and I don't begrudge you that! TOTP is perfectly fine for that purpose, so long as you understand the tradeoffs you make in terms of symmetricity/phishability/replays/etc.
- bjt2n3904 7y ago
  Thanks for the reply. Despite my gripe about this one aspect, your article was very complete and well written. I've bookmarked it to revisit when I need to implement 2FA in projects I'm working on. That being said, I do not like a JavaScript API that provides access to this. JavaScript, JS developers, and the web in general has a horrific track record for security and privacy. To me, this is like the API that provides access to the battery charge state, or my accelerometer for device orientation. Why? Entirely unnecessarily! But it's a cool feature, so let's include it. Suddenly, my keyboard typing is being exfilled through the browser, and I'm being tracked by my battery charge state. Do not want! EDIT: I've maintained this position for "WebBluetooth" too -- a similarly terrible idea. The less my browser does, the better!

kogir 7y ago

I think this article conflates two very different motivations for using 2FA: 1) An organization has valuable resources it wishes to protect and secure from understandable but avoidable user mistakes, like phishing. For example: an employer. Notably, in most of these cases there’s an authority to which the user can appeal to recover account access if 2FA access is lost. It makes sense to be more strict. 2) A user wants to protect something they value, but the provider loses nothing if the user’s account is compromised through user error. For example: personal email. In this case the onus is on the user to ensure they don’t lose access, and the provider may be unwilling or unable to accept the liability of enabling account recovery. The threat models for the two are very different, and in the second case, it’s in the user’s best interest to favor availability of access over all else. I secure my email with TOTP. I have the key stored in 1Password. In all cases 1Password (native app, not web version) is compromised, I’ve lost the battle already. However, I’m not worth burning a zero day on or otherwise targeting specifically. I also have backup codes saved in my personal disk backups. Anyone willing to break into my house to get them could just threaten me more easily. Be very aware why you’re offering 2FA to your users. Are you 1, or 2?

exabrial 7y ago

> Major sites have begun to discourage the use of SMS and voice codes, which are thoroughly broken as second factors Thank goodness. Cell phones and carriers are very soft targets.

DGAP 7y ago
Agreed - but for non-technical consumer 2FA, there's really no other option that users are actually going to use. And SMS 2FA is still orders of magnitude better than just passwords when your threat model is credential stuffing and weak passwords - not attacks on specific accounts.

idlewords 7y ago

I don't understand the prohibition against having the same TOTP seed across multiple devices. Seems like a very useful feature (tap phones to sync TOTP seeds). This feels like a case where religious belief about 2FA has won over real-world usability, especially when people migrate phones.

saxonww 7y ago
I think the answer is that if you share seeds and lose a device, then you really need to invalidate and reprovision all of your remaining devices. If you use separate seeds and lose a device, you just invalidate the one device and move on. From a user's perspective, it seems like a good feature; I'm fine with reprovisioning my 2-3 devices, no big deal, I'm in control of that. From an admin or business perspective, it's less acceptable because if I see something weird and need to invalidate a device, I'm actually preventing my user from authenticating altogether - and that could require more work to recover from depending on where my user is and what my provisioning process looks like.
- idlewords 7y ago
  Why does losing the device require invalidating seeds? If I lose my phone or its stolen, those seeds are still behind a lock screen, and even if they get out, an attacker would need my password.
  - saxonww 7y ago
    Maybe 'requires' is too strong a word. It's hardly mandatory, but I'd argue you should invalidate a lost or stolen seed for the same reason you should reset a lost or stolen password. Of course it is not possible to access something protected by MFA if you only have one factor. But I don't think it follows that making it easy for an attacker to obtain a factor since you have two is OK; the whole point of MFA is that single factors are too easy to guess or steal. Solutions that encourage seed export and sharing make it easier to steal the seed, and leaving a seed active if a device it's on has been lost or stolen is like saying you don't care.

danielpal 7y ago

Founder of Authy here. I've been thinking a lot about this lately and came to the conclusion that the only sensible way to do 2FA are U2F hardware key's. Here's why: First, SMS 2FA. People think SIM port is uncommon, its not (i saw thousands of cases). Your cellphone number its public information - pretty much - and its not a technically difficult attack, you just need to convince a carrier to do it. Once the your SIM is migrated to the hackers possession he will hack into all your accounts before you even realized what happened. Second, TOTP. I founded Authy with the idea that TOTP was strong enough and it is, technically, but in the wild deployments have lots of issues. Biggest one is people constantly change/loose their phones. So you end up with a update issue. At Authy we solved it by encrypting the seeds and storing them on the cloud. But today most users just copy the QR-Code, or store their TOTP key along with their passwords in the password manager. Storing your TOTP in your password manager completely defeats the point of TOTP, it just provides you with a false sense of security. Lastly, because it generates a lot of support issues when people loose their phones, services have added ways to bypass 2FA in their account recovery flows. You'll see backup codes or simply SMS as a recovery mechanism. This means your TOTP is as safe as SMS if your recovery allows it. TOTP today is so misused its just providing a false sense of security. Third, U2F Hardware tokens. Its finally possible to do U2F to the iphone via Bluetooth and Feitan now has a key that supports it (Google sells one for project Titan). You can buy 2 keys for $50 dollars. It's impossible to missuse U2F tokens - you can't unsafely back-them up, you can't "screenshot them", etc, hardware enforces their security. They are 100% un-phishable, its impossible to trick a user into signing a login on a fake site - the key will simply not sign it, and there is no way for the user to make an "exception"(like you can if the SSL cert is invalid.). Also given the price and form factor is easy to buy 2 or 3 and have a few stored as backups. In my case I have 4 keys, 2 that I use on daily basis, and 2 I stored as safe backups. If I were to loose 2, there is no way of knowing they belong to me and tie them back to my account and I would just use the backup keys to logon, remove the lost keys and buy 2 more. No unsafe recovery keys, no unsafe backups. All my 4 keys are the exact same level of security. Lastly, now Android allows you to use your android as 1 U2F key(new androids have secure hardware enclave specifically for this), so essentially all that users would need to do is buy 1 hardware key as backup. If you are a service provider, I hope you consider about offering the ability to use U2F keys as secure login mechanism and enforce minimum 2 keys need to be registered - then you disable any other recovery mechanisms. THIS IS THE RIGHT WAY TO DO 2FA in 2019.

peterwwillis 7y ago

Could we not all agree that the only reason we don't like passwords is because people try to remember them, they are reusable, they are simple, and once stolen we have a hard time telling if the user is genuine? If that's the case, can't we default to sending an out-of-bound request (e.g. push to phone, or fall back to TOTP) for authorization, and if that's not available, require a long, random, website-and-account-unique password be entered that is kept in a browser's password manager? The last case, "user lost everything", is more sticky. Can they still log into their e-mail? If so, they can initiate a password reset (and we'll assume that one day e-mail will be secure) and store a new random password in a browser password manager, and register a new external device for push-auth. The hinge point here is the e-mail account, which may need more robust protection. This scheme should work with existing systems without new standards, be resistant to password reuse & cracking, default to a second factor, allow somewhat reasonable recovery, and not require a hardware token. (The idea that the hardware token is needed to defeat phishing is bogus imho; the browser password manager can auto-fill the password field for the correct site, and refuse to do so for phishing sites)

justnotworthit 7y ago

When I see 2FA/password discussions, I check to see if anyone is talking about Gibson's SQRL. They never are. I don't know if it's the best, but I have a feeling we'll see each other in the "Getting 2FA Right in 2029" comment thread too. https://www.grc.com/sqrl/SQRL_Explained.pdf https://www.grc.com/sqrl/SQRL_Explained.pdf

tialaramex 7y ago
SQRL isn't able to square the circle on Phishing. The exact formula changes (the document you linked was last updated this month though SQRL started many years ago) but this remains true. The idea in SQRL is that surely if we show the user what they're about to do (e.g. sign into mybank.example), they'll realise they're being phished (e.g. by "notmybank.example") and abort. But the whole _point_ of phishing is that humans don't work that way. In one of Microsoft's early experiments with this stuff they asked users to put their own _real_ bank credentials into obviously bogus sites with a variety of warning conditions to try to understand what's effective. _Nothing_ was effective, ordinary users click past the warnings of imminent doom in order to complete the task. I've written here before about "Brick Wall UX" the practice of designing security systems where there is no way to press on into danger. The reason for Brick Wall UX is that it _works_ and that's what WebAuthn/ U2F deliver for phishing. In other respects SQRL isn't much different than other 2FA options like TOTP, although it has more moving parts. But because it can't fix phishing, it's not worth another look, if you decide phishing isn't scary enough to warrant extra work, TOTP already exists. If TOTP isn't good enough because you're (not unreasonably) scared of phishing, buy some Security Keys and do WebAuthn.
- BoppreH 7y ago
  I've done research on this, and I'm working on a SQRL alternative. The solution we came up with is an optional browser addon. Websites tag their QR codes as 2FA codes via HTML, the addon captures it and validates against the expected domain (HTTPS assumed), and if it matches then the QR code is promoted as part of the browser's UI or even sent directly to the phone. The goal is to automate away the domain verification. Since the addon doesn't have to know any secrets, it should be installed in as many devices as possible and eventually be included in the browser itself. Also note TOTP is not an equivalent alternative because it has terrible UX in migration/restoration/revocation scenarios.

jsgo 7y ago

I don't know the security ramifications to what they've done, but as a user, I find Blizzard's current implementation to be the golden standard that everyone else's implementation leaves me feeling bummed by. I login, I get the "hey, we just sent the code VH3Z (making it up) to your phone/watch/whatever" and then on both my phone and Apple Watch, I get a prompt saying the Authenticator has that code and do I approve or reject. I tap approve on either device and then the current window I'm in within whatever Blizzard app (whether web or Battle.NET) switches to the actual content. So long as the phone or watch are present and charged, this is such an easy experience.

deif 7y ago
Same with Monzo banking app (UK). You buy something from Amazon that goes over a certain threshold: Browser: "Waiting for third party auth". Phone: "Hey did you approve this purchase? Yes/No". Very user friendly, intuitive anti-fraud measure.

a-dub 7y ago

I've always thought that Bitcoin multisig was the best implementation of 2FA. 2 of 3 keys, one you keep hot, one pay someone to hold and sign/log on your behalf (and let you know if something seems off) and one you file away in case the person you're paying to co-sign with you disappears...

ChrisCinelli 7y ago

FIDO2 - https://fidoalliance.org/fido2/ https://fidoalliance.org/fido2/ That seems the state of the art at the moment. I wonder why the article does not even mention that.

ken 7y ago

> with sufficient warnings for users who prefer their accounts to fail-deadly This is unfair. A service, in general, can only know if it's fail-open or fail-closed. Unless you're running a nuclear weapons service (where this term came from) or the like, you don't know which way is "fail-deadly". I love promoting security as much as anyone but let's not throw around scaremongering terms. I'd like my GitHub repos, for example, to be fail-open. If I can't get in, nobody benefits from my junk there being lost forever. Certainly, nobody will die. GitHub doesn't really support that, but at least they don't require 2FA.

rkagerer 7y ago

That long list of ways users subvert 2FA guarantees shows this technology isn't yet user-friendly. (In a sense, passwords aren't either, as seen by all the folks who keep theirs on a post-it note). I'd like to see web developers implementing this also put some effort into ensuring their sites are password manager compatible. Even more kudos if you adopt a sensibly layered approach, allowing more innocuous functions with a traditional login, then prompt for 2FA the first time more sensitive activity is requested.