This is a technical post in response to the useful provocation Stephen provided with his video for #el30 exploring Yubi keys and Public / Private keys. Stephen began by saying it is not his area of expertise (mine either). There is a LOT in these topics and I have a friend who is a specialist who helped me put this post together to give an intro in a way we could understand. It was not something I could research and correctly put together on my own, as terminology and details matter a lot with the intricacies of these things and their uses. (and it’s very complicated!) I hope this tutorial-style post is helpful.
My post is divided into that intro, and then some comments/explanation from me on things in the video.
Intro:
Passwords:
Positives:
- They are good because of usability.
- Everyone knows how to use them.
Negatives:
- They are hard to remember and easy for computers to guess (generally).
- People reuse them (this is a human error)
- When credentials (password or email) are reused, compromised details on one site generally leave you open on another site if you have reused them elsewhere.
A good example of a good intention that weakens the use of (more) secure passwords:
Websites that disable ‘paste into password fields’ Those sites thing they are improving security by disabling that feature, but it also means you cannot use a password manager where you can use a randomly generated long string including umpteen special characters and thus most people resort to a more simple, easy to type password that is simply weaker.
- PII (Personally Identifiable Information) like mother’s maiden name, DOB… is also bad because generally available on public record
One approach to counter the weakness of passwords is to strengthen passwords with another factor.
Possible factors include:
- What you know
- What you have
- What you are
A password is something you know
If you are using more than one factor, it ensures that if someone has guessed your password, they still can’t get in because they need another factor.
A fingerprint is another factor (something you are – biometrics)
SMS is not a second factor – it’s something you know, like a password. Many people will argue with this, but it is more like 2-step authentication, where you use 2 passwords. The phone number is something you know, even though we *think* of receiving a SMS as a ‘thing’ but it would be easy to clone your sim and the first thing you would know about it having been ‘popped’ is when you suddenly have no service on your phone.
A Yubi key – something you have. It is a physical token, and thus is a true second factor. There are also RSA tokens (some places of work use these as a factor to log on to a system) which are a physical second factor. Google Authenticator, which is an app that generates a time-sensitive changing code, is like RSA, but not as good because it is still cloneable.
A true second factor (the something you have type) is a hardware product and not a software product.
Despite all the things that are wrong with passwords, people do know how to use them.
Certificates- What if to sign up to a site you had to generate a domain-specific public key and sign it with your private key? How well would that work in an online world measured by sign-up rates and similar metrics?
Beside the human ‘friction’ of onboarding, there is also the problem of compatibility. For example look at GPG tools. I used to send encrypted, key-signed messages with one of my good friends, but when email upgraded with High Sierra, GPG tools broke and you couldn’t use key-encrypted mail any more. It still doesn’t work. (*Sigh*)
So if we asked people to generate those site specific keys, understand it, sign it with their public key, there would be a very high probability that even if they had the gumption to learn how to do it (and believe me, it took me a couple of weeks to sort out key) it is also overwhelmingly likely that people get it wrong in a way that degrades security instead of enhancing it.
My public key is on my website. 🙂
ONE person has ever used it, and that is because we promised to both help each other learn how to use keys!
The idea that Yubi keys replace passwords as a single way in / use device?
Definitely not. Replacing the password factor (something you know factor) and ONLY using a Yubi key (something you have factor) as a single factor is possibly worse than a password, and is certainly no better. Here’s why I say possibly:
The ‘threat model’ is so important. For example, if you live in a very secure house in the middle of nowhere and the Yubi key is in a locked drawer to which only you hold the key, then it may be quite secure. Whereas if you are in an open plan office or university setting and someone could walk by and pick up your Yubi key if you left it on your desk while going to the loo or to get a coffee, then it is not secure. There are no absolutes and it is all completely context specific. What is your threat model? At another end of the spectrum, if you are operating on a network where everyone is meticulously put through a security clearance process, you can operate on a completely different model.
Anytime people make absolute statements it is a clue that they only understand part of the picture. (That’s my friend speaking. I promise I do not understand all the picture, and I can only claim to have a fuzzy image of parts of it.)
A Yubi key is a second factor. – Something you have. To use it as a second factor, it can be used with either something you are or something you know. You want at least two of these, so the Yubi key could be used with biometrics (fingerprint, retina scan, face recognition) and bypass the password (which would then be a third factor) completely, but it is not an all-in replacement system. We really want to aspire to use all three.
Part 2: Comments on the video and a bit of discussion:
Identity is a component of authentication.
Stephen is correct that a system is only as strong as the weakest factor.
In the video at 6:30 Stephen mentions something really important in passing, and perhaps doesn’t realise how important it is. He’s talking about two factor completely correctly- log in with biometrics, and then use the physical token. YES.
Public/private keys are for encryption.
Public and Private keys are generally used for assertion and non-reputation (to show signatures). This can have to do with chains of trust. (I’ve been told that’s a whole separate topic and terminology matters quite a lot there, so I don’t dare convey my extremely limited understanding of it)
Public / Private keys are definitely worth knowing about and understanding the mechanics of how-to. But the possibility of making errors so very easy and real… I’ve done it at least a million times and I only used them for fun, to learn how with a friend – not with anything that actually mattered. The tiny slip with private/public that Stephen highlighted in his newsletter, is exactly how it goes wrong. It is so very, very easy to slip up.
To complete the image Stephen shows us in the video at about 11:15:
In Stephen’s diagram, he is correct that only Alice can read the message, but it doesn’t say anything about where the message came from. To prove it comes from Bob, he would sign with his private key, and encrypt with Alice’s public key. That way only Alice could read it, using her private key, and she could verify it came from Bob with his public key. Simple!?!? (not at all)
It is totally complicated, I realise. Like I said, I only send stuff this way with one friend and we were running a security challenge together a few years back as part of an open course, and yes, we both had to have regular tutorials with an expert to get it even close to right.
Stephen mentioned buying a certificate. If you pay for a certificate from CA you are paying to inherit trust from them. If I self-sign a certificate it is free but nobody (browser) will validate it. At that point the certificate is an assertion of trust. With a self-signed certificate you say ‘you should trust me, but I give you no evidence to support this’.
More on what Stephen explains at 13:15ish. Let’s Encrypt is free (yay!) and yes, Reclaim Hosting offers this on their C-Panel. Https gives you confidentiality, integrity, authenticity. Https does not verify who you are connected to – although people think this – You could be connected to anybody.
- Once the https connection is established, the connection is encrypted. This gives you confidentiality.
- Integrity – someone else cannot inject information into the information you are receiving. In the US you see ISPs injecting ads into http (unencrypted) connections – and the result is you may see adds on a website that the author of the site did not intend to be there.
- Authenticity means whoever provided the cite managed to present a valid certificate that matches the domain. For example this cite lauraritchie.com – it sends a certificate that has been signed. That certificate resolves against the root certificate on your local browser, and that resolution says it is a valid certificate.
Https does not guarantee that the connection is to the person you think it is. It says that cite presented a valid certificate that maintains the chain of trust (signed by a certificate authority) and matches the domain.
A reference and little activity to demonstrate this.
This gives you the error message you would get if someone stole your domain, but didn’t get the certificate right.
When I click on Show Details it shows:
This is an example of how it is not to do just with having a certificate. In this badssl example, they had a valid certificate signed by a certificate authority, but it was presented for the wrong domain. This results in the browser refused to create an https connection, because a valid certificate was presented for the wrong domain. Imagine that we are going through passport control and I hand over your passport. If your passport is valid, I should still be rejected, as it is not ‘mine’. Someone might have stolen your domain and they then present a certificate that doesn’t match. This error message is the very first, most basic step in knowing something has gone wrong with knowing you are connecting to who you think you are.
If it did resolve, you pass the first step in the authenticity test. It still does not guarantee the site (or person) is who you think they are.
One tiny step to show more:
Go to protonmail.com (as an aside, different browsers will display things differently). At the moment in Firefox you can see the ‘handbag’ and you can see that xx cite has presented xx certificate. This is pretty good, but it is possible to do this and pretend to be someone else – e.g. there is nothing saying ‘this is me’. This cite presents an EV certificate which matches the domain name, has been correctly signed by the CA. EV means extended validation, and is the highest level of certification. They are expensive and difficult to get a hold of.
I think I need a cup of tea now. I do get it, but have had to check and retype al least 30% of what I thought I had right. I hope this tutorial helps more than just me! Thanks to my (patient) friend. 🙂
