Which one of these password policies are more secure?How to securely hash passwords?In 2018, what is the...

How to make ice magic work from a scientific point of view?

Increment each digit in a number to form a new number

Can a person refuse a presidential pardon?

Eww, those bytes are gross

Convert exam marks to overall grade

SET NOCOUNT Error in handling SQL call after upgrade

What is the most fuel efficient way out of the Solar System?

Why zero tolerance on nudity in space?

What are "industrial chops"?

use of 4/2 chord more compelling than root position?

Citing paywalled articles accessed via illegal web sharing

How to deal with an incendiary email that was recalled

How can I play a serial killer in a party of good PCs?

What to look for when criticizing poetry?

Why avoid shared user accounts?

How would an AI self awareness kill switch work?

Salesforce package error error “You can't specify version for namespace sf_com_apps because this namespace is not installed to your organization.”

Odd 74HCT1G125 behaviour

Calculate the number of points of an elliptic curve in medium Weierstrass form over finite field

Quickly creating a sparse array

Why would space fleets be aligned?

Why publish a research paper when a blog post or a lecture slide can have more citation count than a journal paper?

How can I get my players to come to the game session after agreeing to a date?

Why are the books in the Game of Thrones citadel library shelved spine inwards?



Which one of these password policies are more secure?


How to securely hash passwords?In 2018, what is the recommended hash to store passwords: bcrypt, scrypt, Argon2?Long Passwords: How are they more secure?Is there more to password hashing?Is this cross-site password model secure?How secure is it to use passwords consisting of one common part and one site specific prefix?How come a controlledly generated password is more secure than a purely randomly generated oneSend password through unsecured connectionDo password policies make passwords weaker?Multiple password fields for one loginIs it a bad idea to use base-64 encoded strings for passwords?Password policies for randomly generating passwords













2















What is more secure, having one password of length 9 (salted and hashed) or having two different passwords, each of length 8 (salted and hashed using two different salts)?










share|improve this question







New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…

    – Polynomial
    4 hours ago






  • 1





    To clarify for the uninitiated, Polynomial is discouraging simple salting of "fast" hashes (like MD5) that are not suitable for password storage, or rolling your own salted hashes. Even modern "hashes" (actually complex cryptographic operations, not simple hashes - but still colloquially called "hashes" by most people in conversation) are also salted. Salting is good. Salting alone, of an otherwise bad/fast hash, is slightly better than not salting ... but not by much.

    – Royce Williams
    2 hours ago


















2















What is more secure, having one password of length 9 (salted and hashed) or having two different passwords, each of length 8 (salted and hashed using two different salts)?










share|improve this question







New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…

    – Polynomial
    4 hours ago






  • 1





    To clarify for the uninitiated, Polynomial is discouraging simple salting of "fast" hashes (like MD5) that are not suitable for password storage, or rolling your own salted hashes. Even modern "hashes" (actually complex cryptographic operations, not simple hashes - but still colloquially called "hashes" by most people in conversation) are also salted. Salting is good. Salting alone, of an otherwise bad/fast hash, is slightly better than not salting ... but not by much.

    – Royce Williams
    2 hours ago
















2












2








2








What is more secure, having one password of length 9 (salted and hashed) or having two different passwords, each of length 8 (salted and hashed using two different salts)?










share|improve this question







New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












What is more secure, having one password of length 9 (salted and hashed) or having two different passwords, each of length 8 (salted and hashed using two different salts)?







passwords password-management password-policy






share|improve this question







New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 4 hours ago









CarlosCarlos

111




111




New contributor




Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Carlos is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…

    – Polynomial
    4 hours ago






  • 1





    To clarify for the uninitiated, Polynomial is discouraging simple salting of "fast" hashes (like MD5) that are not suitable for password storage, or rolling your own salted hashes. Even modern "hashes" (actually complex cryptographic operations, not simple hashes - but still colloquially called "hashes" by most people in conversation) are also salted. Salting is good. Salting alone, of an otherwise bad/fast hash, is slightly better than not salting ... but not by much.

    – Royce Williams
    2 hours ago





















  • You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…

    – Polynomial
    4 hours ago






  • 1





    To clarify for the uninitiated, Polynomial is discouraging simple salting of "fast" hashes (like MD5) that are not suitable for password storage, or rolling your own salted hashes. Even modern "hashes" (actually complex cryptographic operations, not simple hashes - but still colloquially called "hashes" by most people in conversation) are also salted. Salting is good. Salting alone, of an otherwise bad/fast hash, is slightly better than not salting ... but not by much.

    – Royce Williams
    2 hours ago



















You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…

– Polynomial
4 hours ago





You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…

– Polynomial
4 hours ago




1




1





To clarify for the uninitiated, Polynomial is discouraging simple salting of "fast" hashes (like MD5) that are not suitable for password storage, or rolling your own salted hashes. Even modern "hashes" (actually complex cryptographic operations, not simple hashes - but still colloquially called "hashes" by most people in conversation) are also salted. Salting is good. Salting alone, of an otherwise bad/fast hash, is slightly better than not salting ... but not by much.

– Royce Williams
2 hours ago







To clarify for the uninitiated, Polynomial is discouraging simple salting of "fast" hashes (like MD5) that are not suitable for password storage, or rolling your own salted hashes. Even modern "hashes" (actually complex cryptographic operations, not simple hashes - but still colloquially called "hashes" by most people in conversation) are also salted. Salting is good. Salting alone, of an otherwise bad/fast hash, is slightly better than not salting ... but not by much.

– Royce Williams
2 hours ago












2 Answers
2






active

oldest

votes


















3














Splitting the password is almost certainly worse. It allows an eight character rainbow table to be created. It implies that all passwords in the system will be in 8 character parts. (This is exactly how NT LANMAN passwords were broken.) In your case, it would simply require two rainbow tables.



The nine character password system has no such visible flaw, implying that if you entered a proper 14 character password it would be safely stored as a single hash.






share|improve this answer
























  • Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

    – Royce Williams
    2 hours ago













  • Er, unless it was a trivially weak (short) salt. :)

    – Royce Williams
    1 hour ago



















3














As John Deters has noted, 2x8 is almost certainly worse - but the reasons why take a little explaining.



There were a couple of problems with LANMAN hashes (the classic case of breaking a password in half):




  • Since passwords tend to be human-generated and somewhat short, if a single password was only a little longer than the first half (say, 8 characters), then cracking the second half would take dramatically less time - and could even give away what the first half was likely to be)


  • LANMAN was just so darned fast (for the attacker to attempt, in hash operations per second)


  • LANMAN cut the passwords in two at an unfortunate length (7), that was quite susceptible to full exhaustion (and even moreso on modern GPUs)



However, your question is a little different from the LANMAN case, for a couple of reasons:




  • it does not state that the 2x8 passwords are actually a single password broken in half (they could be independently generated, and random)

  • it explicitly states that the two passwords are of length 8 (rather than, say, one of length 8 and the other of length 1, the famous LANMAN worst case)

  • the question would be uninteresting if the passwords were human-generated, (because in practice they would usually fall to easy attacks long before the attacker would have to resort to brute force)

  • unless your salts are trivially small, building rainbow tables would be infeasible, which is the purpose of salting (unlike LANMAN hashes, which were entirely unsalted)


So it's an interesting question - one that's largely answered by looking at the associated math.



For the sake of the thought experiment, let's make some assumptions:




  • both the 9x1 and 8x2 approaches are salted and hashed using the same
    salt lengths and algorithms

  • worst case for the attacker (the passwords are randomly generated from the printable ASCII character set (95 chars), with reasonably long salts)

  • modern hardware and speeds are fair game

  • the hash algorithm may or may not be parallelism-friendly


Given all of the above, I'd roughly expect:




  • The 1x9 hash would be 100% exhausted in 95^9 (6.302 × 10^17) hashing operations (which might be parallelized well or poorly).

  • The 2x8 hashes would be jointly 100% exhausted in (95^8)x2 (1.326 × 10^16) hashing operations (and no matter the algorithm, could easily be naively parallelized simply by cracking each hash on a different system - but can often be parallelized very efficiently on a single system as well, depending on the algorithm).


In other words:




  • that 9th character adds 95 times the work to exhaust, and might be hard to parallelize

  • Two 8-character passwords only doubles the amount of work needed, and can be trivially parallelized


Another way to think about it is that adding one more character roughly creates the same work as having to crack 95 8-character passwords! (If this isn't intuitive, start with simple cases comparing smaller cases like 1x1 vs 1x2, until you understand it).



So all other things being equal, 1x9 should almost always be better than 2x8.



And really, this is not only a simple illustration of the power of parallelization, it should also make it obvious why allowing longer password lengths is so crucial. Each additional character in the model above adds 95 times work to the overall keyspace. So adding two characters adds 95^2 - or 9025 times - the work. Brute force quickly becomes infeasible, even for very fast and unsalted hashes.



This would make an excellent homework question. ;)






share|improve this answer


























  • Agreed with your conclusion. I would of explained this in a very similar manner.

    – Overmind
    8 mins ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






Carlos is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204450%2fwhich-one-of-these-password-policies-are-more-secure%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














Splitting the password is almost certainly worse. It allows an eight character rainbow table to be created. It implies that all passwords in the system will be in 8 character parts. (This is exactly how NT LANMAN passwords were broken.) In your case, it would simply require two rainbow tables.



The nine character password system has no such visible flaw, implying that if you entered a proper 14 character password it would be safely stored as a single hash.






share|improve this answer
























  • Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

    – Royce Williams
    2 hours ago













  • Er, unless it was a trivially weak (short) salt. :)

    – Royce Williams
    1 hour ago
















3














Splitting the password is almost certainly worse. It allows an eight character rainbow table to be created. It implies that all passwords in the system will be in 8 character parts. (This is exactly how NT LANMAN passwords were broken.) In your case, it would simply require two rainbow tables.



The nine character password system has no such visible flaw, implying that if you entered a proper 14 character password it would be safely stored as a single hash.






share|improve this answer
























  • Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

    – Royce Williams
    2 hours ago













  • Er, unless it was a trivially weak (short) salt. :)

    – Royce Williams
    1 hour ago














3












3








3







Splitting the password is almost certainly worse. It allows an eight character rainbow table to be created. It implies that all passwords in the system will be in 8 character parts. (This is exactly how NT LANMAN passwords were broken.) In your case, it would simply require two rainbow tables.



The nine character password system has no such visible flaw, implying that if you entered a proper 14 character password it would be safely stored as a single hash.






share|improve this answer













Splitting the password is almost certainly worse. It allows an eight character rainbow table to be created. It implies that all passwords in the system will be in 8 character parts. (This is exactly how NT LANMAN passwords were broken.) In your case, it would simply require two rainbow tables.



The nine character password system has no such visible flaw, implying that if you entered a proper 14 character password it would be safely stored as a single hash.







share|improve this answer












share|improve this answer



share|improve this answer










answered 4 hours ago









John DetersJohn Deters

27.7k24191




27.7k24191













  • Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

    – Royce Williams
    2 hours ago













  • Er, unless it was a trivially weak (short) salt. :)

    – Royce Williams
    1 hour ago



















  • Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

    – Royce Williams
    2 hours ago













  • Er, unless it was a trivially weak (short) salt. :)

    – Royce Williams
    1 hour ago

















Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

– Royce Williams
2 hours ago







Salting them would automatically exclude the use of rainbow tables. But the method described would indeed reduce the strength of longer passwords, for exactly the reasons you've noted.

– Royce Williams
2 hours ago















Er, unless it was a trivially weak (short) salt. :)

– Royce Williams
1 hour ago





Er, unless it was a trivially weak (short) salt. :)

– Royce Williams
1 hour ago













3














As John Deters has noted, 2x8 is almost certainly worse - but the reasons why take a little explaining.



There were a couple of problems with LANMAN hashes (the classic case of breaking a password in half):




  • Since passwords tend to be human-generated and somewhat short, if a single password was only a little longer than the first half (say, 8 characters), then cracking the second half would take dramatically less time - and could even give away what the first half was likely to be)


  • LANMAN was just so darned fast (for the attacker to attempt, in hash operations per second)


  • LANMAN cut the passwords in two at an unfortunate length (7), that was quite susceptible to full exhaustion (and even moreso on modern GPUs)



However, your question is a little different from the LANMAN case, for a couple of reasons:




  • it does not state that the 2x8 passwords are actually a single password broken in half (they could be independently generated, and random)

  • it explicitly states that the two passwords are of length 8 (rather than, say, one of length 8 and the other of length 1, the famous LANMAN worst case)

  • the question would be uninteresting if the passwords were human-generated, (because in practice they would usually fall to easy attacks long before the attacker would have to resort to brute force)

  • unless your salts are trivially small, building rainbow tables would be infeasible, which is the purpose of salting (unlike LANMAN hashes, which were entirely unsalted)


So it's an interesting question - one that's largely answered by looking at the associated math.



For the sake of the thought experiment, let's make some assumptions:




  • both the 9x1 and 8x2 approaches are salted and hashed using the same
    salt lengths and algorithms

  • worst case for the attacker (the passwords are randomly generated from the printable ASCII character set (95 chars), with reasonably long salts)

  • modern hardware and speeds are fair game

  • the hash algorithm may or may not be parallelism-friendly


Given all of the above, I'd roughly expect:




  • The 1x9 hash would be 100% exhausted in 95^9 (6.302 × 10^17) hashing operations (which might be parallelized well or poorly).

  • The 2x8 hashes would be jointly 100% exhausted in (95^8)x2 (1.326 × 10^16) hashing operations (and no matter the algorithm, could easily be naively parallelized simply by cracking each hash on a different system - but can often be parallelized very efficiently on a single system as well, depending on the algorithm).


In other words:




  • that 9th character adds 95 times the work to exhaust, and might be hard to parallelize

  • Two 8-character passwords only doubles the amount of work needed, and can be trivially parallelized


Another way to think about it is that adding one more character roughly creates the same work as having to crack 95 8-character passwords! (If this isn't intuitive, start with simple cases comparing smaller cases like 1x1 vs 1x2, until you understand it).



So all other things being equal, 1x9 should almost always be better than 2x8.



And really, this is not only a simple illustration of the power of parallelization, it should also make it obvious why allowing longer password lengths is so crucial. Each additional character in the model above adds 95 times work to the overall keyspace. So adding two characters adds 95^2 - or 9025 times - the work. Brute force quickly becomes infeasible, even for very fast and unsalted hashes.



This would make an excellent homework question. ;)






share|improve this answer


























  • Agreed with your conclusion. I would of explained this in a very similar manner.

    – Overmind
    8 mins ago
















3














As John Deters has noted, 2x8 is almost certainly worse - but the reasons why take a little explaining.



There were a couple of problems with LANMAN hashes (the classic case of breaking a password in half):




  • Since passwords tend to be human-generated and somewhat short, if a single password was only a little longer than the first half (say, 8 characters), then cracking the second half would take dramatically less time - and could even give away what the first half was likely to be)


  • LANMAN was just so darned fast (for the attacker to attempt, in hash operations per second)


  • LANMAN cut the passwords in two at an unfortunate length (7), that was quite susceptible to full exhaustion (and even moreso on modern GPUs)



However, your question is a little different from the LANMAN case, for a couple of reasons:




  • it does not state that the 2x8 passwords are actually a single password broken in half (they could be independently generated, and random)

  • it explicitly states that the two passwords are of length 8 (rather than, say, one of length 8 and the other of length 1, the famous LANMAN worst case)

  • the question would be uninteresting if the passwords were human-generated, (because in practice they would usually fall to easy attacks long before the attacker would have to resort to brute force)

  • unless your salts are trivially small, building rainbow tables would be infeasible, which is the purpose of salting (unlike LANMAN hashes, which were entirely unsalted)


So it's an interesting question - one that's largely answered by looking at the associated math.



For the sake of the thought experiment, let's make some assumptions:




  • both the 9x1 and 8x2 approaches are salted and hashed using the same
    salt lengths and algorithms

  • worst case for the attacker (the passwords are randomly generated from the printable ASCII character set (95 chars), with reasonably long salts)

  • modern hardware and speeds are fair game

  • the hash algorithm may or may not be parallelism-friendly


Given all of the above, I'd roughly expect:




  • The 1x9 hash would be 100% exhausted in 95^9 (6.302 × 10^17) hashing operations (which might be parallelized well or poorly).

  • The 2x8 hashes would be jointly 100% exhausted in (95^8)x2 (1.326 × 10^16) hashing operations (and no matter the algorithm, could easily be naively parallelized simply by cracking each hash on a different system - but can often be parallelized very efficiently on a single system as well, depending on the algorithm).


In other words:




  • that 9th character adds 95 times the work to exhaust, and might be hard to parallelize

  • Two 8-character passwords only doubles the amount of work needed, and can be trivially parallelized


Another way to think about it is that adding one more character roughly creates the same work as having to crack 95 8-character passwords! (If this isn't intuitive, start with simple cases comparing smaller cases like 1x1 vs 1x2, until you understand it).



So all other things being equal, 1x9 should almost always be better than 2x8.



And really, this is not only a simple illustration of the power of parallelization, it should also make it obvious why allowing longer password lengths is so crucial. Each additional character in the model above adds 95 times work to the overall keyspace. So adding two characters adds 95^2 - or 9025 times - the work. Brute force quickly becomes infeasible, even for very fast and unsalted hashes.



This would make an excellent homework question. ;)






share|improve this answer


























  • Agreed with your conclusion. I would of explained this in a very similar manner.

    – Overmind
    8 mins ago














3












3








3







As John Deters has noted, 2x8 is almost certainly worse - but the reasons why take a little explaining.



There were a couple of problems with LANMAN hashes (the classic case of breaking a password in half):




  • Since passwords tend to be human-generated and somewhat short, if a single password was only a little longer than the first half (say, 8 characters), then cracking the second half would take dramatically less time - and could even give away what the first half was likely to be)


  • LANMAN was just so darned fast (for the attacker to attempt, in hash operations per second)


  • LANMAN cut the passwords in two at an unfortunate length (7), that was quite susceptible to full exhaustion (and even moreso on modern GPUs)



However, your question is a little different from the LANMAN case, for a couple of reasons:




  • it does not state that the 2x8 passwords are actually a single password broken in half (they could be independently generated, and random)

  • it explicitly states that the two passwords are of length 8 (rather than, say, one of length 8 and the other of length 1, the famous LANMAN worst case)

  • the question would be uninteresting if the passwords were human-generated, (because in practice they would usually fall to easy attacks long before the attacker would have to resort to brute force)

  • unless your salts are trivially small, building rainbow tables would be infeasible, which is the purpose of salting (unlike LANMAN hashes, which were entirely unsalted)


So it's an interesting question - one that's largely answered by looking at the associated math.



For the sake of the thought experiment, let's make some assumptions:




  • both the 9x1 and 8x2 approaches are salted and hashed using the same
    salt lengths and algorithms

  • worst case for the attacker (the passwords are randomly generated from the printable ASCII character set (95 chars), with reasonably long salts)

  • modern hardware and speeds are fair game

  • the hash algorithm may or may not be parallelism-friendly


Given all of the above, I'd roughly expect:




  • The 1x9 hash would be 100% exhausted in 95^9 (6.302 × 10^17) hashing operations (which might be parallelized well or poorly).

  • The 2x8 hashes would be jointly 100% exhausted in (95^8)x2 (1.326 × 10^16) hashing operations (and no matter the algorithm, could easily be naively parallelized simply by cracking each hash on a different system - but can often be parallelized very efficiently on a single system as well, depending on the algorithm).


In other words:




  • that 9th character adds 95 times the work to exhaust, and might be hard to parallelize

  • Two 8-character passwords only doubles the amount of work needed, and can be trivially parallelized


Another way to think about it is that adding one more character roughly creates the same work as having to crack 95 8-character passwords! (If this isn't intuitive, start with simple cases comparing smaller cases like 1x1 vs 1x2, until you understand it).



So all other things being equal, 1x9 should almost always be better than 2x8.



And really, this is not only a simple illustration of the power of parallelization, it should also make it obvious why allowing longer password lengths is so crucial. Each additional character in the model above adds 95 times work to the overall keyspace. So adding two characters adds 95^2 - or 9025 times - the work. Brute force quickly becomes infeasible, even for very fast and unsalted hashes.



This would make an excellent homework question. ;)






share|improve this answer















As John Deters has noted, 2x8 is almost certainly worse - but the reasons why take a little explaining.



There were a couple of problems with LANMAN hashes (the classic case of breaking a password in half):




  • Since passwords tend to be human-generated and somewhat short, if a single password was only a little longer than the first half (say, 8 characters), then cracking the second half would take dramatically less time - and could even give away what the first half was likely to be)


  • LANMAN was just so darned fast (for the attacker to attempt, in hash operations per second)


  • LANMAN cut the passwords in two at an unfortunate length (7), that was quite susceptible to full exhaustion (and even moreso on modern GPUs)



However, your question is a little different from the LANMAN case, for a couple of reasons:




  • it does not state that the 2x8 passwords are actually a single password broken in half (they could be independently generated, and random)

  • it explicitly states that the two passwords are of length 8 (rather than, say, one of length 8 and the other of length 1, the famous LANMAN worst case)

  • the question would be uninteresting if the passwords were human-generated, (because in practice they would usually fall to easy attacks long before the attacker would have to resort to brute force)

  • unless your salts are trivially small, building rainbow tables would be infeasible, which is the purpose of salting (unlike LANMAN hashes, which were entirely unsalted)


So it's an interesting question - one that's largely answered by looking at the associated math.



For the sake of the thought experiment, let's make some assumptions:




  • both the 9x1 and 8x2 approaches are salted and hashed using the same
    salt lengths and algorithms

  • worst case for the attacker (the passwords are randomly generated from the printable ASCII character set (95 chars), with reasonably long salts)

  • modern hardware and speeds are fair game

  • the hash algorithm may or may not be parallelism-friendly


Given all of the above, I'd roughly expect:




  • The 1x9 hash would be 100% exhausted in 95^9 (6.302 × 10^17) hashing operations (which might be parallelized well or poorly).

  • The 2x8 hashes would be jointly 100% exhausted in (95^8)x2 (1.326 × 10^16) hashing operations (and no matter the algorithm, could easily be naively parallelized simply by cracking each hash on a different system - but can often be parallelized very efficiently on a single system as well, depending on the algorithm).


In other words:




  • that 9th character adds 95 times the work to exhaust, and might be hard to parallelize

  • Two 8-character passwords only doubles the amount of work needed, and can be trivially parallelized


Another way to think about it is that adding one more character roughly creates the same work as having to crack 95 8-character passwords! (If this isn't intuitive, start with simple cases comparing smaller cases like 1x1 vs 1x2, until you understand it).



So all other things being equal, 1x9 should almost always be better than 2x8.



And really, this is not only a simple illustration of the power of parallelization, it should also make it obvious why allowing longer password lengths is so crucial. Each additional character in the model above adds 95 times work to the overall keyspace. So adding two characters adds 95^2 - or 9025 times - the work. Brute force quickly becomes infeasible, even for very fast and unsalted hashes.



This would make an excellent homework question. ;)







share|improve this answer














share|improve this answer



share|improve this answer








edited 39 mins ago

























answered 2 hours ago









Royce WilliamsRoyce Williams

5,31211641




5,31211641













  • Agreed with your conclusion. I would of explained this in a very similar manner.

    – Overmind
    8 mins ago



















  • Agreed with your conclusion. I would of explained this in a very similar manner.

    – Overmind
    8 mins ago

















Agreed with your conclusion. I would of explained this in a very similar manner.

– Overmind
8 mins ago





Agreed with your conclusion. I would of explained this in a very similar manner.

– Overmind
8 mins ago










Carlos is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















Carlos is a new contributor. Be nice, and check out our Code of Conduct.













Carlos is a new contributor. Be nice, and check out our Code of Conduct.












Carlos is a new contributor. Be nice, and check out our Code of Conduct.
















Thanks for contributing an answer to Information Security Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204450%2fwhich-one-of-these-password-policies-are-more-secure%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Can't compile dgruyter and caption packagesLaTeX templates/packages for writing a patent specificationLatex...

Schneeberg (Smreczany) Bibliografia | Menu...

Hans Bellmer Spis treści Życiorys | Upamiętnienie | Przypisy | Bibliografia | Linki zewnętrzne |...