Info about the recent attack

[TiagoTiago]

Btw, do you guys got an ETA when SMF is gonna have the fix for the zeroday officially released so you can talk about it openlly?

[1714041541]

1714041541

[1714041541]

1714041541

[1714041541]

1714041541

[1714041541]

1714041541

[1714041541]

1714041541

[BCEmporium]

PHP has this...now. The old insecure way is "deprecated" which means because so many billions of lines of deployed code depend on it, it'll be forever before it gets removed.

That "this" was what made PHP insecure. After that "java-like piece of crap" came along magic_quotes_gpc defaults to off and "deprecated", as many don't seek this settings in php.ini their sites become vulnerable to SQLi.
PDO is the typical piece of "paranoia-security", deem all unsafe because a paranoiac found something else more "safe"...

[c_k]

Thinking about it with all the information available now. Imagine yourselves in Theymos and Sirius position. I understand that they used 3rd party plugin for simple machine forum to collect donations as such importing SQL injection vulnerability. Than eventually Cosby came to wreck the forum. Once they know it, they shut down the forum. So far so "good".

Now they have no skill to sort it themselves. They do have to bring someone in. Who can they bring? This is already all over the news. Sirius resigns and asks for help from "devs". Mark surely is right here with an offer of help, but there are some voicing privacy and de-decentralisation worries.

What could they do. They surely can not bring someone like me in, since I am being so adversarial here. Who else? not many offers were sent on that mailing list. They have chosen Mark. Even though it is probably a mistake, their choice is perfectly understandable.

They should have brought in some independent security professional instead of mtgox or me or anyone else with clear conflict of interests. They should have been more open and issue at least some kind of statement ASAP. Things could have been handled better. But hey nobody is perfect.

What you evidently fail to realise is that nothing is set in stone, why don't you have a calm and constructive discussion with the owners of the site and organise something like you're suggesting?

Focus on the future, make a change and become the positive next step in the sites future history.

I'd rather read about how you were the savior instead of the armchair critic who instead simply points out everything that went wrong and tries to get everyone to go to his forum instead.

[Xenland]

WHAT PROGRAMMER IN THEIR RIGHT MIND SALTS WITH THAT KIND OF DATA!?!?!

A good programmer would salt the data that is in a file, but then again, I guess I'm looking like an ass whole becuase the attacker could have just ran exe('vi /www/salt_location/saltfail.txt'); or something of the like.... lol Different forum software I guess right? wtf why do people use these forums even after an attack? sounds retarded.

anyways you guys have fun... this forum is funner then watching Jersey Shore....

[BCEmporium]

You mean exec and it's cat not vi. Vi would open the file to edit, cat shows its content.

What's retarded about using a forum?! Supposedly there's no financial data here, nothing but baloney and chit-chat. So nothing to worry about, let the "hacker" be happy.

[Xenland]

You mean exec and it's cat not vi. Vi would open the file to edit, cat shows its content.

What's retarded about using a forum?! Supposedly there's no financial data here, nothing but baloney and chit-chat. So nothing to worry about, let the "hacker" be happy.

Yep you are correct, however , i'm not going the mile to checking the validity of my post for every single word. This forum isn't really that worth the integrity.

[defxor]

WHAT PROGRAMMER IN THEIR RIGHT MIND SALTS WITH THAT KIND OF DATA!?!?!

Anyone who understands what salt is and why it is used? Using the nickname as salt instead of a random value doesn't change the fact that it makes rainbow table lookups useless. Salt is never a secret and doesn't protect against brute forcing anyway.

http://en.wikipedia.org/wiki/Salt_(cryptography)

[Xenland]

WHAT PROGRAMMER IN THEIR RIGHT MIND SALTS WITH THAT KIND OF DATA!?!?!

Anyone who understands what salt is and why it is used? Using the nickname as salt instead of a random value doesn't change the fact that it makes rainbow table lookups useless. Salt is never a secret and doesn't protect against brute forcing anyway.

http://en.wikipedia.org/wiki/Salt_(cryptography)

My theory was that if someone were to set a static salt in a file and the attacker only downloaded the database it would render useless(this only works if the salt length is of a long length such as 64characters long mininum).

Thats just my thoery, any great ideas on protecting your self bruteforcing for this particular situatiom?

[defxor]

My theory was that if someone were to set a static salt in a file and the attacker only downloaded the database it would render useless(this only works if the salt length is of a long length such as 64characters long mininum).

Thats just my thoery, any great ideas on protecting your self bruteforcing for this particular situatiom?

You cannot protect a password hash from brute forcing and still allowing an authentication system to work. Some seem to mistake salt for a secret nonce (which it isn't) which would just make the database of secret nonces into another password database. There's no reason to suspect two databases to be more secure than one.

Salt's only purpose is to make rainbow table lookups ineffective/useless. The salt used on this forum succeeded in doing that. I'm worried about the lack of basic crypto terminology and usage in some posts here.

[Xenland]

My theory was that if someone were to set a static salt in a file and the attacker only downloaded the database it would render useless(this only works if the salt length is of a long length such as 64characters long mininum).

Thats just my thoery, any great ideas on protecting your self bruteforcing for this particular situatiom?

You cannot protect a password hash from brute forcing and still allowing an authentication system to work. Some seem to mistake salt for a secret nonce (which it isn't) which would just make the database of secret nonces into another password database. There's no reason to suspect two databases to be more secure than one.

Salt's only purpose is to make rainbow table lookups ineffective/useless. The salt used on this forum succeeded in doing that. I'm worried about the lack of basic crypto terminology and usage in some posts here.

I think you assume too much. I'm dont find the need to prove my self of how valid my programming skills are based on how well i use accurate teminology especially over the internetz! Lol!

[neptop]

@Xenland: He just thinks that you probably have no idea about salts, which appears to be true. This isn't about terminology.

@defxor: You shouldn't wonder about the lack of knowledge. There are a lot of people who join the forum Bitcoin, because it sounds like easy money. What really worries me is that some people could actually share information in PMs that they shouldn't. This also isn't good for the operators of the forum. I am not sure whether this is true for the US, but in many parts of Europe the operators could receive a lot of legal threats making it very vulnerable to a take down.

[gat3way]

My theory was that if someone were to set a static salt in a file and the attacker only downloaded the database it would render useless(this only works if the salt length is of a long length such as 64characters long mininum).

Thats just my thoery, any great ideas on protecting your self bruteforcing for this particular situatiom?

Not that good idea. This all lies on the assumption that the attacker would not be able to access the filesystem which is not necessarily the case. Depending on configuration, the user might be able to read arbitrary files using e.g mysql's LOAD_FILE(). The forum software might have other attack vectors like LFI that would allow reading the file. The salt file should be outside the document root but that would break some (already inefficient) security mechanisms like open_basedir. Short enough salts would fall victim to simple attacks (like registering an user with a single-character password then bruteforcing to obtain the salt). But what's worst - you'd have a single salt for all the passwords that way. This is enough to thwart rainbow table attacks if salt is long enough (even 10 bytes of salt is enough to render readily available tables useless). But there is also another huge advantage of using salts which you are losing by using a single common salt. You turn the complexity of a hash crack attack from (nearly) O(1) to O(N) where N is the number of passwords. That's because if all passwords have the same salt, you do:

1) hash = H(salt,password)
2) compare hash to all the hashes in the list.

overall that's one compute-intensive operation per candidate


if you have many salts, you need to do the following:

for each hash K in the list do:
  1) hash = H(salt, password)
  2) compare hash to K

overall that's N compute-intensive operations per candidate where N=number of users.


So yes, it might be a good idea if you can guarantee that the attacker would never get the salt. Once it gets it though, you lose a great deal of the time that password hashing buys you prior to your hacker obtains your password. For a forum of 1000 users, cracking the passwords using a single common salt would be up to 1000 times faster than cracking 1000 passwords with different salts.

[Xenland]

My theory was that if someone were to set a static salt in a file and the attacker only downloaded the database it would render useless(this only works if the salt length is of a long length such as 64characters long mininum).

Thats just my thoery, any great ideas on protecting your self bruteforcing for this particular situatiom?

Not that good idea. This all lies on the assumption that the attacker would not be able to access the filesystem which is not necessarily the case. Depending on configuration, the user might be able to read arbitrary files using e.g mysql's LOAD_FILE(). The forum software might have other attack vectors like LFI that would allow reading the file. The salt file should be outside the document root but that would break some (already inefficient) security mechanisms like open_basedir. Short enough salts would fall victim to simple attacks (like registering an user with a single-character password then bruteforcing to obtain the salt). But what's worst - you'd have a single salt for all the passwords that way. This is enough to thwart rainbow table attacks if salt is long enough (even 10 bytes of salt is enough to render readily available tables useless). But there is also another huge advantage of using salts which you are losing by using a single common salt. You turn the complexity of a hash crack attack from (nearly) O(1) to O(N) where N is the number of passwords. That's because if all passwords have the same salt, you do:

1) hash = H(salt,password)
2) compare hash to all the hashes in the list.

overall that's one compute-intensive operation per candidate


if you have many salts, you need to do the following:

for each hash K in the list do:
  1) hash = H(salt, password)
  2) compare hash to K

overall that's N compute-intensive operations per candidate where N=number of users.


So yes, it might be a good idea if you can guarantee that the attacker would never get the salt. Once it gets it though, you lose a great deal of the time that password hashing buys you prior to your hacker obtains your password. For a forum of 1000 users, cracking the passwords using a single common salt would be up to 1000 times faster than cracking 1000 passwords with different salts.

Finally someone with an intelligent answer to salts.
This makes perfect sense.

I do however don't think that using the username as a salt helps scince the attacker would already know that the forum is salted with usernames..so wouldn't they just point their brutforcing problem to query for the username first before the bruteforce attempt?

[theymos]

I do however don't think that using the username as a salt helps scince the attacker would already know that the forum is salted with usernames..so wouldn't they just point their brutforcing problem to query for the username first before the bruteforce attempt?

Salt offers no protection at all from bruteforcing. It is only used to prevent attackers from using rainbow tables.

[Inaba]

I do however don't think that using the username as a salt helps scince the attacker would already know that the forum is salted with usernames..so wouldn't they just point their brutforcing problem to query for the username first before the bruteforce attempt?

Salt offers no protection at all from bruteforcing. It is only used to prevent attackers from using rainbow tables.

If you think that, you really don't understand the purpose of salts.  Gat3way detailed it fairly well, which explains why salts (when properly implemented) offer some protection against bruteforcing and, as you correctly stated, rainbow tables.  However, a properly implemented salt system increases the compute requirement for bruceforcing dramatically, slowing own the bruteforce by a factor inversely proportional to the complexity of the salt. (I think that's how the formula works out, but in any case, it does indeed offer protection against brute force attacks.)

Properly implemented random salts will make the compute requirement on a given dataset a minimum of 3x harder/slower, and that amount can be increased by an order of magnitude depending on how it's handled.

In the end, it's all about how many operations are required to test a hash.  The more operations required, the longer it takes.  When it takes one operation to test a hash, as in the case of say for BTC mining, even adding an additional operation doubles the time it would take to solve. 

[runeks]

The principle of this browser extension is that at any site where you are asked to enter a password, the extension will enter a password that is sha256(<your password of choice> + domain) (or any other cryptographic hash function). For example, if my chosen password is "masterpassword", the password that would be used to log into gmail.com would be sha256("masterpasswordgmail.com") (=9b2b649d3124c81093f9080a88b9d3723940dfe0707d8524d0403c9641bc99c3).

According to your description you only get entropy matching your password. Unless your password is a complex 12 char password that means an attacker can still bruteforce it. While they do need to know that your passwords are generated this way, they have knowledge of the domain of the site and the above indeed looks like an obvious hash.

Security by obscurity isn't.

Passwords don't need to be complex and 12 chars to be high entropy but you make a valid point. This method is not meant to attain a higher entropy password than what was put in, it's purpose is to not reveal your master password.
These types of plugins are meant to be used with an already hard-to-crack password. For example one created with the following command (in Linux):

Code:

shuf -n 6 --random-source=/dev/random /usr/share/dict/words

which gives us about 10³⁰ combinations or about 100 bits of entropy.

[theymos]

However, a properly implemented salt system increases the compute requirement for bruceforcing dramatically, slowing own the bruteforce by a factor inversely proportional to the complexity of the salt. (I think that's how the formula works out, but in any case, it does indeed offer protection against brute force attacks.)

No, it doesn't. The attacker always has the salt, so he doesn't need to bruteforce that, and hashing differently-sized data has no difference in speed when both sizes take up the same number of hash blocks. All password+salt strings under 512 bits take the same amount of time to compute with SHA-1.

Gat3way described how you can create rainbow tables for password sets when you don't use unique salts for each password.

[neptop]

I do however don't think that using the username as a salt helps scince the attacker would already know that the forum is salted with usernames..so wouldn't they just point their brutforcing problem to query for the username first before the bruteforce attempt?

Salt offers no protection at all from bruteforcing. It is only used to prevent attackers from using rainbow tables.

If you think that, you really don't understand the purpose of salts.  Gat3way detailed it fairly well, which explains why salts (when properly implemented) offer some protection against bruteforcing and, as you correctly stated, rainbow tables.  However, a properly implemented salt system increases the compute requirement for bruceforcing dramatically, slowing own the bruteforce by a factor inversely proportional to the complexity of the salt. (I think that's how the formula works out, but in any case, it does indeed offer protection against brute force attacks.)

Properly implemented random salts will make the compute requirement on a given dataset a minimum of 3x harder/slower, and that amount can be increased by an order of magnitude depending on how it's handled.

In the end, it's all about how many operations are required to test a hash.  The more operations required, the longer it takes.  When it takes one operation to test a hash, as in the case of say for BTC mining, even adding an additional operation doubles the time it would take to solve. 

I think you are saying it in the wrong way. "Protection against brute force" is simply a stupid thing to  say. Ever heard of key strengthening/stretching? I guess this would be a better method. Increasing the effort for a brute force shouldn't be described as "protecting from a brute force" (which would mean that you have something that prevents a brute force). You could also switch to an algorithm like CubeHash (it dropped out of the SHA-3 competition for being to slow, but it's relatively simple) if you want to do this. Salts are against rainbow tables.

[TiagoTiago]

Would it help if the salt instead of the plain username was a tripple SHA512 of the username?

[Inaba]

No, it doesn't. The attacker always has the salt, so he doesn't need to bruteforce that, and hashing differently-sized data has no difference in speed when both sizes take up the same number of hash blocks. All password+salt strings under 512 bits take the same amount of time to compute with SHA-1.

Yes, it does.  You can only hash one user at a time if you operate under the constraints you've outlined.  If you want to hash multiple users, you will have to compute the password + salt for each user over each iteration, increasing your compute time.  If you want to brute force just one user, then I would agree with you, but we aren't talking about brute forcing a user, we're talking about compromising a database.  You have no knowledge as to whether a given user has a strong or weak password, so forcing one user is folly.  Forcing a large database, and you are almost guaranteed to have at least one user with a weak password.  Using random salts will cause the brute force to take a minimum of 2x - 3x longer than using static (or no salts), thereby offering you protection against brute force in the time it takes to yield a result (double or treble).

Gat3way described how you can create rainbow tables for password sets when you don't use unique salts for each password.

What kind of dumbass would use static salts to salt a password database in this day and age?  Yes, you can outline all sorts of broken implementations of salting and point to them and say see they don't offer any protection!  But that is also a folly.  A broken implementation is a broken implementation and it's no surprise that something that's broken doesn't offer the kind of protection it should.

I think you are saying it in the wrong way. "Protection against brute force" is simply a stupid thing to  say. Ever heard of key strengthening/stretching? I guess this would be a better method. Increasing the effort for a brute force shouldn't be described as "protecting from a brute force" (which would mean that you have something that prevents a brute force). You could also switch to an algorithm like CubeHash (it dropped out of the SHA-3 competition for being to slow, but it's relatively simple) if you want to do this. Salts are against rainbow tables.

Yes, that would be a better method.  But we are talking about salting, so I was addressing that.  Why would you not describe doubling (or more) the amount of time it takes to brute force a password as "protection?"  Protection does not mean it prevents it.  It CAN mean that it prevents it, but the definition of protection is not solely limited to prevention... otherwise why have "protection" and not "prevention?"  The wrapper on a condom says it offers protection against STD's... but no condom company is going to offer "prevention" of STD's, since no method is 100% effective... just like protection against brute forcing.  The very nature of brute forcing makes it impossible to prevent - that's why it's brute force.  The only thing you can do is protect against it as best you can.

Are there better methods to protect against brute forcing than salting?  Absolutely.  Is salting somehow not a protection?  No.  It's a first line defense/protection against rudimentary brute force.  As the brute force gets more sophisticated, the protection also needs to get more sophisticated.