 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Aug 2011 18:18:00 +0100, Orchid XP v8 wrote:
>>> (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...
That's what a lab server is for (ie, a server in an IT lab, not a server
in the lab you work for <g>).
You might have to disable the AV software, since it's 'greyware' (that's
a term I've not heard before, but presumably it means 'this is a hacking
tool', to which one might say 'well, duh!').
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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...
>
> That's what a lab server is for (ie, a server in an IT lab, not a server
> in the lab you work for<g>).
That's what VMware is for. ;-)
> You might have to disable the AV software, since it's 'greyware' (that's
> a term I've not heard before, but presumably it means 'this is a hacking
> tool', to which one might say 'well, duh!').
I'm guessing if I boot up a Linux VM and ask it to install the Linux
version of the tool, the AV won't know what just hit it. (I don't think
it scans network traffic, only actual files. On the other hand, maybe it
will recognise the data in the disk image? But on the first hand, I
doubt it scans for Linux threats, only Windows ones...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 12 Aug 2011 19:29:03 +0100, Orchid XP v8 wrote:
>>> 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...
>>
>> That's what a lab server is for (ie, a server in an IT lab, not a
>> server in the lab you work for<g>).
>
> That's what VMware is for. ;-)
You're learning. I remember not too long ago when you thought what VMware
did was impossible so not worth even trying out. ;) And yes, VMware does
make an excellent lab environment.
>> You might have to disable the AV software, since it's 'greyware'
>> (that's a term I've not heard before, but presumably it means 'this is
>> a hacking tool', to which one might say 'well, duh!').
>
> I'm guessing if I boot up a Linux VM and ask it to install the Linux
> version of the tool, the AV won't know what just hit it. (I don't think
> it scans network traffic, only actual files. On the other hand, maybe it
> will recognise the data in the disk image? But on the first hand, I
> doubt it scans for Linux threats, only Windows ones...)
Yeah, that would probably work as well.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> That's what VMware is for. ;-)
>
> You're learning. I remember not too long ago when you thought what VMware
> did was impossible so not worth even trying out. ;) And yes, VMware does
> make an excellent lab environment.
I still find it surprising that VMware manages to run software at nearly
native speed. Other emulators I've seen are way, way slower...
It still amuses me that I can run Linux under QEMU, and it's *still*
fast enough to run DOOM with software rendering. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 13 Aug 2011 10:41:56 +0100, Orchid XP v8 wrote:
>>> That's what VMware is for. ;-)
>>
>> You're learning. I remember not too long ago when you thought what
>> VMware did was impossible so not worth even trying out. ;) And yes,
>> VMware does make an excellent lab environment.
>
> I still find it surprising that VMware manages to run software at nearly
> native speed. Other emulators I've seen are way, way slower...
VMware doesn't emulate, that's a big difference. The code runs natively
in many/most cases.
> It still amuses me that I can run Linux under QEMU, and it's *still*
> fast enough to run DOOM with software rendering. ;-)
Computers are pretty speedy these days.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I still find it surprising that VMware manages to run software at nearly
>> native speed. Other emulators I've seen are way, way slower...
>
> VMware doesn't emulate, that's a big difference. The code runs natively
> in many/most cases.
...until it performs any kind of kernel-mode operation, presumably.
(Which would be ALL THE TIME, more or less.)
>> It still amuses me that I can run Linux under QEMU, and it's *still*
>> fast enough to run DOOM with software rendering. ;-)
>
> Computers are pretty speedy these days.
That's my point, yes. ;-)
The old POV-Ray benchmark (skyvase.pov) used to take /hours/ to run,
unless you had a cluster. Today it can be run in a few split seconds.
It's so fast it's useless as a benchmark. Now that's progress...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 15 Aug 2011 09:21:42 +0100, Invisible wrote:
>>> I still find it surprising that VMware manages to run software at
>>> nearly native speed. Other emulators I've seen are way, way slower...
>>
>> VMware doesn't emulate, that's a big difference. The code runs
>> natively in many/most cases.
>
> ...until it performs any kind of kernel-mode operation, presumably.
> (Which would be ALL THE TIME, more or less.)
Ring 0 has to be emulated, yes, but with various hypervisors implemented
in hardware now, that "emulation" is done by hardware.
>>> It still amuses me that I can run Linux under QEMU, and it's *still*
>>> fast enough to run DOOM with software rendering. ;-)
>>
>> Computers are pretty speedy these days.
>
> That's my point, yes. ;-)
>
> The old POV-Ray benchmark (skyvase.pov) used to take /hours/ to run,
> unless you had a cluster. Today it can be run in a few split seconds.
> It's so fast it's useless as a benchmark. Now that's progress...
Indeed it is.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/11/2011 11:17, 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.
> Arguably that's the most accurate way, but not the most realistic way.
However, I know a number of corporations that will try to crack your
password each time you change it and if they can, they'll make you change it
again. You just get an email after a couple days saying "change it or get
locked out."
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Aug 2011 16:05:31 -0700, Darren New wrote:
> On 8/11/2011 11:17, 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.
>
>> Arguably that's the most accurate way, but not the most realistic way.
>
> However, I know a number of corporations that will try to crack your
> password each time you change it and if they can, they'll make you
> change it again. You just get an email after a couple days saying
> "change it or get locked out."
Yeah, that's a different approach - and not necessarily a bad one.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/11/2011 3:09 AM, Invisible wrote:
> 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.
>
This is the truth.
A better philosophy in creating a password IMO is to come up with a
sentence that includes capitalization and punctuation. This makes it
harder for a computer to brute force it, I think.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
>>
>
> This is the truth.
>
> A better philosophy in creating a password IMO is to come up with a
> sentence that includes capitalization and punctuation. This makes it
> harder for a computer to brute force it, I think.
As people on the forums have pointed out, a worrying number of things
have a /maximum/ password length. (!) Quite apart from taking a long
time to type a whole sentence, many systems won't allow you to use one
as a password.
(That said, PGP and GPG [yes, those are real product names] don't even
ask for a "password"; they want a "passphrase".)
The method I generally use is to take a complete sentence, but only type
the first letter of each word, plus any punctuation that might be
present. This has the unfortunately result that all my passwords tend to
start with an uppercase letter and end in a full spot. On the other
hand, how many password crackers are going to try "TSHwmygI." as a password?
Well, that rhetorical question is one I'd like to answer. But not on my
employer's VMs, apparently...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> As people on the forums have pointed out, a worrying number of things
> have a /maximum/ password length. (!) Quite apart from taking a long
> time to type a whole sentence, many systems won't allow you to use one
> as a password.
For a very long time unixes used only 8 character passwords at most.
(You could write more, but everything after the 8th character was ignored
and could thus be anything.)
I think most modern unixes have lifted this limitation.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/17/2011 13:18, Warp wrote:
> For a very long time unixes used only 8 character passwords at most.
The way you do a cryptographic hash is to take a symmetric key algorithm and
use the password as the key and encrypt a constant. The result is a hash.
(Of course, there are other ways, but given (say) DES, this is a way to use
DES as a hash.)
The original unix cyrpt (and later DES) were used this way to generate
password hashes, and that's the reason UNIX tossed more than 8 characters.
Just for general edification. :-)
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/08/2011 09:18 PM, Warp wrote:
> For a very long time unixes used only 8 character passwords at most.
> (You could write more, but everything after the 8th character was ignored
> and could thus be anything.)
>
> I think most modern unixes have lifted this limitation.
If I'm not very much mistaken, obsolete versions of Windows did
something similar. Like, when you *set* your password, it uses only the
first 14 characters and ignores the rest, but when you *enter* your
password for authentication, it uses all 14 characters...
...in other words, if you set a password containing more than 14
characters, you just locked yourself out of the network. Until you
figure out that by typing only the first 14 characters, it lets you in
again. Like, WTF?
Since Windows XP and higher use Kerberos, a protocol designed by people
who have a clue, I'm guessing this kind of stupidity is gone now...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 17 Aug 2011 23:06:14 +0100, Orchid XP v8 wrote:
> On 17/08/2011 09:18 PM, Warp wrote:
>
>> For a very long time unixes used only 8 character passwords at most.
>> (You could write more, but everything after the 8th character was
>> ignored and could thus be anything.)
>>
>> I think most modern unixes have lifted this limitation.
>
> If I'm not very much mistaken, obsolete versions of Windows did
> something similar. Like, when you *set* your password, it uses only the
> first 14 characters and ignores the rest, but when you *enter* your
> password for authentication, it uses all 14 characters...
>
> ...in other words, if you set a password containing more than 14
> characters, you just locked yourself out of the network. Until you
> figure out that by typing only the first 14 characters, it lets you in
> again. Like, WTF?
Yep, you do remember correctly, in fact, I think I wrote something
similar in this very thread. :)
> Since Windows XP and higher use Kerberos, a protocol designed by people
> who have a clue, I'm guessing this kind of stupidity is gone now...
Well, I remember in Windows Server 2000 (with the first release of AD)
that there were circumstances where NTLM authentication would be used
instead of Kerberos, and it wasn't always predictable. So you could
actually end up with a real authentication nightmare in a distributed
environment (which is what I was dealing with) where you might change
your password and then try to authenticate using NTLM, but the PDC
Emulator hadn't received the update (depending on your sync schedules and
such), and since the PDC Emulator was used for NTLM authentication, you
could lock yourself out and not even realise that you were setting the
password using one method and trying to authenticate using the other.
I *hope* they got that sorted out (and would be surprised if they
didn't). We duplicated that in the lab with Microsoft Consulting at the
time....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Since Windows XP and higher use Kerberos, a protocol designed by people
>> who have a clue, I'm guessing this kind of stupidity is gone now...
>
> Well, I remember in Windows Server 2000 (with the first release of AD)
> that there were circumstances where NTLM authentication would be used
> instead of Kerberos, and it wasn't always predictable. So you could
> actually end up with a real authentication nightmare in a distributed
> environment
Ah yes. I think I recall there may have been some difference between how
Windows NT and Windows XP authenticate. Maybe that's the issue I was
remembering...
I haven't seen this problem in a long time. Then again, I haven't tried
to set a really long password. (And I doubt anybody else has.)
I also have a vague recollection that NTLM didn't like certain
characters in a password. But I don't remember which ones.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 18 Aug 2011 09:17:50 +0100, Invisible wrote:
>>> Since Windows XP and higher use Kerberos, a protocol designed by
>>> people who have a clue, I'm guessing this kind of stupidity is gone
>>> now...
>>
>> Well, I remember in Windows Server 2000 (with the first release of AD)
>> that there were circumstances where NTLM authentication would be used
>> instead of Kerberos, and it wasn't always predictable. So you could
>> actually end up with a real authentication nightmare in a distributed
>> environment
>
> Ah yes. I think I recall there may have been some difference between how
> Windows NT and Windows XP authenticate. Maybe that's the issue I was
> remembering...
That could be.
> I haven't seen this problem in a long time. Then again, I haven't tried
> to set a really long password. (And I doubt anybody else has.)
>
> I also have a vague recollection that NTLM didn't like certain
> characters in a password. But I don't remember which ones.
Now that you mention it, I think I ran into that as well.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
