20 ms·
Why aren't PGP and SSH keys popular as a second factor for authentication?
- tacos 10y agoThere was a ton of FUD around PGP and encryption export legalities and commercial use. There was a window to make this stuff standard 20 years ago and we, as technologists, totally whiffed on it. The "these are not web technologies" quip at StackExchange made me cringe for some reason. As if this has anything to do with web protocols. For the sordid history: https://en.wikipedia.org/wiki/Pretty_Good_Privacy https://en.wikipedia.org/wiki/Pretty_Good_Privacy For yet another sadly ignored, co-opted, would-be-standard: https://tools.ietf.org/html/rfc4880 https://tools.ietf.org/html/rfc4880
- atonse 10y agoMaybe – but I still think the problem with tools like PGP are the user experience, and not any underlying tech. If you look at things like WhatsApp and iMessage, they give you the same kind of security in a completely transparent way. And I believe Whisper/WhatsApp also give you a cool way to verify keys in person (I believe they use QR codes?) So public key crypto is here, and it's widespread. It's just not in the form of PGP, and that's because of the UX shortcomings of PGP. On a side note, Keybase really is awesome – I have setup keybase and am hopeful for it, but I feel even in that case, if you try to do PGP, it feels a bit odd.
- mikekchar 10y agoIt's not just the UX. A very good example: what does "signing a key" mean? You've got public/private key pairs (both of which are called "keys" in some places), you have a master "key" and sub "keys". The master key is called "the key" but doesn't actually contain the sub keys (which are also called "keys". When you sign a "key" what actually gets signed? (Hint: not a key) Where does the signature go? Etc, etc, etc. The Open PGP protocol is just insanely complicated because it took many different iterations to get right and they didn't want to break backward compatibility. The documentation that tries to explain it is downright wrong because they don't want to go down the rat's nest that is the protocol. So even most technically savvy users have absolutely no idea what's going on. Unfortunately, it can't really be fixed with UX, IMHO. I think we need to learn from Open PGP and design something that doesn't make people's heads (even programmers) explode.
- atonse 10y agoYeah honestly I'm curious as to why Keybase is using PGP – is it really that widespread, or is it that PGP is so hardened with time? I know the keybase devs lurk around here. Is there perhaps a way to use the Signal Protocol instead of PGP?
- nickpsecurity 10y agoIdk about Keybase but I recommended GPG because it was one of only three or so tech the NSA couldn't break per Snowden leaks. They were smashing most stuff. So, my recommendation was modifying proven code to put a better UI on it that ignored most of the complexity to focus on just fundamental features. Note: Keybase with with their own PGP implementation. Idk what its security is going to be like. I see why they'd use tech that's had years of auditing and attacks, though.
- jamespitts 10y agoConvenient blockchain wallets, on the desktop and in the browser as extensions, will make this approach much more widely used by consumers.
- znpy 10y agothis is extremely important: just yesterday I forgot my phone at my university (luckily it hasn't been stolen) and realized that i was cut out of most services that use my phone as second authentication factor.
- wlesieutre 10y agoGet a pebble! You can have TOTP codes on your wrist where it's a lot harder to lose. Presumably similar apps available for Android Wear and Apple Watch, but those are too smart for my tastes.
- fps 10y agoAuthenticator Plus[1] has an android wear view, but it goes into lockdown mode if your phone is offline. Luckily (but also insecurely) it also supports regularly backing up two factor codes to google drive with gpg encryption, for when you crack the digitizer on your phone and need to get a new phone. 1: https://play.google.com/store/apps/details?id=com.mufri.authenticatorplus&hl=en
- simonebrunozzi 10y agoKickstarter idea: a pebble, but just as a 2FA, on your wrist.
- colejohnson66 10y agoWasn't there some RSA authentication fob you could attach to your keys a while back? It generated keys like Google Authenticator and worked without internet thanks to the magic of RSA. EDIT: RSA SecurID[0] [0]: https://en.wikipedia.org/wiki/RSA_SecurID https://en.wikipedia.org/wiki/RSA_SecurID
- niftich 10y agoRSA is the company, the RSA algorithm isn't involved in this product. It actually uses a TOTP [1], a variant of HOTP. Here's the famous Blizzard authenticator in the manufacturer's original branding [2], from a competitor. There are others like this. [1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_A... [2] https://www.vasco.com/products/two-factor-authenticators/hardware/one-button/ https://www.vasco.com/products/two-factor-authenticators/har...
- fidget 10y agoIf you loose your github 2FA, they will ask that you prove your identity by SSHing to some host and providing them with the token returned by that host
- mnkmnk 10y agoI had recently reset phone and had lost my 2FA recovery codes. This was how I was able to recover my account.
- elahd 10y agoTake a look at Authy as a drop-in replacement for your Google Authenticator app. Codes are encrypted and stored on Authy's servers -- they can be re-synced to your phone after a wipe. There's also a Chrome plugin that syncs with the mobile app.
- colejohnson66 10y agoHow do we know it's encrypted in a way they can't see?
- deleted 10y ago[deleted]
- Johan-bjareholt 10y agoYou can also have a backup phone number on most websites (google, github, dropbox). If you lose your phone you call your carrier to block that sim card and request a new one anyway, so you're not locked out.
- textmode 10y agoBecause Google et al. want your phone number for certain commercial uses unbeknownst to you? Is it possible that personal information could be more valuable to these web companies than hex digits? Marketers cannot do much with a block of hex but they will pay for a working phone number. Collect enough personal information about people and in today's world you have a valuable company.
- riffraff 10y agogoogle has 2FA with HOTP/TOTP just fine, which doesn't leave any extra information to them
- propogandist 10y agoall their consumer services are in the business of mining your data. 2FA is just the icing on the cake.
- aclatuts 10y agoI think a public key is just as identifiable as a phone number and just as prone to data collection anything else. Although in this scenario it would be easier for the security conscious , to have multiple private keys.
- a_imho 10y agoExactly, you can generate multiple keys with a push of a button, while your phone number is very personal, supplemented by a contract with an operator. Also, try calling me on my public key.
- deleted 10y ago[deleted]
- zaroth 10y ago> Also, try calling me on my public key. Check out http://telehash.org http://telehash.org
- hannob 10y agoThere's a much more obvious choice: TLS with client certificates. It's already available in mainstream browsers. The key question for all of these solutions is usability.
- jdc 10y agoWhat if we had an web API for using client certificates? Would that help with usability?
- niftich 10y agoLike, TLS client certificates? No. The TLS handshake needs to occur before any other content is exchanged. This is a user-agent problem to solve, not a code-executing-inside-the-user-agent problem. If you meant some other notion of 'client certificates', that's called a password manager.
- jdc 10y agoThanks for the informative response. Can you express in some more detail the user agent problem we have?
- niftich 10y agoSure. The thread's origin refers to TLS. Like some others have said, this is a UI/UX issue, and the UI needs to exist in the browser/curl/httpclient, as that takes the role of the client in the TLS handshake. The existing UX for selecting -- and managing -- keys and certificates is bad, and the cognitive load of these to the user is high. We don't know what a good UI would looks like because no one has made one yet, but the competition is existing 2nd factors: hardware token generators, software token generators, confirmation emails, confirmation texts, etc. I assume by Web API you meant some functionality hook exposed in the browser which the website/webapp can access, like WebRTC [1], or web workers and others [2][3]. The sort of API you entertain would be useful for application-level authentication, but from the perspective of the end-user, it would fulfill a similar purpose to password managers. Bootstrapping this identity to contain useful data is the biggest issue. There is a similar proposal by security researcher Steve Gibson called SQRL [4], which sends a site-specific public key to a website generated from a master key the app keeps. This scheme is pretty good but it's designed to mint uncorrelatable, anonymous identities, so you're not 'jdc' at HN and other places, but [RANDOM STRING] at HN, and [DIFFERENT RANDOM STRING] at some other site. I am, however, curious how you'd envision a web app would hook into such an API, and what functionality it would offer. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API [2] https://docs.webplatform.org/wiki/apis#List_of_all_APIs https://docs.webplatform.org/wiki/apis#List_of_all_APIs [3] https://developer.mozilla.org/en-US/docs/WebAPI https://developer.mozilla.org/en-US/docs/WebAPI [4] https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- mfontani 10y agoI'd be wary of "proving one's identity" via (one of) one's SSH key by connecting to an unknown SSH host. The main reason is a (maybe not on HN) little known scenario where the user has SSH key forwarding enabled, and the host they SSH to takes that forwarded identity and uses it to, say, fetch your private repos on github and the like. https://news.ycombinator.com/item?id=9425805 https://news.ycombinator.com/item?id=9425805 https://www.reddit.com/r/netsec/comments/3frnxb/my_ssh_server_knows_who_you_are_seriously_try_ssh/ https://www.reddit.com/r/netsec/comments/3frnxb/my_ssh_serve... I'd have _no problems at all_ signing a pgp message the likes of "I'm proving I am myself, and that you requested me to sign also with token QIMdoV76LIvymGvTxXEB8LkIIqfM4nEm5W"
- marcosdumay 10y agoIn both cases, the key must be unique for the site. In both cases, key reusing would be very dangerous. But in both cases, you can have a single published key you can use to sign the site-specific shared keys.
- tokenizerrr 10y agoWell, most SSH keys are RSA keys. Could it not also be used for signing? Also you could use a special alias/command (-a) that explicitly disables agent forwarding.
- kerkeslager 10y agoThis is pretty easily solved by using different keys for each service you wish to authenticate with (the same idea as using different passwords, basically). I already do this when pushing to GitHub over SSH versus SSHing into my own server.
- dice 10y agoThis can become problematic if you're using an SSH agent and have 4+ keys loaded into it. The problem is that your agent will step through keys to try auth with, but most OpenSSH servers will reject keys after 3 failed attempts. This means that you also need to keep an up-to-date entry in ~/.ssh/config as to which key to use with which system.
- chrisper 10y agoI am using duo security (duo.com) these days. Instead of having to type in a number, you just have to press confirm / deny.
- criddell 10y agoYou might find the SQRL system by Steve Gibson interesting. https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm Read the "What happened behind the scenes" box for the details. I think it's pretty clever.
- vonklaus 10y agoI was thinking about this yesterday. Other than PGP keys, what about cell phone numbers? Everyone collects email, but for real transactional services, a phone is better and an email doesn't matter.