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

On Fri, 12 Aug 2011 12:21:06 +0100, Invisible wrote:

>> 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.)

Indeed, the proper way to do this in a production environment is to get 
the approval of management so they know what you're doing and why.  It's 
a 'security audit' or 'password audit'.  You don't want to get caught 
doing any kind of penetration testing on your company's network without 
TPTB being aware of it - that can lead to serious consequences 
(potentially personal legal liabilities for that matter).

Jim

Post a reply to this message

>> (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.)
>
> Indeed, the proper way to do this in a production environment is to get
> the approval of management so they know what you're doing and why.  It's
> a 'security audit' or 'password audit'.  You don't want to get caught
> doing any kind of penetration testing on your company's network without
> TPTB being aware of it - that can lead to serious consequences
> (potentially personal legal liabilities for that matter).

Sure. But first I wanted to check whether the tool I've picked actually 
/works/, and have a bit of a play around with it. /Then/ I might see 
about using it on real passwords...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> 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.

Which is why you store the salt you used along with the password. That 
way, any time you need to compare the hash, you know what salt to use.

The salt doesn't need to be "secret" at all. It's only there so that 
each user's password hashes a different way, and so you can't use a 
rainbow table on the whole database.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message