Pages:
Author

Topic: Info about the recent attack - page 4. (Read 52585 times)

administrator
Activity: 5222
Merit: 13032
September 15, 2011, 12:25:49 PM
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.
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
September 15, 2011, 10:44:59 AM
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?
sr. member
Activity: 256
Merit: 250
September 15, 2011, 02:51:37 AM
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.



sr. member
Activity: 314
Merit: 251
September 15, 2011, 01:48:37 AM
@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.
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
September 15, 2011, 12:48:15 AM
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!

hero member
Activity: 530
Merit: 500
September 15, 2011, 12:40:35 AM
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.
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
September 15, 2011, 12:27:06 AM
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?
hero member
Activity: 530
Merit: 500
September 15, 2011, 12:14:46 AM
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)
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
September 14, 2011, 07:13:21 PM
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.
legendary
Activity: 1218
Merit: 1000
September 14, 2011, 06:20:52 PM
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.
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
September 14, 2011, 05:57:47 PM
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....
c_k
donator
Activity: 242
Merit: 100
September 14, 2011, 04:44:35 AM
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.
legendary
Activity: 1218
Merit: 1000
September 14, 2011, 04:20:05 AM
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"...
hero member
Activity: 616
Merit: 500
Firstbits.com/1fg4i :)
September 14, 2011, 02:13:16 AM
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?
hero member
Activity: 588
Merit: 500
September 14, 2011, 12:02:49 AM
This mess. ultimately, is the PHP language authors' fault. They seem to argue that securing your scripts (and not just from SQL injections) is the programmer's problem.
A properly designed SQL interface (with prepared statements and placeholders) makes writing code that's prone to injections more difficult to write than code which isn't.
In PHP, it's the other way round, and the language authors don't think that's a problem.

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.
donator
Activity: 2772
Merit: 1019
September 13, 2011, 04:20:24 PM
Allright, thanks for clearing that up, man. Cause you had my hard stop for a second there.
lmao. Sorry 'baut that. No, for that very reason - that browsers store passwords in a common file - is exactly why browsers are so paranoid about preventing web scripts from interacting with the local file system. They're run in little sandboxes, and it while it's not entirely impossible to hack around those safeguards, it would take an *entirely* different set of hacks to do so, not just a "display random funny Cosbycoin/uplaoding walletdat" image randomizer to do so Smiley

No problem. It's this damn paranoia lately. Who knows? Some browser exploit, whatever...

I happy I made you laugh, though. Much needed in these forums nowaday Wink
newbie
Activity: 23
Merit: 0
September 13, 2011, 02:45:40 PM
Salting bascially changes the original value and the comparison value with a known figure so the hashes can't be referenced to a lookup table, and so they can't be broken without knowing the salt value. Oh wait, we know the salt value now. Haha, that was easy™.

Again, with the big exclamation of, "Everyone lock your doors, they might have gotten a copy of the KEY TO THE KINGDOM! *attachment: high-res picture of key to the kingdom.jpg*"
You forget that everybody and their dog can just go and check out the forum PHP code themselves, and examine the password hashing algorithm in detail.

This mess. ultimately, is the PHP language authors' fault. They seem to argue that securing your scripts (and not just from SQL injections) is the programmer's problem.
A properly designed SQL interface (with prepared statements and placeholders) makes writing code that's prone to injections more difficult to write than code which isn't.
In PHP, it's the other way round, and the language authors don't think that's a problem.

Well, I happen to disagree, rather vehemently in fact, which is why I try to encourage people to program their web sites in some other language (Python for instance), and why every single PHP-using website on my server runs in a FastCGI sandbox and has (almost) no access to the rest of the system.
full member
Activity: 176
Merit: 100
September 13, 2011, 01:51:14 PM
Allright, thanks for clearing that up, man. Cause you had my hard stop for a second there.
lmao. Sorry 'baut that. No, for that very reason - that browsers store passwords in a common file - is exactly why browsers are so paranoid about preventing web scripts from interacting with the local file system. They're run in little sandboxes, and it while it's not entirely impossible to hack around those safeguards, it would take an *entirely* different set of hacks to do so, not just a "display random funny Cosbycoin/uplaoding walletdat" image randomizer to do so Smiley
donator
Activity: 2772
Merit: 1019
September 13, 2011, 01:45:08 PM
were wallet.dat files uploaded or not?
To answer your question with another question:

Why would they go after your wallet.dat when they could just go after your browser's (unprotected by default) password store?

What are you talking about? How would they gain access to the browser password store?
EXACTLY MY POINT. They didn't steal wallet.dats because they couldn't. And even if they could, they'd probably rather go after something more useful than the Bitcoins they hate so much. That's my point: if they COULD steal wallet.dat, they probably wouldn't've bothered with something so trivial. Browsers have paranoid amounts of security regarding file-upload abilities (remember when the "file path" field disappeared from HTML file controls?), so it's just not possible for a stupid little Javascript playtime script to go stealing wallet.dats. That's the point I was making.

Allright, thanks for clearing that up, man. Cause you had my hard stop for a second there.
full member
Activity: 176
Merit: 100
September 13, 2011, 01:43:34 PM
were wallet.dat files uploaded or not?
To answer your question with another question:

Why would they go after your wallet.dat when they could just go after your browser's (unprotected by default) password store?

What are you talking about? How would they gain access to the browser password store?
EXACTLY MY POINT. They didn't steal wallet.dats because they couldn't. And even if they could, they'd probably rather go after something more useful than the Bitcoins they hate so much. That's my point: if they COULD steal wallet.dat, they probably wouldn't've bothered with something so trivial. Browsers have paranoid amounts of security regarding file-upload abilities (remember when the "file path" field disappeared from HTML file controls?), so it's just not possible for a stupid little Javascript playtime script to go stealing wallet.dats. That's the point I was making.
Pages:
Jump to: