1. That Brostoff / Sasse article about penalty lockouts … is it for real!?! I was almost able to fisk it — scarcely a paragraph without something wrong.

2. Phrases like “multi-million dollar businesses” are one of my bugbears. It is quite a long time since a multi-million dollar business meant a large business. If you mean it cost several million to buy or set up, then you are talking something like a corner store with 4 or 5 employees. If you mean several million per annum revenue, then that’s a slightly bigger business, but still probably no more than a couple of dozen employees.

I have worked at a start-up like that. A “multi-million dollar business” (revenue, that is, not profit!) and the techie side of the house included 4 coders, ~4 DBAs, and half a dozen sysadmin / helpdesk / gophers. I was one of the latter. None of the coders was what I would call a “software engineer”, but they certainly weren’t terrible.

However, they knew sweet FA about security engineering. As an example, I was the only person there who understood the difference between ECB and CBC cipher modes. And got a reputation as a gun coder when I sped up a certain module more than an order of magnitude by realising that they were re-doing the Blowfish key schedule for every block.

Fact is, few sites less than a multi-BILLION dollar business have *any* security engineers. Unless they get a complete login / authentication module from a competent project, they will try to roll their own and unwittingly repeat all the mistakes of the past. Many systems like Rails and PHP make it very easy to role your own, whereas complete, bulletproof (??) systems are usually only available in expensive “Enterprise Platforms”, and even then they have issues.

Consider JGuard, for example. It is a complex authentication and authorisation management package. But what does it say about hashing and salting? Buried deep in the docs there is one paragraph about hashing, how to query your system about what is already available, and add it it. No hint about why it is so important. Salting gets one paragraph also, which recommends you read about it in Wikipedia. You have to enable salting in a config file, and you get just ONE fixed system-wide salt.

I’m not picking on JGuard here; it’s a nice project, and the rest are no better. If you are not expert enough to roll your own, this is as good as it gets. (Spring / Acegi, for example, is slightly worse in this respect. But even more complicated and Enterprisey!)

Another problem is sites that have a backup mechanism. If you forget your really strong password you can have it reset by entering the name of your pet dog. The reset question becomes a far weaker secret than the password they protect. You are also encouraged to enter clues to it. I should really have a second strong password for these. “My dog is called ’sd876Dfs!$d’, honest!”. I think more sites now will require you to have access to your registered email account to use this feature which gives some protection for it.

Something that dig ring alarm bells in the article: “Only 1 site of 150 successfully hashed passwords in the browser using JavaScript, giving us confidence that passwords aren’t stored in a recoverable format (two other sites tried but botched the details).”

Did this site check the hash sent by the javascript with the value on the database? Do they use a nonce or something to ensure that it is not vulnerable to replay attack? Otherwise the hashed value generated by the javascript becomes the new password and if there is no nonce and no further processing then there is no effective salting on the database. The hashing just becomes a way of turning “PA55W0RD” into something that looks a bit stronger.

Did you find the answer ? is the explanation in the in-depth report ?

First: the password requirements for ordinary users are deliberately very lax, because ordinary users have no special privileges. In most web software, even unprivileged users can take destructive or privileged actions, such as deleting their own posts or messages, or viewing secret information like private messages sent to them, their friend’s wall, etc.

In MediaWiki, basically the only interesting thing you’d be able to see or do if you hacked an ordinary account is get the user’s e-mail address. Users cannot send or receive private messages of any type, and pages cannot generally be configured to be editable only by some users and not others. Nothing can be permanently deleted or irreversibly changed in any way. The worst an attacker could do to you is get you temporarily blocked for vandalism, until you contact the system administrators to demonstrate your identity, so that your password can be reset.

Given all this, it wouldn’t be reasonable to impose strong password requirements on users. The usual measures for improving password security impose extra burdens on users, and the modus operandi of Wikipedia is to keep barriers to entry as low as possible, so anyone can contribute.

Note that at least at some point, privileged users (sysops) did have restrictions placed on their passwords, including length, checking against dictionaries, etc. I don’t know if those are still in effect for any or all wikis. However, even privileged users can’t take irreversible actions in MediaWiki, and almost no privileged users can even view much private information, so again, it’s not as big a security problem as it would be on other types of sites.

I looked over the rest of your data for Wikipedia, and noticed that you have “email required” true. Wikipedia does not require an e-mail address to be provided for signup. If you don’t provide one, or it doesn’t get verified, all e-mail-based features will be disabled, but you can otherwise use the site normally.

You also said that Wikipedia provides no TLS support. I don’t know if you meant none required or none available at all, but you can sign in and browse the site via secure.wikimedia.org if you know about it. This sends images insecurely, but cookies and passwords are still encrypted. (Forcing all login to be over TLS would be nice, but it’s not a high priority for the ops team.)

You have the maximum password length listed as “?”. The maximum password length is dictated by the maximum POST size, so on the order of megabytes. I’ve actually tested a multi-megabyte password on MediaWiki, and it worked fine, since of course the passwords are only stored as salted hashes. I guess “?” is standing in here for “really high”.

Overall, though, the study was interesting. In addition to correcting a few minor inaccuracies, I just wanted to point out that Wikipedia deliberately favors usability over security when it comes to account takeovers, because a compromised account usually hurts no one but the legitimate account-holder, and that not even much (since little information is disclosed and all illicit actions are easily reversible). It would be good if we required HTTPS for login and allowed OpenID, though.

When I have just created an account on a website, I do not need the website to remind me what password I just provided. I may have forgotten by tomorrow exactly what algorithm I used to create that password (did I tell Amazon “ama#$sgpzon!” or “zon!sgp#$ama”?) , but at the time of creation, that it when a reminder is of the least value.

I run a tiny website, which authenticates blog posts and a wishlist, but it matches all of these criteria other than TLS.

Because generating a hash, storing the hash, and sending off an email with the plaintext password in it (which is never stored beyond the POST in the registration form) is also a common thing for registration, so the new user has a copy.

Very nice work, indeed!

I have published two posts recently which might be interesting for you (although it is more about password structure again):

* http://www.scip.ch/?labs.20091120
* http://www.scip.ch/?labs.20100709

Regards,

Marc

This is a non-sequitur, at least if you are referring to the sort of email that gives you a new password when you’ve forgotten yours. It’s perfectly possible to generate the new password, store its hash, and email the cleartext version. Whether this actually happens is of course another question.