Rel-publickey and Rel-pgpkey Specification

Rel-publickey and Rel-pgp are a simple open format to indicate that a link points to an individual’s or entity’s PGP or other public key.

Specification 6-Sep-2013

Author

Mark Burnett (mb@xato.net)

Copyright

This specification is released into the public domain per the Creative Commons Public Domain License or any later version published by Creative Commons; with a waiver of rights, and an assertion that no rights attach to this particular work.

Patents

This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.

Abstract

The Rel-publickey attribute is to be used with HTML A and LINK elements to describe a public key related to the current document’s author, role, or entity. The link’s href attribute contains the URI of the key in either plain text or binary formats as indicated by the type attribute as shown in this example:

<a href="http://example.com/pgpkey.asc" rel="publickey" type="text/plain">My PGP Key</a>

The type attribute should be one of the following depending on the format of the certificate:

MIME Type Encoding Extension
text/plain ASCII .asc, .txt
text/xml XML (XKMS) .xml
application/pgp-keys Binary (PGP) .pgp, .gpg, .pub
application/pkix-cert Binary (DER) .cer
application/x-x509-ca-cert Binary (DER) .crt, .der, .key, .cer
application/x-x509-user-cert Binary (DER) .crt, .der
application/x-pem-file Text (PEM) .pem
application/x-pkcs7-signature Binary (DER) or Text (PEM) .p7s

Specifying Key Owner

The owner of the linked public key should be identified by the full name, e-mail address, or certificate id and may be specified in the title, id, or name attributes or within the anchor text. The author might also be assumed through a rel-author value elsewhere, an author meta tag in the page header, in an embedded hCard, or the owner of a domain or blog that uniquely identifies a single individual or entity.

Rel-publickey vs Rel-pgpkey

Due to the ambiguity of the text/plain format, one could alternatively use rel=”pgpkey” to explicitly define the key as a PGP/GPG key. When using rel=”pgpkey” the type must be specified as either text/plan or application/pgp-keys. The rel=”publickey” form may be used with any public key format.

Examples

Link to PGP key:

<a href="https://xato.net/x/Mark_Burnett_mb@xato.net_(0x9A61D7D1)_pub.asc" rel="publickey" title="mb@xato.net" type="text/plain">My PGP Key</a>

Use as a hidden link in the page header:

<head>
<link  href="https://xato.net/x/Mark_Burnett_mb@xato.net_(0x9A61D7D1)_pub.asc" rel="publickey" title="mb@xato.net" type="text/plain">
</head>

See Also

Getting Started with PGP in 10 Minutes or Less

NSA SpyingConsidering recent news about the collecting of data communications, I think its time to bring PGP back to life. PGP is an extremely secure encryption method that is easy to integrate into email messages. Although it has been around since 1991, early efforts to make it a standard largely failed. Even I eventually stopped installing PGP because I simply never used it. But the Internet is very different nowadays and I think it’s time to dust off that old key and give PGP another chance.

PGP does have some limitations and it is by no means a perfect solution, but it is much better than sending unencrypted emails. Unfortunately, one big reason for lack of adoption is simply that too many people are intimidated by it. The good news is that you really don’t have to understand how PGP works in order to start using it.

Here are the basic concepts you probably should know:

  • You start by creating two keys for yourself:  one that you pass out to the world, and one that you guard with your life (along with having a reliable and secure backup). The Kleopatra software mentioned below walks you through the process of creating these. It’s really easy. 
  • If someone wants to send you an encrypted email they will need your public key so you generally publish it on a public keyserver or put it on your web site. Mine is here.
  • To be able to read that email you use your private key.  That is why you keep it private.
  • You can also use your private key to sign emails that  you send out. Signing just proves that you are the real sender. Others can verify your signature with your public key.
  • Other people can sign your public key. The more people who sign your key, the more others can be sure that it is authentic.

That’s all you really need to know, so here are some quick instructions for getting started under Windows:

1. Download and install Gpg4Win.

2. After installing, open Kleopatra to import an existing key or create a new key.

3. Once your key is in Kleopatra, right click on it and select Export Certificates to Server to publish your key on a public keyserver, then get another PGP user you know to sign it.

4. Configure your mail client (or use Claws Mail client that comes with Gpg4Win). If you are using Outlook, Gpg4Win comes with an Outlook add-on. If you are using Thunderbird, get the Enigmail add-on.

5. Talk a friend into installing PGP so you can send and receive PGP encrypted email.

A big problem for most people is that using PGP with web-based mail accounts such as GMail, Hotmail, or Yahoo! mail just isn’t that easy. Yes there are solutions, but I have not had great luck with any of those.

In my case, what I chose to do is create a Gmail filter to forward all messages that contain “BEGIN PGP MESSAGE” to another unpublished email account (and delete the original). This other email account is a POP account that I access with Mozilla Thunderbird. I installed the Enigmail plugin and now have Thunderbird to deal with all PGP messages.

All my regular mail I still access through GMail and all my encrypted and other sensitive messages I deal with through Thunderbird. Works great so far! My next step is to explore some of the mobile PGP apps.

I have also added a new contact form that will automatically encrypt all messages using my public PGP key. The nice thing about the form is that it comes from my server, not from you; your email address and name are encrypted in the message body.

My PGP Key: https://xato.net/x/Mark_Burnett_mb@xato.net_(0x6E23BA97)_pub.asc
PGP Key ID: 0x6E23BA97
Fingerprint: C127 C510 79D7 E457 E20D 4419 7752 D68B 6E23 BA97

Email: The Security Industry’s Single Biggest Failure

Email securityI still remember so clearly the frustration I felt back in the 90′s when starting in the security industry and trying to sell my services. It was so difficult trying to emphasize just how much at risk potential clients were and then get them to pay me to fix their stuff. Too often I came off like the paranoid conspiracy theorist–their sky wasn’t falling and they saw no wolf.

I remember one particular conference call at the peak of my frustration where a network administrator confidently bragged to me and the managers on the call just how secure their network really was. What the managers didn’t know at the time was that as we were all talking, the network administrator was scrambling to lock things down as I was furiously trying to break in. Being that I was pretty good at that stuff at the time, I was able to quickly drop a little program called cdtray.exe onto a number computers, including the admin’s own PC, and used the at command to schedule all of their CD trays to open in one minute. I started asking the admin some questions and could hardly contain my amusement sixty seconds later as he suddenly seemed distracted. Then I went in for the kill: “are you convinced now you need more security?” I asked.

That was over a decade ago but I still remember the password: superchicken.

I didn’t get that job.

Nor did I get any work from Bank of America when I notified them of a glaring security flaw that exposed their global.asa file which contained their database username and password. That was over a decade ago but I still remember the password: superchicken. More on email security

RSA’s Distributed Credential Protection: Yeah They Are Overselling it a Bit.

RSA recently announced their new Distributed Credential Protection (DCP) product which they proudly tout as a “revolutionary” way to secure user credentials. But looking closer (especially at that $160,000 per license price tag), I’m not so sure this product will do much to protect anyone’s credentials.

But let me say this first, the technology itself is absolutely brilliant. Without getting into the details of threshold cryptography (there’s an excellent article by Peter S. Gemmell on page 7 of this PDF), what it does is allow you to split up a secret into any number of parts but you only need a specified number of parts to reproduce the data.

“…let me say this first, the technology itself is absolutely brilliant”

It’s kind of like how you see nuclear missile launches in movies: two people have to insert and turn their keys at the same time to initiate the launch. But threshold cryptography is even more advanced, it would be like handing out 5 keys but you only need any 2 of them to fire the missile. What makes the technology so cool is that it gives you redundancy, integrity, and secrecy but no single piece is useful for obtaining the secret. This technology has many uses in cryptography (it would be perfect for Bitcoin) but I think that RSA’s claim that it will revolutionize password protection is greatly overstated.

The problem is that yes, you are splitting up credentials into multiple parts but all of those parts are components of the same system. It would be like handing both missile launch keys to the same person. Yes, someone would have to steal both keys, but if they can steal one from you couldn’t they just steal the other?

Now one of the claims RSA makes is that if you suspect that an attacker has compromised one of the databases, you can immediately randomize and rescramble the pieces so when they grab the second database the data is useless. So yeah if you happen to catch an attack right after an attacker grabs the first bundle of data but before they grab the second bundle, and you are able to immediately identify all points of intrusion and lock out the attacker so they can’t go back in and re-grab the first bundle, then yes this will work. What are the chances of that happening? Slim to none.

Splitting the databases into two locations is not particularly helpful because both must be accessible to the web server, which is usually the point of entry in these types of attacks, and therefore if an attacker can access one database they can likely access them both. Again, it’s like handing both keys to the same person.

The thing is that RSA’s DCP product is addressing the wrong problem with the wrong solution. The reason most companies get their data leaked is because they have poorly secured their public-facing servers and applications and that they don’t follow best practices for storing user credentials. Both of these problems already have solutions and any organization would be better off spending their money on some code audits and pen-testing.

The fact is that if you have problems with hackers getting into your databases, I think you will still have problems even after shelling out $160,000 for DCP. If you don’t have that problem because you have proper security controls and practices already in place, chances are you don’t even need DCP.

To be fair I have to mention that I have not seen or reviewed this implementation in depth so I could in fact be completely wrong with my criticisms. Perhaps this system could be deployed in such a way that it is much more resilient than I am supposing. And certainly RSA acknowledges that this product is just one layer in a multi-layered defense-in-depth strategy. But I still come back to the fact that you are giving both keys to the same person.

What I would like to see is this technology implemented in a much smarter manner. For example, distributing credentials across multiple distinct trust authorities. For example, it would be a great way to overcome many of the weaknesses and distribution issues we see with SSL certificates. Having multiple holders of a secret not only better protects the secrets but upholds integrity in the case a small number of authorities are compromised. This technology could be helpful for preventing insider attacks and would be useful if you have your servers at third-party data centers that you may not completely trust. There are also some legal advantages with having databases distributed across multiple jurisdictions. And hey, if this technology prevented just one attack, in the absence of other attacks it would probably be worth the expense.

There are many other areas that could greatly benefit from threshold cryptography, but splitting credential storage within an organization is probably not one of them. The concept of a black box authentication appliance (although this is vm-based) is a great direction to be going, considering how many organizations simply don’t implement credential storage correctly, but they seem to be overselling (and overpricing) what this product really can accomplish.

 

 

Is Mozilla’s Persona the Authentication System That We’ve All Been Waiting For? Probably Not.

Last week, Mozilla announced the first beta release of Persona. Persona, formerly called BrowserID, is a personal authentication system that aims to eliminate passwords to log in to web sites. Of course, you still need one master password to log in to Persona, but it takes care of every site login after that. Persona is definitely interesting, but it likely won’t be signing any death warrants on passwords just yet.

The problem with Persona…is that the stuff that makes it so cool is also what exposes it most to attack.

How Persona Works

One thing that Persona has going for it is that on the surface it is relatively simple. When it comes to authentication, simple is good. Here is a simplified explanation of how it works:

  1. You visit a site and that site asks for your identity.
  2. Your browser goes to persona.org (or whatever identity provider you use but for this example I will use persona.org) and asks you to enter your email address and password.
  3. Once authenticated, persona.org signs your public key, basically giving you a seal of authenticity that’s good for 24 hours.
  4. Your browser creates a document called an identity assertion, signs it with your private key, then sends that and your signed public key to the site you want to log in to.
  5. The site looks at the document, verifies that it was signed by you, verifies that your signature was signed by persona.org, and then verifies that persona.org’s signature was signed by a trusted authority such as Verisign or Thawte.

Note that the identity assertion is valid only for that one site, only from your current web browser, and only for the next 24 hours. At any time, however, you can logout and invalidate all currently stored sessions.

What Makes Persona Great

One thing that makes Persona unique is that the site you visit doesn’t need to communicate with persona.org directly, meaning that persona.org never knows what sites you are logging in to. Another big advantage is that it is solely based on your email address, which is much easier to remember than an OpenID URL, and which means that you can easily remain as anonymous as your email address allows. Even better, Persona is distributed so if you own your domain you can be your own identity provider.

Persona is built on a concept that inherently protects your privacy puts you in control of your identity.

Mozilla Persona

But There Are Problems

Like any authentication system, Persona does need some serious real-world testing to prove itself and work out the bugs. The problem with Persona, however, is that the stuff that makes it so cool is also what exposes it most to attack.

For example, there is the signing key at the identity provider. Normally you want the strictest safeguards  to protect any signing key. Some signing keys are so important that they are not even stored on network-accessible computers. The problem here is that in order to sign user certificates, you would need to allow the web server to access the private signing key. That usually means storing it on the web server itself.

We have all seen the news reports of user passwords stolen from a server and dumped on the Internet. But what happens if someone grabs a signing key? Basically it means they can sign any request and therefore log in as any user to any site that uses Persona. Yes, that is a pretty big issue. If I ran an identity provider, I would be terrified of taking my eyes off the monitoring consoles.

Another big vulnerability is the web browser itself. Of course, if someone’s browser is infected with malware, they already have some serious issues. But what makes Persona especially vulnerable is that such malware could do more than intercept passwords–it could authenticate it to any web site you use with Persona without any intervention on your part as long as your are logged in to Persona.

Yet another significant issue is that there is way too much room for error in implementing Persona. We have learned by now that if people can get it wrong, they certainly will get it wrong. Persona relies way too much on the implementation which means we will no doubt see plenty of vulnerabilities with identity providers, browsers, and relying parties.

A good example of this we can see on persona.org itself. When you login, it first asks for your email address to see if you are a valid user, then if you are it prompts you for your password. The problem with this two-step approach is that it makes it vulnerable to account harvesting. You always have to ask for email and password together and if one is invalid you never say which one it is.

Despite it’s potential flaws I do still like Persona. I don’t think it is the technology that will save us from having to remember passwords, but it is an important step in the evolution of secure authentication. What we learn from it is that emails are better than URLs as identifiers. We learn that it’s good to do stuff on the client side to ensure user privacy. We learn that we can easily leverage long-established and well-tested technologies without having to invent something new on the crypto side of things. Unfortunately, we also learn how incredibly difficult it still is to do authentication right.

 

My Password is 4.hub.route.edu.

Password security has always been a hot issue but events in the last few years have made it an even more pressing issue to a greater number of people. When I hear receptionists in a doctor’s office sharing strategies for creating secure passwords I know this is now beyond the realm of network administrators and security professionals.

But one thing I have noticed is that many people don’t truly understand why one password can be so much stronger than another so I thought I would walk through the process of cracking a password. In this case, I decided to use as an example the very password that (until I wrote this) I use for the admin account on this blog.

So like I said in the title, my password is 4.hub.route.edu.

That isn’t the best password I have come up with but it is still fairly strong. It is 15 characters long, contains a number, letters, and some periods. It took me just a couple logins to actually memorize that password. The word components are fast to type because we are trained to type in whole words. And there are four parts, each one ending with a period. The repetition of the period helps the memory process.

Chances are that no one would be able to go to my admin page (which itself is protected by a different password) and just guess that, no matter how much they knew about me and no matter how many of my other passwords they knew because I have never used that password anywhere else. As of writing this article, I can do a Google search for “4.hub.route.edu” and there will be no results.

But the real risk isn’t someone being able to keep trying to guess my password via the admin page, the real risk is someone finding a new 0-day exploit that allows them to dump the users table in my database and get the hash of my password (which happens to be $P$9YCJ/QwbFcgbo7OtfWGYYE8sVJBxtF/). If someone can get your hash, they can now try millions of password combinations without you ever knowing it.

Cracking a password hash is a lot like trying keys in a lock. A hash is a string of characters derived from your password that is calculated in such a way that it is nearly impossible to work backwards to discover the original password so it is relatively safe to store. When you log in to a system, it will run the password you enter through this same complex formula and the result should be the same.

So when I first created my password on this blog I entered 4.hub.route.edu. WordPress ran it through these formulas and came up with the hash $P$9YCJ/QwbFcgbo7OtfWGYYE8sVJBxtF/ which it saved it in the database. The next time I log in, I enter my 4.hub.route.edu password, WordPress runs the same formula on that password and it comes up with $P$9YCJ/QwbFcgbo7OtfWGYYE8sVJBxtF/ which matches the hash it has stored so it knows that I am using the correct password even though WordPress never stored my actual password. Now what is special about these formulas is that it is extremely rare that any two passwords will create the exact same hash (a concept known as collision).

So if someone is able to obtain my hash, they can’t directly get my password from that, but they can try millions or even billions of different passwords and run each one through the formula until they find one that produces that exact same hash. It is a lot like having a lock, you can’t easily create a key from it but you can try a bunch of keys until you find the one that works.

Now when it comes to passwords there are actually hundreds of trillions of possible passwords someone might choose. Even with a cluster of powerful computers it could take decades to try every possible password. Fortunately for hackers, most people aren’t that clever with their passwords. There are a number of strategies they use that can drastically reduce the number of passwords you need to test to crack a password. Below is that strategy

1. Hash Lookup

First, an attacker will check to see if someone else has cracked the password before, using either a local database or an online database such as onlinehashcrack.com or hash-database.net or one of the hundreds of other similar sites. In the past few years there have been many large sites that have been hacked and their passwords leaked. If you password was ever one of these, chances are it will appear in one of these databases. Likewise, if you select a common password that others may also be using, it also might be on this list.

In the case of WordPress, the hashes are created using PHPASS but for the sake of this example, let’s just assume they use MD5 hashes like many other systems use. The MD5 hash for my password 4.hub.route.edu is 7914881ba9b78fa307db6ef0db675e29. You can search any online databases for my hash and you will not find it listed anywhere (at least at the time of writing). If your password is one that you have never used before and others likely have not used, you should be safe (try googling one of your passwords, you may be surprised how many results you get).

If your password hash does not appear in one of these databases, there are also rainbow tables which are massive databases of precomputed hashes consisting of every possible password up to 8-10 characters in length, depending on the algorithm. If your password is less than eight characters long, your password surely will be cracked at this stage. However, you will not find 7914881ba9b78fa307db6ef0db675e29 in any of those databases so I am safe so far.

The lesson here is to never use a password less than ten characters long. Never use the same password on multiple systems. Don’t try to be clever with your password, that never works (NCC-1701 is a very common password).

2. The Word List

Since most passwords consist of dictionary words or something similar, checking every word in a dictionary or a specialized wordlist http://svn.isdpodcast.com/wordlists/ is a quick way to find a weak password. Most hackers will use lists of the most common passwords such as this because chances are very high that someone will be using one of those passwords. It normally doesn’t take more than a minute to go through even a gigantic list of words.

In my case, even a Google search for my password turns up nothing so even if you had the massive list of words that Google has indexed you still wouldn’t be able to crack my password.

Considering this, you can see why so many systems simply probihit any password that is a dictionary word.

3. Rules and Patterns

If a dictionary or wordlist check fails, the next step is to try some of the common (albeit innefective) tricks people use to make a password more complex. If you asked me what I thought was the most common password pattern I would say a proper noun (such as a name) followed by 2-3 numbers. So it would be smart for a hacker to take each word in a wordlist and add ever possible number from 1 through 999. If that doesn’t work, you could try reversing each word or doing simple substitutions like using the number 3 instead of the letter e. It really does not take much effort for a cracking program to try hundreds of different patterns.

For example, a dictionary word may be “password” so a rules-based attack my try PASSWORD, dRowssap, P@SSW0RD, p@ssW0rd, dr0Wss@p, passwordpassword, @ssW0rdp, dp@ssW0r, p@9sW0rd, 1p@ssW0rd, p@$$W0rd, ppp@ssW0rd, 1p@ssW0rd, and thousands of other variants of the word. Depending on the number of rules and the size of the wordlist, this step may take only five to ten minutes and will crack a great number of passwords.

If an attacker has sufficient processing power, another effective strategy is to try two dictionary words together with various delimiters between them (such as dashes or periods). If you had a wordlist of 100,000 words and tried every combination of two words that means you would have ten billion possible combinations. Trying different delimiters between the words would make it a little bit harder but not much.

You probably wouldn’t want to try three-word combinations because that would take you up to a quadillion (1,000,000,000,000,000) possible combinations which would not be an effective strategy. In the case of my password there is a number and three other words that would likely appear in a dictionary but testing for four-word combinations would mean there are 100 quintillion (100,000,000,000,000,000,000) possible passwords, so the odds are my password would still be pretty safe.

The lesson here is that a strong password is not a matter of being clever, it is a matter of beating the numbers. Passwords should always contain three or more words or other sequences.

4. Brute Force

If a password hash doesn’t show up in a database or hasn’t been cracked before, does not show up in a list of common passwords or dictionary words (even after trying hundreds of common variants), the only method left is to simply brute-force the password. This means trying every possible combination of letters until you find the password. It would be like trying to crack a simple bicycle lock, you would start with 000 and try 001, 002, 003, and so on until you got to 999.

In the case of passwords you would need to try every combination of lowercase letters, uppercase letters, numbers, and punctuation symbols. In other words, imagine a bicycle lock where each dial contains abcdefghijklmnopqrstuvwxyz ABCEDFGHIJKLMNOPQRSTUVWXYZ0123456789`~!@#$%^&*()_-+={[}]|:;"'.?/ and there are eight or more dials. This is why so many systems require that you use a variety of characters because using different types of characters is like making each dial larger. And making your password longer is like adding more dials.

 

 

Now brute-force attacks are much smarter nowadays using techniques such as mask-based attacks. These types of attacks basically use knowledge about passwords to make the brute-force process much smarter. For example, if you look at this chart http://xato.net/img/UpperCaseLettersLarge.jpg you will see that uppercase letters are very likely to show up in position 1 but are extremely rare after position 8. Knowing this, it would be more effective to not even bother looking for uppercase letters after the first few characters. Now if you look at the distribution of all character sets in this graph http://xato.net/img/CharacterDistributionByPositionLarge.jpg you can see that much can be done to optimize the brute-force process. Nevertheless, these rules become less and less effective the longer and more complex your password gets.

The big secret here is if you can force a hacker to have to use a brute-force attack and you have a password that is at least 15 characters long, chances are that you have won. Eventually computing power will catch up so that even 15 characters might be enough but the good thing is that these numbers grow exponentially so a 16-character password is almost 100 times stronger than a 15-character password and a 17-character is more than 9,000 times stronger!

So What Makes a Password Strong?

Your password must be something very unique and one that you have never used before. In fact it should be so unique that if you did a Google search for it, there would never be any results. You can’t just take a word and dress it up a bit, you need 3-4 words or other sequences to make a password strong. And finally it has to be long. It helps to throw in some numbers and pumctuation but most importantly it has to be long.

Creating Free 3rd Party Certificates

There are many ways you can use digital certificates in Windows. The only problem is that it often involves either having your own CA, paying for certificates from a trusted CA or, the worst option, using self-signed certificates. Fortunately, there is another solution. CAcert.org provides free digital certificates for anyone who wants to set up an account. This frees you from having to bother with setting up a certificate server and of course it doesn’t cost you anything. Continue reading “Creating Free 3rd Party Certificates” »