my (and your) PGP habits could be better
I am an opportunistic PGP user, and I've used PGP for quite some time. if you encrypt mail to me, I'll encrypt back. if a download has a signature, I'll check it. I sign every one of my blog posts automatically, thanks to some dirty hacks to bashblog.
what's the issue then? well, I don't always do it religiously. I used to have a proper canary, but I abandoned it because it was a hassle on my end and I was afraid that nobody checked it anyway (I was wrong, one person actually did check it). that's why I have switched to blogging, which is sort of a more natural medium to sign and doesn't require me to go as out of my way to update (and even then, I have been slacking on my blog really hard).
there are some other issues with my current use of PGP. check to see if the following also applies to you:
- creating a perfect keypair? forget it. I don't have an airgapped device to do this safely. and even if I settled for a special removable medium, I used to have some trouble importing my stripped keypair into OpenKeychain. not to mention, the GnuPG utility – or any utility, for that matter – doesn't really have first-class support for this kind of scenario. there are a lot of issues with PGP's user experience, and I'll go into more detail with those later.
- confirming trust of keys by signing them? signing keys and publishing my signatures to keyservers? it's difficult for me to remember to do this. so far, I'm pretty sure I have signed fewer than a dozen other people's keys.
- confirming keys in general? I do basic checking, but I don't know how much is enough.
- maintaining my key properly? who knows, honestly. I have not had a religious policy for subkey creation, deletion, and renewal. nor do I really know what is the
optimalpractice for maintaining my key.
- refreshing and maintaining my keyring? a while ago, I found a safer way to do this but I have never ended up using it. furthermore, I have made very little effort to remove invalid keys from my keyring.
here are some issues I have seen with others' use as well as when I have been trying to use PGP with others:
- first off, this is really on my side: I use elliptic-curve subkeys for signing and encryption, but I also have RSA 4096 subkeys when communicating with older PGP implementations. there are a few issues I have run into with this, such as not really knowing which subkeys I'm using since I let programs handle this automatically, as well as possible delivery errors because my recipient has no support for ECC algorithms. it's all very opaque to me and I tend to dismiss errors as
their issue, not minewhile in hindsight that might not have actually been the case.
- I have seen many people, especially on Tor, try to be smart and reveal as little detail about them in their key metadata. this is straight-up the wrong way to use PGP especially over E-mail. your address is not
email@example.com, stop making your key more difficult to use. create separate keys for separate purposes and use them appropriately.
- since there is no
right wayof using PGP, we end up with people using all kinds of algorithms, all kinds of expiry policies, all kinds of renewal policies. some people properly renew their keys, others create new keys to replace the old ones (and I was guilty of this). some people's keys expire never, others' expire next week. I know some of this is a personal threat model consideration, but still, I believe too many people set unrealistic, unsafe expiries on their keys.
and lastly, usability and interface issues. it feels like XMPP all over again, what with all the different clients and none of them implementing the full standard in a correct and easy-to-use manner. there are practically no full-featured GUI frontends for PGP, and the GnuPG commandline implementation discourages newbies (and even people like me) from figuring out how to correctly maintain personal keypairs and a full keyring. I use keys for different purposes (some for E-mail, others for download signing) and it isn't immediately obvious that I could probably have two or more keyrings for that. also, is it possible to attach metadata to PGP keys (such as your XMPP account, website, or anything else that could possibly help verify people)? if it's possible, I surely don't know how to do it, nor do I know where I can search for more information.
so, my suboptimal use of PGP is everyone's fault. and if you use PGP, you're probably using it suboptimally as well. I don't want to bash PGP outright for being a poor standard – I mean, come on, it has been around for decades, and it's still suggested by security professionals. but over those decades, very little has been done to change the state of affairs, and it's so easy to use it wrong.
as always, I accept E-mail replies to my posts, but I especially want to hear readers' thoughts on this. I want to gauge how others use PGP, and I want to see what others believe should be the
correct way of using it.
are passwords the right solution?
[I have lacked motivation to write anything lately, but this week marks the beginning of my spring college semester, so I figured I'd force myself back into a schedule.]
a month or two ago I read an article by Alec Muffett, where he attempted to defend password authentication as possibly the only viable online security solution. I even sent him an E-mail asking him to reconsider some of his thoughts toward passwords:
[...] I came across your opinion on password use  and I have to disagree with you. My issue with passwords (as they are currently widely implemented) is that the password has to be sent to the server verbatim, and it is up to the server to safely handle this password (hashing it and making sure memory where passwords are handled is promptly cleared, in case of vulnerabilities in the server that allow reading memory), and it is up to both the user and the server to initiate a secure connection so that password eavesdropping is infeasible. I favour PKI, challenge authentication, and other mechanisms which do not require any transmission of a private key or passphrase over plaintext to the server. This places the burden of security on the user and on the PKI/challenge protocol itself, which I believe to be much safer than having to place the burden on all of the user, server, and transmission medium. Please consider these points and perhaps revise your decision on claiming that passwords as they are used today are a sound security mechanism.
so already, that explains half my stance on passwords off the bat. I do favour PKI -- I use elliptic curve keys for all SSH connections and disable password authentication, and I would use similar authentication for websites if it was an option. to me, it makes more sense to have a file or files tied to each device I own, and should that device be compromised, I can simply log in from another device and revoke the now-insecure key. this allows for finer-grained access control than I would have with passwords: for example, right now I would have to reset my password if I logged in even once on an untrusted public computer. granted, I would have to use a temporary key for a public computer, stored on something such as a USB drive, but at least I wouldn't have to change the key on each device I own. it's a different story if you have a remarkable memory and can memorise random passwords with ease, but a lot of people including myself cannot or will not trust our memory to this task.
I have more faith in TFA than I do in plain passwords. to save myself from reiterating ideas I have already typed (again) I will cite my response to the Hidden Answers question
What and how much credentials do you save in KeePassX? (please note this link is only accessible over Tor or this I2P link):
[W]e should look more into TFA. KeePass supports it to some extent (it combines a password, something you know - with a keyfile, something you have like a USB drive). It allows you a little more time to react to breached security because even if the attacker has one piece of the TFA, it will take him some time to get the other piece and actually be able to utilise that information.
Weigh the differences:
- Store the passwords in your head. Pros: you can't hack a brain (as far as I know). Cons: unless you have impeccable memory, you will likely formulate smaller, weaker passwords because that's all you can remember. Also, you may choose to reuse passwords more often, which is also unsafe.
- Store the passwords on paper. Pros: you can't hack a piece of paper. Also, if you don't label the passwords (you use something like PasswordCard.org) you can be a little safer in case you lose it / someone sees it. Cons: someone can easily steal that piece of paper, and even if you use the PasswordCard, you have significantly narrowed the possible passwords for the attacker. So, if you lose that card, you're going to want to rush to change all your passwords.
- Store the passwords in a password manager. Pros: Password managers organise your passwords and they require you to only know the master password, leaving you with less to remember. Good managers can also generate strong random passwords for you. Cons: once someone gets the master password, your passwords are all in the open and you're in big trouble unless you set up TFA for all your accounts.
TFA/multi-factor authentication is a definite improvement over single-factor authentication, and only recently have I decided to add TFA to any account I could find an option to do so. I also use a combination of storing frequently-used passwords in my head and storing the rest in a password manager, which are encrypted and synchronised to Google Drive and, in effect, to my phone. that way, I have a copy wherever I go and I am as secure as possible within the confines of password management.
I still believe authentication should be given more thought; there are still plenty of organisations that have very poor regard for security and impose artificial limits on passwords out of cost/laziness:
- limits on password length or character composition,
- storing passwords in the remote database as plaintext,
- sending back a password over an insecure channel as
confirmationof a password reset, and
- requiring a user to add
security questionsto one's account (which is a huge fucking oxymoron; there's nothing secure about security questions).
if all websites agreed that these are poor practices, that would eliminate many of the issues with passwords right away. combine that with mandatory use of a secure channel such as TLS (which many sites thankfully do now), use of server-side password hashing such as bcrypt or Argon2, and user education on proper password formulation (no password reuse, no dictionary words, et cetera) and sites would be sitting pretty while not compromising compatibility with the current security ecosystem. users should know that password managers are as necessary as an Internet browser at this point, and that there are many user-friendly solutions to this already: many Web browsers even have built-in password saving and synchronisation across devices, but of course there are also solutions such as KeePass and LastPass. in fact, these points I just made are in line with Alec's article I linked at the beginning, so we're in agreement there.
but what if we want to take a step further and opt for a more secure (but less orthodox) solution? let's look at the list of advantages Alec gave favouring passwords, and compare this to something like PKI:
- passwords are easy to deploy [and so is a PKI solution, at the cost of a temporary stage of switching from passwords to PKI. if done correctly, PKI can be abstracted to the end-user so that it is actually easier to use than passwords, and users can just click
generate loginto create a random file and save it to an internal (optionally synched) database on-the-fly.]
- passwords are easy to manage [... see above for why PKI would be easy to manage without the user being concerned with implementation.]
- passwords don’t require identity linkage between silos – so your Google username can be different from your Skype username, can be different from your SecretFetishPornSite.com username [... PKI doesn't require this either; simply generate new keys for each site you use.]
- passwords are scalable – you can use as many different ones as you like [... same for PKI.]
- passwords can be varied between silos so that loss of one does not impact the others [... see above.]
- passwords don’t (necessarily) expire [... still same for PKI. advanced users could optionally be allowed to set expiries for keys (just like X.509 allows), and users could at any time revoke a key from a website if it's compromised.]
- passwords are the purest form of authentication via ‘something you know’, and thus ideal for the network or “cyber” environment. [now, this is an actual argument for passwords. PKI is along the lines of
something you have, but for the majority of security-conscious users, so are passwords. passwords are stored in a database or on a piece of paper (something we have) unless we have remarkable memory (more power to you) or we reuse passwords (which is wrong).]
- you don’t need to pay an intermediary or third-party a surcharge just to get a new password, nor to maintain an old one [... same for PKI.]
aside from the fact that PKI is
something you have rather than
something you know, it maintains many of the properties of passwords and has the added benefit of being secure by default: secret keys are not transmitted over the wire, and server database compromises would be fruitless since all keys stored are already public. end result, both users and server administrators have less to think about and worry about. there are still perfectly valid uses for passwords, but I would like for people not to fool themselves into thinking passwords are the universal solution. passwords should strictly be something you know rather than something you stick in a database, and you should only have to memorise a handful of passwords, instead of having to remember one password per mail account, social network account, bank account, forum account, game account, and whatever other accounts you have. passwords should be used in a local context: useful to decrypt your PKI database locally or to unlock your computer/phone quickly.
[two blog posts in one week, but this was on my mind today so I figured I'd publish it now]
another thing I wrote back in 2016:
I use self-signed certificates for all TLS-enabled servers I set up. I know there are freely-available certificates being handed out by authorities, and I know that Let's Encrypt exists. I do not refrain from requesting a CA-signed certificate because I am too lazy to do so; if I wanted, I would ready a CSR right away and get that taken care of. There is only one key reason I abstain from getting my certificate signed by a root signing authority: they are too centralised.
Let's take it from the top: when you install a new operating system, be it Windows or Linux or Mac or a mobile device firmware, the system will most likely come preloaded with root certificate trusts. Who decides to trust these? You haven't hand-picked them, and most people don't even bother looking at the list of authorities their system trusts. Not to mention, most people don't even recognise half the companies and organisations that provide certificates. So, you're at the whim of others – all you can do is hope they have your best interests at heart and that they aren't screwing you over, accidentally or on purpose. In reality, quite a few authorities are lazy with checking if a CSR is valid or just a spoof attempt. As long as they profit, they don't really have your security at heart.
And of course, high-profile companies can and do get hacked. This holds true for certificate authorities as well. And the more widely used a CA is, the more susceptible to attack it will be. Also, while this does not apply to everyone, there are workplace, school, and governmental filters that are put in place to censor certain sites deemed to be unacceptable for access, as well as to detect obscene or unsafe (malware) content. In order for a filter to be effective for these purposes, it must intercept all your traffic; HTTP is straightforward, but HTTPS requires the firewall to strip, analyse, and re-encrypt the content that passes between you and the webserver. In doing so, it relies on each computer in the network having its own certificate installed and accepted. End users may not be fully aware that this is going on, and they may believe they are completely safe because their browser is not warning them at all. This may be acceptable if everyone understands what this filter does and if the filter is configured correctly, but that isn't always the case. My high school's filter made no distinction between valid and invalid certificates, so I could unknowingly be put at risk for accessing an unsafe site that appears to my browser to be safe. Plus, if people wanted to use their own devices on the school network, they were required to install the root certificate even though they were not made aware of the consequences this would have.
So that's one issue: most people don't even explicitly trust the certificates installed on their system. Even if you are aware of the root certificates you trust, you cannot fully trust that they will remain uncompromised and trustworthy in the future. Let's Encrypt was proposed as a solution to the skimpy checks most authorities put their customers through; Let's Encrypt uses a cryptographic proof to verify that you are the owner of your server. While this is a great step in the right direction, it does not change the fact that Let's Encrypt is still a centralised certificate authority, and thus is fallible to the same issues as every other authority.
In contrast to the common SSL/TLS methods of verification, SSH actively encourages you to accept key fingerprints on a per-server basis. There is no metadata attached to this (e.g.this key is valid on domain.xyz and www.domain.xyz) that can be changed to fool you into accepting the certificate – there's just an arbitrary fingerprint that tells the complete truth about who the server is, straight to the point and no bullshit. PGP operates in much the same way, except that there is certain metadata on keys that describe the owner and their E-mail address. With both of these, the key owner can disclose the fingerprint via whatever channels he deems secure, meaning that an adversary has a harder time compromising this information. TLS certificates have fingerprints as well, but most client software obscures this in favour of a less helpfulthis may be insecurewarning.
A compromise would be to provide a simple-to-use and simple-to-understand web of trust system that combines the benefit oflazyand indirect trusting (I trust my friend's judgment, therefore I would like to accept all the certificates that he does) with the benefit of decentralisation (points of weakness are smaller and more dispersed, making damage caused by compromise much more tolerable than if a large CA was compromised) and direct trusting (I know that this site is what it says it is, similar to theadd exceptionfunction already available in most client software). Right now we do not have the luxury of a well-thought trust system that is straightforward, unobtrusive, and secure. So for now, I will opt only for thesecureoption since it is the most important in this scenario. After all, if you wantstraightforward and unobtrusivewithoutsecure, why don't you just use HTTP?
to put my money where my mouth was, I did create my own CA to use with all my websites, and that worked relatively well for about a year. but lately I have found that some XMPP servers will not federate with servers that have untrusted certificates, so it was time for me to make a decision: compatibility or security. I bit the bullet and now I'm using Let's Encrypt certificates on all my websites and servers, forced TLS on websites/E-mail/XMPP (and soon IRC), and overall I guess it's a good move even though I'm upset with the CA system. hopefully one day we have a better system in place to address the flaws of the CA system.