PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Mon Dec 17, 2018 10:55 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Thu Jan 20, 2011 3:11 pm 
Offline
DevNet Master
User avatar

Joined: Thu Mar 15, 2007 6:28 pm
Posts: 2765
Location: Redding, California
Unless they have the code of course?


Top
 Profile  
 
PostPosted: Thu Jan 20, 2011 3:50 pm 
Offline
DevNet Master
User avatar

Joined: Wed Jun 27, 2007 9:44 am
Posts: 4313
Location: Sofia, Bulgaria
Benjamin wrote:
VladSun wrote:
I think rainbow attacks or dictionary attacks are useless (or at least very hard to apply) for salted hashes even if the salt is known.


What makes you say this?


Both dictionary attacks (I'm not talking about bruteforce dictionary attacks which may be/are very SLOW) and ranbow attacks have precalculated tables of values. When salt is used, these table values do not match anymore.

_________________
There are 10 types of people in this world, those who understand binary and those who don't


Top
 Profile  
 
PostPosted: Thu Jan 20, 2011 3:55 pm 
Offline
DevNet Master
User avatar

Joined: Wed Jun 27, 2007 9:44 am
Posts: 4313
Location: Sofia, Bulgaria
Jonah Bron wrote:
Unless they have the code of course?


Considering "not having the code" (which is an obscure method IMHO) something like this will be much easier amd stronger:
Syntax: [ Download ] [ Hide ]
  1. hash(crypt(salt+password)) 

where crypt is a encrypting function.

_________________
There are 10 types of people in this world, those who understand binary and those who don't


Top
 Profile  
 
PostPosted: Thu Jan 20, 2011 4:48 pm 
Offline
Site Administrator
User avatar

Joined: Sun May 19, 2002 10:24 pm
Posts: 6887
Jonah Bron wrote:
Unless they have the code of course?


No, even with the code they cannot determine the salt length without knowing the actual length of the password.

_________________
Image


Top
 Profile  
 
PostPosted: Thu Jan 20, 2011 5:00 pm 
Offline
DevNet Master
User avatar

Joined: Thu Mar 15, 2007 6:28 pm
Posts: 2765
Location: Redding, California
But if they're using a rainbow table, they're guessing, right? So if they guess right, they also guess the salt right (providing they know how the salt is generated). Right?


Top
 Profile  
 
PostPosted: Sat Feb 12, 2011 3:19 am 
Offline
DevNet Resident
User avatar

Joined: Sun Sep 03, 2006 5:19 am
Posts: 1579
Location: Sofia, Bulgaria
On the minus side, you're working from a wrong (security-wise) assumption and you have a "bug" in your code.
On the plus side, the "bug" is a problem only in regards to your assumption, and since the assumption is wrong, the bug has no negative consequences (as far as I can see)
After the bottom line, what you do is secure enough, even if it doesn't add anything useful to the security properties of a salted password.

Details:

The assumption that a salt that is kept (albeit transformed) in the database can be a "secret" is wrong. Everything you need to check if "123456" is a password is in the database, even if it's moved around a bit.

The "bug" is that the left/right pieces are not so "secret". The sum of their lengths (L) is a fixed value, dependent on the hash function being used. For whirlpool, it's 21 hex digits, for sha256 it's 10, for sha1 it's 6, for md5 it's 5. To retrieve the left/right pieces of the salt, you simply need L attempts taking the leftmost K hex digits and the rightmost L-K digids. Not that you would need to do it when attacking the hashes, that's why this bug doesn't matter to the overall security.

In the end, what the function does is no different than keeping the salt separately in the database. The difference is actually a bit to the worse, as the salt length is made dependent on the hash function used, instead of the desired password strength as it should be. For example with md5 the salt is only 5 hex digits, 20 bits, the equivalent of about 3.5 mixed cap characters.

I think the confusion came from mixing what the different attacks do:
For stolen database of unsalted hashes, precomputed attack methods (aka rainbow tables, but there are others as well) work well.
For stolen database of salted hashes with in-database salts, dictionary attacks work well. In the edge case of weak salts (as this code would do for md5, sha1, arguably for sha256) precomputed tables would work as well.

If you really want to add security, use multifactor salts (aka salt-and-pepper), I've explained this in an old article (draft) in the security forum:
http://forums.devnetwork.net/viewtopic.php?f=34&t=62782

Some elements of the article are not quite correct, for example I would now recommend using HMAC for mixing the password and the salt, but overall it stands.


Top
 Profile  
 
PostPosted: Sat Feb 12, 2011 1:43 pm 
Offline
Site Administrator
User avatar

Joined: Sun May 19, 2002 10:24 pm
Posts: 6887
Interesting. I could have sworn I tested the salt lengths. I will need to update that so that the salt lengths are specifically based on the password length, or some other element specific to the password.

On the bright side it's still very secure. If you want to create an updated version feel free to take a crack at it.

_________________
Image


Top
 Profile  
 
PostPosted: Sat Feb 12, 2011 3:28 pm 
Offline
DevNet Resident
User avatar

Joined: Sun Sep 03, 2006 5:19 am
Posts: 1579
Location: Sofia, Bulgaria
Benjamin wrote:
Interesting. I could have sworn I tested the salt lengths. I will need to update that so that the salt lengths are specifically based on the password length, or some other element specific to the password.

On the bright side it's still very secure. If you want to create an updated version feel free to take a crack at it.


Erm, no, you don't have to update it. It makes no difference, as I did (try to) explain. There's absolutely no benefit from using this compared to simply keeping the salt in another column. Plus, for some hashes your salts are weak.


Top
 Profile  
 
PostPosted: Sat Feb 12, 2011 7:59 pm 
Offline
Site Administrator
User avatar

Joined: Sun May 19, 2002 10:24 pm
Posts: 6887
How can a known salt not be less secure than an unknown salt? Crack it:

Syntax: [ Download ] [ Hide ]
5794bb03a911e3530c17c8547e7cedc277500bae22172e4cc7a470cc5a77b232a97826d109379378ff754f3dc31f1c04d2ae9cadf0c5fb6c0e234e6a7a437246


If you can't crack this knowing the salt, how do you plan on cracking it without knowing the salt?

_________________
Image


Top
 Profile  
 
PostPosted: Sun Feb 13, 2011 4:50 am 
Offline
DevNet Resident
User avatar

Joined: Sun Sep 03, 2006 5:19 am
Posts: 1579
Location: Sofia, Bulgaria
You are still not grokking my overview paragraph on how to attack hashes. Salted hashes, your scheme included, are attacked with a dictionary/bruteforce.

Benjamin wrote:
If you can't crack this knowing the salt, how do you plan on cracking it without knowing the salt?


If I can't crack this knowing the salt, it means your password was not in my dictionary, well done. You will note thought that salts are used to prevent attacks against weak passwords; strong passwords are secure even with weak hashing schemes.

If, on the other hand, your password is in my dictionary, I will not worry about the salt at all, I will just call your function for every password in there and it will happily extract the correct salt from the hash (for the correct password, I don't care about the failed attempts).

Note that this will be true no matter what "fixes" you do in the implementation of your function, as such it is no different than just keeping the salt in a separate column, as I already conjectured. The only fixes I would recommend is to increase the salt length (which is a definite problem in your current scheme) and use HMAC.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group