Bitcoin Forum
December 03, 2016, 07:51:58 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 »  All
  Print  
Author Topic: Info about the recent attack  (Read 48877 times)
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2492


View Profile
September 16, 2011, 01:38:55 AM
 #201

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
1480794718
Hero Member
*
Offline Offline

Posts: 1480794718

View Profile Personal Message (Offline)

Ignore
1480794718
Reply with quote  #2

1480794718
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Xenland
Legendary
*
Offline Offline

Activity: 980


I'm not just any shaman, I'm a Sha256man


View Profile
September 16, 2011, 03:43:55 AM
 #202

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.
To everyone that thought i didn't know anything about salts....
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

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
September 16, 2011, 01:53:24 PM
 #203

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:
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.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
terrytibbs
Hero Member
*****
Offline Offline

Activity: 560



View Profile
September 16, 2011, 01:55:52 PM
 #204

Man, theymos,
You're really good at jumping around the elephant in the room.

Yours Truly,
Terry.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 16, 2011, 02:13:43 PM
 #205

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.

Compute salt?!  Grin Grin Grin Grin Grin
And you will salt the salt? Or it's a plain hash?  Grin Grin

Or your idea is for have some sort of hidden function that will render salt's value?
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile
September 16, 2011, 03:12:51 PM
 #206

Theymos YTMND

Someone should post something (worthy) at http://theymos.ytmnd.com/
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
September 16, 2011, 03:26:23 PM
 #207

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
  • 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.
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
September 16, 2011, 08:01:30 PM
 #208

To everyone that thought i didn't know anything about salts....
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 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.


BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 16, 2011, 08:32:07 PM
 #209

And this keeps going around...
Anyone mind to explain WTF is a "random salt" in a sense it needs to be computed?!

Something like:

Code:
<?php
$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.  Tongue
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
September 16, 2011, 10:56:31 PM
 #210

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.



If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 16, 2011, 11:11:22 PM
 #211

Inaba,

The only way to do that by not storing the generated salt is by creating a function sort of:

Code:
<?php
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.
TiagoTiago
Hero Member
*****
Offline Offline

Activity: 616


Firstbits.com/1fg4i                :Ƀ


View Profile
September 17, 2011, 01:15:48 AM
 #212

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?

(I dont always get new reply notifications, pls send a pm when you think it has happened)

Wanna gimme some BTC for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX Smiley

The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!

Do you like mmmBananas?!
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 17, 2011, 01:31:55 AM
 #213

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:
<?php
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;
}
?>

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
September 17, 2011, 06:20:40 AM
 #214

Inaba,

The only way to do that by not storing the generated salt is by creating a function sort of:

Code:
<?php
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.

I'm not sure what you're getting at, but I don't disagree with what you've said.  Although we are veering further away from the topic at hand.  Are you posing a question or other interrogative or just commenting?


If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 17, 2011, 12:59:24 PM
 #215

I'm not sure what you're getting at, but I don't disagree with what you've said.  Although we are veering further away from the topic at hand.  Are you posing a question or other interrogative or just commenting?

I'm checking and demonstrating in terms of real code what you are discussing about; Salt generation.

In fact that $algorithm$salt$hash of crypt
the hash:salt of many systems
is a handicap on encryption.

But what resembles to be the best solution on this on-demand generated salt with Open Source software would be to create a salt class with different approaches and let the site owner to select which to use within config. This way an attacker would have to guess first which salting method was used before attempt to attack, and within the availabilities to generate the salt and input; xored strings, substring of hashes, multiple round sha hashing, bitwise etc... this would may means he would grow old before achieve something, even to the weakest of passwords.
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
September 17, 2011, 02:22:21 PM
 #216

would have to guess first which salting method was used

http://en.wikipedia.org/wiki/Security_through_obscurity

There's no reason to make the salt a part of the complexity of brute forcing passwords. Educate the users instead. "Password strength" indicators are one of several good ways of doing that.

BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 17, 2011, 02:48:52 PM
 #217

Why everyone comes with "security by obscurity" without even KNOW what that stands for?!

In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".


Quote
Educate the users instead.

This is what I call "Fascistly Imposed Security".

We don't need no education
We dont need no thought control
No dark sarcasm in the classroom
Teachers leave them kids alone
Hey! Teachers! Leave them kids alone!
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
September 17, 2011, 02:57:14 PM
 #218

Why everyone comes with "security by obscurity" without even KNOW what that stands for?!

In Open Source NOTHING is "obscure", it's a class with several flavors, creating entropy, not "obscurity".

Feel free to write coherent posts. Either the attacker has to guess (obscurity) or not. In any case, you're completely missing the point of salt if you feel that's a suitable place in a crypto system to add stronger complexity.


BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 17, 2011, 03:02:26 PM
 #219

In passwords the attacker is attempting to «GUESS» the password. You may ADD OR REMOVE walls of his path, ENTROPY.

Such system will ADD WALLS for him to break before «GUESS» what we wants to get.

Salt alone inputs a "NO PRE-COMPUTED HASHES" wall, but it's normally plain text on itself. Your objection is like saying that ADD A WALL is wrong because you think of it to be "obscure".
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
September 17, 2011, 03:09:22 PM
 #220

You may ADD OR REMOVE walls of his path

Yes, that's the "obscurity" part of your reasoning. It doesn't provide any added level of (real) security. When designing a security system all forms of added levels of complexity are risks where there might be edge cases you haven't thought about. You want as few implementation parts as possible, while still giving you a provable level of security.



Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!