 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/08/2011 3:27 AM, Chambers wrote:
>
> Correctly demonstrates that the important facet is the sheer length of
> the password :)
How about using a phrase in dialect, such as?
Fit like ma quine?
which is an easily remembered greeting if you've ever been to Aberdeen.
It translates to: How are you my young woman?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 11/08/2011 21:36, Jim Henderson a écrit :
> On Thu, 11 Aug 2011 19:27:17 +0100, Orchid XP v8 wrote:
>> On the other hand, salting the password trivially defeats rainbow
>> tables.
>
> Sure, but how many password systems don't use a salt value?
Are you aware that some current glibc2 version of crypt can move away
from the traditional one way function (DES) with a salt of 2 chars to
use an alternative hashing algorithm (MD5/blowfish/sha-256/sha-512) with
a salt in [a-zA-Z0-9./] of 16 chars (instead of 2).
There is also a pitfall: only SHA-* take into account the whole password
(MD5 stops at 8 chars, as does classical DES).
So, yes, "correct horse battery stapple" is a strong password on a
recent system which use sha.
But it is damn weak on an old system, where it get truncated to "correct
". (dictionnary attack, word +space, an easy rule)
The extended salt of MD5 is better against the rainbow book (DES rainbow
book are very short with only 2 chars of salt), but it is still
vulnerable to "correct " discovery.
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 12/08/2011 08:45, Le_Forgeron a écrit :
> (MD5 stops at 8 chars, as does classical DES).
on some versions... MD5 seems fixed on latest implementation (no more 8
char limitation)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So in other words, you'd test your passwords offline before choosing them.
Yeah, pretty much.
>>>> 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.
The purpose of salt is to defeat rainbow tables. Therefore, the only
thing that matters is that the salt is an arbitrary random string which
is unlikely to appear in a rainbow table. (E.g., raw binary instead of
ASCII.) Doesn't matter how predictable it is, so long as it's not
predictable enough to be in a rainbow table. (And it's different for
every password in the database.)
This was Tom's argument. Since (in one prospective design) the database
table stores, username, password and salt right next to each other, he
argued that the salt provides to added security. But in fact it does: It
means you can't reuse the work of cracking password #1 to crack password
#2, #3, #4, etc. faster. You have to do it the long way around.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So in other words, you'd test your passwords offline before choosing them.
I'm actually tempted to go take a password cracker to our network and
see how quickly it can guess everybody's passwords. >:-D
Unfortunately, I downloaded the cracker do I could go try it in a test
environment, and the AV software went mental...
(Obviously, before you try breaking people's passwords "for real", there
are various political issues to consider. But I didn't even get as far
as /testing/ the tool, since the AV classes it as "greyware". Which I
suppose is reasonable.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Aug 2011 08:45:30 +0200, Le_Forgeron wrote:
> Are you aware that some current glibc2 version of crypt can move away
> from the traditional one way function (DES) with a salt of 2 chars to
> use an alternative hashing algorithm (MD5/blowfish/sha-256/sha-512) with
> a salt in [a-zA-Z0-9./] of 16 chars (instead of 2).
>
> There is also a pitfall: only SHA-* take into account the whole password
> (MD5 stops at 8 chars, as does classical DES).
>
> So, yes, "correct horse battery stapple" is a strong password on a
> recent system which use sha.
> But it is damn weak on an old system, where it get truncated to "correct
> ". (dictionnary attack, word +space, an easy rule)
>
> The extended salt of MD5 is better against the rainbow book (DES rainbow
> book are very short with only 2 chars of salt), but it is still
> vulnerable to "correct " discovery.
I wasn't aware of the glibc2 issue - but I was aware of how passwords can
be truncated. I ran into an issue years ago with a 20-character password
I used to use on Windows (XP, I think it was, or maybe Win2K). The
password routines on that version of Windows would trucate the password
to 14 characters (IIRC) and generate a hash when setting the password,
but then would generate the hash with the full password length when
verifying the password.
End result was that if you set a password to > 14 characters, Windows
would silently do it and not tell you it was truncating it, and then if
you tried to login with the full password, a different hash would be
generated and you wouldn't be able to log in.
ISTR that, even worse, something in the algorithm meant you couldn't just
enter the first 14 characters of the password and get in - almost as if
the salt value was based on the original length or something like that.
Basically, you'd have to hack your way in, login as administrator and
change the password, or rebuild the system (depending on the
authentication model).
Kinda nasty.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Aug 2011 09:00:27 +0100, Invisible wrote:
>> So in other words, you'd test your passwords offline before choosing
>> them.
>
> Yeah, pretty much.
>
>>>>> 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.
>
> The purpose of salt is to defeat rainbow tables. Therefore, the only
> thing that matters is that the salt is an arbitrary random string which
> is unlikely to appear in a rainbow table. (E.g., raw binary instead of
> ASCII.) Doesn't matter how predictable it is, so long as it's not
> predictable enough to be in a rainbow table. (And it's different for
> every password in the database.)
It can't be arbitrarily random, though, because the salt value is
necessary to compute the hash. Give it the wrong salt, and the value
that comes back is wrong.
> This was Tom's argument. Since (in one prospective design) the database
> table stores, username, password and salt right next to each other, he
> argued that the salt provides to added security. But in fact it does: It
> means you can't reuse the work of cracking password #1 to crack password
> #2, #3, #4, etc. faster. You have to do it the long way around.
Oh, true, if you use a salt value that progresses, but the sequence still
has to be predictable (at least as I understand it).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
