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!

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.

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.

Many hackers around that time weren’t malicious or set out for destruction, but were more of the mindset of whistle blowers. It was easy to get so caught up in frustration that we took extreme steps such as actually breaking in to systems before they hired us as clients just to get our point across. I have since learned to have a bit more tact with my approach, but the frustration is still there and has evolved from web server security to email security.

The Email Security Problem

It amazes me how complacent we (yes, including myself) have all become with email security. It is one of the oldest and most fundamental of Internet technologies yet it is also one of the least secure. It’s funny how we freak out about passwords stored plaintext, yet we all communicate sensitive information every day using a fragile, unreliable, and insecure technology that really hasn’t changed much since the seventies.

I almost feel dumb having to list these long-time flaws yet again, but here are some of the major shortcomings with email communication as commonly implemented:

• Much of it travels from server to server using unencrypted protocols allowing for interception
• The email itself can be read and intercepted by any server involved in the transport across the Internet
• There is no way to know if someone has read or intercepted the email during transport
• The email is stored unencrypted, sometimes permanently, on the receiving server and often the sending server
• We store the email unencrypted, sometimes permanently, in our own inbox
• When we send an email we can never be certain that it will go to the intended recipient and that only that recipient can, will, or has read the message
• There is no way the recipient can be certain that we were the actual sender nor is there a way to prove we did or didn’t send an email
• There is no assurance that the message you sent has not been altered
• It is difficult to send a truly anonymous and untraceable email
• It is difficult to conceal who you communicate with on a daily basis

Of course technology exists to address every single one of these problems, and many of us use those, but as a whole these flaws still exist. And none of this is new, we have been complaining about and pointing out these flaws for decades. What is critical here is that we have become so complacent with email security while at the same time working on the baseless assumption that email is somehow secure.

Just look at some of the ways we have built upon that assumption of security:

• So many authentication practices entirely depend on email as a key component for identifying an individual, such as password resets or to remove certain account restrictions as Matt Honan discovered the hard way.
• We often use email to initiate sensitive financial, business, or extramarital transactions.
• Many mail systems rely on mechanisms rely on technologies that are not globally or are poorly implemented as mathematician Zach Harris pointed out to Google last year.
• We often communicate and store extremely sensitive information which can be very damaging as demonstrated by the painful experiences of Stratfor and HBGary Federal.
• As unreliable as it is, courts allow submitting email as legal evidence in many situations.

The fact is that if someone owns our email account, they own us. To make things worse, so many of us hand the keys to our lives over to the custody of third parties such as Google, Microsoft, and Yahoo! It is good to see companies such as Google adding two-factor authentication to Gmail and making SSL protocols more the standard, but we all know that they can read our email–or turn it over to law enforcement–anytime they want.

My frustration surfaces as I write posts like this because I realize not only how much we have failed, but how difficult it will be to get major email providers to give us the tools we need to make global email security a reality. The technologies to accomplish this have been around for years. While there are some limitations, none of these are insurmountable–as humans we are extremely proficient at solving problems.

For some reason, whistle blowing-style hacks and scare tactics haven’t phased us much when it comes to email security. If we knew that every postal letter we sent went through an NSA facility where they opened, photocopied, and stored every postal letter we sent, we’d freak out. But that happens every day with email, yet we happily continue to exchange highly sensitive and personal information in those emails.

While it is easy for people like me to complain about the problem and then say that someone else has to go fix it, in this case it is clear that global email security will only come about once Gmail, Hotmail, and Yahoo! mail all make strong and seamless encryption a reality. Once the day comes that even Google can’t read our email, we will have succeeded. Will we see it in 2013? Definitely not. How about in the next ten or even twenty years? That too remains to be seen.

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.

Because this case potentially affects everything we do in the cloud, I have followed it closely. But I have to say I am a bit amazed by the arrogant, contradictory, hypocritical, almost desperate brief the government filed a few days ago. I recommend taking a few minutes to read the whole thing, but it basically comes down to the government arguing that instead of having one hearing to see if the guy can get his data back they should break it down into several different hearings, one to argue each point. Their logic is that if they don’t get past the first point, they don’t need to hold any more hearings.

The government would like the hearing broken down like this:

1. A hearing requiring Kyle Goodwin to prove he owns the files he says he owns.
2. A hearing to determine if Federal Rule of Criminal Procedure 41(g) allows Goodwin any relief.
3. Another hearing that would consider exactly what relief might be appropriate.

They also imply other hearings, such as an evidential hearing or another to ensure the court even has jurisdiction over the complaint.

Of course, this is all absurd and an obvious attempt to delay the proceedings and put a greater burden on Goodwin and anyone else who might want to get their files back. It is a common tactic and is one of the reasons why many law firms refuse to accept cases suing the government: even if the government is wrong, they have enough resources to completely swamp a law firm with paperwork and procedural obstacles potentially costing the firm millions of dollars just to get the case heard.

The government’s argument is that by breaking the hearings up, they can put less of a burden on the court. They state that by having just one hearing that “the Court may unintentionally authorize a large amount of irrelevant discovery that impinge on the criminal proceedings.” Plus, they argue, if you dispute some facts, that would likely result in having to dispute other facts and that might require “the testimony of numerous witnesses, including potential expert witnesses.” Finally, they argue, that because they won’t know the scope of the hearings, they don’t know how much information they will need to gather.

Much of the government’s filing is a clear attempt to kill the case by saying that Goodwin can’t even prove he owns his files. It all comes down to Federal Rule of Criminal Procedure 41(g):

(g) Motion to Return Property. A person aggrieved by an unlawful search and seizure of property or by the deprivation of property may move for the property’s return. The motion must be filed in the district where the property was seized. The court must receive evidence on any factual issue necessary to decide the motion. If it grants the motion, the court must return the property to the movant, but may impose reasonable conditions to protect access to the property and its use in later proceedings.

To argue that Goodwin has no ownership rights, the government says that he only used a service provided by Megaupload and they only leased servers from Carpathia, therefore Goodwin has no ownership rights to the servers they imaged. The contracts of these services, they argue, probably say that he doesn’t own those servers. But the argument here was never that he owned the servers, only that the government took the only copy of his data.

So what about the data? The government argues that owning a copyright “is not sufficient to establish that he has an ownership interest in… the copies of his data.” They say that there should be a hearing to determine whether Goodwin has a prima facie case before proceeding and that his contract with Megaupload limits his ownership rights. I find it hilarious that this very fact is why everyone is angry about the Megaupload case in the first place: the government had no hearing to prove that the entertainment industry had ownership rights of their data and the fact that Megaupload’s contract and federal laws indemnify them of any liability for sharing copyrighted files.

Their argument also has a major flaw: this is not a contract dispute between Goodwin and Megaupload or Carpathia, it is a lawsuit against the US Government. The government is not a party to any of these contracts and therefore they are completely irrelevant.

Then it gets even stranger. Although the government says they do not have Goodwin’s data on the servers they imaged, and that they are not in possession of the other servers, and that finding any particular users’ data may be technically infeasible, they go and claim that his Megaupload account contains files that might be pirated music. So do they have access to his files or not? Further, having pirated files in his account does not negate the fact that he owns his video files. It’s nothing more than a scare tactic and veiled threat that Goodwin should not continue this case because he does not have “clean hands.”

After the whole argument about Goodwin having to provide evidence of ownership, the government goes on to say that in a hearing to decide a Rule 41(g) motion, “the Court may use affidavits and documentary evidence, without the need for live witnesses.” Basically what they want is to be able to use sworn affidavits instead of putting up live witnesses. This means that they get to introduce a statement from their witness with no opportunity for the plaintiff to cross-examine the witness. Their argument is that Goodwin must bear the burden of proof, not the government. Nice trick, but our legal system doesn’t work that way. The only way to reconcile disagreements of prima facie evidence is through a full trial and that includes witnesses.

What the government is trying to do here is abuse the process to prevent the question coming up asking if their raid was legal in the first place. Part of Goodwin’s case relies on proving that his data was unlawfully seized, which might include proving whether Megaupload’s servers themselves were unlawfully seized and searched. This is an extremely important question that needs to be asked because it will set the precedent for all future government seizures. It affects every company on the Internet that hosts the data of others. And it affects any of us that completely rely on the cloud for running our own lives and livelihoods.

The government must be held to the same standards as anyone else and cannot be allowed to abuse the law to take out any company in any country that threatens the US entertainment industry. If we can stop the little abuses, we help prevent the big abuses.

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.

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.

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.

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.