Which one of these password policies is more secure?How to securely hash passwords?Why is using salt more...
Can a person refuse a presidential pardon?
How to say "Brexit" in Latin?
Is the set of language decidable by some Turing machine computing in some given computable time bound decidable
Why is working on the same position for more than 15 years not a red flag?
Graph with overlapping labels
Why has the mole been redefined for 2019?
A title for a history book
Citing paywalled articles accessed via illegal web sharing
How to deal with an incendiary email that was recalled
How can I get my players to come to the game session after agreeing to a date?
Difference between i++ and (i)++ in C
How long is the D&D Starter Set campaign?
Am I a Rude Number?
Is boss over stepping boundary/micromanaging?
The weather forecast
Advice for a new journal editor
Replacement expressions
Traveling through the asteriod belt?
IGBT transistor with auxiliary emitter
What incentives do banks have to gather up loans into pools (backed by Ginnie Mae)and selling them?
One Half of Ten; A Riddle
Early credit roll before the end of the film
Do authors have to be politically correct in article-writing?
Which one of these password policies is more secure?
Which one of these password policies is more secure?
How to securely hash passwords?Why is using salt more secure?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
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
New contributor
|
show 1 more comment
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
New contributor
3
You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…
– Polynomial
14 hours ago
30
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
13 hours ago
3
Obligatory xkcd
– T.J. Crowder
9 hours ago
5
Option 3: a single 16 character password, using a modern password hash with salting built in (e.g, bcrypt). Assuming the password is randomly generated, of course.
– jpmc26
6 hours ago
@RoyceWilliams so...we should be using salted hashes, but they should be known to be secure (e.g., bcrypt) , as opposed to either known to be weak (e.g., MD5) or unknown to be secure (self-rolled algorithm). Is that what I should take "you shouldn't be using salted hashes" as? Because if so, I have trouble understanding the advice. Sure, it makes sense but it's not new and doesn't exactly match the question.
– VLAZ
38 mins ago
|
show 1 more comment
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
New contributor
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
passwords password-management password-policy
New contributor
New contributor
edited 11 mins ago
scohe001
1206
1206
New contributor
asked 15 hours ago
CarlosCarlos
4112
4112
New contributor
New contributor
3
You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…
– Polynomial
14 hours ago
30
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
13 hours ago
3
Obligatory xkcd
– T.J. Crowder
9 hours ago
5
Option 3: a single 16 character password, using a modern password hash with salting built in (e.g, bcrypt). Assuming the password is randomly generated, of course.
– jpmc26
6 hours ago
@RoyceWilliams so...we should be using salted hashes, but they should be known to be secure (e.g., bcrypt) , as opposed to either known to be weak (e.g., MD5) or unknown to be secure (self-rolled algorithm). Is that what I should take "you shouldn't be using salted hashes" as? Because if so, I have trouble understanding the advice. Sure, it makes sense but it's not new and doesn't exactly match the question.
– VLAZ
38 mins ago
|
show 1 more comment
3
You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…
– Polynomial
14 hours ago
30
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
13 hours ago
3
Obligatory xkcd
– T.J. Crowder
9 hours ago
5
Option 3: a single 16 character password, using a modern password hash with salting built in (e.g, bcrypt). Assuming the password is randomly generated, of course.
– jpmc26
6 hours ago
@RoyceWilliams so...we should be using salted hashes, but they should be known to be secure (e.g., bcrypt) , as opposed to either known to be weak (e.g., MD5) or unknown to be secure (self-rolled algorithm). Is that what I should take "you shouldn't be using salted hashes" as? Because if so, I have trouble understanding the advice. Sure, it makes sense but it's not new and doesn't exactly match the question.
– VLAZ
38 mins ago
3
3
You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…
– Polynomial
14 hours ago
You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…
– Polynomial
14 hours ago
30
30
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
13 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
13 hours ago
3
3
Obligatory xkcd
– T.J. Crowder
9 hours ago
Obligatory xkcd
– T.J. Crowder
9 hours ago
5
5
Option 3: a single 16 character password, using a modern password hash with salting built in (e.g, bcrypt). Assuming the password is randomly generated, of course.
– jpmc26
6 hours ago
Option 3: a single 16 character password, using a modern password hash with salting built in (e.g, bcrypt). Assuming the password is randomly generated, of course.
– jpmc26
6 hours ago
@RoyceWilliams so...we should be using salted hashes, but they should be known to be secure (e.g., bcrypt) , as opposed to either known to be weak (e.g., MD5) or unknown to be secure (self-rolled algorithm). Is that what I should take "you shouldn't be using salted hashes" as? Because if so, I have trouble understanding the advice. Sure, it makes sense but it's not new and doesn't exactly match the question.
– VLAZ
38 mins ago
@RoyceWilliams so...we should be using salted hashes, but they should be known to be secure (e.g., bcrypt) , as opposed to either known to be weak (e.g., MD5) or unknown to be secure (self-rolled algorithm). Is that what I should take "you shouldn't be using salted hashes" as? Because if so, I have trouble understanding the advice. Sure, it makes sense but it's not new and doesn't exactly match the question.
– VLAZ
38 mins ago
|
show 1 more comment
4 Answers
4
active
oldest
votes
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, gone awry):
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:
- 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)
- 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.
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. (The question would be less interesting 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)
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 eight-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. ;)
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
1
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a1
replaced by a2
.
– Federico Poloni
5 hours ago
add a comment |
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.
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
13 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 hours ago
add a comment |
Starting from math point of view ...
(to simplify calculation I assume only digit passwords)
Situation A: 2 parts 8 digit password,
'bruteforce attack on part one require max 10^8 hashes, same for part. Total of max 2*10^8 hashes required '
Situation B: 1 part 9 digit password,
'bruteforce attack require max 10^9 hashes'
Math say that's B is better than A
New contributor
add a comment |
No meaningful answer is possible without knowing what your threat scenario is. What are you trying to protect against? Are you worried about brute force or hash cracking? In the first case, we need to know your login procedure (e.g. do I enter the passwords sequentially or in parallel?). Also, if your login procedure doesn't lock me out after thousands or millions of failed login attempts, it is broken. That's not a question of password strength.
What about users writing things down? Shoulder surfing? Phishing? What's the model behind the passwords?
There are legitimate uses of two passwords, for example one read-access password and a seperate change-enable password. I doubt you have that in mind because of your 9-letter password alternative, just throwing that out there to show that reality is more complicated than an academic question on password strength based only on length.
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204450%2fwhich-one-of-these-password-policies-is-more-secure%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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, gone awry):
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:
- 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)
- 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.
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. (The question would be less interesting 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)
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 eight-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. ;)
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
1
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a1
replaced by a2
.
– Federico Poloni
5 hours ago
add a comment |
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, gone awry):
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:
- 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)
- 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.
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. (The question would be less interesting 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)
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 eight-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. ;)
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
1
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a1
replaced by a2
.
– Federico Poloni
5 hours ago
add a comment |
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, gone awry):
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:
- 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)
- 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.
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. (The question would be less interesting 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)
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 eight-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. ;)
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, gone awry):
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:
- 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)
- 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.
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. (The question would be less interesting 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)
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 eight-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. ;)
edited 1 hour ago
answered 12 hours ago
Royce WilliamsRoyce Williams
5,48211642
5,48211642
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
1
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a1
replaced by a2
.
– Federico Poloni
5 hours ago
add a comment |
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
1
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a1
replaced by a2
.
– Federico Poloni
5 hours ago
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
Agreed with your conclusion. I would of explained this in a very similar manner.
– Overmind
10 hours ago
1
1
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a
1
replaced by a 2
.– Federico Poloni
5 hours ago
If the 2x8 passwords are human-generated, there are good chances that the second one is just the first one with a
1
replaced by a 2
.– Federico Poloni
5 hours ago
add a comment |
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.
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
13 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 hours ago
add a comment |
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.
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
13 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 hours ago
add a comment |
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.
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.
answered 15 hours ago
John DetersJohn Deters
27.8k24191
27.8k24191
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
13 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 hours ago
add a comment |
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
13 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 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
13 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
13 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 hours ago
Er, unless it was a trivially weak (short) salt. :)
– Royce Williams
12 hours ago
add a comment |
Starting from math point of view ...
(to simplify calculation I assume only digit passwords)
Situation A: 2 parts 8 digit password,
'bruteforce attack on part one require max 10^8 hashes, same for part. Total of max 2*10^8 hashes required '
Situation B: 1 part 9 digit password,
'bruteforce attack require max 10^9 hashes'
Math say that's B is better than A
New contributor
add a comment |
Starting from math point of view ...
(to simplify calculation I assume only digit passwords)
Situation A: 2 parts 8 digit password,
'bruteforce attack on part one require max 10^8 hashes, same for part. Total of max 2*10^8 hashes required '
Situation B: 1 part 9 digit password,
'bruteforce attack require max 10^9 hashes'
Math say that's B is better than A
New contributor
add a comment |
Starting from math point of view ...
(to simplify calculation I assume only digit passwords)
Situation A: 2 parts 8 digit password,
'bruteforce attack on part one require max 10^8 hashes, same for part. Total of max 2*10^8 hashes required '
Situation B: 1 part 9 digit password,
'bruteforce attack require max 10^9 hashes'
Math say that's B is better than A
New contributor
Starting from math point of view ...
(to simplify calculation I assume only digit passwords)
Situation A: 2 parts 8 digit password,
'bruteforce attack on part one require max 10^8 hashes, same for part. Total of max 2*10^8 hashes required '
Situation B: 1 part 9 digit password,
'bruteforce attack require max 10^9 hashes'
Math say that's B is better than A
New contributor
New contributor
answered 4 hours ago
WaltZieWaltZie
1792
1792
New contributor
New contributor
add a comment |
add a comment |
No meaningful answer is possible without knowing what your threat scenario is. What are you trying to protect against? Are you worried about brute force or hash cracking? In the first case, we need to know your login procedure (e.g. do I enter the passwords sequentially or in parallel?). Also, if your login procedure doesn't lock me out after thousands or millions of failed login attempts, it is broken. That's not a question of password strength.
What about users writing things down? Shoulder surfing? Phishing? What's the model behind the passwords?
There are legitimate uses of two passwords, for example one read-access password and a seperate change-enable password. I doubt you have that in mind because of your 9-letter password alternative, just throwing that out there to show that reality is more complicated than an academic question on password strength based only on length.
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
add a comment |
No meaningful answer is possible without knowing what your threat scenario is. What are you trying to protect against? Are you worried about brute force or hash cracking? In the first case, we need to know your login procedure (e.g. do I enter the passwords sequentially or in parallel?). Also, if your login procedure doesn't lock me out after thousands or millions of failed login attempts, it is broken. That's not a question of password strength.
What about users writing things down? Shoulder surfing? Phishing? What's the model behind the passwords?
There are legitimate uses of two passwords, for example one read-access password and a seperate change-enable password. I doubt you have that in mind because of your 9-letter password alternative, just throwing that out there to show that reality is more complicated than an academic question on password strength based only on length.
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
add a comment |
No meaningful answer is possible without knowing what your threat scenario is. What are you trying to protect against? Are you worried about brute force or hash cracking? In the first case, we need to know your login procedure (e.g. do I enter the passwords sequentially or in parallel?). Also, if your login procedure doesn't lock me out after thousands or millions of failed login attempts, it is broken. That's not a question of password strength.
What about users writing things down? Shoulder surfing? Phishing? What's the model behind the passwords?
There are legitimate uses of two passwords, for example one read-access password and a seperate change-enable password. I doubt you have that in mind because of your 9-letter password alternative, just throwing that out there to show that reality is more complicated than an academic question on password strength based only on length.
No meaningful answer is possible without knowing what your threat scenario is. What are you trying to protect against? Are you worried about brute force or hash cracking? In the first case, we need to know your login procedure (e.g. do I enter the passwords sequentially or in parallel?). Also, if your login procedure doesn't lock me out after thousands or millions of failed login attempts, it is broken. That's not a question of password strength.
What about users writing things down? Shoulder surfing? Phishing? What's the model behind the passwords?
There are legitimate uses of two passwords, for example one read-access password and a seperate change-enable password. I doubt you have that in mind because of your 9-letter password alternative, just throwing that out there to show that reality is more complicated than an academic question on password strength based only on length.
answered 8 hours ago
TomTom
5,353831
5,353831
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
add a comment |
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
Thought-provoking! And another interesting use case for two passwords: increased resistance to insider threat (requiring two people to collude in order to use the system).
– Royce Williams
1 hour ago
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204450%2fwhich-one-of-these-password-policies-is-more-secure%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
3
You should not be using salted hashes in 2019. See security.stackexchange.com/questions/211/… and security.stackexchange.com/questions/193351/…
– Polynomial
14 hours ago
30
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
13 hours ago
3
Obligatory xkcd
– T.J. Crowder
9 hours ago
5
Option 3: a single 16 character password, using a modern password hash with salting built in (e.g, bcrypt). Assuming the password is randomly generated, of course.
– jpmc26
6 hours ago
@RoyceWilliams so...we should be using salted hashes, but they should be known to be secure (e.g., bcrypt) , as opposed to either known to be weak (e.g., MD5) or unknown to be secure (self-rolled algorithm). Is that what I should take "you shouldn't be using salted hashes" as? Because if so, I have trouble understanding the advice. Sure, it makes sense but it's not new and doesn't exactly match the question.
– VLAZ
38 mins ago