Why aren't PGP and SSH keys popular as a second factor for authentication? | Hacker News Reader

Why aren't PGP and SSH keys popular as a second factor for authentication?

security.stackexchange.com

117 pointsverandaguy73 comments

I'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://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"

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

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

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

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

*6 attempts, I just looked that up today :)

Do people not already do this? I don't really make an effort to use a different keypair for every service, but I ran into the the max-attempts thing very soon after I started using ssh-agent, and so I do have to keep my .ssh/config up-to-date. I assumed the benefit for ssh-agent was in not having to retype the passphrase for each connection, not for it to try every keypair for every login.

Is there a way to specify the hashed key fingerprint (or a just-long-enough subset of the key fingerprint) instead, as you try to authenticate to a specific host?

Or an interactive key selection on the command-line? With a 'Remember my choice' option. These could be relatively easy UI enhancements for a command-line SSH agent.

With the agent the -i flag or IdentityFile config option is not honored.

You then must maintain different agents, one for each distinct set of keys you want to use. The ssh-ident package helps do this.

Or, you must insert a filter proxy between the real agent and the ssh client. The ssh-agent-filter package helps do this.

That's true, but I keep an up-to-date entry for each of my servers in my ~/.ssh/config anyway. Some of them don't even have hostnames; they only have IPs. I can't imagine having to remember that.

That is very annoying; luckily, it's possible to use %h and other variables to embed the remote host name in the file name of the key. Definitely useful to also have IdentitiesOnly set to avoid the automatic attempts, though.

Or just manually specify which keyset to use with the SSH "-i" identity option for the specific thing you're connecting to. I could have a hundred different public/private key sets stored in my ~/.ssh/ if necessary.

If you keep your keys on a smartcard, you'll need a number of cards that grows linearly with the number of keys.

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

What if we had an web API for using client certificates? Would that help with usability?

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

Thanks for the informative response. Can you express in some more detail the user agent problem we have?

Sure. 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 [2] https://docs.webplatform.org/wiki/apis#List_of_all_APIs [3] https://developer.mozilla.org/en-US/docs/WebAPI [4] https://www.grc.com/sqrl/sqrl.htm

Okay that's plenty of background info. So why not expose something like p12U_ImportPKCS12Object() to the web? You could generate and store the key and cert on the user's mobile device and have an app for pushing the cert via Bluetooth (which has a web api). Let the user and web server app sort out what his handle will be. It can be treated as a separate problem (however interesting it might be!).

The problem is that the UX on the browsers for using client certificates is horrible.

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

google has 2FA with HOTP/TOTP just fine, which doesn't leave any extra information to them

all their consumer services are in the business of mining your data. 2FA is just the icing on the cake.

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

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

> Also, try calling me on my public key.

Check out http://telehash.org

Google requires a phone number to create an account nowadays no matter if you use 2FA or not.

This is not the case when creating a new account from an Android device.

It is not true anywhere. GP is simply talking out of his ass.

There was definitely a time, maybe a few years ago in the 2013-2014 range, when opening a new Gmail account required a phone number to activate[1]. The rule wasn't applied to every one, it was based on some heuristic or another.

Though, amusingly enough, you could use a Google Voice number and there was no limit to the number of accounts one number could activate (at least not that I noticed).

1 http://timesofindia.indiatimes.com/tech/tech-news/Google-Yah...

The reason why I make my throwaway email accounts with gmx.com is because when I tried to create Google or yahoo addresses they both required a phone number. Yes, I am aware that wasn't a requirement 10 years ago. You also got my gender wrong.

Once you set up 2fa via their code generator, you can remove the phone number from your account.

Or use a throwaway phone number, then remove the phone number.

They verify your phone number.

Absolutely not true at least from France. They severely insist you provide one, but if not they can Auth you from another mail address.

Last week I traveled home and Google did not let me login to my account because they were somehow 'suspicious' it was not me using my password (same machine). They wanted to force me to provide my phone number, even though I never asked for 2FA. Not truly a dark pattern, but shady anyway, expecting nothing less from a prism company.

ot. I guess you are downvoted because the element of truth in your comment (e.g. 2FA is data collection) hit some nerve. Just yesterday a similar 'questioning 2FA panacea' comment was downvoted, even though it was just arguing about the security aspects.

I'm sorry but if you purposely haven't opted for 2 Auth, then Google asking for a similar thing when they have a doubt is not shadowy. It's definitely in the real of needed. Do you realize what a Google account / identity means on today's Web?

They want your number so they can prevent you from creating multiple accounts or know which accounts are linked to your real identity.

If 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

I had recently reset phone and had lost my 2FA recovery codes. This was how I was able to recover my account.

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

How do we know it's encrypted in a way they can't see?

The same way you know (or don't) that your existing OTP app is not uploading your secret key.

You don't, but that's fine for my risk profile. I use LastPass, as well, with different passwords for every site and 2FA where available.

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

And how well does your carrier verify your identity?

Now this worries me, beacause in my country you just call to your carrier and ask the number to be deleted, you just need to provide your name, then anyone can cancel your number.

What country, may I ask?

Mexico

About my previous reply, that is if I recall correctly, I remember being able to cancel numbers of lost phones providing the number and the name of the owner (in this case, one time I lost my number, other times my dad lost his')

You might find the SQRL system by Steve Gibson interesting.

https://www.grc.com/sqrl/sqrl.htm

Read the "What happened behind the scenes" box for the details. I think it's pretty clever.

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

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

Authenticator 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

Kickstarter idea: a pebble, but just as a 2FA, on your wrist.

Wasn'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

RSA 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_A... [2] https://www.vasco.com/products/two-factor-authenticators/har...

Right, my mistake. I wasn't sure when I was writing the comment. When I made the edit, I forgot to change the "magic of RSA" part

That reason is why I have my various 2fa credentials available from my computer as well. Problem is that I have some that either use a text message or the Authy API, which has abysmal desktop support.

It's best to have the codes on multiple devices. Might not help in the short term ie 'left my phone and won't be home to use my tablet until 9'.

But in the event our phone was stolen, it can get pretty tough to recover some accounts once you've set up 2fa. If it's not, then there's really no point in having 2fa on the account at all.

EDIT: Also of note, If you don't have a second device, a yubi key will store all the codes on the key. So any phone/laptop with the yubico auth app will be able to show the codes if you wanted to use that for a backup.

Well, the kind of 2fa that simply sends you a text message, once you get a new phone with the same phone number, you're back in. Which can happen pretty quickly.

But yeah, I think there are probably a variety of 2fa nightmares that we'll only start encountering/discovering in the near futre, some amount of time after 2fa reached critical mass.

if your services doesn't provide fallback options for 2FA (TOTP/SMS/paper codes) I'm inclined not to consider enabling 2FA at all, it's just too risky.

I dislike sms since the most likely device I own to get stolen is my phone. Also, the codes aren't sent to your locked secured phone, they are sent to your SIM card.

Paper codes are the same as having a second device with TOTP, you probably won't carry them with you everywhere (both should be an offsite backup).

Print out the backup codes, and keep them in your wallet (or a safe at home). You should do that, anyway, in case your device gets stolen. Most sites which use 2FA tell you to do that right when you enable 2FA.

^ This. Print your QR codes and put them in the safe.

I put all my 2FA credentials into my Yubikey as well. Plus, if I lose it, you have to guess my PIN in three tries, otherwise the secrets get deleted.

Convenient blockchain wallets, on the desktop and in the browser as extensions, will make this approach much more widely used by consumers.

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

I am using duo security (duo.com) these days. Instead of having to type in a number, you just have to press confirm / deny.

There 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

For yet another sadly ignored, co-opted, would-be-standard: https://tools.ietf.org/html/rfc4880

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

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

Yeah 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?

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

Reply on news.ycombinator.com