
Why aren't PGP and SSH keys popular as a second factor for authentication? - verandaguy
https://security.stackexchange.com/questions/127288/why-dont-pgp-and-ssh-keys-see-more-widespread-use-as-a-second-factor-when-authe/127310
======
mfontani
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://news.ycombinator.com/item?id=9425805)

[https://www.reddit.com/r/netsec/comments/3frnxb/my_ssh_serve...](https://www.reddit.com/r/netsec/comments/3frnxb/my_ssh_server_knows_who_you_are_seriously_try_ssh/)

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"

~~~
kerkeslager
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.

~~~
dice
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.

~~~
niftich
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.

~~~
frumiousirc
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.

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

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

~~~
niftich
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.

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

~~~
niftich
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](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)

~~~
jdc
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!).

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

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

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

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

~~~
nommm-nommm
They verify your phone number.

------
fidget
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

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

~~~
elahd
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.

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

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

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

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

~~~
wlesieutre
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.

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

~~~
colejohnson66
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](https://en.wikipedia.org/wiki/RSA_SecurID)

~~~
niftich
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...](https://en.wikipedia.org/wiki/Time-based_One-
time_Password_Algorithm) [2] [https://www.vasco.com/products/two-factor-
authenticators/har...](https://www.vasco.com/products/two-factor-
authenticators/hardware/one-button/)

~~~
colejohnson66
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

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

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

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

------
tacos
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](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
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.

~~~
mikekchar
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.

~~~
atonse
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?

~~~
nickpsecurity
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.

