Topic: Info about the recent attack - page 3. (Read 52589 times)
I didn't see an answer so i'll repeat my question, would using a triple SHA512 hash of the username instead of the plain username be of any help?
As we say in portuguese: "Nim" (mix não [no] and sim [yes])
It would be better to input a random number of turns instead of fixed 3, let's say 3~6:
Code:
function genSalt($username){
$rounds = mt_rand(3,6);
$salt = $username;
for($l = 0; $l < $rounds; $l++){
$salt = hash("sha512",$salt);
}
return $salt;
}
function checkPass($username,$givenpass,$hashpass){
$pointer = 0;
$salt = $username;
for($l = 0; $l < 6; $l++){
$salt = hash("sha512",$salt);
$pointer++;
if($pointer > 3){
$test = hash("sha512",$givenpass.$salt);
if($test == $hashpass) return true;
}
}
return false;
}
?>
I didn't see an answer so i'll repeat my question, would using a triple SHA512 hash of the username instead of the plain username be of any help?
Inaba,
The only way to do that by not storing the generated salt is by creating a function sort of:
It had some entropy to the salt, as the only way to get the salt is by getting not only the database but the code itself also.
Nevertheless you won't be getting much, as within several samples the attacker would have enough to dump the xored var value.
The only way to do that by not storing the generated salt is by creating a function sort of:
Code:
function computeSalt($var_to_use_as_ground,$site_secret = "akljhe34907##!@3hjd"){
$pw_pointer = 0;
$salt = "";
for($l = 0; $l < strlen($var_to_use_as_ground); $l++){
if($pw_pointer >= strlen($site_secret)) $pw_pointer = 0;
$salt .= $var_to_use_as_ground[$l] ^ $site_secret[$pw_pointer];
$pw_pointer++;
}
return $salt;
}
//Example:
$pw = md5($receivedPwd,computeSalt($user['username'])); //be sure to use the username as in the database to not make it case-sensitive on login
?>
It had some entropy to the salt, as the only way to get the salt is by getting not only the database but the code itself also.
Nevertheless you won't be getting much, as within several samples the attacker would have enough to dump the xored var value.
Not quite. I should have been more specific.
A different salt is used for each user, and it might as well be random since it's completely arbitrary. You have to gather the unique salt into a variable, pass it and the password candidate along to the hashing function, compare the hash result. With a static salt, you do not have to gather the salt and you can have your comparison routine just run that salt against the password hash.
When using the username, the username is already collected and ready to go as well, so using that is slightly less secure (is it a meaningful difference? I dunno, never really ... ahem ... hashed it out).
You have to store the random salt, you can't just pick one at random and hope for the best... but I assume you were being facetious in regards to that.
A different salt is used for each user, and it might as well be random since it's completely arbitrary. You have to gather the unique salt into a variable, pass it and the password candidate along to the hashing function, compare the hash result. With a static salt, you do not have to gather the salt and you can have your comparison routine just run that salt against the password hash.
When using the username, the username is already collected and ready to go as well, so using that is slightly less secure (is it a meaningful difference? I dunno, never really ... ahem ... hashed it out).
You have to store the random salt, you can't just pick one at random and hope for the best... but I assume you were being facetious in regards to that.
And this keeps going around...
Anyone mind to explain WTF is a "random salt" in a sense it needs to be computed?!
Something like:
?!
Sounds nice? Am I listening a "security bullshitter" about the MD5? Rest assure! This function is so damn secure that no one will be able to decrypt it, even if it's MD5... even if brutteforced all it can renders is something out of a collision, not by any chance your actual password.
A small glitch, as we don't store the salt anywhere and it is plainly random, there's no way for anyone to log in. A small detail, but... hey... it's secure.
Anyone mind to explain WTF is a "random salt" in a sense it needs to be computed?!
Something like:
Code:
$chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
$charsToUse = mt_rand(8,25);
$salt = "";
for($l = 0; $l < $carsToUse; $l++){
$char = mt_rand(0,strlen($chars)-1);
$salt .= $chars[$char];
}
md5($pass,$salt);
?>
?!
Sounds nice? Am I listening a "security bullshitter" about the MD5? Rest assure! This function is so damn secure that no one will be able to decrypt it, even if it's MD5... even if brutteforced all it can renders is something out of a collision, not by any chance your actual password.
A small glitch, as we don't store the salt anywhere and it is plainly random, there's no way for anyone to log in. A small detail, but... hey... it's secure.
To everyone that thought i didn't know anything about salts....
Didn't I just say something this earlier about a page back?
Didn't I just say something this earlier about a page back?
No.
I still don't get why people believe salt is about increasing the difficulty in brute forcing. While it may be a side effect depending on how it's implemented, the main purpose is in making rainbow tables inefficient.
Yes, brute forcing one user at a time with or without a salt would take the same amount of time.
Exactly, but it has to be explained here since quite a few seem to believe otherwise.
Quote
Properly implemented salt:
Random salt. The attacker can not pre-compute the salt, because it's different for every user.
Random salt. The attacker can not pre-compute the salt, because it's different for every user.
Random vs the username, as was the case here, then? Are you trying to claim that using the username as salt makes it static over the whole database??
If not, the difference between random and username becomes slim. This whole discussion began with self-appointed security experts claiming there was something inherently stupid in using the username as salt.
Just want to point out some things.
First off it's incorrect that candidates of length <=64 bytes take the same time to hash. The "boundary" in question (after which you calculate another compression function for the padding) is 55. Remember you need to add a 1 bit which would overwrite the last 8 length bytes.
Also depending on implementation, calculating hash of a 4-byte candidate might be faster than calculating say 32-byte candidate hash. That's because there is a common optimization that can be done: if w
Key stretching (e.g PBKDF or using phpass) is the common way to increase security. However that comes at a cost. Large forums with many users and lots of authentication attempts would consume a lot of CPU resources.
First off it's incorrect that candidates of length <=64 bytes take the same time to hash. The "boundary" in question (after which you calculate another compression function for the padding) is 55. Remember you need to add a 1 bit which would overwrite the last 8 length bytes.
Also depending on implementation, calculating hash of a 4-byte candidate might be faster than calculating say 32-byte candidate hash. That's because there is a common optimization that can be done: if w
- is always zero, then you can skip some of the ALU operations regarding it. That's because X ^0 = X and X+0=X and X|0=X and so on.
Key stretching (e.g PBKDF or using phpass) is the common way to increase security. However that comes at a cost. Large forums with many users and lots of authentication attempts would consume a lot of CPU resources.
Properly implemented salt:
Random salt. The attacker can not pre-compute the salt, because it's different for every user.
1 cycle = gather salt into memory
1 cycle = compute salt
1 cycle = compare salt + password hash
1 try = 3 cycles. Ta-da! You've just increased the time it takes to brute force a dataset by 3x.
Random salt. The attacker can not pre-compute the salt, because it's different for every user.
1 cycle = gather salt into memory
1 cycle = compute salt
1 cycle = compare salt + password hash
1 try = 3 cycles. Ta-da! You've just increased the time it takes to brute force a dataset by 3x.
Compute salt?!
And you will salt the salt? Or it's a plain hash?
Or your idea is for have some sort of hidden function that will render salt's value?
Man, theymos,
You're really good at jumping around the elephant in the room.
Yours Truly,
Terry.
You're really good at jumping around the elephant in the room.
Yours Truly,
Terry.
You can only hash one user at a time if you operate under the constraints you've outlined.
Right. Because there's a salt, so rainbow table attacks are prevented.
Stop cherry picking your argument and address the matter at hand. Yes, brute forcing one user at a time with or without a salt would take the same amount of time. That is NOT a realistic scenario in the case of a database being compromised. Once again, you can take an outlying case and make it say anything you want. We aren't talking about tailor made cases to fit your conjecture.
Quote
You said:
So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.
Quote from: Inaba
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.
So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.
I am not saying that. I said NOTHING like that. In fact, I said EXACTLY THE OPPOSITE. Re-read what I wrote.
A realistic scenario is an attacker brute forcing an entire (or large subset of the entire) user table of a database. Trying to brute force a single user without knowing the strength of the underlying password is just dumb. Unless you need access to a specific user for a specific purpose, you are going to attack the whole database to get at the weakest passwords as quickly as possible.
This is where a properly implemented salt system protects you, and protects you fairly well, from a brute force attack.
Broken salt implementation with no protection:
In a static salt (or no salt) situation (both being broken implementations of a salting mechanism), the attacker has already precomputed the salt and then compares the hashes + salt. Ok, no advantage there. Duh!
1 try = 1 cycle
Properly implemented salt:
Random salt. The attacker can not pre-compute the salt, because it's different for every user.
1 cycle = gather salt into memory
1 cycle = compute salt
1 cycle = compare salt + password hash
1 try = 3 cycles. Ta-da! You've just increased the time it takes to brute force a dataset by 3x.
With some nifty coding, you might be able to combine two of those steps. You've still DOUBLED the time it takes to brute force a dataset.
I would say a 2 - 3x increase in brute force time is some hefty protection, personally. You can disagree all you want, but the fact remains that properly implementing salt is a first line defense against brute forcing and when properly implemented is going to thwart all but the most determined crackers. A static salt is fairly worthless for anything but thwarting a rainbow table, so quit holding up static salts as your pivotal argument, since that is not what we are talking about. We are talking about properly implemented salting mechanisms. Static salts are not properly implemented.
PS -
I forgot to address this:
Quote
In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.
So again, you are holding up some sort of broken password system as an example of why password systems don't work? I don't understand your chain of logic. What properly implemented salt system would use a short salt, besides maybe crypt? But, by your logic, then a > 32 character salt would offer protection? That being the case, you've just agreed with everything I've been saying and invalidated your entire argument.
You can only hash one user at a time if you operate under the constraints you've outlined.
Right. Because there's a salt, so rainbow table attacks are prevented.
You said:
Quote from: Inaba
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.
So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.
Didn't I just say something this earlier about a page back?
But "noooo!!!" everyone was just thinking I was just putting sea-salt on meh hardware encryption function. LOL
Theymos YTMND
You can only hash one user at a time if you operate under the constraints you've outlined.
Right. Because there's a salt, so rainbow table attacks are prevented.
You said:
Quote from: Inaba
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.
So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.
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).
Quote
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.
Quote
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.
Would it help if the salt instead of the plain username was a tripple SHA512 of the username?
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.
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.
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( + 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.
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
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.
Jump to: