4

A site I frequent has a policy to make you change your password every 90 days. That's a cool policy, but I stumbled upon an old xkcd and facepalmed myself, because lots of doxing happens on this site. It just never crossed my mind that something like this could happen to a more reputable site (silly I know). The site runs on vBulletin.

How can I find if the site I'm using is storing my password securely?

Adi
  • 43,953
  • 16
  • 137
  • 168
grass-hopper
  • 49
  • 1
  • 2
  • 1
    Why does their requirement for a change every 90 days make you worry about how they store passwords? The two are unconnected. – Rory Alsop Nov 02 '13 at 08:01
  • I justified my concerns in the description. – grass-hopper Nov 02 '13 at 08:11
  • 1
    SOmeone else has also voted to close as unclear. Your 3 sentences aren't connected to your headline question. It appears from your comment to Adnan that the headline question is the one you want to ask - if that is so, the content of the question just muddies the water. – Rory Alsop Nov 02 '13 at 10:11
  • *vBulletin* stores passwords double-md5-hashed with salt. – tylerl Nov 02 '13 at 18:50

4 Answers4

16

There's no legitimate way for you to directly know if a website stores passwords in plaintext, stores them in a reversable (possibly encrypted) format, stores as mediocre hashes, or securely hashes them. One possibility is to try to recover your password using their "forgot my password" functionality. If they send you your password, then they're definitely storing it as plaintext or as a reversible (possibly encrypted) format. The problem with this method is that it doesn't work the other way around; if they do not send you your password, it does not mean they're not storing it as plaintext or in a reversible format.

Bottom line is: Unless you gain legitimate or illegitimate (hacking) access to their servers to see for yourself, there's really no way to tell.

Adi
  • 43,953
  • 16
  • 137
  • 168
6

Since secure password hashing is a second line of defence, its effectiveness cannot be tested until the first line of defence is breached, i.e. the server is hacked into, or they do something stupid like sending your password by email.

As others have explained, if the site can send you back your own password, then, by definition, they stored it, and not just a one-way verification token (usually designated by "password hash"). This is a definite clue about very insecure storage. However, if they do not send your password back, it still does not mean that they store it securely. They could still store it reversibly (e.g. encrypted instead of hashed), or they could even hash it with a weak password hashing function (e.g. without salt, or with a hash function which is way too fast, or both -- see this answer for details).

Other clues of bad password storage include:

  • After-the-fact detection of "bad passwords": if they send you an email stating that your password should be changed because it does not comply to some internal rules, then they have access to the password asynchronously (i.e. not just when you enter it for authentication), and that's bad.

  • Rejection of similar passwords: if you change your password with a new password which is very similar (but not identical) to a previous password that you used, and the site rejects it on that basis, then the site can know which passwords are similar to each other, which again implies reversible storage.

  • Very fast response time. This one is hard to measure and you cannot certainly do it by hand; it has to be scripted. When you send an authentication request, you can measure the time it took for the server to answer. During that delay, with normal password hashing, the server must have computed the hash function. For better accuracy send many authentication requests; if the server can handle 100 requests per second then you know that whatever hashing they used requires no more than 1/100th of their CPU power. Warning: if you do that, you may be detected as an attacker trying to do a dictionary attack (conversely, if you are not detected, then this means that the site is not protected against online dictionary attacks, and that's bad, too).

Personally, I'd say that enforcing a password change every 90 days is already a sign of bad password management in general. In any case, you shall not reuse passwords. When you do not reuse passwords, the lack of security in password storage on one site is much less critical.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Bad passwords can come from bruteforcing their own list of passwords. [Facebook uses a scheme where they hash common variations of your password](http://security.stackexchange.com/a/53483/3874) so they can tell you *"Your new password is too similar to your current password. Please try another password."*. All without storing passwords in reversible encryption. – Ian Boyd Aug 25 '15 at 21:07
3

vBulletin hashes their passwords (although not really all that great):

md5(md5(password) + salt)

Which is not the greatest/securest of password hashing algorithms, but at least they use a salt. These days the above hashing algorithm is not considered secure, (md5 is really fast). Have a look at one of our blogposts for more info.

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • Yes, it hashes by default, but the webmaster can change this to happen in plaintext, if I read it correctly. I read the blogpost (talk about a timesink). Enjoyed it very much, but it didn't reassure me at all. It Even if they are stored in hash form, theoretically a dictionary attack could break it. As far as I know dictionaries are pretty thorough nowadays so the biggest chunk of passwords are at the whim of the webmaster. – grass-hopper Nov 02 '13 at 09:16
  • Most passwords can be cracked when using a dictionary attack, that's why you need enforce password complexity. – Lucas Kauffman Nov 02 '13 at 09:32
  • Would 60 thousand rounds of `sha512($prevoutput + $password + $salt)` be secure? – hifkanotiks Nov 02 '13 at 11:59
  • just use pbkdf2, bcrypt or scrypt. – Lucas Kauffman Nov 02 '13 at 12:44
  • @bearbin PBDKF2 is such a thing; you specify the number of rounds desired (e.g. 10,000). But as Lucas said, it is better to use bcrypt, or best to use scrypt. Internally, scrypt really is PBKDF2, except it has an expensive way of generating the salt `salt = BlockMix(password, salt, ...)` – Ian Boyd Aug 25 '15 at 21:12
1

Very simple way: Request that you forgot your password and see if they send you the original password. If they do then they are not using hashes.

Green Fly
  • 1,957
  • 1
  • 16
  • 21