Paul E. Jones' Blog

Passwords are really getting out of hand. Every web site you visit requires a password. Every password should be different. You should change your passwords from time-to-time. Every password should be very hard to remember, uhm, I mean use letters, numbers, and special characters so they are hard for hackers to crack or guess. Oh, and never write down passwords in a place where somebody might steal them.

While one solution might be to store your passwords securely in a bank vault, that is not a practical solution to managing passwords.

Risk of Using the Same Password

Of all of the rules that people are advised to follow, the one that says you should not use the same password on multiple sites is definitely one rule you do not want to break. While perhaps no web site intends to divulge your password, the fact is that web sites get hacked often and passwords are stolen. When a web site gets hacked that has your password on file and you use that same password for your bank account, watch out! You really should not use the same passwords twice.

Complexity of Passwords

Passwords should also be complex. However, passwords do not need to be as complex as some people might lead you to believe. Web sites that argue that you need a special character (e.g., #, $,%) in your password simply have not done the math to see that such a requirement is utterly useless.

What is important is that passwords are sufficiently long and cryptic. One should not use a password like “12345.” One should also not use a password like “wildcat”. Those are simply too easy to guess. If one can look in the dictionary and find your password, you need a better password. If you merely take a word or a name and a few numbers, that’s also not sufficient. While it might take you a while to guess a password like “sally123”, it would take a computer a very short amount of time to discover that password.

What is a good password length? And what characters should be used? The answer requires a little math, so please don’t fall asleep now. Oh, and the answer requires a little understanding of how a computer organizes information. That might put you to sleep, but keep reading and, if nothing else, just see the result.

Let’s assume you take all upper- and lower-case letters and the digits 0-9 and use those in your passwords. That gives you a total of 62 characters. Let’s assume you have a one-character password. That would mean a hacker would have to look at 62 different values to guess your password. Using password cracking software on a computer, cracking your one-character password would take a split second.

What about a two-character password? Using the same characters, the possible permutations would be 62*62 = 3844. Still, that is nothing for a computer. A hacker could still have your password cracked in the blink of an eye.

Clearly, you need something stronger. How do you measure the “strength” of a password? If you understand that, then it starts to become clearer.

Each character used provides a certain amount of “strength” to your password. Specifically, it provides log2(62) bits of strength, or roughly 5.954 bits of strength. Having a two character password would provide you with about 11.91 bits of strength. So, what is 11.91 in a form a human can understand? This essentially means 2^11.91 possible values, or 3844 possible values. That’s because, 2^(log2(62) * 2) is the same as 62 * 62. I’m not trying to make this challenging for the heck of it. You’ll see why it is useful to use logarithms. It’s important that you think of password strength in terms of bits, not the number 62.

What about a 5 character password? That would provide a bit strength of log2(62)*5 = 29.77. That’s improving, but a purpose-built password cracking machine would have that one cracked in 0.32 seconds. (Per Wikipedia, commercial products can crack 2,800,000,000 passwords per second on a standard desktop computer.)

So, we need more bits of strength. Still, how many bits? Perhaps the answer is another question: how many years would you like a hacker to consume trying to crack your password?

We know that the strength in bits of a password comprised of letters and numbers is log2(62)*n, where n is the number of characters in the password. Further, this means that 2^(log2(62)*n) tells us how many passwords the hacker will have to consider while cracking the password. We also know that a commercial product can crack 2.8x10^9 passwords per second and there are 31556926 seconds in a year. So, the number of years it would take to crack a password of length n using this computer would be 2^(log2(62) * n) / (2.8x10^9 * 31556926).

Let’s use this formula once with a password length of 12 characters. That would be 2^(log2(62) * 12) / (2.8x10^9 * 31556926) = 36513 years. I feel fairly comfortable that my bank account would be secure with such a password, don’t you?

Working the other way, we can compute how long the password should be to force the hacker to work a specified number of years. The formula is log2(years * password_cracks_per_second * 31556926) / log2(62) or log62(years * password_cracks_per_second * 31556926) (but who uses log62?), where “years” you want to make the hacker work. Let’s say you want it to take 100,000 years. Then, you would need a password that is at least log2(100000 * 2.8x10^9 * 31556926) / log2(62) = 12.24 characters long. Since you cannot use part of a character, you would just use 13 characters for good measure.

Let’s also remember that hackers have access to more than one computer. Perhaps they might employ 1000 computers to crack your password. Using the equation 2^(log2(62) * 12) / (2.8x10^9 * 31556926 * 1000), we can see it would still take a hacker up to 36 years. I still feel fairly confident. I do not know a hacker who would want to devote 36 years of computing resources of 1,000 machines to get any information I have.

Even so, let’s say I’m overly paranoid and I want to ensure it would take 100,000 years with 1000 machines. How long should my password be? We use the formula log2(100000 * 2.8x10^9 * 31556926 * 1000) / log2(62) to learn that the password needs to be 13.92 characters long. So, a 14 character password really packs a powerful punch!

Now, recall that I talked about how some web sites insist that you use “special” characters on the keyboard to make passwords “stronger”? On most keyboards, there are only a handful of additional characters available. Let’s assume you use a total of 93 characters, using letters, numbers, and various special characters. How strong would that password be? Well, the bit strength would be log2(93) or 6.54. That’s only a little better than 62 characters. So, a 12-character password with 62 different values has a strength of log2(62)*12 = 71.45 versus log2(93)*12 = 78.47. You can see that there is little difference. If the extra strength is important, just make your password one character longer. There’s no reason to require use of special characters on the keyboard, as it adds an insignificant amount of bit strength. Let’s consider that example again where we want to protect our password from attack for 100,000 years using a single computer. Recall that for 62 characters, we need 12.24 characters. With 93 characters, we need 11.15 characters. So, it’s 12 versus 13 characters. Big deal. It’s not worth the complexity forced on a human to type in the special characters.

So the bottom line is that anything more than 70 bits of strength (12 or more characters) is a strong password today, though I personally prefer using over 90 bits (16 or more characters).

Generating Strong Passwords

Now we know you need a password that is 12 characters or longer to be good. But they cannot be simple words. They need to be as random as possible. It would be advisable to use a program that will generate random passwords for you. Passwords should not be easily guessed and should truly be as random as possible.

Password Management

So, how in the world do you keep track of your passwords? You could write them all down on paper and keep it secure. That’s a valid option, but not portable. Will you take that piece of paper with you on trips? You could write them down in a computer file and take that with you. But what if the file or paper is stolen or lost?

One solution is to keep all of your passwords stored inside of some kind of password management program. Typically, these programs store all of your passwords, securing them with a single secret password that you do not write down. This is a reasonable solution to the problem, especially if the data is accessible while at home, work, or traveling.

Another solution is to use Single Pass. What Single Pass does is generate a unique, secure password that is 16 characters long using a single “master” password that only you know. It’s similar in concept to the password management software, but it actually does not store passwords. Rather, it generates them on demand. To ensure that each password is unique, you provide a “service name” when generating the password. Given your Single Pass password and Service Name, the same password is always generated.

The Service Name could just be the name of the web site or business (which is reasonable for lower-security applications), or it could also be a cryptographically strong string of random characters (useful for your bank account). In fact, I generate random strings for Service Names. I maintain a file that lists the “Service Names” I give to web sites, using this password generator. I then have a master password that I do not write down that only I know. In order to crack my passwords, you would either have to crack it using brute-force (and they are 16 characters long, meaning it would take 1000 high-end machines 539 million years to crack).

The good thing about this dual-password approach is that my Single Pass password is useless without the accompanying file that holds the Service Names. Likewise, the Service Names are useless without the Single Pass password. Should somebody steal either piece of information, I would still have plenty of time to go change my passwords. But I can remember my one password and I don't have to worry so much if somebody steals my list of Service Names.

Doing Away with So Many Passwords

In an ideal world, we would have a better login solution on the Internet than having to use passwords on all web sites. There is one solution on the Internet that has promise: OpenID. OpenID allows you to login to a web site using a single password stored at an OpenID Provider. There are many providers, such as Yahoo!, Google, and VeriSign. If you can place your trust with one of these companies, you can avoid the need to have a different password for every web site on the Internet.

Questions still abound as to whether OpenID will succeed. There has been pretty good adoption and I’m personally a supporter of OpenID. Unfortunately, support is not as widespread as I would like, and most web sites still do not support it. So, alternative solutions like Single Pass that work with the world's crazy password craze are a necessity.

I've used WinZip for a very long time. I can’t say for certain when I first started using it, but I’ve been using the product since at 1998. Unfortunately, the latest version (v16) proved to be a huge step in the direction of being sleazy adware.

One of the first things I noticed when I installed WinZip 16 was that the icons had changed. There is this new “ZIP Send” icon that is ugly. For that matter, most of the interface elements are not as pretty as they used to be in previous versions of WinZip. The attractiveness of the user interface was actually one of the things I liked about WinZip. I did not let that ugly Z bother me, though. I was more interested in the functionality.

What really got under my skin was a new toolbar that got installed without my permission. This was a toolbar apparently created by an outfit called “Conduit Ltd” called “WinZipBar”. I didn’t want that installed! I am very careful to not install such things. I tried removing it from Chrome and it acted as if it was gone. Unfortunately, it wasn’t. Buried in the Windows Registry, there was stuff that allows the toolbar to reappear. I discovered this when I tried out the “new user” feature in Chrome. That toolbar came back! This software was supposed to have been removed from my system, yet it was there! It took time, but I believe I found all of the necessary registry entries and files on the hard drive. It better be gone.

I went on with WinZip 16, but discovered today that there is a “WinZip Quick Pick” running in the task tray. Again, that’s not something I want, so I tried to remove it. As you can imagine, you cannot remove it. At least, I could not remove it. I could get it to shut down, but it would come back after rebooting the machine.

As if this nonsense wasn’t enough, I discovered that WinZip also installed other programs on my machine that I didn’t want. One was a “Registry Optimizer” from WinZip. I didn’t pay much attention to what the other was, but it also left me with the impression that WinZip is turning into those sleazy companies peddling unwanted adware and spyware.

I’m not accusing WinZip of doing anything unethical, but I want WinZip as a good file compression utility. I do not want a browser toolbar. I do not want a task tray program. I do not want a registry optimizer. I certainly do not want any of that stuff pushed onto my machine without my permission.

I uninstalled the software and the web site sought my feedback. I tried to provide it, but their server reported an error. That figures.

Today, Google opened Google+ to the public. I've been using Google+ for a while. It presents a very different user experience than Facebook. It seems lighter and more relaxing. Then again, it might be because it has largely been a ghost town since opening for private beta. Still, it has millions of users and a fair number actually do post with some regularity. Overall, it looks better than Facebook, in my opinion. It is missing a few useful features, though, such as the ability to create groups of people who are not otherwise in one's circle (e.g., a team of people collaborating on a project or similar). It also lacks the concept of a "Facebook Page", which suits me fine. The whole darn Internet is supposed to be for posting content. Facebook Pages remind me of AOL's attempt to own all on-line content.

In any case, I have a Google account and a Google Profile URL that's so simple and easy to remember. It's https://plus.google.com/103173924987331945891 :-)

I really enjoyed being a part of the revolution that helped move traditional voice services from the PSTN to IP. Merely moving voice from a switched circuit network to a packet-switched network was not the reason for my interest in the field of multimedia communications, though. I was interested (and remain interested) because IP networks open up the door to a world of rich communication capabilities. With IP, there are so many more modes of communication that are possible. Concepts like the Advanced Multimedia System are really cool, where one can utilize a device (like a mobile phone) and communicate with various other devices on the network to realize a powerful and rich communication experience. One can utilize an electronic whiteboard on one device, while having a video stream on another device, and transfer a file in the background on a third device.

All the while, though, there is one ancient piece of technology that simply will not go away. As much as I wish it would, people still insist on using it. That technology is the PSTN facsimile machine.

I was also one of the people that helped to define the standard for transmission of Fax over IP (FoIP). To be fair, I was not the person who designed the first version of the protocol (known as Recommendation ITU-T T.38). Even so, I played a significant role in helping to ensure its place in the IP world. I did not do that work because I liked T.38, though. On the contrary, I have always been of the mind that T.38 did little more than perpetuate the PSTN and a better solution should have been delivered to the market. T.38 exhibits all kinds of problems, especially when there are multiple PSTN gateway hops in the call path. The protocol is very sensitive to end-to-end round-trip delay and, as a half-duplex technology, there are often collisions on the PSTN circuits that cause calls to fail. If that were not enough, some service providers do not provide proper treatment of the modulated signals, sometimes even running them through voice codecs! If you have experienced problems sending faxes, it might very well be due to the fact that the faxes are going over an IP network.

Still, I cannot fault the original designers. At the time the specification was first written, device capabilities were limited and the designers had to make certain choices. Moreover, many of the current-day problems with T.38 will disappear as fewer and fewer PSTN gateway hops are inserted in the end-to-end media path. I look forward to that day, but at the same time I have to ask, “Why do we live with fax at all?”

The answer to that question is simple. It is the reason I was asked to work on T.38, related session signaling protocol support, security enhancements, and so forth. Fax is an important part of day-to-day business for many businesses and government agencies. Many companies around the world rely heavily on their fax machines to get business done.

Even so, there is a better solution on the market and it has been there for years. It’s called “PDF over SMTP”. It is a very simple technology for end users to use, too. All one has to do is send an email and attach a PDF document. There are even multi-purpose devices sold in office supply stores now that will scan documents and email them as PDF documents to people anywhere in the world. It is just as easy to use as the legacy fax machines, provides the same or better security, reduces wasted paper, reduces cost, produces a higher-quality black and white or color document, and completely side-steps all of the transmissions problems that exist with legacy fax machines. Further, it is a completely standard solution to the document transmission problem!

Seriously, we should all switch over to using email to send documents and stop using the old fax machines. I am absolutely amazed that the world has not already moved away from that old technology, but my guess is that many people are simply unaware that there are many models of printers and scanners already on the market that have PDF over SMTP capability. Here is one such high-end model and a low-end model. Perhaps the problem is simply that nobody calls it PDF over SMTP. In fact, none of the vendors have a name for this capability. So, I plea to device manufacturers: call it PDF over STMP so customers know they can get away from the old fax machines they are currently forced to use.

One of the challenges we’ve often faced with IP multimedia communications systems is that of session identification. H.323 has the concept of a “Call ID” and SIP has the concept of a “Call ID”, but they are not compatible with each other. As such, it’s impossible to allow a session to be identified end-to-end. This opens up the possibility of getting into call loops, etc.

Aside from avoiding network issues like call loops, though, there is also a desire to be able to identify a session end-to-end (even through interworking functions), track a session as it is transferred, identify sessions that are part of the same multipoint conference, and associate media flows with a signaling session.

In H.323, we introduced a field (called CallLinkage) that made an attempt at tracking calls as they were transferred. However, the rules for how to populate those fields were complex and, in the end, few implemented the procedures. Still, what would work for H.323 did not work for SIP.

Within H.323, we have the ability to associate all devices that are part of the same conference, since all participants use the same conference identifier (CID). Well, so is the theory. In practice, though, most multipoint conferences are really just a logical association of point-to-point sessions. So, the conference identifier in H.323 has not been use consistently. And, as before, what would work for H.323 does not work for SIP.

Management systems, policy enforcement points, and other network elements might also want to associate session signaling with media flows. To do that, somehow those two need to be correlated with each other. There are ways we could allow that to work for SIP or H.323, but there are real-world implementation issues in trying to do that. Further, selecting a mechanism that works for SIP or H.323 would not allow this to work end-to-end.

In recent weeks, there has also been a lot of activity on the SIPREC mailing list in the IETF where folks recognize a need to have some kind of session identifier, and what currently exists for SIP is not workable.

For these (and other) reasons, some colleagues and I put together an initial draft of a new Session Identifier that can be used by H.323, SIP, or even the forthcoming H.325 multimedia communication systems. Feel free to give us feedback!

I just read an article on CNET about expansion of the gTLD namespace. Is this really a good idea?

We already have domains like .museum, .aero, .biz, .jobs, .mobi, .travel, .pro, etc. How many of these do we see being used in practice? I have seen a few such domains, but very few. So, why do we think opening up more gTLDs will encourage people to use them? I doubt it will.

The biggest frustration with .com is the fact that so many names are taken, quite often by somebody sitting on the name to earn ad revenue. If that behavior were stopped, we would not have an issue with .com. After all, if one wanted to create a company called “Foo” and discovered that “Foo” was already used by another legitimate business, that person would probably want a different name just to avoid confusion. Having foo.com and foo.biz is not helpful to the business with that name. Having foo.* only exasperates the problem.

Do we really want or need foo.plumbing and foo.computers? Imagine if Apple's domain was apple.computers. What would the company do when it decided that it was no longer a “computer” company and wanted to present itself more broadly? Oh, apple.com. So, why not just start with .com in the first place?

I think ICANN should put more effort into removing domains that exist solely for the generation of ad revenue. I believe that would address the concerns people have with limited name space.

For most sizable corporations, there is a desire to be able to federate identity for users within the corporation to third-parties. For example, your company might provide travel services to employees through a third-party portal, allow employees to view paychecks on a third-party web site, etc. To allow this to be done safely and securely, the two businesses must work together to come up with a way in order to authenticate the corporate user. All too often, though, the third-party has absolutely no hand in the authentication step and merely trusts that a URL from the company, that somehow identifies the user, is legitimate.

Some of the inter-domain federation mechanisms are really, really insecure. I’ve seen some that are so bad that all one needs to do is grab the URL and use it to access an employee’s confidential information.

OpenID can be used to address this issue securely and without using proprietary mechanisms. Rather than authenticating the user and redirecting the user to a third-party with some kind of trust “credentials” inside the URL, the company can just redirect the user to the third-party and provide the user’s OpenID identifier. For example, when redirecting the user to the corporate travel site, perhaps this might be the URL used:

http://travelsite.example.com/?openid=http%3A%2F%2Fopenid.packetizer.com%2Fpaulej

The receiving travel site will receive the OpenID identifier http://openid.packetizer.com/paulej and can then go through the normal OpenID procedures to authenticate the user with the corporation’s OpenID server. This is far better than passing “credentials” around via URLs. Equally important, the method is very simple and secure. Further, it removes the need to create and manage a host of proprietary mechanisms between various “trusted” third-parties.

For years, I’ve been frustrated with the fact that I have so many login identities and passwords for literally hundreds of web sites. Of course, I’m certainly not alone in that respect, as just about everybody has way more logins than they can deal with. The problem has been so bad that I laugh when I read a notice on a web site that says to make your password secure, using mixed-case and special characters. Say, something like this: rS3YC%e@6. Oh, and don’t write it down, is the advice given. Memorize it. And don’t use the same password on two sites. Yeah, right. Nobody can do that. Perhaps a person can manage to do that with one or a very few passwords, but not hundreds of passwords.

That is why I am so delighted to see OpenID taking off. For those who do not know, OpenID solves this problem by giving users a single user identity and password that they can use to access all of their OpenID-enabled web sites. Right now, sites like Blogger, Facebook, Flickr, MySpace, WordPress, Google, Yahoo!, and many more sites have support for OpenID. We even have OpenID support for Packetizer Forums, so you don’t have to keep up with a separate ID to discuss stuff about VoIP, videoconferencing, or cloud computing.

One of the really cool features of OpenID that is not fully appreciated is the fact that it is possible for you to log in once and never have to log in again. You can roam around from site to site and be automatically logged in. Perhaps you might have to provide your user ID, but you don’t have to provide your password if your identity provider supports the right features in OpenID. With the OpenID software we use on Packetizer, you can indicate when you log in the first time whether you want to be prompted for a password again or not.

Anyway, I’m excited since more and more web sites are adding support for OpenID. This makes using the Internet so much more enjoyable.

Recently, President Obama signed into a law a bill that would help encourage tourism to the US. Called the Travel Promotion Act, every visitor to the United States will be required to pay an entry fee.

That certainly does not sound like it would encourage tourism to the US. “Welcome to the US. Now, pay your fee.”

There is, of course, more to the bill than that. The bill is intended to create a marketing organization and a set of programs to help encourage visitors to come to the United States. This is all fine, but why do people not want to come to the United States, anyway?

Well, there are reasons. First, many visitors to the US must get a visa. There are certain countries where this is not required, but even in those cases, visitors are required to go online and complete some entry form, otherwise they will be denied entry.

All visitors are required to fill out far more paperwork than any other country in the world (the white I-94 or green I-94W form), staple crap into their passports, and are required to ensure that the departure document is properly returned before departure. Failure to do that might jeopardize the visitor’s ability to come to the US again, and will certainly increase the likelihood of having to get a visa the next time the visitor might wish to come to the US.

Upon arrival, US immigration officers will take the visitor’s mug shot and fingerprints, almost as if the person arriving is assumed to be a felon. Sure, all of this was done to “protect national security” after the attacks of 9/11, but does the leadership of the United States not understand how this makes a visitor feel?

Oh, and have you ever watched how our border agents (especially those running the scanners) treat visitors when they do not follow instructions? They are absolutely rude. It does not matter that the visitor cannot speak English. They don’t care. They’ll just yell at the visitor as if they’re a common criminal. I’ve seen it happen far too many times.

So, because we put up so many barriers to people who want to visit the United States, people do not come. And then we wonder why. So, we create a marketing organization and fund it to encourage visitors.

Do the folks in Washington not understand the root problem? I can hop on a plane and fly to Switzerland tomorrow. I’ll be greeted with a smile, not required to fill out any documents at all, and given no harassment whatsoever by the border agents. There is a difference and people feel it.

Lots of folks I work with in the ITU-T, which is a part of the United Nations, have explicitly asked me to not hold meetings inside the United States for all of these reasons -- and so I don’t. Perhaps one day our government will stop treating visitors so poorly.

Web-based interfaces (also called APIs) are growing in popularity. Some are very trivial, such as an interface that returns a list of stock quotes, while others are more complex. There are a number of technologies in use today, but what I’ve been focused on primarily is REST.

REST is a very simple idea, but there are so many opportunities for making it complex. One example is REST Versioning. We posted some recommendations on how to deal with REST versioning and we also have some discussion of XML versioning to support that.