30 replies to this topic

[PeterUK]

Why? It was a good post.

Because I realised afterwards that it wasn't exactly what you were suggesting, but a similar thing I had thought of.

For anyone else who was interested, my idea was to store a large, user-configurable string somewhere (by large, say 128 characters) in the config file, and use this appended to the password as part of the hashing process. In order to make passwords realistically crackable, an attacker would have to obtain data both from the database (the SQL data), and the file system (the key from the config file), which is a much more unlikely scenario than them just getting access via an SQL injection or something.

IPB could have a default value for this string, and power users could configure it (there would have to be some sort of column in the DB to dictate whether it had been applied if you were converting an existing system). It puts power users in a significantly better position in terms of password hashes and doesn't change the position of your regular users who don't bother to change it.

[Wolfie]

Because I realised afterwards that it wasn't exactly what you were suggesting, but a similar thing I had thought of.

Someone else had mentioned the same idea (password in conf_global file) in the other topic. If someone manages to get both, then it's somewhat pointless. However, if someone is only able to somehow obtain the database but not the conf_global file, then it would indeed create a very secure password system. In the other topic, I mentioned the idea of IPS returning a hash or something and for the script to unset the value immediately after using it. The idea being that unless someone alters the files to make a copy of that value, then it wouldn't be stored somewhere that the hacker could download or make it appear on screen, etc.

[PeterUK]

Well I couldn't read that topic as it no longer exists or it's been moved somewhere private.

The other option is rather than use the string to make the password hash itself stronger, is simply to use the string as the key to encrypt the hash with something like blowfish.

[Wolfie]

Well I couldn't read that topic as it no longer exists or it's been moved somewhere private.

Other topic loads just fine for me.

[eGullet]

With technology today, a hacker could delegate out the work load to multiple computers so even a long password (say 14 characters) could be cracked in less than a month.

First off, any password of any length can theoretically be cracked, so you are correct about that. But let's take a look at the actual numbers for a moment. There are 95 printable characters in the ASCII character set. To brute force a 14-character password, even if you KNOW that it is 14 characters, you have to check on average 0.5 * 95^14 passwords: that's 2.4e27 passwords. You can't use a conventional rainbow table because the password is salted. To check each password you have to calculate two MD5 sums. A top-of-the-line modern GPU can calculate something like 200 million hashes per second. So that's 4.8e19 seconds per password per card. That means that is will take that GPU 7.7 billion years PER PASSWORD, if you know how long the password is. The lessons here: a) always salt your passwords (Invision does this) and b) adding a single character to your password makes it 95 times harder to brute force even if the attacker knows how long it is. If they don't then they also have to check all the shorter passwords too. The upshot: if you use a long password and it's salted in the DB, it is NOT going to get brute-forced. Period.

[PeterUK]

A top-of-the-line modern GPU can calculate something like 200 million hashes per second.

Actually a GPU on the low end of the high end (if that makes sense, like a GTX 560) can calculate 1.5-2 billion MD5s per second.

Amazon's setup with multiple GPUs or using a bunch of really high end GPUs like HD5970s yourself, you can top 25 billion hashes per second. This is why it's so problematic, because your average user uses nowhere near a 14 character password.

On this forum, the majority of us are administrators of our communities, we're not bothered about *our* passwords being cracked because chances are, we use decent passwords, we're worried about our users' passwords should the worst happen and the hashes get exposed. You can force your users to use complex passwords if you want but you can also expect to see new registrations fall.

Other topic loads just fine for me.

http://community.inv...orums-attacked/

That one? What forum is it posted in?

[Wolfie]

The upshot: if you use a long password and it's salted in the DB, it is NOT going to get brute-forced. Period.

I find it difficult to believe what someone says when their understanding (or at least your wording) of probabilities is flawed at best.

http://community.inv...orums-attacked/

That one? What forum is it posted in?

Client Lounge

[PeterUK]

Oh, I don't have Client Lounge because this account is a secondary contact. My other account the support has expired so I don't have it there either.

[eGullet]

Amazon's setup with multiple GPUs or using a bunch of really high end GPUs like HD5970s yourself, you can top 25 billion hashes per second. This is why it's so problematic, because your average user uses nowhere near a 14 character password.

OK, my figures are from 2009, so let's use yours: 95^14 possible passwords, two MD5sums per, on average you have to test half of them. 25 billion MD5s per second. 2.4e27 MD5s to calculate, at a rate of 2.5e10 per second gives 1.95e17 seconds. You're still talking billions of years. Again, what this all boils down to is that the single most effective way of preventing brute-forcing of a password is to make it longer.

[PeterUK]

Again, what this all boils down to is that the single most effective way of preventing brute-forcing of a password is to make it longer.

Again, I think you missed the point of my post. We're all well aware of that, but currently, forcing users to do this isn't a popular option and so people will be people and they will continue to use weak passwords. We need a solution for the users who choose to do that to help protect them. And I'm sure you're thinking, "users who use weak passwords get what they deserve", but regardless of that, if your community gets breached, it's already bad enough publicity, but then when a user gets their password cracked, even if it was weak, they still hold you responsible in their eyes.

[Cyrem]

I've been using IPB for a few years, well I had it installed, but it's been idle, just never had the time to 'use' it, but each install has been hacked within a few months. Just tonight I had to do a complete wipe and re-install, this is the 3rd time.

You must be setting your password to "a" or have very poor server security. I suggest changing all your hosting passwords.

Most hacks are not done through the front end.