vBulletin login security

mikeblas

[H]ard|DCer of the Month - May 2006
Joined
Jun 26, 2004
Messages
12,777
I notice that lots of vBulletin installations don't use HTTPS when logging in the user.

I was worried that this meant the user name and password were sent in clear text. I've finally gotten around to do some sniffing to see if that's true, and it appears that it's not. The login button sends a POST to "/login.php?do=login" that includes the user name in plain texr, but doesn't include a plain text password.

It further includes a "securitytoken" and a "vb_login_md5password". Looks like the plain text password is hashed with plain MD5 (but not salted!) and that becomes the md5password.

Is this arrangement secure? Can't an observer intercept the password hash and rainbow it, or otherwise attack it?
 
All simple HTTP transactions are vulnerable to man-in-the-middle attacks. In this case, vBulletin can be configured through a module to require a salted MD5 string from the client, but since the hashing is done locally, the salt parameter is sent in the clear (usually as obfuscated JS). By default, vBulletin doesn't do a very good job of obfuscating the login but in the end, the only way to truly protect the user is to use HTTPS.
 
I notice that lots of vBulletin installations don't use HTTPS when logging in the user.

I was worried that this meant the user name and password were sent in clear text. I've finally gotten around to do some sniffing to see if that's true, and it appears that it's not. The login button sends a POST to "/login.php?do=login" that includes the user name in plain texr, but doesn't include a plain text password.

It further includes a "securitytoken" and a "vb_login_md5password". Looks like the plain text password is hashed with plain MD5 (but not salted!) and that becomes the md5password.

Is this arrangement secure? Can't an observer intercept the password hash and rainbow it, or otherwise attack it?

So they're hashing the passwords client-side? That seems, well....idiotic. Using TLS to send encrypted passwords is not difficult, as illustrated by the majority of the internet doing it.

If the passwords aren't salted, it should be simple to rainbow tables the password.
 
Last edited:
I can confirm that it is indeed possible to determine a password from the 'clear' login POST in this configuration. Ideally, sites using this configuration should consider reconfiguring to a more secure setup.
 
Last edited:
So they're hashing the passwords client-side? That seems, well....idiotic.

For some reason I thought client side salty password double hashing + TLS would be the standard approach.

I'm not sure where I developed that belief since I've never worked on anything remotely related to password security.
 
For some reason I thought client side salty password double hashing + TLS would be the standard approach.

I'm not sure where I developed that belief since I've never worked on anything remotely related to password security.

There are two major issues that I am aware of with hashing passwords client-side instead of server side, even if you're encrypting with TLS before sending the hash over the wire.

First, since properly hashed passwords should not be readily reversible, that would prevent the application from doing any real server-side validation, making it really easy to circumvent complexity requirements.

More importantly though, if your hashing is done client-side, you're not really storing the hash of the password....the hash IS the real password, and the user's 'password' is just a key to getting the client to send the password. If an attacker were to be able to compromise the database of stored hash without administrators detecting the trespass, they would be able to simply fabricate login requests that send the user's hash over, thus defeating some of the purpose of the hashing. Sure, they wouldn't be able to reverse the password any more easily, but they wouldn't need to be able to in order to log in as a given user. If the hashing is server-side, you need to send a password that generates the correct hash, rather than simply the correct hash itself.

This is another problem with the way vBulletin is doing logins aside from the obvious sniffability of the password from the request. If I get access to a database of hashes, even if I can't reverse the hashes, I can still log in as any user on the forum. With normal server-side hashing, you would only be able to log in if you were able to reverse the hash correctly.
 
I can confirm that it is indeed possible to determine a password from the 'clear' login POST in this configuration. Ideally, sites using this configuration should consider reconfiguring to a more secure setup.

Hardforum.com doesn't do it. All the vBulletin sites I could think to test don't do it, either.
 
Hardforum.com doesn't do it. All the vBulletin sites I could think to test don't do it, either.

Are you sure?

Also, by clear I meant using HTTP, not that the passwords are in plain text.
 
More importantly though, if your hashing is done client-side, you're not really storing the hash of the password....the hash IS the real password, and the user's 'password' is just a key to getting the client to send the password. If an attacker were to be able to compromise the database of stored hash without administrators detecting the trespass, they would be able to simply fabricate login requests that send the user's hash over, thus defeating some of the purpose of the hashing. Sure, they wouldn't be able to reverse the password any more easily, but they wouldn't need to be able to in order to log in as a given user. If the hashing is server-side, you need to send a password that generates the correct hash, rather than simply the correct hash itself.

I guess my thinking was:
Server stores A = hash(password+per-password salt)
Server authenticates based on hash(one-off salt + A), and this hashing is done on the client side.

When someone wants to sign-in, the server will send them both the per-passworld salt and a generated one-off salt, and request the double hashed contents. What gets sent over the wire is not useful beyond the current session - whereas hashing on the server side means that a non-expiring password is susceptible to being eavesdropped.
 
I guess my thinking was:
Server stores A = hash(password+per-password salt)
Server authenticates based on hash(one-off salt + A), and this hashing is done on the client side.

When someone wants to sign-in, the server will send them both the per-passworld salt and a generated one-off salt, and request the double hashed contents. What gets sent over the wire is not useful beyond the current session - whereas hashing on the server side means that a non-expiring password is susceptible to being eavesdropped.

This Challenge-response auth mechanism prevents a replay attack from a passive eavesdropper, but since it is done in HTTP session hijacking is still trivial. It requires a more complicated attack but nothing you couldn't easily pull off on a coffee shop wifi.
 
This Challenge-response auth mechanism prevents a replay attack from a passive eavesdropper, but since it is done in HTTP session hijacking is still trivial. It requires a more complicated attack but nothing you couldn't easily pull off on a coffee shop wifi.

Additionally, most people are moving to forward secrecy, so the situation this client-side hashing is trying to circumvent isn't really the most likely problem. TLS is moving towards things like ECDH, where the shared secret is not sent across the wire. The situation where HTTPS gets broken is far less likely than introducing attack opportunities through using a goofy client-side hashing approach.
 
Are you sure?

Also, by clear I meant using HTTP, not that the passwords are in plain text.

Well, maybe we're not talking about the same thing. Hardforum.com doesn't use HTTPS. The password is hashed on the client and sent along with the logon POST request. There's a "security token" that's floating around, and I haven't investigated that. (I logged off and logged back on, but I didn't reset cookies. Maybe in the cold case, the security token isn't there, and something different happens. But even in the test I did, I can confirm that the password hash is MD5 without any salting... so I don't think the security token has an effect on the exchange.)
 
Well, maybe we're not talking about the same thing. Hardforum.com doesn't use HTTPS. The password is hashed on the client and sent along with the logon POST request. There's a "security token" that's floating around, and I haven't investigated that. (I logged off and logged back on, but I didn't reset cookies. Maybe in the cold case, the security token isn't there, and something different happens. But even in the test I did, I can confirm that the password hash is MD5 without any salting... so I don't think the security token has an effect on the exchange.)

Right, and I can confirm that it's possible to observe that request going across the wire, grab the hash header and reverse it to find the password with a rainbow table.
 
Yeah, HTTPS would really help here. Sending an MD5 hash across standard HTTP is not secure. For those curious about how the hardforum login works, open up Chrome's Developer Tools (F12), go to Network, and try to log in. Here's what happens when I try to log in with the user/pass "usernamehere/password"-
L2HdHgu.png

Looking at the headers for the login.php?do=login post, we see the unsalted hash under vb_login_md5password.
Aaaaaaand the lookup against a hash table:
FNbIewY.png
 
Back
Top