Web login using SSH
github.com
github.com
Does this ring a bell? That's right, it's BrowserID ladies & gents. I'll never let this go, Persona was a great thing for the web and its death is mourned.
I think I've seen ssh auth implemented before but this is the smoothest POC yet. Your next step: Make a firefox extension that integrates this, as a proof of concept for in-browser authentication.
> I'll never let this go //Using this as an excuse
> Your next step: Make a firefox extension that integrates this
Do it while it is still possible, before Mozilla carries out their plan to lobotomize Firefox and bring it down to the level of Chrome like they have planned. :)
https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
Chrome has most features I need and makes up for missing ones with nicer implementations of others, or has them before Firefox does. Firefox freezes regularly for seconds, feels slower in many situations and degrades quicker if you open to many tabs (Chrome just eats ton of RAM, but can deal with many hundreds of open tabs otherwise). Oh, and faulty sites crash the entire Firefox instance instead of just a tab.
Firefox is about to get multiprocess feature in full releases, I hope this will fix many of these issues.
What am I missing out on in terms of plugins/extensions that Firefox can do that Chrome can't? It's been a couple years, but I don't feel like I'm missing anything in Chrome..
Tree style tabs
Scrapbook extension (misleading name, dowloads pages recursively and let you search locally)
My opinion is that BrowserID had a very flawed core concept. I firmly believe that my identity is something that I [can] naturally define and possess. But everyone since OpenID had stolen this from the end-user and identities became something that you're provided with - and I find the very term "identity provider" unnerving.
With identity providers you're not you anymore, but merely your Facebook account or your email address or your domain name - a things you only temporarily lease from a third-party like an email provider or a domain registry. Sure, there's some common sense, legal protections and stuff, but I'm don't like merely relying on those. I think, in a sane world, at least personal (i.e. non-group) identities must be merely asserted, not provided - and they must originate from a person themself.
On the contrary, this login-with-ssh thingy and few other schemes (gpgAuth and WebID) are much closer to what the things should be like. While they don't yet completely resolve the distinction between an identity and a credential (it's really hard), they root your identity in something that you can actually define for yourself and handle without depending on anyone else - a key pair.
Yet, I'm particularly against about the BrowserID adoption because it helps to cement the idea of leased identities. At the moment, we're still with in the "warring states" world, where no particular scheme had won. This could've changed with BrowserID embedded in the User-Agent, so I fear it would be at least a decade until we'll be able to talk about something else.
WebID, being a W3C WG, could've also hit big... It's not perfect, but from my understanding of the drafts it looked better than BrowserID to me. But no luck here.
Persona/BrowserID simply reuses the concept of email address as identity (and email host as identity provider). This is honestly already pretty heavily cemented in the web (I think the war has long since been lost): almost every website uses in some way emails as natural keys for identities and with the critical overuse of email as the medium for "Forgot Password" login schemes, email hosts are already everyone's de facto identity providers.
At least there is more personal choice involved in email hosts, and indeed sometimes direct ownership in paid email accounts, unlike the walled garden monopolies we see in Twitter/Facebook/Google "social" logins.
I think that the first major standard to come - that'd be embedded in the browser - could change this game rules, because it must be (well - I don't know, I just think it is) a big thing. Even users who don't care would've bought secure yet seamless authentication, neat identity management and so on. But not something after this, because the momentum would be lost and there won't be enough incentive to switch.
So, the first standard must have something sensible as credential, or - I fear - it will be a long time before we can hope for any changes. Maybe I'm wrong here.
It is possible to care about privacy and still accept a more convenient (less secure) way to access specific things.
If we step back a bit and look at the problem, the main thing that sites should care about is proof. That is, I'm essentially a number (an opaque, abstract identity), and all the site should want is for me to be able to prove that I am that number. We should forget about email addresses, user names and passwords. A site should be able to request real-world identity information such as your name and address, but there's no need to comingle that with login. A site that isn't an e-commerce app generally has no business getting at that data in the first place.
Such a system would be a boon to implementors, too. As a developer, I would greatly appreciate not having to implement another damn account/login system just so that I can remember my visitors.
But nothing is going to happen until browsers implement such identity management natively, and the only way to get there is for the browser developers to collaborate on the tech.
It's not tangible, because domains aren't, but it's a lot more like owning a car than leasing a car. The ownership is stronger than for my phone number or my birth name, for example.
While the term identity provider might not sound well, it is necessary for a system where you have multiple identities. And I think it's pretty well established that that is a requirement for the modern web.
I do agree that Persona with a personal domain is a much better system, but why should it be necessary to have one to avoid being tied to a third-party IdP?
Ultimately yes, if you want to sign in to a website with your email address you typically have to trust your email provider. This is true on the web almost universally with or without Persona.
Why is any IdP required by Persona? Identity protection and reuse across browsers are two big reasons. If I want to say that I am/use the email "wm@example.com", Persona tries to verify that I actually have access to that email (can sign in to my email provider, or can do the classic click a random token link in an email cycle if my email provider isn't supported).
It's a luxury those days, with email providers snooping over messages to show your advertisements and all sort of TLAs snooping just because they feel so. There is some buzz about end-to-end encryption out there for a reason, and the reason is a lot of people don't trust their email providers.
But I reasonably do. I'm hosting my email myself, on the hardware I own, located on my own premises. Although I may get hacked - one can't be ever sure they won't - most modern systems are too complex for any single human to grasp and sometimes bad things just happen.
But I don't trust my domain registrar and the network. DNS may get poisoned/spoofed, network may be tapped and traffic redirected, registry or nameservers may get hacked or subpoenae'd (ok, I'm not a criminal, but who has a protection from powerful authorities if they suddenly decide they want you?) and whatever else.
And if you decide you do, the requirements are a lot more relaxed. With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity.
However, if - for example - you have an identity asserted by a keypair - you have way more possibilities, ranging from a key backup in a tamper-resistant HSM in a safe vault behind a blast-resistant doors in your basement, or setting up a secret sharing scheme where 3 out of 6 your close friends must get together to help you recover a lost key, to just uploading your key to Dropbox and not giving a damn. Isn't that a good thing?
And if the key's completely lost - it's the same as if the email provider's gone - you'll have to either give up or recover your accounts using some other ways (talking to a support and figuring out what would be a good replacement proof).
Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users. Users have trouble remembering passwords, key management is seemingly beyond most users. So too are systems like the "web of trust" model of key identification much to complicated (and onerous and time consuming) for the average user.
IdP is the best bet we have of at least somewhat decentralizing trust decisions in a way that is user friendly.
«With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity.»
This is not a requirement of Persona. You can use any email you like with Persona and it's not a platform requirement that user accounts in a system be one-to-one with email addresses. It's certainly possible a site using Persona can very easily tie multiple identifying emails to your account. It may not be likely that a lot of sites would do it, as one email, one person is a rather generally accepted identity world at the moment, but it's also not far fetched that the replacement for the "Forgot Password" button in a hypothetical universe where Persona is the only option is a "Associate another email address to your account" button.
«However, if - for example - you have an identity asserted by a keypair»
But what good is this assertion? How do I as an application provider trust your assertion? At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0". You could self-assert an email address or a name/pseudonym, fine, but as an application provider I can't make any assumptions about the contents of that email address or name/pseudonym and the only trust I have in it is "your word". You could use web of trust assertions, but again we get into the bootstrapping issue of "web of trust is hard" and "users don't want to have to do it".
The same goes for all of your hypothetical key management: yes, you can manage a key on your own cognizance in any number of ways. Ultimately, most people just don't want to.
On the flipside, Persona too has more options in this space for IdP management and key management than maybe you've given it thought: There's a Mailinator-based IdP that will sign any key request from Persona for pseudonymous identities (while even maintaining the application provider assertion that the email is valid and accessible to that user). There's the ability to do IdP delegation from a domain, using a file on my website to choose which IdP I trust right now, which can easily change over time. (Static HTTP sites on custom domains are cheap as free, including Github Pages as one option.) There are more ideas out there and you can reasonably approximate whatever half-finished idea you have for your own key management system with Persona given a little bit of time and elbow grease.
So, let them put their unencrypted keys on, err, Firefox Sync or Dropbox or whatever, and not give a damn. It would be almost exactly the same security level - identity conveniently secured by an external service.
I just don't see a downside. Yes, the keypairs don't have a human-readable name - but they don't have to, they're just like passwords, except for they can be globally recognized (if user wants to). Yes, for non-paranoid users' convenience we need some sort of key escrow system with some trusted party that can take hold of a file - but that's well possible and I think every other user has some "cloud storage" those days.
> This is not a requirement of Persona.
Yes, you're right. I simplified it a bit. A requirement of Persona is that IdP is a very specific service identified by a domain name, not an email. But the rest of logic should still hold.
> How do I as an application provider trust your assertion?
Generally, you don't need to check assertions, unless you want to confirm that this specific user has some affiliation with this specific third party. Then you check a signature from that party.
If you don't need an information that your user is also a specific person on, say, Facebook, or, say, a representative of some company (verified by a notary) - you don't need to care about any assertions. You just take a key and that's it.
Seriously, an average service does not need any identity assertions. Do you need a passport to enter a restaurant or a store? It's the same thing here. (Ok, maybe you do if that's a gun or liquor store, or some private lounge that needs a membership.) Oh, and, sure thing, almost every store out there would just love to ask for a passport and have a very detailed and extensive tracking of their visitors.
> At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0".
Neither do I, but I don't see why you thought about using fingerprints as identifiers for humans. Those are credentials, not identities, although they're tied because it's hard to separate the concepts. Users already have a lot of weird stuff but and don't care that they're username/pbkdf2_sha256$12000$6Q0D5rq4nz1m$xsAqY1hlIuFqY4sD+9Ia0dxNLooy+jmHFJCrBgByhHw=. Let us leave those details to computers. Hope you see the idea.
Also, that juridical sense isn't international. There are countries that seize or undelegate domains they can reach at whim. There are countries that block other zone domains, mandating Internet traffic filtering within a country. Legal sense doesn't mean a thing against rogue governments.
To put it security: I really don't want to trust any other entity but myself to be a source my identities, and find any concept of trusted authorities to be hazardous. Seriously, how come we designed the whole damned network that when I come to someone's place why I happen to need some landlord to confirm (why?) that I am who I am? Isn't this is only a matter between myself and whoever welcomes me on their site?
That's true for every way to prove identity. For most use cases, it's a feature that you can get it back in court. See also "identity theft".
> that juridical sense isn't international. There are countries that seize or undelegate domains they can reach at whim.
In a way it's very international. It has never happened in the history of the Internet that one top domain organization has undelegated domains under another top domain.
It is true however that you are always subject to your country's laws. But this system is international in a way that none of your other identities are: You can easily get a domain in another country, and that ownership is exclusively managed by that country's laws.
> I really don't want to trust any other entity but myself to be a source my identities,
That doesn't make for very useful names.
I may assert that I am Barrack Obama. You will most certainly not agree. That limits the usefulness of self-asserted identitites. See also "Zooko's Triangle".
I also haven't heard of such thing. I have heard of few others, though.
US had seized a few .com domains, and I doubt they cared about citizenship of registrar. Russian government had requested un-delegation of few .ru ones, and blocking any access (ISP-level) to many others across the world. Australian .oz ccTLD was moved to .oz.au. Yugoslavian .yu ccTLD is gone and doesn't exist anymore. It was once feared that .su would also begone, but it had survived for some weird reason, although - who knows - for how long?
I think a few email accounts I had registered in early '00s are long gone, some with the very email providers. But I still have my old private key I've created a decade ago. That's what I know about the credentials. YMMV, of course, and - sure - I know a few peers who had lost their keys.
> I may assert that I am Barrack Obama
Sure, and while I suppose it's not your name, I bet there is not a single Mr. Obama in this world. Zooko's triange is fine, identity system doesn't need unique names - a natural one doesn't have those anyway. We don't require worldwide login (username) uniqueness, right?
If for some reason we want to know it's real US President Obama who wrote a message or signed up on a site, we need an assertion on his identity from US Govt, don't see any issues with this. And, duh, I bet he has a few tamper-resistant tokens that hold some signed keys, to sign his mail and whatever. I would be very surprised if he doesn't.
Your SSH private key is not your identity, it's just some bytes. Your identity is determined by what public key is considered to be "you", i.e. what's in ~/.ssh/authorized_keys. Your infrastructure provider can usually change this, with or without your permission.
Unless you own the land where the hard disk public key -> account mapping resides, your identity is leased.
Absolutely. It's my credential. In a perfect system, we decouple those from identities - but that's hard. If you have some ideas about this or know a system that handles this - please share a link.
In a less than perfect system, we at least have to try to assure that credentials are self-sufficient and don't require a third party to just exist. That leaves us with either keypairs or pre-shared secrets (traditional passwords). Maybe something else but I don't know.
> In a sane world, it needs to be possible for someone with common sense to revoke and reissue your credential if you lose it
Well, yes. However, there is just no advancement at the moment - proposed general approach is just not better or worse in this regard. It's the same as if you've lost your password and email in a most traditional identity system out there. If you lose all credentials - your identity's lost and you can only talk to each consumer individually and negotiate whenever a recovery's (to a new identity) possible. This doesn't change.
However, in theory, you can set up a system in which your friends or someone you trust may help you to recover or revoke your key. I'm no crypto expert, but I heard we have fancy things like threshold signatures and secret sharing schemes (where k-out-of-n members quorum is necessary to recover a secret or generate a valid signature), so I believe there are some options for the future how we can improve things - in a ways more flexible and secure than things are now.
If two weeks pass without incident, then they can publish a new public key half which is considered yours, and presumably give the private half to you.
1. We're currently stuck with X.509 and those don't allow subkeys or multiple signatures.
2. Then, the problem is that, AFAIK, there's no way to tell in that we accept just anything in TLS. I think there were a lot of discussions about allowing spontaneous authentication (changing state machine to allow TLS client to send certificate without CertificateRequest) or adding hacks like DN=WebID, but none is here. My memory's blurry in this regard - I've read about this about an year or two ago, sorry. But I'm certain there were some issues here.
3. Then, the problem is, browser UI and UX for managing certificates are terrible. There weren't any changes in this area for decades, and everything about those is deep hidden. Then, there are no subkeys and no cross-browser sync or key escrow mechanisms (opt-in, absolutely), so it's very unlikely to be useable by average person. And so on.
So, format is not ready, protocol is not ready and browsers are not ready. Thus, sad but no, it's not going to work.
The main problems are:
1. Certificate authenticity -- the key has to be added to authorized_keys on the server. This includes certificate revocation and expiration, and re-establishing trust after certificate is lost.
2. Private key management -- how do I migrate keys to a new browser or a new machine? Where are the keys stored anyways? Absolute PITA in every existing implementation.
3. Key generation -- we need some more user-friendly tools if this is to catch up
2. http://www.ibm.com/developerworks/lotus/library/ls-SSL_clien...
It's not perfect, of course. You can lose your CAC card and then you're screwed unless you have a way to get new one. It requires a smart card reader which is not standard on most computers. The cards themselves can get damaged by corrosive liquids or sweat (learned this the hard way). Still, it's not a bad way of authenticating and I feel much better about it than a SSH private key that hasn't been encrypted with a passphrase.
These examples illustrate rather the near impossibility to implement this kind of a scheme successfully, even when backed by a state.
What I like: I am authenticated by some proof of ownership, and, unlike with password authentication, the "thing I own" is never transferred over a wire or stored at the server. This is even better than what I have now (unique passwords for every site, managed with 1Password, and 2FA for important sites).
But the SSH callback would have to be automatic - Via a browser plugin, or even better, implemented by the browser itself. I don't think I want to start a terminal and past a string every time I log in to a site.
The "paste this into your terminal" also opens up a completely different can of worms - Social engineering!
I mean, https already supports this, it's just that setting up servers to deal with client certs sucks and the UI for users is also pretty bad. But the infrastructure is already there without poorly reinventing the wheel over SSH.
You know, there is a reason nobody uses client certificates...
Does anyone have any type of explanation of why the UI in browsers for client certs are so user-unfriendly?
I would really like to use client certs more, but with things the way they are that's impossible right now. It's just too hard for a normal person to use them.
Specifically, I think there's a missing binding between the SSH session used for authentication and a user's web session.
Let's say that Alice has an account on bob.com. Mallory sets up mallory.net and sets up demo-ssh.mallory.net as a DNS alias (or TCP proxy) pointing to demo-ssh.bob.com.
1. Alice visits mallory.net, which Mallory controls
2. Mallory visits bob.com and starts an authentication session.
3. bob.com presents an SSH challenge to Mallory
ssh demo-ssh.bob.com -l 7d7662f63f70de7714 -p 2222
ssh demo-ssh.mallory.net -l 7d7662f63f70de7714 -p 2222
6. Upon detecting a successful login, mallory.net accepts Alice's login to avoid raising suspicion.
The only sure sign that this has happened would be that demo-ssh.bob.com and demo-ssh.mallory.net would have the same host keys, but OpenSSH isn't designed to prohibit duplicate host keys.
ssh demo-ssh.bob.com -l 7d7662f63f70de7714 -p 2222 https://www.bob.com
ssh demo-ssh.mallory.net -l 7d7662f63f70de7714 -p 2222 https://www.bob.com
It would be awesome if YubiKeys or other SmartCard-like devices were more widespread and better supported in browsers, because it would make client-cert workflows way easier. It's really mostly an UX issue.
SSH keys are asymmetric. Think of public keys as locks and private keys as ... well, keys. You hand out copies of the lock but you keep the key to yourself. Anyone can put a lock on a box and know you're the only one who can open it. You tell them what lock to use and then use your key to open it to show them you are who you claim to be.
e.g.:
~/.ssh/authorized_keys
api.github.com/user/keys
iam.amazonaws.com/?Action=CreateAccessKey
(edited for formatting)
The thinking is that we never want to move a private key, but public keys can go anywhere.
https://news.ycombinator.com/item?id=8970402
There has also been mention of a few other SSH + browser ideas:
1. Browsers support syncing between different devices using some type of cloud provider (think Google's sing into Chrome, Safari's iCould integration, etc.). This obviously would need some type of client side encryption to be secure. Could be achieved with a plug in as a stop gap.
2. Browser support for this type of auth. Basically, you'd do <input type="identity" protocol="ssh" nonce="abc">, which would render as a drop down with a list of identities the browser has (which correspond to your private keys). You simply choose one, then submit the form. The server sees your public key (which it may remember after registration), the nonce, and the nonce signed with your private key, verifiable against your public key (I am hand-waving the actual authentication here. This implementation is susceptible to at least replay attacks unless the nonce is remembered by the server.)
That's pretty much it. If you think about it, this is how LastPass works now, except instead of sending a one time signed nonce back to the server it sends a username and plain text password.
Unfortunately, I didn't get very far and stopped working on it a while ago, but one thing I did learn was that the source code for links was much easier to come up to speed on and use for rough experiments than the source code for a full-on graphical browser.
I still have notes for it... somewhere.
[0] http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent...
Edit: https://github.com/mcavage/node-ssh-agent is interesting.
You could have a browser extension that connects back to a local daemon.
None of which is to say that this is a better solution. I don't think ssh over the web is going to have wide application based on the fact that coordinating ssh is still a devops type of exercise.
Say you have a blog, or even some kind of small application, only you develop/administrate it, and only you ever will. SSHing in couldn't be simpler, but front-end authentication sucks. Everything available feels overkill to just authenticate that you are you. Most recently, I just used HTTP basic auth, resolving to see if there was a way to use SSH 'soon'.
This is how you authenticate with StartSSL.com for example.
The solution for this kind of thing is still something like OpenID, however simpler, so everyone can implement everywhere they want, even using custom SSH-OpenID servers, and normal people can use with their Google emails.