Translation: the passwords were stored using dumb MD5/SHA1. Seriously, it's 2013, why can't 99% of the web get their act together when it comes to password hashing?

Not sure what vB is using today.

http://security.stackexchange.com/questions/19906/is-md5-con...

With apologies for asking, is there an ELIM (Explain Like It's Midnight) version?

(I did read the security.stackexchange.com question linked in the GP - is the answer in there and I missed it?)

Thanks!

Also, the salts are stored unencrypted in the database, right next to the hashes.

Here, the salt only needs to be sufficiently long to make the rainbow table huge enough that it can't be computed in a timely or efficient fashion. So, a salt that's only a single printable ASCII character in length is rather short and probably insufficient; an attacker could build a rainbow table of the top X most common passwords (taken from previous leaked password lists) with every possible character as a salt and then use this against a leaked DB.

On the other hand, a massive salt doesn't help much in this phase either. A salt of fifteen characters is more than sufficient to prevent a rainbow table from including all possible salts, so there's not much of a point in using something ridiculous like a 100-char salt.

But once the DB is leaked, assuming a rainbow table is not feasible, an attacker instead will swap over to brute-force attacks (usually trying dictionary lookups first to find the very weakest passwords, then doing other techniques like trying common words with letters replaced with 1337 digits, and so on). Here, the attacker knows the salt (by virtue of the DB being leaked) and so the most important factor is how fast the attacker can try potential passwords. This is where MD5 breaks, of course; it's far too fast. An attacker with virtually no funding can test billions of passwords per seconds (on a GPU), and so a large Bitcoin GPU farm could be repurposed to crack salted MD5'd passwords at an extremely scary rate.

In fact, the block size of MD5 is 512 bits (64 bytes), so all strings with less than 64 bytes should take about the same time to hash. Thus, even a 40-byte salt with MD5 won't affect password cracking rates until the passwords hit 20 characters long, and a password that long is rarely cracked anyway. Even a 64-byte salt would only make the hashing take about twice as long, and when you're testing billions of passwords per second anyways, twice as long doesn't sound like much. (Actually, if you prepend the salt to the password, I can think of an attack where only the partial blocks at the end of the salt affect the brute-force attempt, which would make the salt's length not affect the cracking rate at all.)

So in sum, before the DB is leaked, the salt needs to have enough entropy to prevent pre-computing all possible salt values. Once the DB is leaked, the attacker doesn't much care about the salt length anymore because they know now all the salts used.

  <http auto-config='true'>
    <intercept-url pattern="/**" access="ROLE_USER" />
  </http>

  <beans:bean class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" id="passwordEncoder" />

  <authentication-manager>
    <authentication-provider>
        <jdbc-user-service data-source-ref="dataSource" />
        <password-encoder ref="passwordEncoder" />
    </authentication-provider>
  </authentication-manager>

Since Discourse is fully open source under GPL v2 anyone can validate its security (or lack thereof) at will on GitHub. And it is not written in PHP.

There are better ways of doing things (despite PHP's inherent warts) that some other projects have used quite successfully, and more importantly sustainably, but there's a very long history of doing things "because that's just the way it's always been done" and I don't see that changing anytime soon, I'm afraid.

I mean if you look at some of the tutorials out there, a lot of it is just appalling in terms of maintainability, efficiency and security (and that includes some very popular frameworks). There are a lot of cases where short-term, and often short-sighted, convenience trumps long-term goals.

Forget a full on forum, if someone took the time to use best practices to build a MVC/P app as a reference, there would be plenty adopters. I don't mean something that "hides" work, I.E. A framework like Code Igniter. These just introduce more magic into code that doesn't actually teach the why and how.

For instance, vBulletin knows about (and doesn't plan to fix) a vulnerability that allows any moderator to privilege escalate to take over a server (and steal passwords) under default settings. They don't consider it a big deal because moderators should be considered trusted users.

Unfortunately, it's significantly harder to ensure that every moderator won't get their password stolen than it is to ensure that every admin won't get their password stolen. Recently, @rootinabox exploited that (and possibly other vulnerabilities) to hack a bunch of Pokemon sites that were running vBulletin.

I think the main problem comes from the fact that much of the code still resembles the spaghetti that was written over 10 years ago. Even recent versions have problems with basic input sanitization, which makes injection attacks really easy. Social engineering is also a massive problem: if you can phish an admin login, you can essentially take over the entire web server because the admin panel is just too powerful.

If it is an attack, it just means a time bandit for the admins I suppose...

HTML source: http://pastebin.com/raw.php?i=7JXk5s1F

Then I remembered how much work this kind of prank generates for the system administrators.

The top was a splash image that linked to this twitter account: https://twitter.com/Sputn1k_

Below was some text (scraped from Chrome's history database):

    Shoutout to @rootinabox.

    None of this "y3w g0t haxd by albani4 c3bir 4rmy" stuff.
    Straight up, you dun goofed. It's as simple as that.

[1] https://twitter.com/Sputn1k_/status/354362220727111681

---

@Sputn1k_ @CubeWorldForum It's a fairly easy "hack". You set your forum avatar to a remote site that actually serves up a meta redirect.

---

That's... interesting. Like a php-generated image containing a redirect header, or a referrer check set up in .htaccess? I didn't know images were hackable like that, beyond just sending an alternative image for nonexistent referrers?

If anyone needed a good argument against blindly hotlinking to other sites' content I guess this would be it.