Cracking OpenVMS passwords with John the Ripper
Jean-loup Gailly
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
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
<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
> 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
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
>
> 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
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
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
>
> 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
> 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
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
> 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
>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
>
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
> 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
>> 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.
DCL.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
David Mathog
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
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
(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
: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
:A README file is at http://gailly.net/security/john-VMS-readme.html
:or in ascii at http://jl.gailly.net/security/README.VMS
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
In article <as2d1o$2kmi$1...@news2.ipartners.pl>, "Tomasz Dryjanski" <tdryjans...@hotmail.com> writes:
:> 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
> 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
>
> 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
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
>
>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
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
> 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
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
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
root effectively has the equivalent of BYPASS privilege. The permission
mask is more or less meaningless in such circumstance.
Georges A. Tomazi
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
> 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
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
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
>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.)
>
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
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
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
>
> 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.
>
> 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
> 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
> 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
>
(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
>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.
>
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
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
> 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
> 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
> 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
>> 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
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
>
...
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
References please.
Bill Gunshannon
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
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
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
> 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
>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
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
> 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
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
> 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
> 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
> Jean-loup Gailly wrote:
>> 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.)
>
>
> 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 ?
Where we work the system manager would be derlict in his duties if he
did not bring this to the attention of the boss. Weak == guessable,
so there's no decision to be made.
Bob Koehler
>
> I have only seen in movies people finding password after 3 attempts.
I was watching GoldenEye rerun last week. "You sit on it, but you
don't take it with you" is a password none of my systems would allow
to begin with.
As a matter of fact, my systems wouldn't allow phonetic spellings of
less common Gaelic terms, something which was once touted as a good
example of a good password.
But the PHMs have got 2 day password minimum lifetimes set on some
of our systems. There's a good way not to have security.
JF Mezei
> 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.
Or simply add words to the dictionary that are common to your enterprise or
locality. When I've have users on the phone who had problems changing
passwords, I would reply/enable my terminal (or step next door to the OPA0 to
see the messages) and tell them that the password they used was in a
dictionary or that it was in the history file. I would explain to them that
proper password management is extremely important because this system was
accessible worldwide. And would give them tips on how to choose a password
that is robust yet easy to remember.
Educating users is far more effective than playing detective in my opinion.
Since I was dealing with users from different institutions, it was quite
interesting to see the different corporate cultures. (all were involved in
corporate security, you'd think that they would know about security). One UK
bank stood out with users fully aware of what the corporate passowrd policies
were and when they explained how they worked at their banks, I changed their
account to match their policy and also changed the passowrd expiry date to put
their account "in sync" with their accounts at their banks so that they would
all expired at the same time: they would then change all their passwords at
the same time once every 90 days.
Other users from other banks just weren't aware of the password policy and
just changed it whenever they were forced to and didn't understand the need
for a password dictionary etc etc.
Note that the password dictionary isn't quite up to snuff in my opinion. One
user kept trying dirty words in english. She was italian in origin, so I told
her (after seing the opcom messages and knowing her) to think of that word in
italian. She laughed, tried it and it worked. I didn't know what word she was
thinking about, but figured it had something to do with sex.
Lets face it, there are systems where password security isn't all that
important. And there are others where it is extremely important. Explaining to
the users the importance of the password goes a long way towards gettin the
users to take the passowrd policy seriously.
There were operators who had to run a nightly SWIFT job. They had no idea what
those transactions were and didn't take the system seriously. I spent one
evening with them, chatting, getting to know them and observingt how they
worked (learning more about IBM and tandem operations at the same time so it
wasn't a selfless act on my part). And when the time came to do the SWIFT job,
I showed them the actual transactions that they were about to send. They
couldn't believe the numbers of zeros on those numbers. (these transactiosn
were generated on an IBM mainframe and then picked up via the SNA gateway by
the swift app on VMS).
The next day, the operations manager phoned me and asked me what I had done to
his operators since they came to him and told him how important the VAXes were
and were sending out transactions in the millions of dollars, instead of the
silly $40 transactions the IBM was processing for ATMs :-)
They took the initiative to properly secure the passwords that had been
written down nect to the VT consoles because they realised that they had a
responsability and didn't want to screw up now that they knew how important
that machine was.
Bob Koehler
> Increasing the characterset from which VMS passwords can be chosen probably
> wouldn't really increase VMS security when these mechanisms are properly
> deployed.
No, but it does help to keep VMS in shops where the security "experts"
are convonced they must have rules requiring characters VMS doens't
currently allow or care about.
Bob Koehler
> 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.
>
I'm still disappointed that I couldn't use ö in a password.
Bill Gunshannon
> to the cube wall, in plain sight.
Or the last page of their desk calendar. :-)
Bill Gunshannon
Atlant Schmidt <atlant...@mindspring.com> writes:
> Charlie Hammond wrote:
>
> 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.
If you have been folowing any of this since 9-11 you would know
how unlikely that really is. None of them have worked reliably
and some of them were easily defeated by high school kids using
materials found around the house (An example was lifting a finger-
print from a drinking glass and "installing" it on a fake finger
made with JELLO.) Voice systems have very high failure rates as
many factors (a cold, excitement, etc.) can significantly change
it. And how many people are going to be willing to stick their
eye up against something they don't understand?? My stupid little
"laser" pointer says don't shine it in your eyes.
Charlie Hammond
bi...@cs.uofs.edu (Bill Gunshannon) writes:
..
>> Charlie Hammond wrote:
>>
>> 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.
Nope.
Incorrect attribution.
I did NOT write this, nor did I express an opinion on it.
Atlant Schmidt
> In article <3DEBABD6...@mindspring.com>,
> Atlant Schmidt <atlant...@mindspring.com> writes:
>
> > 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.
>
> If you have been folowing any of this since 9-11 you would know
> how unlikely that really is. None of them have worked reliably
> and some of them were easily defeated by high school kids using
> materials found around the house (An example was lifting a finger-
> print from a drinking glass and "installing" it on a fake finger
> made with JELLO.) Voice systems have very high failure rates as
> many factors (a cold, excitement, etc.) can significantly change
> it. And how many people are going to be willing to stick their
> eye up against something they don't understand?? My stupid little
> "laser" pointer says don't shine it in your eyes.
So you say, but I know that you and I can recognize
the people we know under a wide variety of
lighting, audio quality, etc., and computers
are rapidly growing in power, so the odds
are that *somebody* will develop "biometrics
that works" real soon now, probably mimicing
one of the recognition schemes that we routinely
use.
Notice, BTW, that I said "iris scans" and not
"retinal scans". Iris scans can be done quite
easily at typical human-to-monitor distances
and systems that require that you possess live,
reactive irises aren't susceptible to the simple
passive fake-outs seen in movies like "Charlie's
Angels".
Sidenote: Ray Kurzweil's "The Cognitive
Computer" makes a fascinating read on the
impact of exponentially-increasing computer
power and what it may bring about.
Atlant
JF Mezei
> Prediction: Passwords are a thing of the past;
> it'll all be biometrics soon anyway.
Assuming VMS survives this long, how will it impact SYSUAF.DAT ? Would the
engineers modify the format of SYSUAF to allow for oneway encryption of
biometric data as well a a password ? Or would they prefer to add a layered
product with sufficient privs to bypass the SYSUAF password mechanism?
Shane Smith
few releases ago. It'd be relatively easy to plug into that, I would
imagine.
Shane
Bill Gunshannon
Atlant Schmidt <atlant...@mindspring.com> writes:
> and systems that require that you possess live,
> reactive irises aren't susceptible to the simple
> passive fake-outs seen in movies like "Charlie's
> Angels".
Sorry, I rely on more reputable sources for information on
biometrics. :-)
>
> Sidenote: Ray Kurzweil's "The Cognitive
> Computer" makes a fascinating read on the
> impact of exponentially-increasing computer
> power and what it may bring about.
>
Heard all that before. I'm still waiting for my personal
gyrocopter to eliminate fighting the traffic on crowded
expressways and the drive-it-self car so I can enjoy a
good book while my car handles the task of navigating and
the computer controlled house with robotic man servants
or even speech recognition that actually works in some
reliable manner so I can dictate my papers instead of
typing them. And waiting and waiting and waiting.....
[Hint: all of the above items were either predicted or in
some cases even advertised as existing. Some of them were
announced as "imminent" 40 years ago.]
Larry Kilgallen
> IIRC they added the ability to use an external verification mechanism a
> few releases ago.
Certainly by V5.5-2, which is the earliest version still supported.
Larry Kilgallen
> Heard all that before. I'm still waiting for my personal
> gyrocopter to eliminate fighting the traffic on crowded
> expressways and the drive-it-self car so I can enjoy a
> good book while my car handles the task of navigating and
That is called commuter rail, and while there is none in your town,
there was some 100 years ago :-)
Tim Llewellyn
Atlant Schmidt wrote:
>
> 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.
>
Hmmm, I've seen a few movies where fingers, eyeballs whatever
were actually removed from the individual or the threat of removal
was used to defeat biometric scans. I for one would prefer it if
lowlife did not have the option of maiming me for the contents
of my current account.
> 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
* PLEASE NOTE tim.ll...@cableinet.co.uk address is NO LONGER VALID *
Hoff Hoffman
In article <as54i3$4jt$1...@home.gailly.net>, jl...@gailly.OmitThisWord.net (Jean-loup Gailly) writes:
: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 recall making no such recommendation -- I had intended to offer
alternative algorithms as an option, but not as a recommendation.
...
: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.)
Your phrasing had implied other uses as the primary goal for the tool.
Please spend your time writing a filter for use on OpenVMS, and not a
PC-based password cracking tool. While I expect that John the Ripper
is a good tool, cracking tools are and have been available for some
years now and are certainly useful to authorized security managers
for verifying passwords. They also run afoul of breakin evasion and
of other default techniques, assuming the site has good security for
its critical system data files and (as Larry Killgallen mentioned)
its system data archives.
Password filters and schemes are rather less commonly available and
-- as was quite correctly pointed out in one of the various email
discussions that have started resulting from this thread -- these
filters and algorithms are rather more difficult to implement in a
correct and consistent and secure fashion. Poor implementations can
and do serve to the detriment of system security; to weaken security.
Stronger implementations of these can serve to reduce the likelyhood
that the users can choose bad or weak passwords.
When password filters are better, John The Ripper and other tools have
rather larger and more complex targets -- well, assuming the authorized
or nefarious user does not have a copy of the password database, as is
the case here.
I do have one or two sneaky ideas for rendering the approach used by
John The Ripper somewhat more, um, unreliable. But I digress. :-)
But all that written, password-based schemes are weak, and are getting
weaker.
---------------------------- #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
JF Mezei
> > reactive irises aren't susceptible to the simple
> > passive fake-outs seen in movies like "Charlie's
> > Angels".
>
> Sorry, I rely on more reputable sources for information on
> biometrics. :-)
All those fancy authorisation are totally useless. Every sunday, ABC TV (in
USA) has a one hour documentary showing how a young girl (Sydney Bristow) can
break into all the super high intensity security systems/building in mere
seconds and without much training. This last sunday, she needed fingerprints
of a dead guy in the balkans and she had no problems getting them in order to
gain access to some fancy lock that opens a suitacse that contained a laptop
which contain the super secret passwords/codes. (On has to wonder however how
she gets through airport security with all her high tech gadgets.
John Santos
> In article <asgdoa$qop3a$2...@ID-135708.news.dfncis.de>,
> bi...@cs.uofs.edu (Bill Gunshannon) writes:
> ..
> >> Charlie Hammond wrote:
> >>
> >> 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.
> ..
>
> Nope.
> Incorrect attribution.
> I did NOT write this, nor did I express an opinion on it.
Actually, according to Bill's post, Atlant wrote it (and in
a subsequent follow up, Atlant responds, snipping the bogus
">> Charlie Hammond wrote:" line but not challenging the
attribution...)
Charlie: Since the "Charlie Hammond wrote:" line and the
following text has the same number of >'s, all of it is
quoted from the next level out, which was Atlant's post.
Bill: When you snip a post back to some relevant point
(a Good Thing, IMHO), and you remove everything someone
said, you should also remove the attribution line to
avoid this type of confusion.
The only reason I bring this up is I've noticed it several
times recently on c.o.v, and sometimes it results in rants,
name calling, fights, etc. I think we have enough of that
when there is a real disagreement.
P.S. This thread is making me re-think some security
issues, which is a good thing, even if I decide we are
already doing it right for the most part. There is always
room for improvement.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Paul Sture
> 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.
I had never bothered much with generated passwords until a couple of years ago.
That day I wasn't feeling very creative, and the password generator
cheerfully gave me some nonsense words which I found easy to remember.
Why was I changing all my passwords? I had been playing with Samba on
VMS and discovered a published security hole in NT, which would allow
an attacker to attack passwords a few bytes at a time. Oh dear, I
had been using Samba with a privileged VMS username. Quickly changed,
but lesson learnt.
--
Paul Sture
Switzerland
John Santos
There was some 25 years ago... (IIRC, it was suspended during the
blizzard of 78 and was never resumed afterwards. The tracks have since
been replace by a bike path.)
Bill Gunshannon
Having lived in Germanty for about 6 year I can assure you there is
nothing I have ever seen in the US that qualifies as commuter rail.
And I was talking about the personal gyrocopter promised by such
rags as Popular Science back in the 50's-60's.
Bill Gunshannon
in NEPA since before I was born (which is a lot longer ago than I
wish it was!!) There is one of those "rails-to-trails" right behind
my house where I frequently go running (actually, the old railroad
bed is part of my property line) but it was freight only and hasn't
run a passenger since the trolley to the lake days when my mother was
a child.
Bill Gunshannon
JF Mezei <jfmezei...@vl.videotron.ca> writes:
>
> All those fancy authorisation are totally useless. Every sunday, ABC TV (in
> USA) has a one hour documentary showing how a young girl (Sydney Bristow) can
> break into all the super high intensity security systems/building in mere
> seconds and without much training.
Documentary??
Larry Kilgallen
> In article <102120219465...@ives.egh.com>,
> John Santos <JO...@egh.com> writes:
>> On 2 Dec 2002, Larry Kilgallen wrote:
>>
>>> In article <asghgu$r33oi$1...@ID-135708.news.dfncis.de>, bi...@gw5.cs.uofs.edu (Bill Gunshannon) writes:
>>>
>>> > Heard all that before. I'm still waiting for my personal
>>> > gyrocopter to eliminate fighting the traffic on crowded
>>> > expressways and the drive-it-self car so I can enjoy a
>>> > good book while my car handles the task of navigating and
>>>
>>> That is called commuter rail, and while there is none in your town,
>>> there was some 100 years ago :-)
>>
>> There was some 25 years ago... (IIRC, it was suspended during the
>> blizzard of 78 and was never resumed afterwards. The tracks have since
>> been replace by a bike path.)
>
> Where was that?? There has not been passenger service on any track
> in NEPA since before I was born (which is a lot longer ago than I
> wish it was!!)
What about the Laurel Line, or doesn't an Interurban count ?
You are a real youngster :-)
JF Mezei
> > All those fancy authorisation are totally useless. Every sunday, ABC TV (in
> > USA) has a one hour documentary showing how a young girl (Sydney Bristow) can
> > break into all the super high intensity security systems/building in mere
> > seconds and without much training.
>
> Documentary??
Well, everything broadcasted on TV is true, isn't it ? If it isn't true, how
come they have footage showing it ?
Same with reputable newspapers such as World Weekly News are far more
believable since they always have pictures of the events they are reporting
on, wheras rags such as the new york times just put text in a narrow column
without supporting images.
NOw, if VMS marketing were smart they would arrange for the World Weekly New
to report on:
"Aliens unable to break into VMS system", complete with a picture of an angry
Alien in front of a terminal.
Alan Greig
(David Webb) wrote:
>In article <3DEB6E87...@mediasec.de>, Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbr...@mediasec.de> writes:
>>> 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
>
>References please.
Call Microsoft and ask for a briefing on Active Directory security and
their plans to re-implement for .NET
If they act dumb try adding "I've heard that you no longer claim a W2K
domain is an effective security boundary. Can you explain this?"
>David Webb
>VMS and Unix team leader
>CCSS
>Middlesex University
--
Alan
Alan Greig
An MS Windows based system will handle it via the external
authentication mechanism...
--
Alan
Doc.Cypher
No effort was made to verify the identity of the sender.
--------------------------------------------------------
On Mon, 02 Dec 2002, Atlant Schmidt <atlant...@mindspring.com> wrote:
>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.
Despite there being problems, I now have quite a few users here who deposit
a public key on the system and use that with SSH to log in.
Their private key then becomes the "prize" that would give you access to
all systems they use the keypair for - if you also get the passphrase for
it (Rubber hose cryptography anyone?).
One user brought up an issue with this though...
On a *ix system they'd ask the sysadmin to disable logins with a password,
this being achieved by replacing the password entry with *. How can I do
this on VMS?
Doc.
--
The bigger the humbug, the better people will like it.
~ Phineas Taylor Barnum. https://vmsbox.cjb.net
Main, Kerry
Like so many other things, since security costs escalate with increasing
levels, it depends on what your requirements are and/or what you are
protecting.
There are three main levels normally used today - often referred to as
factors.
In increasing level of complexity and cost:
1. What you know - username/password
2. What you have - cards, keys etc
3. What you are - biometrics - fingerprints, Iris checks etc.
Many of the issues outlined in this thread would be resolved by adopting
level 2 + level 1 i.e.. secure card access combined with
username/password. By adopting more than one level, this is called
multi-factor security.
Note - The secure cards today do not require readers on terminals or
laptops - only that you physically have them.
Reference:
http://www.rsasecurity.com/products/securid/hardware_token.html
Does it address all the issues?
No, but the costs are much less than going to level 3. Some sites don't
care about the extra cost and going to level 3 makes sense for them.
Is level 2 without issues?
No. What happens if a user forgets their card at home? Well, imho, its
no different if you forget your card access for physical access to all
locations in the building - you either go home and get your card, or
some temporary card with appropriate controls is signed out to you. How
many people go to work without your wallet or purse?
If the card is stolen, that person must also crack your username and
password. A quick call to the help desk and that card will be no longer
valid - no matter what they punch in.
As to the future, I suspect we will continue to see user/pass as the
main scheme, but if there is a big mainstream increase in any of these
levels, it will be with "what you have" level 2 technologies.
While it may be "cool" or look "neat", most things we protect at work or
at home today do not warrant the extra costs of level 3 "what you are"
technologies.
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)
-----Original Message-----
From: Tim Llewellyn [mailto:tim.ll...@blueyonder.co.uk]
Sent: December 2, 2002 5:47 PM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper
Atlant Schmidt wrote:
>
> 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.
>
Hmmm, I've seen a few movies where fingers, eyeballs whatever were
Larry Kilgallen
> On a *ix system they'd ask the sysadmin to disable logins with a password,
> this being achieved by replacing the password entry with *. How can I do
> this on VMS?
Presuming you mean "while allowing authentication with another technique",
this will be done by setting a combination of SYSUAF flags.
If you meant "while also disabling all other logins", the answer is still
DISUSER.
Larry Kilgallen
External Authentication providers are expected to store their own
metadata. The Windows ACME provided with the VMS Advanced Server
does that by relying (among other things) on a Microsoft system,
but when VMS releases the ability to write your own Authentication
Provider (ACME), each ACME author can choose any method they want.
David Webb
>In article <as7ll2$q9e$1...@aquila.mdx.ac.uk>, dav...@alpha2.mdx.ac.uk (David Webb) writes:
>> Increasing the characterset from which VMS passwords can be chosen probably
>> wouldn't really increase VMS security when these mechanisms are properly
>> deployed.
>
> No, but it does help to keep VMS in shops where the security "experts"
> are convonced they must have rules requiring characters VMS doens't
> currently allow or care about.
>
Which is pretty much what I said in the next few paragraphs of that posting.
David Webb
VMMS and Unix team leader
CCSS
Middlesex University
Jan C. Vorbrüggen
> the people we know under a wide variety of
> lighting, audio quality, etc., and computers
> are rapidly growing in power, so the odds
> are that *somebody* will develop "biometrics
> that works" real soon now, probably mimicing
> one of the recognition schemes that we routinely
> use.
It wouldn't even nowadays be a question of computer power - for about a
decade now it a question of "how-to" or "know-how". As a co-developer and
-inventor of the approach that still is, AFAIK, the best face recognition
algorithm I can tell you we have a long way to go - and even your "gold
standard", your own recognition ability, is more fallible than you know.
> Sidenote: Ray Kurzweil's "The Cognitive
> Computer" makes a fascinating read on the
> impact of exponentially-increasing computer
> power and what it may bring about.
Kurzweil's a modern-age crackpot.
Even his name is a giveaway.
Jan
David Webb
Alan,
Sorry I thought Jan was referring to something different than the fact that
PHYSICAL access to any domain controller in a forest can be used to compromise
an entire organisation which you reported in september.
Reporting that to management has resulted in our AD implementation being
simplified down to just a single domain since having multiple domains (or
forests) doesn't add any real security and is easier to manage.
Microsoft just says that we should severely restrict Physical access to domain
controllers.
Atlant Schmidt
>
> > Sidenote: Ray Kurzweil's "The Cognitive
> > Computer" makes a fascinating read on the
> > impact of exponentially-increasing computer
> > power and what it may bring about.
>
> Kurzweil's a modern-age crackpot.
There are apparently a fair number of blind
people and musicians who disagree with you.
Atlant
Atlant Schmidt
> Atlant Schmidt wrote:
>
> > 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.
> >
>
> Hmmm, I've seen a few movies where fingers, eyeballs whatever
> were actually removed from the individual or the threat of removal
> was used to defeat biometric scans. I for one would prefer it if
> lowlife did not have the option of maiming me for the contents
> of my current account.
That was my point about the "Charlie's Angel"
joke (which someone apparently took seriously).
The Angel had fake-irises (in the form of contact
lenses), but this wouldn't fool a real recognition
system as the fake irises would be unresponsive
to changes in light level.
Similarly, modern fingerprint recognition can
be combined with other methods to decide
whether the finger is alive or dead. It can
also challenge you to present a specific
digit out of your ten (or so).
I guess I have a lot more faith in the speed
of technological progress than most of you do.
But then again, you're still trying to get minor
improvements made to DCL (like longer strings
and longer prompts, so I can see where you
might be jaded. :-)
Atlant
Alan Greig
(David Webb) wrote:
>
>Reporting that to management has resulted in our AD implementation being
>simplified down to just a single domain since having multiple domains (or
>forests) doesn't add any real security and is easier to manage.
>Microsoft just says that we should severely restrict Physical access to domain
>controllers.
Which can be difficult if you have domain controllers in highly
unstable countries - as we do!. Armed guards protect the compound 24x7
but it will probably get a forest all if its own when we move to AD
live. Although we are now looking at delaying roll out for the .NET
re-architecturing.
With .NET supposedly a (.NET) domain in a (.NET) forest can again be a
security boundary.
Larry Kilgallen
> I guess I have a lot more faith in the speed
> of technological progress than most of you do.
The issue is not technological progress, but the speed of adoption.
For the past 20 years there has been no need for reusable passwords,
yet they still predominate.
Bill Gunshannon
I'm 52 and grew up falling asleep to the rhythm of the rails as the tracks
were less than 50' from my house. The only passenger service I ever saw
locally was when we hopped a boxcar for a quick ride to the other end of
town. Unless you count things like The Stourbridge Lion which still hauls
passengers to Honesdale for a day of shopping in the quaint shops and back.
Or Pocono Norhteast who fielded 2 Rapid Transit type cars and never got
far enough along to actually carry a passenger before the cpompany folded up.
The nearest serious passenger service was Harrisburg and even that died
long ago (although I hear they want to revive it not only there, but up
here as well. But at this stage of the game it will do more harm than
good.)
Bill Gunshannon
>
> On a *ix system they'd ask the sysadmin to disable logins with a password,
> this being achieved by replacing the password entry with *. How can I do
> this on VMS?
How about having the system generate a maximum length random password
and just not tell anyone what it is?? Not exactly the same, but I'll
bet the result is the same.
Shane Smith
within hearing distance of the local railway line. It mostly carried
cargo, but there were passenger trains. Don't know if any were intended
for commuters though. The nearest station was 3 miles down the track.
There was at least one ******* driver who insisted on hitting the horn
on the way through town in the middle of the night. I'd have loved to
have a percussive word with him...
Shane
-----Original Message-----
From: bi...@gw5.cs.uofs.edu [mailto:bi...@gw5.cs.uofs.edu]
Sent: Tuesday, December 03, 2002 8:32 AM
To: Info...@Mvb.Saic.Com
Subject: Re: Cracking OpenVMS passwords with John the Ripper
In article <G5Ybba...@eisner.encompasserve.org>,
Kilg...@SpamCop.net (Larry Kilgallen) writes:
> In article <ash46h$qvvue$2...@ID-135708.news.dfncis.de>, bi...@cs.uofs.edu (Bill
Gunshannon) writes:
>>
>> Where was that?? There has not been passenger service on any track
>> in NEPA since before I was born (which is a lot longer ago than I
>> wish it was!!)
>
> What about the Laurel Line, or doesn't an Interurban count ?
>
> You are a real youngster :-)
I'm 52 and grew up falling asleep to the rhythm of the rails as the
tracks
were less than 50' from my house. The only passenger service I ever saw
locally was when we hopped a boxcar for a quick ride to the other end of
town. Unless you count things like The Stourbridge Lion which still
hauls
passengers to Honesdale for a day of shopping in the quaint shops and
back.
Or Pocono Norhteast who fielded 2 Rapid Transit type cars and never got
far enough along to actually carry a passenger before the cpompany
folded up.
The nearest serious passenger service was Harrisburg and even that died
long ago (although I hear they want to revive it not only there, but up
here as well. But at this stage of the game it will do more harm than
good.)
bill