 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I thought this was funny, since there was the recent discussion on
password strength...
http://xkcd.com/936/
Correctly demonstrates that the important facet is the sheer length of
the password :)
(Assuming that the person trying to crack it doesn't take a stab at
solving for combinations of simple words like this before they go brute
force on your a**)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/08/2011 03:27 AM, Chambers wrote:
> I thought this was funny, since there was the recent discussion on
> password strength...
>
> http://xkcd.com/936/
People on the XKCD forums have posted links to several online "password
strength meters". These are mostly of the type where you get a +10 point
bonus for using uppercase and lowercase, but a -N penalty for every N
consecutive characters of the same type, but then there's also a score
for...
Personally, I think the most /realistic/ way to gauge password strength
is to see how long it takes real, commonly-available password crackers
to break your password. After all, /that/ is what most unsophisticated
attackers are going to use against you.
> Correctly demonstrates that the important facet is the sheer length of
> the password :)
>
> (Assuming that the person trying to crack it doesn't take a stab at
> solving for combinations of simple words like this before they go brute
> force on your a**)
This assumption is unnecessary. That's the point.
People have banded around the figure of "8,000 words" as a typical
English vocabulary. I have no idea whether that's correct or not. (It
varies wildly depending on what you count as a "word".) That means that
if your password is, literally, a word, an attacker has 8,000
combinations to try. This is trivial.
If your password is 4 words, an attacker now has 8,000^4 =
4,096,000,000,000,000 combinations to try (again, still assuming that
they /know/ they only need to check combinations of common dictionary
words). That's 4 quadrillion 97 trillion. This is going to take
drastically longer. Assuming you can check one million combinations per
second, that's about 130 years. (Assuming the same speed, 8,000
combinations would take less than 1 second.)
As I recently wrote, this is the utterly counter-intuitive thing about
combinatorics. The exponential function works in such a way that X
digits can be trivially crackable, but X+Y, where Y is a fairly small
number, can be utterly infeasible to crack.
Now, if instead of 1 computer, you had 130, then the password would only
take 1 year to crack, instead of over a century...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/08/2011 09:09 AM, Invisible wrote:
> If your password is 4 words, an attacker now has 8,000^4 =
> 4,096,000,000,000,000 combinations to try.
Alternatively, if we assume that none of the words are repeated (let's
face it, humans aren't that random), the number of combinations falls to
"only" 4,092,928,703,952,000. That makes the cracking attempt several
months faster. But, given that we're talking about something that takes
over a /century/, a few months is nothing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/08/2011 09:09 AM, Invisible wrote:
> As I recently wrote, this is the utterly counter-intuitive thing about
> combinatorics. The exponential function works in such a way that X
> digits can be trivially crackable, but X+Y, where Y is a fairly small
> number, can be utterly infeasible to crack.
Number of common | Number of combinations | Crack time at
dictionary words | | 10^6 guesses / second
-----------------+------------------------+-------------------------
1 | 8,000 | ~8 milliseconds
2 | 64,000,000 | ~1 minute
3 | 512,000,000,000 | ~6 days
4 | 4,069,000,000,000,000 | ~130 years
5 | ###################### | ~1.039 million years
So a 1-word password is trivially breakable, 2 is trivial, 3 is vaguely
challenging (for one desktop PC), and 4 is for all intents and purposes
unbreakable unless you have a fairly large quantity of hardware and/or
unusually fast hardware. 5 is probably unbreakable no matter what
hardware you have.
It's quite surprising that a 2-word password is weak as hell, and yet a
4-word password is really very strong. You would have thought it would
require a 20-word password or something to get good security...
All of these calculations of course assume that the words involved are
/truly random/. If they're picked by a human, they aren't random. For
example "correct horse battery staple" is almost all nouns. Words like
"dog" are far more likely to be picked than "sifaka". (It's a kind of
lemur. Go look it up.)
You could probably do some sort of statistical analysis to order the
search in terms of more common words first, and it would probably go
much, much faster.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <Ben### [at] geemail com> wrote:
> I thought this was funny, since there was the recent discussion on
> password strength...
>
> http://xkcd.com/936/
>
> Correctly demonstrates that the important facet is the sheer length of
> the password :)
>
> (Assuming that the person trying to crack it doesn't take a stab at
> solving for combinations of simple words like this before they go brute
> force on your a**)
>
> ...Chambers
This is both true and helpful. Thank you.
As it happens, it is also suggestive of a prank in which the user is given a
series of "randomly" chosen common words to use as a password. This is presented
along with a brief explanation of the mathematics of password length like the
one in the link to make the whole thing sound serious and plausible. The user is
then encouraged to memorize the word sequence by repeating it aloud several
times.
Something like: "EYE YAM SEW WHEAT HEART DEAD"
There is a much ruder version (NOT suggested for office use) where "SEW" is
replaced by synonyms for /couch/ and /monarch/.
Perhaps *I* could be given the sequence:
"MICE HENNA TEA EASE INK WEST SHUN" ;-)
Best Regards,
Mike C.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 11 Aug 2011 09:09:01 +0100, Invisible wrote:
> Personally, I think the most /realistic/ way to gauge password strength
> is to see how long it takes real, commonly-available password crackers
> to break your password. After all, /that/ is what most unsophisticated
> attackers are going to use against you.
Arguably that's the most accurate way, but not the most realistic way.
It wouldn't be realistic to run a prospective password through each one
of those tools when setting the password.
In addition, if you've got rainbow tables-based cracking, as long as the
tables extend to the length of the password (and take into account the
appropriate factors for the password algorithm, naturally), then the
cracking time is linear no matter what the complexity of the password is
- which would be both unrealistic and inaccurate as a measure, because
the hashes are precomputed.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/08/2011 07:17 PM, Jim Henderson wrote:
> On Thu, 11 Aug 2011 09:09:01 +0100, Invisible wrote:
>
>> Personally, I think the most /realistic/ way to gauge password strength
>> is to see how long it takes real, commonly-available password crackers
>> to break your password. After all, /that/ is what most unsophisticated
>> attackers are going to use against you.
>
> Arguably that's the most accurate way, but not the most realistic way.
> It wouldn't be realistic to run a prospective password through each one
> of those tools when setting the password.
You don't think so?
I think that if you type a password and a cracker can guess it in under
30 seconds, you should definitely pick a different password. But maybe
that's just me...
> In addition, if you've got rainbow tables-based cracking, as long as the
> tables extend to the length of the password (and take into account the
> appropriate factors for the password algorithm, naturally), then the
> cracking time is linear no matter what the complexity of the password is
> - which would be both unrealistic and inaccurate as a measure, because
> the hashes are precomputed.
On the other hand, salting the password trivially defeats rainbow tables.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 11 Aug 2011 19:27:17 +0100, Orchid XP v8 wrote:
> On 11/08/2011 07:17 PM, Jim Henderson wrote:
>> On Thu, 11 Aug 2011 09:09:01 +0100, Invisible wrote:
>>
>>> Personally, I think the most /realistic/ way to gauge password
>>> strength is to see how long it takes real, commonly-available password
>>> crackers to break your password. After all, /that/ is what most
>>> unsophisticated attackers are going to use against you.
>>
>> Arguably that's the most accurate way, but not the most realistic way.
>> It wouldn't be realistic to run a prospective password through each one
>> of those tools when setting the password.
>
> You don't think so?
>
> I think that if you type a password and a cracker can guess it in under
> 30 seconds, you should definitely pick a different password. But maybe
> that's just me...
You said "password crackers" (plural). You might have noticed, but users
aren't exactly patient about things. If it takes all these tools 20
minutes to decide the password is secure enough, they'll be complaining
to you that their system hung when they changed their password.
>> In addition, if you've got rainbow tables-based cracking, as long as
>> the tables extend to the length of the password (and take into account
>> the appropriate factors for the password algorithm, naturally), then
>> the cracking time is linear no matter what the complexity of the
>> password is - which would be both unrealistic and inaccurate as a
>> measure, because the hashes are precomputed.
>
> On the other hand, salting the password trivially defeats rainbow
> tables.
Sure, but how many password systems don't use a salt value?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Arguably that's the most accurate way, but not the most realistic way.
>>> It wouldn't be realistic to run a prospective password through each one
>>> of those tools when setting the password.
>>
>> You don't think so?
>>
>> I think that if you type a password and a cracker can guess it in under
>> 30 seconds, you should definitely pick a different password. But maybe
>> that's just me...
>
> You said "password crackers" (plural). You might have noticed, but users
> aren't exactly patient about things. If it takes all these tools 20
> minutes to decide the password is secure enough, they'll be complaining
> to you that their system hung when they changed their password.
Oh, I see.
Well, yes, the average user doesn't give a fig how secure their password
is, only how difficult it is to remember. I was thinking more of people
who *do* care about such things.
>> On the other hand, salting the password trivially defeats rainbow
>> tables.
>
> Sure, but how many password systems don't use a salt value?
Well, that's true enough, sadly...
(I still remember having a 25-post discussion with Tom Kyte about this.
He still fails to see why salt is useful.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 11 Aug 2011 20:47:40 +0100, Orchid XP v8 wrote:
>> You said "password crackers" (plural). You might have noticed, but
>> users aren't exactly patient about things. If it takes all these tools
>> 20 minutes to decide the password is secure enough, they'll be
>> complaining to you that their system hung when they changed their
>> password.
>
> Oh, I see.
>
> Well, yes, the average user doesn't give a fig how secure their password
> is, only how difficult it is to remember. I was thinking more of people
> who *do* care about such things.
So in other words, you'd test your passwords offline before choosing them.
>>> On the other hand, salting the password trivially defeats rainbow
>>> tables.
>>
>> Sure, but how many password systems don't use a salt value?
>
> Well, that's true enough, sadly...
>
> (I still remember having a 25-post discussion with Tom Kyte about this.
> He still fails to see why salt is useful.)
Salt is useful only if the way in which it's selected is useful. If the
salt value is predictable or easily determined, then it's not so useful.
But of course the salt value has to be predictable and easy for the
system to determine, otherwise (of course), you couldn't properly salt
the hash, and you'd end up with a mismatch on the result.
One of the more creative salt values I've seen used is the password
length. It's always predictable and easy to determine if you have the
password, but if you have the password, you don't need to determine the
salt value (duh).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
