The Pathetic Reality of Adobe Password Hints

AdobeThe leak of 150 million Adobe passwords in October this year is perhaps the most epic security leak we have ever seen. It was huge. Not just because of the sheer volume of passwords, but also because it’s such a large dump from a single site, allowing for a much better analysis than earlier sets. But there’s something unique about the Adobe dump that makes it even more insightful–the fact that there are about 44 million password hints included in this dump. Even though we still haven’t decrypted the passwords, the data is extremely useful

One thing I have pondered over the years in analyzing passwords is trying to figure out *what* the password is. I can determine if the password contains a noun or a common name, but I can’t always determine what that noun or name means to the user.

For example, if the password is Fred2000, is that a dog’s name and a date? An uncle and his anniversary? The user’s own name and the year they set up the account? Once we know the significance of a password we gain a huge insight into how users select passwords. But I have never been able to come up with a method to even remotely measure this factor. Then came the Adobe dump.

The sheer amount of data in the Adobe dump makes it a bit overwhelming and somewhat difficult to work with. But if you remove the least common and least useful hints the data becomes a bit more manageable. Using a trimmed down set of about 10 million passwords, I was able to better work with the data to come up with some interesting insights.

Just glancing at the top one hundred hints, several patterns immediately become clear. In fact, what we learn is that a large percentage of the passwords are the name of a person, the name of a pet, the name of a place, or an important date.

Take dates for example. Consider the following list of top date-related hints:

Hint Total Note
birthday 29425
bday 17697
date 15272
birth 14956
DOB 13109
niver 9484 Spanish: Anniversary (short for aniversario)
fecha 8899 Spanish: Date
naissance 7892 French: Birth
anniversary 6959

In all, there are about 420,000 passwords with a date-related hint which represents about 3.6% of the passwords in the working set.

We see similar trends with dog names which account for 375,000 passwords or 3.2% of the total (plus another 120,00 that mention “pet”):

Hint Total Note
dog 70550
dogs name 13559
my dog 9780
dog’s name 8191
dog name 8187
perro 8000 Spanish
hund 7185 German, Danish, Swedish,  Norwegian
first dog 5653
chien 5542 French
doggy 5184

One interesting insight offered here is something we already know but find difficult to measure: password reuse. Surely a large percentage of these users have the same password across multiple sites, but it is interesting to see that about 361,000 users (or 3.11%) state this fact in their password hints:

Hint Total Note
same 44565
password 14634
always 13329
la de siempre 8559 Spanish: as always or the usual
same as always 8289
usual password 5277
same old 5111
siempre 4163 Spanish: always
normal password 3898
my password 3022

Keep in mind that these are just those passwords that admit to reuse in the hint. The number of passwords actually in use across multiple sites certainly is much greater than this.

Looking at the three lists above, we see that nearly 10% of the passwords fall into just these 3 categories. Adding names of people and places will likely account for 10% more.

So what did we learn by analyzing these hints?  First, that you should never use password hints. If users forget their password, they should use the password reset process. Second, that decades of user education has completely failed. No matter how much we advise not to use dates, family names or pet names in your passwords and no matter how much we tell people not to use the same passwords on multiple sites, you people will just do it anyway.

This is why we can’t have nice password policies.

 

 

Fingerprints and Passwords: A Guide for Non-Security Experts

iphoneToday Apple announced that the iPhone 5S will have a fingerprint scanner. Many of us in the security community are highly sceptical of this feature, while others saw this as a smart security move. Then of course there are the journalists who see fingerprints as the ultimate password killer. Clearly there is some disagreement here. I thought I’d lay this out for those of you who need to better understand the implications of using fingerprints vs or in addition to passwords.

Biometrics, like usernames and passwords, are a way to identify and authenticate yourself to a system. We all know that passwords can be weak and difficult to manage, which makes it tempting to call every new authentication product a password killer. But despite their flaws, passwords must always play some role in authentication.

The fact is that while passwords do have their flaws, they also have their strengths. The same is true with biometrics. You can’t just replace passwords with fingerprints and say you’ve solved the problem because you have introduced a few new problems.

To clarify this, below is a table that compares the characteristics of biometrics vs passwords, with check marks where one method has a clear advantage:

Passwords Biometrics
Difficult to remember Don’t have to remember 
Requires unique passwords for each system Can be used on every system 
Nothing else to carry around Nothing else to carry around
Take time to type Easy to swipe/sense 
Prone to typing errors Prone to sensor or algorithm errors
Immune to false positives  Susceptible to false positives
Easy to enroll  Some effort to enroll
Easy to change  Impossible to change
Can be shared among users 1  Cannot be shared 
Can be used without your knowledge Less likely to be used without your knowledge 
Cheap to implement  Requires hardware sensors
Work anywhere including browsers & mobile  Require separate implementation
Mature security practice  Still evolving
Non-proprietary  Proprietary
Susceptible to physical observation Susceptible to public observation
Susceptible to brute force attacks Resistant to brute force attacks 
Can be stored as hashes by untrusted third party  Third party must have access to raw data
Cannot personally identify you  Could identify you in the real world
Allow for multiple accounts  Cannot use to create multiple accounts
Can be forgotten; password dies with a person Susceptible to injuries, aging, and death
Susceptible to replay attacks Susceptible to replay attacks
Susceptible to weak implementations Susceptible to weak implementations
Not universally accessible to everyone Not universally accessible to everyone
Susceptible to poor user security practices Not susceptible to poor practices 
Lacks non-repudiation Moderate non-repudiation 
1 Can be both a strength and a weakness

 

What Does This Tell Us?

As you can see, biometrics clearly are not the best replacement for passwords, which is why so many security experts cringe when every biometrics company in their press releases claim themselves as the ultimate password killer. Biometrics do have some clear advantages over passwords, but they also have numerous disadvantages; they both can be weak and yet each can be strong, depending on the situation. Now the list above is not weighted–certainly some of the items are more important than others–but the point here is that you can’t simply compare passwords to biometrics and say that one is better than the other.

However, one thing you can say is that when you use passwords together with biometrics, you have something that is significantly stronger than either of the two alone. This is because you get the advantages of both techniques and only a few of the disadvantages. For example, we all know that you can’t change your fingerprint if compromised, but pair it with a password and you can change that password. Using these two together is referred to as two-factor authentication: something you know plus something you are.

It’s not clear, however, if the Apple implementation will allow for you to use both a fingerprint and password (or PIN) together.

Now specifically talking about the iPhone’s implementation of a fingerprint sensor, there are some interesting points to note. First, including it on the phone makes up for some of the usual biometric disadvantages such as enrollment, having special hardware sensors, and privacy issues due to only storing that data locally. Another interesting fact is that the phone itself is actually a third factor of authentication: something you possess. When combined with the other two factors it becomes an extremely reliable form of identification for use with other systems. A compromise would require being in physical possession of your phone, having your fingerprint, and knowing your PIN.

Ultimately, the security of the fingerprint scanner largely depends on the implementation, but even if it isn’t perfect, it is better than those millions of phones with no protection at all.

There is the issue of security that some have brought up: is this just a method for the NSA to build a master fingerprint database? Apple’s implementation encrypts and stores fingerprint locally using trusted hardware. Whether this is actually secure remains to be seen, but keep in mind that your fingerprints aren’t really that private: you literally leave them on everything you touch.

 

 

So What Exactly Did The US Government Ask Lavabit to Do?

The recent shutdown of Lavabit’s email services prompted a flurry of reporting and speculation about the extent US Government spying, mostly due to the mysterious statement by Lavabit founder Ladar Levison:

Most of us saw this as yet another possibly overhyped government spying issue and didn’t really think too much of it. Much of the media coverage is already starting to die down but there still is some question as to exactly what the government required of Levison that left him with only one option: shutting down his entire business he built from ground up. I wondered if there were enough clues out there to get some more insight into this case. I started by looking at exactly what Lavabit offered and how that all worked behind the scenes.

Lavabit Encryption

Lavabit claimed they had “developed a system so secure that it prevents everyone, including us, from reading the e-mail of the people that use it. ” This is a bold claim and one that surely was a primary selling point for their services.

The way it worked is relatively simple: Lavabit encrypted all incoming mail with the user’s public key before storing the message on their servers. Only the user, with the private key and password could decrypt messages. Normally with encrypted email, users store private keys on their own computers, but it appears that in the case of Lavabit, they stored the users’ private keys, each encrypted with a hash of that user’s password. This is by no means the most secure way of doing this, but it dramatically increases transparency and usability for the user. By doing this, for example, users do not need to worry about private keys and they still have access to their email from any computer.

So let’s break this down: a user logs in with their password. This login might occur via POP3, IMAP4, or through the web interface (which in turn connected internally via IMAP). Because Lavabit used the user’s password to encrypt the private key, they will need the original plaintext password which means they would not be able to support any secure authentication methods. In other words, all clients must send passwords using AUTH PLAIN or AUTH LOGIN with nothing more than base64 encoding. The webmail interface appears to have been available as both SSL and non-SSL and the POP3, IMAP4, and SMTP interfaces all seem to have accepted connections with or without SSL. All SSL connections terminated at the application tier.

Once a user sends a password, the Lavabit servers create SHA-512 hashes explained as follows:

… Lavabit combines the password with the account name and a cryptographic salt. This combined string is then hashed three consecutive times, with the former iteration’s output being used as the input value of the next iteration. The output of the first hash iteration is used as the secret passphrase for AES [encryption of the private key]. The third iteration is stored in our password database and is used to verify that users entered their password correctly.

The process they describe produces two hashes: one for decrypting the user’s private key and after two more hashing iterations, a hash to store in the database for user authentication. While this is a fairly secure process, given strong user passwords, it does weaken Lavabit’s claim that even their administrators couldn’t read your email. In reality all it would take is a few lines of code code to log the user’s original password which allows you to decrypt the private key which in turn allows you to receive and send mail as that user as well as access any stored messages.

The message here is that US courts can force a business to subvert their own security measures and lie to their customers, deliberately giving them a false sense of security.

It is important to note that the scope of Lavabit’s encryption was limited to storage on it’s own servers. The public keys were for internal use and not something you published for others to use. Full protection would require employing PGP or S/MIME and having untapped SSL connections between all intermediate servers. On the other hand, if an email was sent through Lavabit already using PGP or S/MIME encryption, they would never be able to intercept or read those emails.

The question here is what exactly did the government request Levison to do that was so bad that he’d rather shut down his entire business? What information could Lavabit even produce that would be of interest to a government agency? Unencrypted emails, customer IP addresses, customer payment methods, and customer passwords. Based on media statements, it appears that he would be required to provide unencrypted copies of all emails going through his system.

Let’s look at some quotes levison has given to various media outlets. First, here are some quotes from an interview with CNET:

“We’ve had a couple of dozen court orders served to us over the past 10 years, but they’ve never crossed the line.”

“Philosophically, I put myself in a position that I was comfortable turning over the information that I had. I built Lavabit in a reaction to the original Patriot Act.”

“Where the government would hypothetically cross the line is to violate the privacy of all of my users. This is not about protecting a single person or persons, it’s about protecting all my users. What level of access to this nation does the government have?”

“Why should I collect that info if I didn’t need it? [That philosophy] also governed what kind of information I logged.”

“Unfortunately, what’s become clear is that there’s no protections in our current body of law to keep the government from compelling us to provide the information necessary to decrypt those communications in secret.”

“If you knew what I know about e-mail, you might not use it either.”

In an article from NBC News, we have this:

Levison stressed that he has complied with “upwards of two dozen court orders” for information in the past that were targeted at “specific users” and that “I never had a problem with that.” But without disclosing details, he suggested that the order he received more recently was markedly different, requiring him to cooperate in broadly based surveillance that would scoop up information about all the users of his service. He likened the demands to a requirement to install a tap on his telephone. Those demands apparently began about the time that Snowden surfaced as one of his customers, apparently triggering a secret legal battle between Levison and federal prosecutors.

And finally in an interview with RT he said:

I think the amount of information that they’re collecting on people that they have no right to collect information on is the most alarming thing,” he told RT. “I mean, the Fourth Amendment is supposed to guarantee that our government will only conduct surveillance on people in which it has a probable suspicion or evidence that they are committing some crime, and that that evidence has been reviewed by a judge and signed off by a judge before that surveillance begins. And if there’s anything alarming, it’s that now that’s all being done after the fact. Everything’s being recorded, and then a judge can after the fact say it’s okay to go look at the information.

Given the above information, let’s analyze some of the facts we know:

  • The government asked Lavabit to do something which levison considered to be a crime against the American people.
  • Levison was comfortable and had complied with warrants requesting information on specific users.
  • Levison told Forbes that “This is about protecting all of our users, not just one in particular.”
  • Levison is not even able to reveal some details with his own attorney or employees.
  • Shutting down operations was an option to circumspect compliance, although there was a veiled threat he could be arrested for doing so.
  • He did not delete customer data, he still has that in his possession so this was a request for ongoing surveillance.
  • This was a court order, which levison is fighting through the US Court of Appeals for the Fourth Circuit.
  • Levison compared the request to installing a tap on his telephone.

Apparently what made Levison uncomfortable with the request was that the fact that it collected information about all users, without regards to a warrant. Presumably law enforcement wanted to collect all data that they would later retroactively view as necessary once they had a warrant. The two issues here are that the Government wanted to collect information on innocent users (including Levison himself) and Levison would be out of the loop completely, taking away his control over what information he provided to law enforcement. These were the lines the Government crossed.

What’s interesting here is that Lavabit terminated the SSL connections right on the application servers themselves. These are the servers that also performed the encryption of email messages. Because of that, a regular network tap would be ineffective. The only way to perform the broad surveillance Levinson objected to would be (in order of likelihood) :

  1. Force Lavabit to provide their private SSL keys and route all their traffic through a government machine that performed a man-in-the-middle style data collection;
  2. Change their software to subvert Lavabit’s own security measures and log emails after SSL decryption but before encrypting with the users’ public keys; or
  3. Require Lavabit to install malicious code to infect their own customers with government-supplied malware.

Sure, this could have been a simple request to put a black box on Lavabit’s network and Levinson is just overreacting, but the evidence doesn’t seem to indicate that. Regardless of which of the requests the Government made, they would all make Levison’s entire business a lie; all efforts to encrypt messages would be pointless. Surely there were some heated words spoken when the Department of Justice heard about Levison’s decision, but this is not an act of civil disobedience on Levison’s part, his personal integrity was on the line. Compliance would make his very reason for running Lavabit a deception; a government-sponsored fraud.

While Lavabit initially had quite a bit of media coverage over this issue, the hype seems to be a casualty of our frenzied newscycle. But after looking closely at the facts here, I now see that this is a monumentally important issue, one that the media needs to once again address. The message here is that US courts can force a business to subvert their own security measures and lie to their customers, deliberately giving them a false sense of security. They can say what they want about security on their web sites, it means nothing. If they did it to Lavabit, how many hundreds or thousands of other US companies already participate in this deception?

If the courts can force a business to lie, we can never again trust the security claims of any US company. The reason so many businesses specifically rely on US services is the sense of stability and trust. How sad that an overreaching and panicked pursuit of a whistleblower has thrown that all away.

This issue is so much more than a simple civil liberties dispute, it is the integrity of a nation at stake. We walked with the devil in a time of need–that is a legacy we must live with–but at what point do we sever that relationship and return to the integrity required to lead the world through respect and not by fear?

 

Lavabit,png

2004-2013

 

UPDATE: Since publishing this post, this Wired article has since revealed that in fact Lavabit was required to supply their private SSL keys as suspected above.

 

Pafwert: Now Open Source

PafwertMore than 15 years ago I started working on a unique password generator that eventually evolved into a small program I now call Pafwert.

Pafwert is an unique tool to help you to select strong passwords that are easy to remember. Using strong entropy, tens of thousands of seed words, more than a hundred patterns with endless variations, and following password best practices, Pafwert can help you to select very strong passwords that are surprisingly easy to memorize. We have all seen random password generators, but Pafwert is very different.

Of course, while I still recommend using a password manager and generating completely random passwords, there are plenty of passwords we need to remember that we just aren’t able to save in a password manager. That is where Pafwert comes in.

Pafwert uses familiar patterns and a variety of memorization techniques to help you create strong passwords that are also easy to remember. Keep in mind that you don’t have to use the passwords exactly as it spits them out, you can use it simply as a tool to spark your own imagination when creating your passwords.

Pafwert is actually much more complex than it appears on the surface and generates passwords based on patterns and wordlists that you can customize. It then runs these passwords through a number of filters to obscure them just enough to make them unique. Yes, I probably wasted many thousands of hours overthinking this thing. Nevertheless, over the years it has gotten buried on my web site and largely forgotten (although I still use it myself every day).

I thought it was about time to update this tool and open source it (under the Apache license) to share it with the community. I would like to see it updated with new features and maybe even ported to PHP, but for now the code is there for anyone to play with. Note that I began work on this version of the code in 1999 so it is written in Visual Basic 6. That means that few of you will have the tools to do anything with the program itself (although I do have a complete dev environment in a VM if someone is serious enough about working on it).

If you would simply like to download the latest compiled version to install yourself, you can always grab it at http://xato.net/pafwert or you can check out the source code at GitHub.

If you want to get a taste for the complexity of this tool, you may want to spend a few minutes and read the Pattern Guide.

Hopefully someone can find this useful, if you do, let me know!


Pafwert – Smart Password Generator
https://github.com/m8urnett/pafwert
4 forks.
0 open issues.
Recent commits:


 

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

Now eBay Wants in on Password Patents

I wrote a couple months ago about the many attempts to patent various methods of checking passwords. Now eBay wants in on the game with United States Patent Application 20120284783. Here’s their summary:

A proposed password is decomposed into basic components to determine and score transitions between the basic components and create a password score that measures the strength of the proposed password based on rules, such as concatenation, insertion, and replacement. The proposed password is scored against all known words, such as when a user is first asked to create a password for an account or access. The proposed password can also be scored against one or more previous passwords for the user, such as when the user is asked to change the user’s previous password, to determine similarity between the two passwords.

Reading through the claims, this is by no means novel or innovative and there certainly is plenty of prior art for this. Want to help prevent yet another abuse of the patent system? You can post any evidence of prior art on this Ask Patents post.

 

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.

 

Want to Block Common Passwords? Sorry, That is Patented

I always enjoy browsing through password-related patents to see all the flawed, silly, or outright dumb ideas that people come up with in an attempt to improve how we authenticate ourselves in the digital realm. What amazes me though is how many patents I encounter that have been granted for some of the most obvious, well-known and ordinary techniques we use in the authentication process. In fact, every imaginable aspect of password selection, authentication, storage, and recovery seems to be covered by one or more patents. Continue reading “Want to Block Common Passwords? Sorry, That is Patented” »

6 New Password Rules

Considering the increasing attention passwords have been getting lately, I thought it was about time we sit down and establish some new rules to define exactly what is a password. After all, so much of our personal lives, finances, and identities rely on these obscure jumbling of letters, numbers, and punctuation.

1. Password, 1234, letmein, and anything else that you see on this common passwords cloud are not passwords.

Recently I took my son over to a friend’s house and when we got there we found he lived in a gated community that required a PIN to enter. My son was about to call his friend when I told him, “I got this.” I reached over and entered 1234 and the gate promptly swung open. Yeah my son was very impressed at my hacker skills, but the fact is that 1234, 12345, or even 12345678 are not strong enough to be considered passwords.

 

2. If you google your password and get more than 10,000 results, it is not a password.

It’s really simple, if your password shows up that many times in Google, your password is not a password it is a dictionary or common wordlist word.

3. If your password is 8 characters or less, it is not a password.

An 8-character password just isn’t strong enough these days to be considered a password. Most 8-character passwords consist of a dictionary word or name with a couple numbers added to the end. These are incredibly easy to crack and will not stand up to a brute force attack no matter what type of encryption used. If your password is 8 characters long, you might have a PIN, but it certainly is not a password, which is probably why banks seem to love limiting password length to 8 characters. I recently explained just how much of a difference there is between an 8-character password and a 10-character password, but maybe this would illustrate it better:

8 Character Password

This is the equivalent of an 8-character password

6 Character Password

This is the equivalent of a 6-character password

 

 

 

 

 

 

 

 

 

 

4. If you use it on multiple sites, it is no longer a password.

Considering the huge number of passwords hacked and dumped on the internet every single day, I would hope that most of us have learned that you simply cannot reuse the same passwords on multiple sites. You are better off never even considering using the same passwords everywhere because it is easy to fall into that habit.

Just to illustrate why this is such a big deal, there are people such as me who collect passwords. Here is a list of all the passwords I have for the username bonehead. Now if I know that there is a user named bonehead on a web site, I can try all of these passwords and chances are surprisingly good that one of these passwords is correct. Why is this such an effective technique? Because everyone reuses their passwords on multiple sites.

5. If a password is older than 3 years, it has expired and is no longer a password

I know some of you get really attached to your passwords, but it is time to start using a password manager and changing those very old Hotmail and PayPal passwords.  You wouldn’t eat 3-year old food, so don’t use a 3-year-old password.

6. If you tell someone your password, it is no longer a password

Certainly sometimes it is necessary to share an account, but there is no excuse for telling someone your personal passwords, and this includes writing them down and sticking them on your monitor. If you have trouble doing this, one trick is to set your password as some phrase that reveals some highly personal or embarrassing fact you would never tell anyone–problem solved!

So come on people, we really can make passwords that really are passwords. Passwords don’t need to be totally random and they don’t always have to have numbers, capitals, and punctuation, but they do need to be long, unique, and secret!

 

 

 

 

My Advice: Just use a Password Manager

For years I have advocated using long, memorable passwords using a variety of different memorization techniques. Humor, repetition, common suffixes, memorable phrases, and other methods are great for creating long passwords that are easy to remember.

But now my philosophy has changed: now I say just go ahead and use a password manager and generate long, random passwords for each online account.

While I still use my own easy-to-remember passwords for sites where I often need to enter passwords manually, the bulk of the passwords I create now are long, random passwords that LastPass generates for me. Even five years ago it was possible to manage and memorize ten or twenty unique passwords, but the world has changed and it is not uncommon for a typical web user to have dozens if not hundreds of online accounts.

With so many large web sites becoming victims of public account dumps, it is now more important than ever that you never reuse the same password anywhere. Tools such as LastPass or KeePass make the process of creating, managing, and entering passwords so simple, there is hardly any reason not to use one of these tools.

Yes, you can come up with fancy patterns or methods of creating unique passwords for each site, but it just is not worth the effort and pattern-based passwords tend to be shorter than they should be. Passwords are more vulnerable to attack than ever; you should never create a password less than 10 characters but use 20 or more if the system lets you. Managing this many strong, unique passwords is almost impossible to do now without the help of a password manager.

Yeah, I kind of miss making new clever passwords, that was always the fun part of creating new accounts. On the other hand, it is still kind of fun seeing how long a password each web site lets me create. My record so far: 128 characters, and it was a dumb recipes site.