Adobe had a security breach affecting 2.9 million customers. They state that “the attackers accessed Adobe customer IDs and encrypted passwords“ (emphasis added).

It’s bad practice to store encrypted passwords. We don’t know where Adobe kept the encryption key—they don’t say—but if the attacker was able to get the key they would have all the passwords in plain text. Furthermore, we don’t know how long the system was compromised. Perhaps the attacker could see the unencrypted passwords before they were encrypted by the system. If not, what I would do in the attacker’s place would be to open up a bunch of fake accounts where I could choose the password myself, mounting a chosen-plaintext attack on the key.

Not only is it dangerous to keep encrypted passwords around, it’s unnecessary. Standard practice is to keep only the hashes of passwords. This is still vulnerable to a dictionary attack, but cracking a single password hash doesn’t reveal all the passwords, unlike in the encrypted case.

Augmented password-authenticated key agreement schemes like SRP are an even better solution: in these schemes the password is not sent to the server at all. Even if the server has been completely compromised at the time you enter your password, they don’t get the password.

Adobe is a big company, big enough to have a chief security officer. If you can’t trust them to handle passwords safely, you can’t trust anyone. We need to insist on SRP or a similar scheme.

SRP can be implemented completely in Javascript in a login page. The problem with this is that you are still relying on every company/web site to get it right. The effective way to do this is make it the responsibility of the web browser, by adding it to the HTTP or HTML/Javascript standards. Right now it’s available in SSL/TLS but the reality is that web sites want to control the styling of the login page themselves; putting SRP into SSL doesn’t give this control.