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.
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.
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.
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.
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.
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.
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
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.
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.
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')
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.
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.
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).
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.
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?
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.
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.
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!).
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.
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"
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.
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.
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.
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.
75 comments
[ 3.0 ms ] story [ 157 ms ] threadThere 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
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.
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.
I know the keybase devs lurk around here.
Is there perhaps a way to use the Signal Protocol instead of PGP?
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.
Presumably similar apps available for Android Wear and Apple Watch, but those are too smart for my tastes.
EDIT: RSA SecurID[0]
[0]: https://en.wikipedia.org/wiki/RSA_SecurID
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...
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.
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.
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).
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.
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')
Check out http://telehash.org
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...
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.
The key question for all of these solutions is usability.
If you meant some other notion of 'client certificates', that's called a password manager.
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
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"
But in both cases, you can have a single published key you can use to sign the site-specific shared keys.
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.
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.
https://www.grc.com/sqrl/sqrl.htm
Read the "What happened behind the scenes" box for the details. I think it's pretty clever.