Re: Password Cracking

From: Fireglyph (fireglyph@gmx.net)
Date: 01/26/03 

From: Fireglyph <fireglyph@gmx.net>
Date: 26 Jan 2003 02:37:58 GMT

Lohkee <Lohkee@worldnet.att.net> wrote:
>
> [snipping a lot]
>
> This is not in reply to this particular message, rather thoughts about the
> thread in general. I think we tend to get hung up on the password as being
> somehow pivotal.

No, we didn't. We tried to understand your article and to get the whole
terminology right, because otherwise it would have been hard to discuss
the topic.

> We have a manual attack (typically insider) and an
> automated attack (typically outsider). We also have numerous control
> mechanisms at our disposal (outlined in my original paper, number of
> attempts, etc, etc) that can be used to reduce risk.

Look, here you're using terminology correctly and of course you're
right. By applying certain types of control mechanisms, the risk of
someone trying out passwords manually sitting in front of the
login screen or someone guessing passwords remotely can be reduced.
I also have to agree with you that for this single type of attack
the strength of the password isn't that much important and can be
almost ignored (except for using absolutely obvious passwords or
really bad generation schemes like using birthdays).

> In the case of a manual attack, perhaps we can agree that words
> found in a dictionary are "strong."

Now this is the point where you're using the wrong terminology,
which makes the whole statement wrong.

What you said about reducing the risk above completely suffices to
make your ideas clear to everyone and to point out that passwords
in that particular case aren't that much imporant.

Password strength doesn't depend on the type of attack or on
the attacker! As I already tried to explain to you, it is a feature
of the generation scheme which has produced the password alone.

I'll try to explain it to you with an analogy which I will also
use in the rest of my posting to comment on some other things.

Let us say you have a diamond you want to protect. You put it into
a box and put a lock on this box, only you have the key. Moreover,
you put the box into a room with a door.

The diamond are all your system resources (cpu, memory, etc.)
The box protects your system (permissions, firewall, whatever)
The lock closes the whole box and is the authentication module:
only someone who has the key (password) can open the box.
The room + door protects everything.

You can reduce the risk of someone opening the box by opening the door
to the room only from time to time. That is what you're proposing:
restricting access by other control mechanisms. The quality (strength) of
the lock and the key isn't affected.

You could also construct a floor which will give the attacker an
electrical shock when he has chosen the wrong key: he will need some
time to refresh (= restricting access). The risk is reduced, but
the quality of the lock still isn't affected.

You mentioned that a company with a system which isn't protected
enough has many more problems than weak passwords. You're right.
For example, the box might be made of wood and the attacker can simply
take an axe, destroy it and get the diamond (wrong permissions set,
unpatched system, trojan horses, whatever). Nevertheless, the
quality of the lock isn't affected.

I hope you can see what was wrong. What you were honestly trying to
tell us in many of your articles (and I even was so stupid to make the
same mistake at first ;-) is that the lock (authentication system + keys)
could become affected by changing the material and quality of the box or
by building other protection mechanisms around it.

Wrong.

The strength of a password doesn't change by limiting access to the
system resources. It is completely independent of that. It also
doesn't change by someone trying it manually or automatically.

What changes is only the chance of an attacker and the risk for us
that the diamond could be stolen.

I can only hope you got it now and that you will correct your original
articles accordingly.

So let's go on.

> If, for example, the system allows passwords shorter than 9 chars it is
> then pointless to crack them to enforce "stronger" passwords since all can
> be broken and are therefore essentially "weak" by default

What do you mean here? That the password generation *policy* allows
passwords shorter than 9 characters or that the *system* allows them?

Normally you use a password cracker to test and ensure that users have
followed the policy. So if you find passwords shorter than the length
specified in your policy, you will go to the person which has chosen a
weak password and inform her.

So it is not pointless to use a cracker, but the only way to find out
if people are following your policy!

> I think my point here is forcing users to remember difficult passwords
> serves no real purpose other than to piss them off and burden the help
> desk unnecessarily. The real issue (in my mind anyway) is the effective
> use of the many available control mechanisms to mitigate risk in the event
> of either type of attack. Cracking passwords does not do this.

First of all, I want to mention here that passwords aren't only used
to restrict system access, but may also protect other resources, like
cryptographic private keys, encrypted hard disks, backup tapes, etc.
There are many applications for using passwords and educating users
to use strong passwords in general therefore is a good idea.

The security of a well-designed cryptographic system even depends almost
completely on the security of the keys. It is comparable to a lock on
a box which can't be destroyed by other means.

But okay, back to our application: restricting access to a system.

There are many other possibilities for a hacker to break into a system.
He could make use of bugs in unpatched software, like buffer overflows,
to gain administrator rights. He could access information by sniffing
the network. He could send emails, in the hope that someone will run
the trojan horse attachment which will erase the whole hard disk. That
is, he simply could try to destroy our box.

All this has nothing to do with passwords or the password file at all,
like destroying the box and getting the diamond has nothing to do with
the lock and keys. It shows that overall system security doesn't depend
on the use of strong passwords alone. Of course, to secure a system,
it is necessary to minimize the overall risk by patching the system,
setting the right file permissions and so on.

So far, I can agree with you that the whole password mechanism or using a
password cracker isn't very helpful (so far!).

Nevertheless, once you have secured your system by all those means and
reduced the risk that someone can destroy the box, your whole security
then depends on the lock and keys - almost comparable to a cryptographic
system. Since you want to reduce the risk even further, strong passwords
come into play again.

But that is not the only reason why I cannot share your opinion that
choosing strong passwords is unimportant.

Estimation of risk does also depend on the value of what I'm trying to
protect. That means, if that what I'm trying to protect has no value
for me, I'm taking no great risk by allowing access to it.

Now, there goes the idea that once a hacker has gained system access,
for example by exploiting a weakness in software, he first will try to
get the password file. Why should he? He already has access - and doesn't
need the passwords. Really?

Of course, that's not true.

The password file has great value. Imagine that it contains keys.
Maybe those keys will also fit in other locks and holes. It even doesn't
only contain keys, but also identity cards. The whole purpose of an
authentication system lies in determining the identity of a user.
So once the hacker has cracked the passwords, he can log in into the
system at any time, as any user, as long as the passwords won't be
changed.

Since I assume that passwords don't change as often as a good sysadmin
applies new patches, the chances of an attacker to break into a
system even after a patch of the security hole he exploited are high.
It is also very unlikely that passwords of all users will change at
the same time, so he always can log in at least as one of the users.

If users use passwords for several accounts, he can exploit all those
accounts. He may read your web mail, for example. He can do *anything*
what you can do, maybe much more than what he could have done by
just exploiting one single security hole in software. Maybe that
hole only allowed him access to one computer and to get the password
file, but once he has cracked it, he suddenly can be the admin of
the whole network!

Since he takes on the identity of a user, he probably will remain
undetected for a long time. The sysadmin will think that the user has
caused all the problems.

By cracking a password file and taking on the identity of a user who
is trusted, a hacker can destroy the whole trust-relationships of
a company.

Imagine that!

So the reason why security experts make such a fuss about strong
passwords is that the password file can have such a great value for
a hacker. Since protecting the password file or the hashes is so
very difficult (sniffing a network is easy!), strong passwords are the
last resort of a sysadmin. It is damn hard to apply security patches
regularly enough and fast enough (especially with companies like
Microsoft which need months to fix something!) to hinder hackers from
getting the password file.

The point of strong passwords is that it can be mathematically proven
that you could even give away that what has the greatest value to you
- the password file - for free, since a hacker would need years to
get the keys.

The risk for the overall security of a company is dramatically increased
if getting the password file undetected is so easy and 90 % of all
users are using weak passwords which all can be found by a password
cracker in a matter of seconds.

A thief might be able to get into a closed room and open a drawer,
but once he has found the keyring, he is able to access your whole
house. So wouldn't you try to protect that keyring especially well?

Think about it.

Good night (uaaah, I'm tired),

Fireglyph

Relevant Pages

  • Re: ssh gives "Permission denied, please try again"
    ... as secure as those Debian generated keys... ... If you always pick passwords whose first four letters are 'A' you're ... The point being that keys are not some panacia and those that think they ... lots of people attack passwords, nobody attacks keys. ...
    (uk.comp.os.linux)
  • Re: ssh gives "Permission denied, please try again"
    ... possibly have enough entropy to be secure. ... If you always pick passwords whose first four letters are 'A' you're ... The point being that keys are not some panacia and those that think they ... I've seen a lot of dictionary attacks, ...
    (uk.comp.os.linux)
  • Re: Any Way to Defeat Cracker Login Attempts? (OS X)
    ... Ssh keys are more secure than passwords. ... By ssh keys I assume you mean PKA keys, unless I am misreading you yet ...
    (comp.sys.mac.system)
  • Re: SSH as root
    ... and the passwords are sent securely. ... unix passwords is when the same passwordcan be used to compromise ... > you are in the same boat if you choose passwords, or keys with passphrases. ... Yes, indeed, if the client system is compromised then all bets are off, ...
    (SSH)
  • Re: See what a weak password will get ya?
    ... >>Just wanted to share the need for strong passwords. ... are that even the relatively mnemonic lists are of very high quality. ... I find that these keys are usually pretty ... and typical keys run 10-15 characters. ...
    (Debian-User)