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