Cracking OpenVMS passwords with John the Ripper

162 views
Skip to first unread message

Jean-loup Gailly

unread,
Nov 26, 2002, 6:11:27 PM11/26/02
to
I have written a patch for John the Ripper http://www.openwall.com/john/
to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
code from Shawn Clifford, Davide Casale and Mario Ambrogetti.

The sources are in http://jl.gailly.net/security/john-VMS-patch.tar.gz
A README file is at http://gailly.net/security/john-VMS-readme.html
or in ascii at http://jl.gailly.net/security/README.VMS

This patch has been tested on x86 only and does not work yet on big endian
systems. It uses asm code for speed but a portable C version is included as
well. The asm version checks about 150,000 passwords per second on a 1 GHz
system. Password cracking is much easier on OpenVMS than on other systems
since passwords are not case sensitive and limited to alphanumeric,
'$' and '_' only.

Jean-loup Gailly
http://gailly.net/security/

Shane Smith

unread,
Nov 26, 2002, 7:11:40 PM11/26/02
to
If this is a password guesser, which your wording suggests it is, I
doubt it will be particularly effective against a properly secured VMS
system. Successive failed guesses would incur longer delays between
retries, and after a few failures it'd lock off the account. IIRC,
that's default settings out of the box, but I haven't done a fresh
install in a while so I'd welcome corrections from those with fresher
(or better) memories.

Shane

Robert Deininger

unread,
Nov 26, 2002, 8:25:59 PM11/26/02
to
In article <01C29566...@sulfer.icius.com>, Shane Smith
<ssm...@icius.com> wrote:

>If this is a password guesser, which your wording suggests it is, I
>doubt it will be particularly effective against a properly secured VMS
>system. Successive failed guesses would incur longer delays between
>retries, and after a few failures it'd lock off the account. IIRC,
>that's default settings out of the box, but I haven't done a fresh
>install in a while so I'd welcome corrections from those with fresher
>(or better) memories.

No, he's copying the SYSUAF to another system, guessing plaintext
passwords, hashing them, and comparing to the hashed password stored in
SYSUAF. I don't know if the hashing algoithms are correct, complete, and
up-to-date, but they look plausible.

Since the method bypasses the usual VMS login checks, it gets as many
guesses as it needs. This is a fairly old strategy for obtaining VMS
passwords, and is valid in some environments. A system manager might want
to weed out passwords that are easily guessed. It isn't a serious
security risk, since the SYSUAF isn't readable by non-prived users. (The
default protection is world:nothing for SYSUAF.)

JF Mezei

unread,
Nov 26, 2002, 8:29:04 PM11/26/02
to
Shane Smith wrote:
> doubt it will be particularly effective against a properly secured VMS
> system.

If the program has access to the sysuaf.dat FILE, then it can try all the
passwords it wants without arousing any suspicion by the VMS operating system
(expecially if it makes a copy of the file for its own use). Note that the
poster said that the program was a wintel one, so one would expect it would
have its own local SYSUAF.DAT.

Shane Smith

unread,
Nov 27, 2002, 2:55:54 AM11/27/02
to
True. However, access to that file would also be restricted in a
properly locked down system, so it's still of limited use to hackers.
They'd have to get in and get privs to get the file, and the program
would be fairly pointless once you'd done that.

Shane

JF Mezei

unread,
Nov 27, 2002, 3:33:24 AM11/27/02
to
Shane Smith wrote:
>
> True. However, access to that file would also be restricted in a
> properly locked down system, so it's still of limited use to hackers.
> They'd have to get in and get privs to get the file, and the program
> would be fairly pointless once you'd done that.

But if you have a system manager as an accomplice, he hand send you the
sysuaf.dat, you crack the boss's password and can then have "fun" on the
system, undetected and without any intrusion attempts.

This is why it is very important to have full trust in anyone with privileges
in your system.

MikeR

unread,
Nov 27, 2002, 3:52:31 AM11/27/02
to
If you have a system manager as an accomplice, why go to all the trouble of
cracking?
1. Get DETACH/IMPERSONATE privs.
2. Use the SYS$PERSONA calls.

Mike

"JF Mezei" <jfmezei...@vl.videotron.ca> wrote in message
news:3DE48345...@vl.videotron.ca...

Shane Smith

unread,
Nov 27, 2002, 3:50:45 AM11/27/02
to
True, but the password's irrelevant if your friend's the system manager.
HGLOGIN. Been there, done that, the boss in question laughed with the
rest of us. (It was a harmless little prank.)

Shane

-----Original Message-----
From: JF Mezei [mailto:jfmezei...@vl.videotron.ca]
Sent: Wednesday, November 27, 2002 12:33 AM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper

Nic Clews

unread,
Nov 27, 2002, 3:59:42 AM11/27/02
to
Jean-loup Gailly wrote:
>
> I have written a patch for John the Ripper http://www.openwall.com/john/
> to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
> code from Shawn Clifford, Davide Casale and Mario Ambrogetti.

...


> This patch has been tested on x86 only and does not work yet on big endian
> systems. It uses asm code for speed but a portable C version is included as
> well. The asm version checks about 150,000 passwords per second on a 1 GHz
> system. Password cracking is much easier on OpenVMS than on other systems
> since passwords are not case sensitive and limited to alphanumeric,
> '$' and '_' only.

Slightly optimistic Jean-loup. Before anyone has a heart attack, I'll
clarify your context and explain why I think it's optimistic.

As you point out, you need access to a copy of the SYSUAF.DAT. If a
system ever got into that state from a genuine crackers' point of view,
I'd quit now and open a Burger stand (there's been enough advice here on
that already).

Secondly, a password list you hit a single user account with in the most
part cannot exist in those that are in the password dictionary (where
implemented!), and for those of us that use the password policy module
forcing the presence of non alphabetic characters and therefore _really_
'unreal' words, you'd have to slow that 150,000 guesses per second down
by generating effectively random strings of all allowable characters in
a password, versus the expected lengths (8 to 32 characters?). I don't
really believe that anyone has the storage or the time to pregenerate
such a colossal list, moving each character through all possible
combinations starting at some arbitrary length, and extending to the
maximum allowable or expected (and risking missing longer ones). The
sheer time to perform the IO alone to this list makes a mockery of the
technique. An Alpha would certainly outclass your Wintel box several
hundred fold in this department alone.

I guess the problem of porting code to different platforms is not
knowing what preconditions can be applied to passwords, and in the case
of OpenVMS, we've been quite blessed with an array of security options,
native to the operating system, when when properly implemented, even a
determined hacker would switch to a softer target and use anything
learnt to resume an otherwise fruitless attack on the OpenVMS box. All
the more reason to allow an OpenVMS box to manage the secrets, rather
than some other system with the water tightness of a teabag. Even taking
that into account, sex, sodium pentathol and large amounts of cash are
probably more viable alternatives in the 'social engineering' stakes.

However, there may be those that need a wake-up call, and your port of
the cracker and what it _can_ do, should hopefully inspire a system
manager to check their environment. As stated its prime purpose is to
detect weak passwords, and if you as a system manager found yourself in
this position, I'd go stock up on burgers right now. Complacency is the
biggest threat of all.

(Nice site by the way.)
--
Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences
nclews at csc dot com

Jan C. Vorbrüggen

unread,
Nov 27, 2002, 4:31:42 AM11/27/02
to
> This patch has been tested on x86 only and does not work yet on big endian
> systems. It uses asm code for speed but a portable C version is included as
> well. The asm version checks about 150,000 passwords per second on a 1 GHz
> system. Password cracking is much easier on OpenVMS than on other systems
> since passwords are not case sensitive and limited to alphanumeric,
> '$' and '_' only.

However, VMS's use of a salt in the encrpytion process makes it impossible
to attack all passwords in a given file simultaneously. If you're just
targetting one specific user, that doesn't make a difference, of course.

Jan

Tomasz Dryjanski

unread,
Nov 27, 2002, 7:15:52 AM11/27/02
to
> If you have a system manager as an accomplice, why go to all the trouble
of
> cracking?
> 1. Get DETACH/IMPERSONATE privs.
> 2. Use the SYS$PERSONA calls.

Or you may even change the user's password temporarily.
Some years ago I wrote a program capable of storing a hashed password,
and then restoring it back.
There is no much fun to break-in to a system you have administrative rights
to. ;)

T. D.


Larry Kilgallen

unread,
Nov 27, 2002, 7:13:38 AM11/27/02
to
In article <as20va$n098t$1...@ID-103225.news.dfncis.de>, "MikeR" <rech...@tzora.co.il> writes:
> If you have a system manager as an accomplice, why go to all the trouble of
> cracking?
> 1. Get DETACH/IMPERSONATE privs.
> 2. Use the SYS$PERSONA calls.

3. Please don't top-post.

4. The vulnerability to such a tool is when people have access to
unencrypted backup tapes. At some shops that is easier to achieve
than privileged access to the running system.

David Webb

unread,
Nov 27, 2002, 10:34:02 AM11/27/02
to
In article <01C29566...@sulfer.icius.com>, Shane Smith <ssm...@icius.com> writes:
>If this is a password guesser, which your wording suggests it is, I
>doubt it will be particularly effective against a properly secured VMS
>system. Successive failed guesses would incur longer delays between
>retries, and after a few failures it'd lock off the account. IIRC,
>that's default settings out of the box, but I haven't done a fresh
>install in a while so I'd welcome corrections from those with fresher
>(or better) memories.
>
>Shane
>
John the ripper is a crack style program ie the hacker needs to have obtained
access to the sysuaf file (and copied it to a (intel) system) where he can run
John the ripper against it.
I don't know very much about John The Ripper but would assume you provide it
with a wordlist (dictionary of words) which John the Ripper then hashes with
all possible salts and compares against the hashes in the filched sysuaf.

If a hacker has gained access to the sysuaf then you have bigger problems than
the fact they can run John the Ripper.

David Webb
VMS and Unix team leader
CCSS
Middlesex University

Bob Koehler

unread,
Nov 27, 2002, 9:43:27 AM11/27/02
to
In article <01C29566...@sulfer.icius.com>, Shane Smith <ssm...@icius.com> writes:
> If this is a password guesser, which your wording suggests it is, I
> doubt it will be particularly effective against a properly secured VMS
> system. Successive failed guesses would incur longer delays between
> retries, and after a few failures it'd lock off the account. IIRC,
> that's default settings out of the box, but I haven't done a fresh
> install in a while so I'd welcome corrections from those with fresher
> (or better) memories.

The stated purpose of John the Ripper is to improve UNIX security.
If you're still using a world readable password file on a UNIX system
you sure better use something like this. If your using VMS or a
shadow password file on UNIX, this may help.

Our UNIX system admins run a similar tool all the time.

David Webb

unread,
Nov 27, 2002, 10:54:54 AM11/27/02
to
In article <as2d1o$2kmi$1...@news2.ipartners.pl>, "Tomasz Dryjanski" <tdryjans...@hotmail.com> writes:
>> If you have a system manager as an accomplice, why go to all the trouble
>of
>> cracking?
>> 1. Get DETACH/IMPERSONATE privs.
>> 2. Use the SYS$PERSONA calls.
>
>Or you may even change the user's password temporarily.
>Some years ago I wrote a program capable of storing a hashed password,
>and then restoring it back.
As long as the sysuaf records aren't too long you can even do it with
DCL.


David Webb
VMS and Unix team leader
CCSS
Middlesex University

David Mathog

unread,
Nov 27, 2002, 11:27:48 AM11/27/02
to
On Tue, 26 Nov 2002 23:11:27 +0000 (UTC)
jl...@gailly.OmitThisWord.net (Jean-loup Gailly) wrote:

> I have written a patch for John the Ripper http://www.openwall.com/john/
> to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
> code from Shawn Clifford, Davide Casale and Mario Ambrogetti.

Which is nice but of little relevance to VMS security. Only a priv'd user
should be able to read SYSUAF.DAT, and if that user has evil intentions
then the system is already compromised - there's no need to crack
the password file. This contrasts with many (most?) Unix systems, where
everybody can read the encrypted password file.

Regards,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Georges A. Tomazi

unread,
Nov 27, 2002, 1:44:42 PM11/27/02
to

David -

On Wed, 27 Nov 2002 08:27:48 -0800, David Mathog <mat...@caltech.edu>
wrote:

[...]

>This contrasts with many (most?) Unix systems, where
>everybody can read the encrypted password file.

That's not anymore true. Most if not all current Unix systems use now
the shadow file (Solaris, Irix, Linux, OpenBSD, NetBSD, etc...).

Georges

--
Georges A. Tomazi - g...@sunwizard.net

Robert Deininger

unread,
Nov 27, 2002, 5:47:28 PM11/27/02
to
In article <SKWHEP...@eisner.encompasserve.org>, Kilg...@SpamCop.net
(Larry Kilgallen) wrote:


>4. The vulnerability to such a tool is when people have access to
> unencrypted backup tapes. At some shops that is easier to achieve
> than privileged access to the running system.


Good point.

Hoff Hoffman

unread,
Nov 27, 2002, 6:23:13 PM11/27/02
to

In article <01C29566...@sulfer.icius.com>, Shane Smith <ssm...@icius.com> writes:
:-----Original Message-----

:From: jl...@gailly.OmitThisWord.net
:[mailto:jl...@gailly.OmitThisWord.net]
:Sent: Tuesday, November 26, 2002 3:11 PM
:To: Info...@Mvb.Saic.Com
:Subject: Cracking OpenVMS passwords with John the Ripper

..

:I have written a patch for John the Ripper http://www.openwall.com/john/


:to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based
:on code from Shawn Clifford, Davide Casale and Mario Ambrogetti.

Password-guessing tools and dictionary attacks have been around for
eons, and OpenVMS has mechanisms that can help reduce the exposure
to even poorly-chosen user passwords.

In particular, the OpenVMS breakin evasion mechanisms.

This breakin evasion security mechanism is enabled and operating by
default on all recent OpenVMS releases.

That said, password-cracking tools -- whether this one or other of
the various options -- can be quite valuable as security auditing
tools for the system manager. In particular, these tools permit
the system manager to look for weak user passwords.


:The sources are in http://jl.gailly.net/security/john-VMS-patch.tar.gz

The correct addresses appear to be:

http://www.teaser.fr/~jlgailly/security/
http://www.openwall.com/john/

:... The asm version checks about 150,000 passwords per second on a 1


:GHz system. Password cracking is much easier on OpenVMS than on other
:systems since passwords are not case sensitive and limited to alphanumeric,
:'$' and '_' only.

Most any password-based mechanism does and will provide poor security
on any platform -- an increase in the size of the character set does
clearly increase the time required for a password match, but if the
nefarious user has a copy of your hashed password or your password
database, you are already in trouble. The match is only a matter of
time, and as the computing cycles available increase, the time to a
matching hash will decreate.

Passwords are case-sensitive and a variety of characters are permitted
as part of external authentication. And you can also implement your
own hashing scheme, if so interested.

The OpenVMS approach is to restrict access to the hashed values as
stored in SYSUAF, and to use a salt value to reduce exposure to attacks
based on the use of pre-generated password tables. Further, OpenVMS
is moving to external authentication, as this permits each site to
provide smartcards or scanners or other technologies, technologies
that are more modern and more secure alternatives to the traditional
text-based password scheme.

If folks here are interested in improving security, consider porting
the John the Ripper "proactive password strength checking module" stuff
or something similar into the LGI callouts. Other approaches involve
enabling and using generated passwords though -- again -- text passwords
are pretty weak as authentication schemes go. (Though the implementation
of an elvish-language password generator was a cute hack.)

Ask The Wizard topics (4612) and (7813) will be of interest here -- the
former is one of the character set discussions, I might add, one of the
previous times that this particular discussion has arisen.

And Jean-loup, the correct DEFINE command is:

"define sysuaf myuaf.dat"

The DEFINE command posted at your webpage is wrong. And no, that isn't
a security hole -- simply knowing usernames is not something that is
secured on OpenVMS nor can it particularly be secure-able.

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com

Hoff Hoffman

unread,
Nov 27, 2002, 6:32:34 PM11/27/02
to

In article <as2d1o$2kmi$1...@news2.ipartners.pl>, "Tomasz Dryjanski" <tdryjans...@hotmail.com> writes:
:> If you have a system manager as an accomplice, why go to all the trouble
:> of cracking?...
..
:Or you may even change the user's password temporarily.

:Some years ago I wrote a program capable of storing a hashed password,
:and then restoring it back.

If you have general read access or unrestricted write access into
the SYSUAF database, then the system is wide-open and literally
any access and any change is possible -- you are fully privileged.

As for your password-maintaining tool, using the existing RENAME
command available within AUTHORIZE (twice) would seem far easier.
But given write-access to SYSUAF means that IMPERSONATE and other
options are also explicity available to a fully-privileged user,
why bother?

For folks joining this discussion in progress, the OpenVMS security
manual is useful -- and arguably now even required -- reading.

Dale King

unread,
Nov 27, 2002, 9:14:29 PM11/27/02
to
Shane Smith wrote:
> True. However, access to that file would also be restricted in a
> properly locked down system, so it's still of limited use to hackers.
> They'd have to get in and get privs to get the file, and the program
> would be fairly pointless once you'd done that.

The big problem of course is people using the same passwords on many systems.
Once a system is comprised so are the rest. Similarly, a priviliged user on one
system can generally be considered privileged on the rest, where a company
policy enforces consistent usernames accross systems.


Larry Kilgallen

unread,
Nov 27, 2002, 8:15:36 PM11/27/02
to
In article <as3kmi$4vk$8...@web1.cup.hp.com>, ho...@hp.nospam (Hoff Hoffman) writes:
>
> In article <as2d1o$2kmi$1...@news2.ipartners.pl>, "Tomasz Dryjanski" <tdryjans...@hotmail.com> writes:
> :> If you have a system manager as an accomplice, why go to all the trouble
> :> of cracking?...
> ..
> :Or you may even change the user's password temporarily.
> :Some years ago I wrote a program capable of storing a hashed password,
> :and then restoring it back.

> As for your password-maintaining tool, using the existing RENAME


> command available within AUTHORIZE (twice) would seem far easier.

But it provides more precise audits of what the attacker is doing.

Andrew Harrison SUNUK Consultancy

unread,
Nov 28, 2002, 4:48:41 AM11/28/02
to

David Mathog wrote:
> On Tue, 26 Nov 2002 23:11:27 +0000 (UTC)
> jl...@gailly.OmitThisWord.net (Jean-loup Gailly) wrote:
>
>
>>I have written a patch for John the Ripper http://www.openwall.com/john/
>>to allow cracking OpenVMS (Vax and Alpha) passwords. The patch is based on
>>code from Shawn Clifford, Davide Casale and Mario Ambrogetti.
>
>
> Which is nice but of little relevance to VMS security. Only a priv'd user
> should be able to read SYSUAF.DAT, and if that user has evil intentions
> then the system is already compromised - there's no need to crack
> the password file. This contrasts with many (most?) Unix systems, where
> everybody can read the encrypted password file.
>

This has been untrue for years for Solaris I cannot comment
on other UNIX's.

/etc/passwd is readable by non root users but doesn't contain
users passwords.

The passwords are held in /etc/shadow and this by default
isn't readable except by root.


ls -la /etc/shadow returns
-r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow


Regards
Andrew Harrison

David Webb

unread,
Nov 28, 2002, 6:17:02 AM11/28/02
to
In article <jg4auuknn6cro1fu2...@4ax.com>, Georges A. Tomazi <g...@diapason.com> writes:
>
>David -
>
>On Wed, 27 Nov 2002 08:27:48 -0800, David Mathog <mat...@caltech.edu>
>wrote:
>
>[...]
>
>>This contrasts with many (most?) Unix systems, where
>>everybody can read the encrypted password file.
>
>That's not anymore true. Most if not all current Unix systems use now
>the shadow file (Solaris, Irix, Linux, OpenBSD, NetBSD, etc...).
>

Most if not all provide a shadow password or similar facility but whether it is
the default I'm not so sure.
Also I doubt whether when upgrading older systems an automatic conversion to
using shadowed passwords is performed.

I've also come across systems using shadowed passwords where for some reason
passwords ended up being setup in the /etc/passwd file and hence posed a risk
until someone noticed.

Jean-loup Gailly

unread,
Nov 28, 2002, 8:09:23 AM11/28/02
to
It seems that many people have misunderstood my intent. It should be
obvious that if a bad guy has access to your sysuaf.dat you're in big
trouble already. I have added a sentence on http://gailly.net/security/ :
"This tool is designed for system administrators to detect users who
too often select very bad passwords, too easily guessable".

I advise system administrators who do not believe this to try
John at least once. You will be amazed to see how bad most passwords are,
and how quickly you can find most of them. Of course, make sure that
the working directory of John and all files within it are correctly
protected against read access by others.

Nic Clews writes:

> Secondly, a password list you hit a single user account with in the most
> part cannot exist in those that are in the password dictionary (where
> implemented!)

I had trouble parsing your sentence. John does much more than trying
all words from a dictionary. It has elaborate rules to generate many
variations of dictionary words, and a sophisticated incremental mode
to try non-dictionary words in optimum order. This is what makes it
the best password cracking tool.

> and for those of us that use the password policy module forcing the
> presence of non alphabetic characters and therefore _really_
> 'unreal' words, you'd have to slow that 150,000 guesses per second down

My patch is designed for the builtin OpenVMS password algorithms, not
for external modules. HP (Hoff Hoffman) indeed recommends using
algorithms other than their own, in this thread and in
http://www.openvms.compaq.com/wizard/wiz_4612.html

> I don't really believe that anyone has the storage or the time to
> pregenerate such a colossal list, moving each character through all
> possible combinations starting at some arbitrary length, and extending
> to the maximum allowable or expected (and risking missing longer
> ones). The sheer time to perform the IO alone to this list makes a
> mockery of the technique.

There is no point in generating a colossal list on disk. The VMS password
algorithms correctly take into account a salt and the user name to prevent
such attacks. But at 150,000 guesses per second it is very easy to try
*all* legal VMS passwords of 7 characters or less, working in memory only.
You can also easily try all simple variations of a small dictionary
(1 million words). John is good at generating the variations that people
actually use most of the time.

By using John, a system administrator can effectively eliminate all weak
passwords. I'm surprised that many VMS fans cannot understand the usefulness
of such a tool. (I wrote the John VMS patch for a security audit of a
large company.)

Jean-loup Gailly
http://gailly.net/security/

marco viola

unread,
Nov 28, 2002, 8:22:05 AM11/28/02
to
Andrew Harrison SUNUK Consultancy <Andrew_No....@nospamn.sun.com> wrote:
> The passwords are held in /etc/shadow and this by default
> isn't readable except by root.


> ls -la /etc/shadow returns
> -r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow

Not writable; interesting.

How do you add users?

Ciao
Marco

Nic Clews

unread,
Nov 28, 2002, 8:44:15 AM11/28/02
to

However you could set the SYSUAF.DAT as /NOBACKUP and independently
secure the backup copies of SYSUAF. Or fix your tape handling procedure,
however, if it is that bad, you deserve to get all your burgers nicked.

There are far easier methods of breaking into a system that any self
respecting hacker would use, as opposed to anything mentioned in this
thread. Like I said, if anyone is allowing passwords as supplied as a
list with that cracker, mine is with lots of ketchup and onions please.

David J. Dachtera

unread,
Nov 28, 2002, 11:21:13 AM11/28/02
to

The hard part is reconciling that to human nature.

What's a big complaint of the security people? SAME passwords on many
systems.

What's the big complauin of users? DIFFERENT passwords on many systems.

Nearly diametric opposition.

--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

David J. Dachtera

unread,
Nov 28, 2002, 11:26:15 AM11/28/02
to

root effectively has the equivalent of BYPASS privilege. The permission
mask is more or less meaningless in such circumstance.

Georges A. Tomazi

unread,
Nov 28, 2002, 9:26:33 AM11/28/02
to

Hi -

On Thu, 28 Nov 2002 14:22:05 +0100, marco viola <m...@mail.com> wrote:

[...]

>> ls -la /etc/shadow returns
>> -r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow
>
>Not writable; interesting.
>
>How do you add users?

That's normal on Solaris. The system bypass that.

JF Mezei

unread,
Nov 28, 2002, 2:00:10 PM11/28/02
to
Jean-loup Gailly wrote:
> By using John, a system administrator can effectively eliminate all weak
> passwords. I'm surprised that many VMS fans cannot understand the usefulness
> of such a tool. (I wrote the John VMS patch for a security audit of a
> large company.)


Suppose you do find that your boss has a weak password. What do you do then ?
Do you go and tell him that you extracted his password and decided that it was
weak ? Wouldn't that jeoperdize the integrity of the system manager who is not
supposed to have access to user's passwords ?

He may have access to his own sysuaf.dat on that small departmental VAX, but
getting his boss's password on the vax would probably also get his password
for the IBM mainframe and email servers etc etc etc. Revealing that you can in
fact extract passowrds would jeoperdize the security of other systems in the organisation.

One would have to be very diplomatic in trying to educate the person on the
use of stronger passowrds without giving any hints that you saw their password.

Jean-François PIÉRONNE

unread,
Nov 29, 2002, 3:38:07 AM11/29/02
to
Salut Jean-Loup,

First I would like not to argument pro/cons security based on password, only
about password guessable.

First, you agree that on a normally configure VMS system you can't read the UAF
file.

Very bad passwords is much less a problem on VMS than on many others systems,
because there is other security
which prevent you to do many try:
for example if you have a direct access, then you terminal will become suspect,
then intruder,then if I have enablethis feature the account will become disuser,
and not including dome audit alarm.
Why did you think that credit card have only a four digits code, because after
three attempts the game is over.
So what is the chance of a, for example, 6 letters passwords, to be be found if
you have only five attempt?
On some other systems, you can made as many attempt as you want, this is
fundamental different.

I don't say it is impossible, just that the probability is very very small.

The thread http://www.openvms.compaq.com/wizard/wiz_4612.html is much more about
general password security versus other methods (Kerberos, smart cards, and
biometric hardware, etc...) and not about some problem into the implementation
of the password mechanism into VMS.

I have only seen in movies people finding password after 3 attempts.

Any way, a good password is better than a bad, but a too good password is
sometime written on some paper because people can't remember it :-)

On most of VMS system I have seen, there are much important security problem.

Jean-François

Andrew Harrison SUNUK Consultancy

unread,
Nov 29, 2002, 7:06:24 AM11/29/02
to

JF Mezei wrote:
> Jean-loup Gailly wrote:
>
>>By using John, a system administrator can effectively eliminate all weak
>>passwords. I'm surprised that many VMS fans cannot understand the usefulness
>>of such a tool. (I wrote the John VMS patch for a security audit of a
>>large company.)
>
>
>
> Suppose you do find that your boss has a weak password. What do you do then ?
> Do you go and tell him that you extracted his password and decided that it was
> weak ? Wouldn't that jeoperdize the integrity of the system manager who is not
> supposed to have access to user's passwords ?
>

You tell him, but in private so as not to make him/her look
idiotic in public.

Most major organsations have standards that they expect their
employees to follow when setting their passwords, if your
bosses password is crackable then it probably doesn't follow
your security standards.

If you don't tell him and someone breas into his account you
will be worse off then not telling him in the the first
place.

We run crack internally in Sun, written by Alex Muffett.

If you have a poorly constructed password then you get a
warning email from the security team. It doesn't distinguish
between job titles and doesn't have a CEO userid filter.

This discussion is a re-run of discussions about crack, COP's
etc.

Have a look at (kindly forwarded to me by Alex)

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=0gcHpabz1%40cs.psu.edu

The thread that follows and the views expressed there are
is pretty much reflected by the views expressed in this thread.
You will however note that the origional discussion was 11 years
ago. (Was the Apollo DN10000 arround 11 years ago, it seems longer).

Regards
Andrew Harrison


David Webb

unread,
Nov 29, 2002, 7:13:22 AM11/29/02
to
In article <3DE667B9...@vl.videotron.ca>, JF Mezei <jfmezei...@vl.videotron.ca> writes:
>Jean-loup Gailly wrote:
>> By using John, a system administrator can effectively eliminate all weak
>> passwords. I'm surprised that many VMS fans cannot understand the usefulness
>> of such a tool. (I wrote the John VMS patch for a security audit of a
>> large company.)
>
Although such tools have there uses it is better to have them runnable on
the system itself (from a suitably privileged and secured account).
The idea of copying the sysuaf onto a PC to do the analysis circumvents all
the VMS mechanisms designed to protect this important file.

I seem to recall that there were some public domain native programs (from
before VMS had password dictionaries etc ie quite some time ago) which
did this. I haven't looked at them in years and hence have no idea whether
they still work.

Problems with weak passwords can be reduced by using VMS mechanisms ie

minimum password length,
password history list - to prevent reuse of passwords,
password dictionary,
inbuilt triviality checks - to stop users choosing trivial passwords such as
the account name

Together with setting appropriate LGI values so that the system takes evasive
action after the user gets the password wrong a certain number of times
ie for a certain period even if the hacker got the password correct they
would not be allowed to login - this drastically reduces the chance of a
successful brute force attack.

Increasing the characterset from which VMS passwords can be chosen probably
wouldn't really increase VMS security when these mechanisms are properly
deployed. However it would increase usability when users (as they will)
use the same password on multiple systems - this of course reduces security
to that of the least secure system.
Many companies have policies on what makes a strong password - in such an
environment either VMS is left out or the company policy is reduced to the
characterset allowed in VMS which may be entirely inappropriate for some
other less protected systems.

David Webb
VMS and Unix team leader
CCSS
Middlesex University

>

Bill Gunshannon

unread,
Nov 29, 2002, 10:24:02 AM11/29/02
to

I used to regularly run password cracking programs against the master
password files in the department usually then informing the the user
that their password was easily determinable (often telling them what
it was, including their little tricks like "h311o" for "hello"). I
stopped doing it when common Unix eliminated the ability of the none
priveledged user to actually read the encrypted passwords and because
I never found a user who cared. They usually just changed their pass-
word to something else just as easily determined.

As to the idea that the number of possible combinations prevents this
kind of attack, while that was true when I first ran "crack" (it took
a week and broke only one or two passwords) now days, I can do the whole
password file overnight and frequently break all the passwords that are
not pure random strings of characters (which is what I issue for initial
passwords.) Remember also, on most systems there really is only one
password you need to break to compromise the system. Now imagine a lab
full of 2GHZ P3's spending the 4 day Thanksgiving weekend running a
distributed password cracking program against the SYSTEM password. Even
A totally random string is not a guarantee.

All the best.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

Bill Gunshannon

unread,
Nov 29, 2002, 10:31:16 AM11/29/02
to
In article <20021127082748....@caltech.edu>,

David Mathog <mat...@caltech.edu> writes:
>
> Which is nice but of little relevance to VMS security. Only a priv'd user
> should be able to read SYSUAF.DAT, and if that user has evil intentions
^^^^^^^^^^^^^^^^^

> then the system is already compromised - there's no need to crack
> the password file. This contrasts with many (most?) Unix systems, where
> everybody can read the encrypted password file.

Once again, we compare current VMS to 20 year old Unix. I know of no
"current" version of Unix (or Linux for that matter) that allows non-
priveledged access to the encrypted passwords without the explicit
allowance of that by the Administrator. And shadow passwords have been
available as a graft on addition as far back as SunOS4. I expect I will
even put that high on the list of improvements I am making to Ultrix-11
even though I doubt anyone using it will really care. :-)

Michael Austin

unread,
Nov 30, 2002, 8:33:43 PM11/30/02
to
JF Mezei wrote:
>
> Shane Smith wrote:
> >
> > True. However, access to that file would also be restricted in a
> > properly locked down system, so it's still of limited use to hackers.
> > They'd have to get in and get privs to get the file, and the program
> > would be fairly pointless once you'd done that.
>
> But if you have a system manager as an accomplice, he hand send you the
> sysuaf.dat, you crack the boss's password and can then have "fun" on the
> system, undetected and without any intrusion attempts.
>
> This is why it is very important to have full trust in anyone with privileges
> in your system.

If you have said accomplice, it is even easier using something like
SETUSER. or other similar methods.

--
Regards,

Michael Austin OpenVMS User since June 1984
First DBA Source, Inc. Registered Linux User #261163
Sr. Consultant http://www.firstdbasource.com

John E. Malmberg

unread,
Dec 1, 2002, 11:49:44 PM12/1/02
to
Robert Deininger wrote:

> In article , Kilg...@SpamCop.net (Larry Kilgallen) wrote:
>
>> 4. The vulnerability to such a tool is when people have access to
>> unencrypted backup tapes. At some shops that is easier to achieve
>> than privileged access to the running system.
>
> Good point.

There are legitimate uses for such tools for security audits. They are
used to discover if users are using weak passwords such as setting the
system password to "XYZZY" or other obvious ones.

IIRC: There is at least one third party security audit tool that
performs this type of check.

If I have physical privileged access to a system, or the actual backup
tapes, I do not need the SYSUAF passwords to access the data.

-John
wb8...@qsl.network
Personal Opinion Only

JF Mezei

unread,
Dec 2, 2002, 12:57:55 AM12/2/02
to
"John E. Malmberg" wrote:
> If I have physical privileged access to a system, or the actual backup
> tapes, I do not need the SYSUAF passwords to access the data.

There may be occasions where you really want/need to have the password, and
login from a real terminal and start an application from that terminal under
that username so that all log entries are "kosher" when they start to
investigate why one hundred million dollars were transfered out of that bank...

Nic Clews

unread,
Dec 2, 2002, 5:41:31 AM12/2/02
to
David Webb wrote:
>
(Excellent points snipped)
....

>
> Increasing the characterset from which VMS passwords can be chosen probably
> wouldn't really increase VMS security when these mechanisms are properly
> deployed. However it would increase usability when users (as they will)
> use the same password on multiple systems - this of course reduces security
> to that of the least secure system.

This gets into the realms of self defeating security. If you did
increase the allowable range of characters, make them case sensitive,
etc., you stand a far higher risk of defeating the human capability to
commit usefully to memory a password, where it becomes necessary for
systems not protected with cryptography to store the password. Post-it
notes under desks are one method that I've observed.

Another I detected from observed system activity is account sharing.
Despite having own accounts, people shared, because they could not be
bothered going to helpdesk, getting their forgotten password reset after
identity verification, then stand a large chance of forgetting it again
to repeat the whole process. There were other things I saw that didn't
specifically involve weak passwords, but nonetheless provided an
opportunity for improper access.

David Webb

unread,
Dec 2, 2002, 6:33:48 AM12/2/02
to
In article <3DEB38DB...@127.0.0.1>, Nic Clews <sendsp...@127.0.0.1> writes:
>David Webb wrote:
>>
>(Excellent points snipped)
>.....

>>
>> Increasing the characterset from which VMS passwords can be chosen probably
>> wouldn't really increase VMS security when these mechanisms are properly
>> deployed. However it would increase usability when users (as they will)
>> use the same password on multiple systems - this of course reduces security
>> to that of the least secure system.
>
>This gets into the realms of self defeating security. If you did
>increase the allowable range of characters, make them case sensitive,
>etc., you stand a far higher risk of defeating the human capability to
>commit usefully to memory a password, where it becomes necessary for
>systems not protected with cryptography to store the password. Post-it
>notes under desks are one method that I've observed.
>
The problem is that if the users are also using a Unix system then (if allowed)
they will set the password to be the same as for their VMS account.
The restricted set of characters allowed for VMS passwords then make their
Unix passwords too weak. A hacker who then cracks their unix password then
gets their VMS password.

Most sites will therefore set up a password policy on their unix systems
- eg every password must contain an uppercase letter, a lowercase letter a
number and a punctuation character. Such a policy will also be applied to their
windows systems. VMS will then appear to be out of step and may even be
portrayed as being insecure since "it's passwords are too weak".

Note.
Whether having such a password policy in place is actually any good or whether
as you note it just results in people writing down passwords is irrelevent
since all the security manuals say that such a policy is needed for the Unix
systems they are using.


>Another I detected from observed system activity is account sharing.
>Despite having own accounts, people shared, because they could not be
>bothered going to helpdesk, getting their forgotten password reset after
>identity verification, then stand a large chance of forgetting it again
>to repeat the whole process. There were other things I saw that didn't
>specifically involve weak passwords, but nonetheless provided an
>opportunity for improper access.
>

This is a fact of life. It doesn't matter how often you tell them not to or how
simple their passwords are they will still share accounts, write down passwords
etc if doing so makes their life just a little bit easier and they don't think
someone will find out and punish them. This is a management not a technical
issue.

Main, Kerry

unread,
Dec 2, 2002, 7:18:07 AM12/2/02
to
Re: passwords between different OS's ..

Yep, has always been a problem i.e.. no matter what you do, human nature
will dictate that users will try and keep their passwords the same. In
addition, when a user leaves how do you ensure all of their accounts are
disabled on all systems? How do you know when the last time that user
logged into each of the systems they are authorized for without going
around to every system and using OS specific means to look at accounting
records?

Now, you can try to enforce different passwords, but this is like try to
stop the oldest profession in the world (red light stuff).

Another approach that I know many large shops are looking at involves
LDAP based security using a distributed directory. Hence, companies have
the capability to have a distributed directory (each system has sub-set
of that directory that is specific to them local to their system) while
at the same time centralizing security policy.

In this way, disabling a user at one location has the effect of
disabling access on all systems on all platforms. Auditing can be done
from central location.

Does it take planning ? You bet.

Can it be expensive? You bet - especially if the directory is an
additional cost per user.

What about the concern for additional security - given resent security
break-ins, hacker attacks and virus's for many platforms???

Hey, use a very secure OS as the basis for that directory.

Oh, by the way, the enterprise directory is included as part of OpenVMS
with no additional cost.

Reference:
http://www.openvms.compaq.com/commercial/eDir/edir_home.html

:-)

Regards,

Kerry Main
Senior Consultant
Hewlett-Packard (Canada) Co.
Consulting & Integration Services
Voice: 613-592-4660
Fax : 613-591-4477
Email: kerryDOTmain@hpDOTcom
(remove the DOT's and replace with "."'s)

Larry Kilgallen

unread,
Dec 2, 2002, 7:20:21 AM12/2/02
to
In article <IDBG9.22177$kO5.3...@news1.news.adelphia.net>, "John E. Malmberg" <wb8...@qsl.network> writes:
> Robert Deininger wrote:
>
>> In article , Kilg...@SpamCop.net (Larry Kilgallen) wrote:
>>
>>> 4. The vulnerability to such a tool is when people have access to
>>> unencrypted backup tapes. At some shops that is easier to achieve
>>> than privileged access to the running system.
>>
>> Good point.
>
> There are legitimate uses for such tools for security audits. They are
> used to discover if users are using weak passwords such as setting the
> system password to "XYZZY" or other obvious ones.
>
> IIRC: There is at least one third party security audit tool that
> performs this type of check.

The LJK/Security approach is to tell the privileged person
how many guesses it took, but not tell them the password.

> If I have physical privileged access to a system, or the actual backup
> tapes, I do not need the SYSUAF passwords to access the data.

But for some scenarios reading the data is less of a vulnerability than
modifying it. In that case, lower physical security on the backup tapes
than the running system is still not appropriate, for reasons discussed
in this thread.

Larry Kilgallen

unread,
Dec 2, 2002, 7:23:10 AM12/2/02
to

> Oh, by the way, the enterprise directory is included as part of OpenVMS

> with no additional cost.=20

Only on Alpha. You still have to pay extra on VAX.

Jan C. Vorbrüggen

unread,
Dec 2, 2002, 9:30:31 AM12/2/02
to
> Oh, by the way, the enterprise directory is included as part of OpenVMS
> with no additional cost.

And Microsoft has apparently decided to re-write, from scratch, Active
Directory (its take on LDAP) because their current design has unfixable
security holes...

Jan

bri...@encompasserve.org

unread,
Dec 2, 2002, 10:05:05 AM12/2/02
to
> Jean-loup Gailly wrote:
>> By using John, a system administrator can effectively eliminate all weak
>> passwords. I'm surprised that many VMS fans cannot understand the usefulness
>> of such a tool. (I wrote the John VMS patch for a security audit of a
>> large company.)
>
>
> Suppose you do find that your boss has a weak password. What do you do then ?
> Do you go and tell him that you extracted his password and decided that it was
> weak ? Wouldn't that jeoperdize the integrity of the system manager who is not
> supposed to have access to user's passwords ?
>
> He may have access to his own sysuaf.dat on that small departmental VAX, but
> getting his boss's password on the vax would probably also get his password
> for the IBM mainframe and email servers etc etc etc. Revealing that you can in
> fact extract passowrds would jeoperdize the security of other systems in the organisation.

Revealing that you can extract passwords would reveal the fact that
the security of those other systems was already in jeopardy.

Yes, it's no fun to be the bearer of bad news. But don't delude yourself
that you are improving security by staying silent.

> One would have to be very diplomatic in trying to educate the person on the
> use of stronger passowrds without giving any hints that you saw their password.

If you know the boss's password, keep quiet about it and are found out,
that could look bad. Tell him. Tell him flat out and without evasion.
Dancing around the truth won't make it go away.

And try to exercise due care with your list of cracked passwords.

John Briggs

Shane Smith

unread,
Dec 2, 2002, 11:43:31 AM12/2/02
to
<Nitpick mode> There are no 2ghz P3's, although they would be noticeably
faster than the 2ghz P4's that Intel does produce.</nitpick mode>

It's not the speed of the machines generating the test passwords, it's
how fast the target machine will let them try and how many failures it
allows before locking off the account. If they've compromised the
machine enough to copy the sysuaf, they don't need to crack the
password. They're in already.

The only way I know of to start users caring about the guessability of
their passwords is to inconvenience them if they don't pick a good one.
When they get their account, make it clear that any guessable passwords
will be arbitrarily changed, and they'll have to come to you to find out
what it changed to. It's tough on you to start with, but they will
learn.

Shane

-----Original Message-----
From: bi...@cs.uofs.edu [mailto:bi...@cs.uofs.edu]
Sent: Friday, November 29, 2002 7:24 AM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper

In article <3DE667B9...@vl.videotron.ca>,
JF Mezei <jfmezei...@vl.videotron.ca> writes:
> Jean-loup Gailly wrote:
>> By using John, a system administrator can effectively eliminate all weak
>> passwords. I'm surprised that many VMS fans cannot understand the
usefulness
>> of such a tool. (I wrote the John VMS patch for a security audit of a
>> large company.)
>
>
> Suppose you do find that your boss has a weak password. What do you do then
?
> Do you go and tell him that you extracted his password and decided that it
was
> weak ? Wouldn't that jeoperdize the integrity of the system manager who is
not
> supposed to have access to user's passwords ?
>
> He may have access to his own sysuaf.dat on that small departmental VAX, but
> getting his boss's password on the vax would probably also get his password
> for the IBM mainframe and email servers etc etc etc. Revealing that you can
in
> fact extract passowrds would jeoperdize the security of other systems in the
organisation.
>

> One would have to be very diplomatic in trying to educate the person on the
> use of stronger passowrds without giving any hints that you saw their
password.

I used to regularly run password cracking programs against the master


password files in the department usually then informing the the user
that their password was easily determinable (often telling them what
it was, including their little tricks like "h311o" for "hello"). I
stopped doing it when common Unix eliminated the ability of the none
priveledged user to actually read the encrypted passwords and because
I never found a user who cared. They usually just changed their pass-
word to something else just as easily determined.

As to the idea that the number of possible combinations prevents this
kind of attack, while that was true when I first ran "crack" (it took
a week and broke only one or two passwords) now days, I can do the whole
password file overnight and frequently break all the passwords that are
not pure random strings of characters (which is what I issue for initial
passwords.) Remember also, on most systems there really is only one
password you need to break to compromise the system. Now imagine a lab
full of 2GHZ P3's spending the 4 day Thanksgiving weekend running a
distributed password cracking program against the SYSTEM password. Even
A totally random string is not a guarantee.

All the best.

bill

Nic Clews

unread,
Dec 2, 2002, 11:48:48 AM12/2/02
to
David Webb wrote:
>
...
I fully agree with your points, I note with interest that on the
Roadmaps, OpenVMS is slated for case sensitivity in passwords.

Just how far do we push the human in authorizing themselves to a system,
where increasing use of online systems demand a wider audience and
participation of non computer literate users, some of those who struggle
with a 4 digit pin.

It drags the discussion around to one of the words I mentioned
"complacency", this is the enemy of security, the policies can encourage
the bad practices leading to breaches without cracking.



> This is a fact of life. It doesn't matter how often you tell them not to or how
> simple their passwords are they will still share accounts, write down passwords
> etc if doing so makes their life just a little bit easier and they don't think
> someone will find out and punish them. This is a management not a technical
> issue.

Precisely, and the more draconian the policy, the more often this will
occur in my view. You could set a management policy that would lead to
the dismissal of much of the workforce, but the key I believe is in
compromise, and perhaps the adoption of other methods of authentication.

I believe we're the converted, I'm interested in others' points of view.

David Webb

unread,
Dec 2, 2002, 12:07:14 PM12/2/02
to

References please.

Bill Gunshannon

unread,
Dec 2, 2002, 12:21:22 PM12/2/02
to
In article <01C299DF...@sulfer.icius.com>,

Shane Smith <ssm...@icius.com> writes:
> <Nitpick mode> There are no 2ghz P3's, although they would be noticeably
> faster than the 2ghz P4's that Intel does produce.</nitpick mode>

Sorry, I never claimed to keep up with this weeks Intel abomination.
What are they up to now?? P5? P6? P7?

>
> It's not the speed of the machines generating the test passwords, it's
> how fast the target machine will let them try and how many failures it
> allows before locking off the account. If they've compromised the
> machine enough to copy the sysuaf, they don't need to crack the
> password. They're in already.

The programs being discussed here do not attempt to login they
work to determine the string that encrypts to a match for the
encrypted string from the password file (whatever it may be called).
Access to unencrypted backups was posted here as a possible method
one could get the SYSAUF without having priveledged access. How many
places degauss tapes before throwing them in the dumpster?? (Outside
of the government, anyway.) I have been given old backups by the data
center here because they changed tape format and I still used the
old style. I know they didn't.

>
> The only way I know of to start users caring about the guessability of
> their passwords is to inconvenience them if they don't pick a good one.

Frequently, for political reasons, that is not an option. Most of us
are peons and not decision makers. Inconveniencing my boss or his boss
could shorten my career rather quickly.

> When they get their account, make it clear that any guessable passwords
> will be arbitrarily changed, and they'll have to come to you to find out
> what it changed to. It's tough on you to start with, but they will
> learn.

Yeah, looking for a new job in todays environment could be very tough on
you. And they won't learn. I even have a policy that new passwords (some
users tend to forget their's quite frequently) must be picked up in person.
A very reasonable policy in my mind. (Who is that really on the other end
of that email??) I have, in the past, been forced to violate that policy
by those above me.

Shane Smith

unread,
Dec 2, 2002, 12:15:53 PM12/2/02
to
I believe Jean-Loup's program is an interesting and possibly useful one,
but it doesn't help against the main techniques I know for capturing
passwords. (Yes, I was on the other side once, long ago.)

The worst one I know is where the system administrator mandates and
enforces ridiculously complex and hard to remember passwords. Sure,
"hX0r13V7aI0" would be hard to crack, but it's so hard to remember the
user will write it on a post-it and stick it somewhere convenient. Often
to the cube wall, in plain sight. We have one customer whose sysadmin
issues passwords like this because he believes they're secure, and
doesn't let the users change them. They're also forbidden to write them
down, but they can't remember them so they have to. I could grab as many
username/password combos as I liked just by wandering around the desks
in the morning. That kind of security is false because it fails to take
into account the human factor.

Another good way to guess a password is by knowing the person who picked
it. I used to have a sysadmin who was known to be a big Status Quo fan
(the rock band). I got his password on the third attempt just by
throwing their song titles at it. I had also managed to get a few of the
letters by watching his fingers while he was logging in, which helped
narrow the field.

Then there's the old "fake login screen" trick, which I once used on the
teacher of a Digital security course in England. Worked like a charm,
sent her a reply from her own account in mid-lecture while her terminal
was being echoed to the projection screen. Giggles all round.

And finally, the old packet sniffer approach, although the last time I
used it was in the form of an RS232 Y-splitter and a VT100. If you can
see what goes over the wire, you're in. Hardly anyone I know uses SSL
within their LAN.

Those are obvious, I won't get into the sneakier stuff. Don't want to
give anyone ideas.

Shane

-----Original Message-----
From: Jean-François PIÉRONNE [mailto:jf.pi...@laposte.net]
Sent: Friday, November 29, 2002 12:38 AM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper


Salut Jean-Loup,

Jean-François

> By using John, a system administrator can effectively eliminate all weak
> passwords. I'm surprised that many VMS fans cannot understand the usefulness
> of such a tool. (I wrote the John VMS patch for a security audit of a
> large company.)
>

> Jean-loup Gailly
> http://gailly.net/security/

David Mathog

unread,
Dec 2, 2002, 12:30:56 PM12/2/02
to
On Thu, 28 Nov 2002 13:09:23 +0000 (UTC)
jl...@gailly.OmitThisWord.net (Jean-loup Gailly) wrote:

> I advise system administrators who do not believe this to try
> John at least once. You will be amazed to see how bad most passwords are,

Which is why I prefer assigning users randomly generated passwords which
they cannot change. The alphabet includes about 90 characters (Unix, so both
upper and lower can be used) which gives a password
space of about 90^8 I ran John on my passwd file once for kicks on a
DS10 (466Mhz) and it didn't crack a single password in 24 hours. If I didn't
have to support Solaris I'd use longer passwords.

The upside - very difficult to crack.
The downside - these are so hard to remember that all users write their
passwords down.

Regards,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

bri...@encompasserve.org

unread,
Dec 2, 2002, 11:41:18 AM12/2/02
to
In article <01C299DF...@sulfer.icius.com>, Shane Smith <ssm...@icius.com> writes:
> <Nitpick mode> There are no 2ghz P3's, although they would be noticeably
> faster than the 2ghz P4's that Intel does produce.</nitpick mode>
>
> It's not the speed of the machines generating the test passwords, it's
> how fast the target machine will let them try and how many failures it
> allows before locking off the account. If they've compromised the
> machine enough to copy the sysuaf, they don't need to crack the
> password. They're in already.

Not neccessarily. The example of reading SYSUAF from backup tapes
has been given. And we have the example of a system manager using
a crack tool to identify accounts with weak passwords. Or maybe
when the system manager moved SYSUAF off the system disk, he
was careless with file permissions. Or maybe he installed a web
server with SYSPRV, thus providing a conduit for privileged
read-only access. Or maybe he recycled a volume formerly containing
a copy of SYSUAF and the attacker has succeeded in a little disk
scavenging. There are any number of ways that a copy of SYSUAF
could be obtained without an attacker having full system privileges.

An offline password cracker is not completely worthless.

An online password cracker is, as you point out, likely to be
of limited value.

John Briggs

Charlie Hammond

unread,
Dec 2, 2002, 1:11:39 PM12/2/02
to
In article <01C299DF...@sulfer.icius.com>,
Shane Smith <ssm...@icius.com> writes:
..

>The only way I know of to start users caring about the guessability of
>their passwords is to inconvenience them if they don't pick a good one.
..

I am of the opinion -- based on personal experience, although not necessarily
accepted by my employer -- that even users who care very much about
secute passwords tend to pick very poor passwords from time to time.
My preferred solution is to enforce generated passwords. Yes, this has
drawbacks too, but I find they are better than user chosen passwords.

--
Charlie Hammond -- Hewlett-Packard Company -- Pompano Beach FL USA
(hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)
All opinions expressed are my own and not necessarily my employer's.

Charlie Hammond

unread,
Dec 2, 2002, 1:33:43 PM12/2/02
to
In article <01C299E3...@sulfer.icius.com>,
Shane Smith <ssm...@icius.com> writes:

'''


>The worst one I know is where the system administrator mandates and

>enforces ridiculously complex and hard to remember passwords. ...
>... [users are ]forbidden to write [passwords] down, but they can't

remember them so they have to. I could grab as many
>username/password combos as I liked just by wandering around the desks

>in the morning. ...

Writing down passwords is one thing.
Letting them lie around openly is quite another.
And then there is failure to enforce a security policy that is
obviously not being followed.

Atlant Schmidt

unread,
Dec 2, 2002, 1:52:06 PM12/2/02
to
Charlie Hammond wrote:

> In article <01C299E3...@sulfer.icius.com>,
> Shane Smith <ssm...@icius.com> writes:
>
> '''
> >The worst one I know is where the system administrator mandates and
> >enforces ridiculously complex and hard to remember passwords. ...
> >... [users are ]forbidden to write [passwords] down, but they can't
> remember them so they have to. I could grab as many
> >username/password combos as I liked just by wandering around the desks
> >in the morning. ...
>
> Writing down passwords is one thing.
> Letting them lie around openly is quite another.
> And then there is failure to enforce a security policy that is
> obviously not being followed.

Prediction: Passwords are a thing of the past;
it'll all be biometrics soon anyway. Fingerprints,
iris scans, voiceprints, signature, finger lengths,
I don't know which will win, but it will be some
sort of biometrics.

And if it isn't biometrics soon, then as a bridge it will
be a knowledge+token sort of security as as exemplified
by the RSA Security SecureID gadget. This is practical
today and is being used by more and more folks.

http://www.rsasecurity.com/products/securid/hardware_token.html

Atlant


Shane Smith

unread,
Dec 2, 2002, 1:54:15 PM12/2/02
to
Agreed, they shouldn't be doing it, and granted few of them put the
paper in plain view. My point is that they are forced to record the
passwords since they are too difficult to remember. A fair chunk of the
blame lies with the policy itself for not taking into account the human
element. If they just made the passwords pronouncable, they'd cut the
problem down considerably as more people would be capable of memorizing
them.

Shane

-----Original Message-----
From: hammond@not@peek.ppb.cpqcorp.net
[mailto:hammond@not@peek.ppb.cpqcorp.net]
Sent: Monday, December 02, 2002 10:34 AM
To: Info...@Mvb.Saic.Com

Subject: RE: Cracking OpenVMS passwords with John the Ripper


In article <01C299E3...@sulfer.icius.com>,
Shane Smith <ssm...@icius.com> writes:

'''
>The worst one I know is where the system administrator mandates and
>enforces ridiculously complex and hard to remember passwords. ...
>... [users are ]forbidden to write [passwords] down, but they can't
remember them so they have to. I could grab as many
>username/password combos as I liked just by wandering around the desks
>in the morning. ...

Writing down passwords is one thing.
Letting them lie around openly is quite another.
And then there is failure to enforce a security policy that is
obviously not being followed.

--

Bob Koehler

unread,
Dec 2, 2002, 1:17:27 PM12/2/02
to
In article <3DE5E679...@nospamn.sun.com>, Andrew Harrison SUNUK Consultancy writes:
> This has been untrue for years for Solaris I cannot comment
> on other UNIX's.

This has been untrue on most UNIX for about a decade and a half. If and
only if the admin turns it on. Has Solaris eliminated the ability of
the admin to turn it off?

Bob Koehler

unread,
Dec 2, 2002, 1:21:34 PM12/2/02
to
In article <t955sa...@127.0.0.1>, marco viola <m...@mail.com> writes:
> Andrew Harrison SUNUK Consultancy <Andrew_No....@nospamn.sun.com> wrote:
>> The passwords are held in /etc/shadow and this by default
>> isn't readable except by root.
>
>
>> ls -la /etc/shadow returns
>> -r-------- 1 root sys 674 Nov 27 09:55 /etc/shadow
>
> Not writable; interesting.
>
> How do you add users?

Utilities like the admin tool and the passwd command are suid root or
only runnable by root.

Since root owns the file and root ignores most file permissions the
programs can deal with the protection.

Bob Koehler

unread,
Dec 2, 2002, 1:23:49 PM12/2/02