2

Say we are given a strong cryptographic hash function hash(), a strong completely random password of 15 characters pass15, two single-character salt values salta, saltb.

We compute the hashes hasha, hashb by applying the hash function to the pass15 password + the salts:

hasha = hash(pass15+salta)

hashb = hash(pass15+saltb)

Now, lets say that salta, saltb, hash(), and hasha are all public. Is hashb any more at risk of being cracked than if hasha was not known?

For those who need specifics, lets go with hash() = sha256, but if it matters please say why it matters to this problem.

My belief is that hashb is no less crackable because only a brute force attack is possible to discover hashb, and that the public knowledge of hasha, salta and saltb has no bearing.

I just do not know if there is some mathematical shortcut that could utilize hasha to speed up the cracking. It does not seem theoretically possible.

**Summary based on responses given so far:**

First, let me rephrase the question in a different way:

If I have a strong, random 15 character password, are the salted hashes completely independent and safe to use however I want, even if the salts are known, are weak single-characters simply appended to the end of the password, and the hash function is fast, such as SHA256?

The answer seems to be yes. So, I could tack on a % character on the end of the password, hash it, and use that hash as my user id. It would be difficult to remember and probably too long as a user id, but it would be safe to do.

I could also tack on a single $ character onto the end of the password, hash it, and use the hash as my laptop password, and it would be safe to do that, even though I am publicly using the % hash as my user id. The list goes on for what I could do with the 15 character password and an appended salt. For example I could tack on the domain name of any site, hash the result, and use the hash as my password to the site.

The last concept is the basis for programs like PwdHash and PasswordMaker.

The assumption has been that (for me at least) the passwords generated by such programs are best kept secret as passwords, lest the hash function somehow gets "broken" or compromised. But it seems that as long as the strong password is kept secret, that any salted hash is individually safe to use however I want - that publishing one such hash to the world in no way jeopardizes the safety of any of the other hashes.

I was simply asking if anyone knows of some weakness with this thinking. The answer so far is no, the individual hashes can be used however I want.

For those who may be wondering about HOW safe, here is a quick math-based answer (I kept the math visible so that you can follow along with your calculator):

I believe that right now some programs can use a computer's graphics card to compute around 1 billon SHA256 hashes per second, 1E9 per second (within an order of magnitude at least).

This is the argument for why SHA256 is poor for passwords, and we SHOULD be using slower hashes such as Bcrypt.

Now, take a 15 character random password. The number of possible candidate passwords given uppercase, lowercase, and numerals in the password would be 62^15 = 7.7E26 possible passwords.

Using SHA256 as the hash function, the number of seconds it would take, on average to crack this password would be half the length of time to enumerate all the possible passwords:

7.7E26/1E9/2 = 7.7E17/2 = 3.9E17 seconds

The number of years to crack the password would be:

3.9E17/60/60/24/365 = 1.2E10 years, or 12 billion years, only a billon years less than the age of the Universe.

So to get from a public SHA256 hash to the original 15 character salted password would likely take more time than I have on this Earth.

Even given improvements in hardware (ignoring the possibility of quantum computers), the gap in technology to get down to cracking it in one year means we need computers that are 10 billion times faster.

So, I should feel free to use SHA256 salted hashes however way I choose as long as the basis of the hash is a random password of 15 characters or more.

  • Can you please clarify your question? You're asking if it's easier to find pass15 with knowledge of two hashes and their respective salts than if you know only one hash and one salt, correct? – Steve Dodier-Lazaro Jul 27 '14 at 15:08
  • Not exactly. I would like to use salta as an "identifier", publicly visible, but still use saltb as a secret (password). This allows the strong 15 char password to have a dual purpose - uniquely identify but also authenticate. It seems that if the password is strong enough to not get cracked, that both hasha and hashb are uncrackable, so knowing hasha does not risk discovering hashb. – Ken Clubb Jul 28 '14 at 14:16
  • So essentially, hasha = hash(salt15+userid) and hashb = hash(salt15+password)? And salt15 is secret and stored along with the hasha/hashb database? What then is the point of discovering hashb? Who wants to discover it? It's even less clear now :) – Steve Dodier-Lazaro Jul 28 '14 at 14:56
  • Not sure where you are getting the formulas you used, they are not the ones I gave in the question. I did not give a salt15 anywhere. hasha = hash(pass15+salta). Please read the question again. – Ken Clubb Jul 28 '14 at 16:52
  • What does the user provide? pass15 and salta? What do you provide? saltb? – Steve Dodier-Lazaro Jul 28 '14 at 17:22
4

I assume your question is:

Can an attacker find pass15 more easily if they know both hasha and hashb than if they know only hashb?

If that hash function is truly good it should have a good uniformity. That means that any input given to the function will be mapped to an output irrespective of how similar input is mapped.

This means that knowing how pass15+salta are mapped should not lead to any additional knowledge of how pass15+saltb are mapped.

An attacker would need to bruteforce either hasha or hashb in order to discover pass15.

In practice, the differences that could occur between salts are:

  • Unique vs common salts: a unique salt per client means that it takes longer to an attacker to break a set of hashes than if it is shared among entries of that set. This is the most important aspect of salts
  • Long vs short salts: if the salt is common, a longer salt is less likely to be already associated to passwords in a rainbow table because it would have taken longer to computer rainbow table entries of a sufficient length. This is a very minor factor as opposed to the uniqueness of salts or use of proper, slow hash functions
  • Duration since which your salt has been discovered: a salt should be private. If your db has been leaked, you should be able to set a lower bound on the time it'll take for an attacker to crack e.g. 1% of your users' passwords, so that you know how long you can wait before you have all your users' passwords reset.
  • Take away the salts for a moment. Even without salt, the password is strong enough to not be cracked with brute force. If it is, then lets go with a 20 character password - whatever it takes to make the hash uncrackable. Now, if the unsalted hash is uncrackable, then the password with salt is also uncrackable. Therefore hasha is uncrackable and hashb is uncrackable, regardless of the salt being known/unknown, short/long, etc. The whole thing seems to hinge on the password being strong enough. Is this correct? If so, then your statements of Unique/common, Long/short, Duration goes away. Right? – Ken Clubb Jul 28 '14 at 14:27
  • The main factor influencing "uncrackable" is how your hash function compares to the assumed computational power of your adversary. If you use a function slow enough so that observing 1% of your password alphabet takes longer than your password's expected lifetime (let's say 10 years?) even without salt, it's uncrackable for 99% of your users. Now adding a salt means doing a few more CPU rounds to compose your hash function's input and a few more bytes of storage per user, but it dramatically decreases the pressure on password length and hash function speed to protect against your adversary. – Steve Dodier-Lazaro Jul 28 '14 at 14:58
  • And that still assumes a uniform distribution of passwords so it is only true for generated and not for user-chosen passwords. Now if you think using generated and long passwords is better for your business than implementing stronger/costlier salting and hashing strategies you'll have surprises down the line because the usability of that would be terrible for your clients :) – Steve Dodier-Lazaro Jul 28 '14 at 15:01
  • Thanks for the analysis. I have a device that I patented a few years ago. I does in fact guarantee strong random passwords, and it is for this device that I am developing the software. – Ken Clubb Jul 28 '14 at 16:47
  • Yes, I agree that this approach of requiring generated random passwords is not for the general case, because strong passwords are impossible with human factors involved. I was specific about the question because I am assuming in my case that a strong random password is involved. – Ken Clubb Jul 28 '14 at 16:49
0

Now, lets say that salta, saltb, hash(), and hasha are all public. Is hashb any more at risk of being cracked than if hasha was not known?

Putting aside for a minute that the password is 15 characters of high entropy (which is good), and that sha256 is a fast hashing algorithm (which is bad)...

Giving GashA to the world is disclosing information that should be private. This hash could be brute forced, leaving the attacker with SaltA + Password. Since SaltB and Hash() are also public knowledge, the attacker could create HashB with Hash(SaltB+Password).

My belief is that hashb is no less crackable because only a brute force attack is possible to discover hashb, and that the public knowledge of hasha, salta and saltb has no bearing.

You are correct that only a brute force attack would disclose HashB, but the attack doesn't need to be against HashB, it could be against HashA.

I just do not know if there is some mathematical shortcut that could utilize hasha to speed up the cracking. It does not seem theoretically possible.

I don't know of any mathematics that would weaken the security of the HashB by knowing HashA. It is only a matter of private information being made public. The salts can be considered public, but the hash should be private.

Edit: After re-reading the question, I realize that this answer is specific only to the implementation of the proposed hash disclosure. I apologize if this was not what you are looking for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.