Re: Developmental Dictionary Attack
- From: John Schutkeker <jschutkeker@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 12 Sep 2006 17:10:05 GMT
"Joseph Ashwood" <ashwood@xxxxxxx> wrote in
news:7NtNg.957$7I1.270@xxxxxxxxxxxxxxxxxxxxxxxxxx:
"John Schutkeker" <jschutkeker@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns983BD4469CD85lkajehoriuasldfjknak@xxxxxxxxxxxxxxxxx
"Joseph Ashwood" <ashwood@xxxxxxx> wrote in
[In a large scale break] I suspect that you would find a great many
roots that match the expected high school and below word list.
Joe
Or even college level. Whenever I look at Mirriam-Webster, I am
amazed at the number of words that I'm absolutely convinced are
obsolete. I understand that even smart people only have a
functioning vocabulary of about 20,000 words. Another thing I've
noticed is that people seem to favor nouns and two syllable words.
Do you have any idea where people get their lists of common
passwords, I occasionally see?
The most common source for them has historically been iterating
through every account on a large UNIX system performing a dictionary
search, it of course takes time, but reveals a lot of useful
information. Recently there has been the occassional large scale
website that will post a frequency list, but most of my direct
experience with this came at a former employer making use of 4-6 digit
PINs.
That's because Unix is obliging enough to give users access to the
encrypted password file and the encryption routine. Real world systems are
much less obliging, and they throw up other barriers to keyway attacks,
like 5 sec response timers and 5 try limits. But it would be possible to
use your data gathering method as an input to a real world attack. Or to
gather statistics on the overlap between two independent unix systems with
the same number of users. When you start talking about huge numbers of
successful cracks, suddenly you're talking about doing satistics on the
output.
It sounds like you're used to working with high security systems, but
the majority of systems on the public internet don't have that degree
of security, and some are gateways to huge marketplaces (ie. ebay).
You would actually be quite surprised, ebay actually has higher
security needs than many "high security" systems, because while the
high security systems can have physical lockouts, ebay has to remain
open and available over the network, and in many cases it is far
cheaper to hire a few ex-Marines to stand guard duty then to implement
intense computer security.
You should read the "Safecracker Meets Safecracker" chapter in "Surely
You're Joking Mr. Feynmann." I mean systems that are "high security" in
more than just name. Of course, ther are differnt levels of high security,
depending on the skill of the attacker, but Marine Guards don't do much
good unless they're guarding the only terminal room that can be used to
login, and no other wires out of the computer exist. In the modern world
of the internet, that model is obsolete.
But
whatever limitations are imposed onto a user's password can also be
written into a cracker's software, like the requirement of at least
one non-alphabetic character. After that, you can still try to apply
programmed psychological crypto.
You can, and you generally do, if you're performing a dictionary
attack. Such attacks are actually fairly uncommon,
And that would be the precise reason why it interests me. I'm not
interested in farming ground that has been tilled by thousands before me.
I'm interested in BRAND NEW IDEAS.
even in the average
engineering facility the only systems without complex passswords are
dev machines that are wiped more or less daily anyway.
I don't know what any of this means. I don't know what a dev machine is,
nor why anything should be wiped more or less daily. And your inclusion of
the qualifier "more or less," suggests that the wiping rate is more 'less'
than 'more'. And I don't know what a "complex password" is.
I wasn't really thinking about cracking large numbers of accounts,
but just single, high-value ones.
In an attack on the high powered ones you can often get a significant
number of lesser accounts for nearly free, once you have a lesser
account you can then use it for leverage. This is also where learning
can come in, if you prioritize the learning of the complexity of a
type of high-value account, you'll get fewer collateral breaks and
lower cost per high-value break.
Again, I wouldn't call this learning, but clever pre-programming. It seems
to me that my idea is evolving into is a programmable dictionary attacker.
Up to now, I hadn't considered any other pre-programming than ranking
different sub-dictionaries by priority.
Also, with security scanning it is
important to break all the weak passwords, from there you show them
how it can be leveraged. This is always the most boring part of a
security review, so I try to hand it off to someone else as much as
possible.
Which one do you hand off, the breaking of the weak passwords or showing
them how it can be leveraged? The latter sounds like a lesson in basic
hacking to me.
Learning would be nice, but it's a lot
more advanced than what I'm thinking of. It reminds me of Toby
Maguire's comment in "Seabiscuit" - "One brick at a time, good
Romans."
The basic process is you take a long list of probable words (50,000
word dictionaries aren't too unusual for this) and then you iterate
through in a chosen order.
What kind of attack times does a dictionary of that size consume, on the
unix machines you're auditing, these days?
If you've got memory limitations, it sounds like you're trying to
write your cracker onto a palm pilot, and I'd love to come hang
around your office someday and swap notes.
You would be amazed how big a learning database like this can be, a
dynamic sorted list is either space expensive or compute intensive,
also once you get through the basic dictionary you get exponential
growth, so it's not unusual for such a database to be several GB once
you've accounted for the sorting data, the datamining collection, etc.
It's not unusual for the collection of several gigabytes of datamining
information to be extracted from a system during a full scan,
I think it's a bad idea to use the word "learning" to describe the
accumulation of a database of cracks. This is just data dumping, and the
actual learning doesn't take place until the data miner finds a regular
expression that returns a lot of matches into the data dump.
the pattern of holes tends to indicate the next hole, which means that
recommendations can be made about what exactly to fix both tactically
and strategically.
I can tell that you and I are thinking toward the same destination, but
approaching from different directions. My idea was to try to infer the
password construction algorithms that users were inventing to satisfy the
constraints of their password approval software. But I guess that you're
right, in that a lot of cracked passwords will give you better idea what
algorithms people have dreamed up.
It seems to be a severe chicken/egg problem - when a clever user dreams up
a new way to construct a password, how do you crack it, to see if there are
a lot of passwords, that other clever users have built according to that
formula? If it's a good method, it will defeat the dictionary attack, so
you can never program your cracker to defeat it.
:) Do you know if Munga-Bunga was ever
rewritten on the PC, with Windows rather than Dos syscalls?
I have no idea.
I guess you've never heard of Munga-Bunga. Are you familiar with any
public domain dictionary attacker that allows the user to specify his own
dictionary?
.
- Follow-Ups:
- Re: Developmental Dictionary Attack
- From: rossum
- Re: Developmental Dictionary Attack
- References:
- Developmental Dictionary Attack
- From: John Schutkeker
- Re: Developmental Dictionary Attack
- From: Joseph Ashwood
- Re: Developmental Dictionary Attack
- From: Joseph Ashwood
- Developmental Dictionary Attack
- Prev by Date: CFP: IADIS INTERNATIONAL CONFERENCE APPLIED COMPUTING 2007
- Next by Date: Re: How long to trust 3DES
- Previous by thread: Re: Developmental Dictionary Attack
- Next by thread: Re: Developmental Dictionary Attack
- Index(es):
Relevant Pages
|