Obviously I'd have to run it under Supervisor-equivalent access to get at the
password information... that's not a problem.
Any info would be helpful.
Dan Berry bugs%atla...@kakwa.ucs.ualberta.ca
==============================> bu...@atlantis.uucp =========================
"On a first date, watch how your date treats the waiter, the bartender,
and so on. That's how she'll be treating YOU after three months."
Have you tried SECURITY.EXE that comes with Netware? It should be located
in the SYSTEM directory. It is a security evaluation utility that is provided
by Novell. It lists each user and group that exists in the Bindery and reports
potential weaknesses that account or group may have.
Jeff Dong don...@acfcluster.nyu.edu
The Man With No Sig
Not true... the bindery won't give out password information, regardless of
your security clearances. The only thing the operating system will let you
do is give it a password attempt, and it will say "yes" or "no."
| Rick Osterberg oste...@husc.harvard.edu 617-493-7784 617-493-3892 |
| 2032 Harvard Yard Mail Center Cambridge, MA 02138-7510 USA |
Just use the SECURITY command.
Eric B. Stauffer - Clinical Research Information Systems
Eli Lilly & Comapny, Indianapolis, IN 46285
>I'm SUPERVISOR for the Novell 3.11 network in the department where I work, and
>I have a number of people who I _know_ have very simplistic passwords for their
>accounts. What I want to do is run a program like CRACK or COPS that exists on
>UNIX machines on my Novell server in order to make a list of potential weak
>accounts in security. Does anyone know if such a program exists?
Such a program exists, but it doesn't do much good if you have account
lockout activated. After 5 tries (or whatever you set it to) the account
would be locked out and no one could get in without Supervisor resetting it.
A simplistic password is not really a problem _unless_ it is something that
can be guessed esaily within 5 tries. So, make sure your users are not
using names of spouses, kids, dogs, phone numbers, etc.
* _______________\|/_ Will Sadler wi...@cica.indiana.edu *
* Laser 44888 /|\ sad...@indiana.bitnet *
"Composing, performing, and listening are three different things. What
could they possibly have in common with one another?" Cage
There is a pgm called SECURITY that comes with NW3.11... It checks for
various security exposures. It reports stuff like users with no passwords
or passwords that are the same as their ID. It also checks for excessive
rights. It's documented in the Utilities reference.
HTH (Hope this Helps)
The views expressed are my | | "... Someday, however, when fathers
own, and could change at any | | learn to love their children more
moment. | | then their hatreds, then peace
--------------------------------| | will come. "
David V. Porco | | Joseph F. Girzone
Systems Programmer | |
Certified Netware Engineer | |
>Not true... the bindery won't give out password information, regardless of
>your security clearances. The only thing the operating system will let you
>do is give it a password attempt, and it will say "yes" or "no."
Sure it will, just lock the bindery, and copy the files net$val.dat, I
don't believe there is a well known utillity developed to crack those
passwords. (Yet... Rumour has it that the encryption code for 3.11 is
available, so you better guard those backups.....)
| Gordon Harry Shephard | Distributed Computing Support Group |
| Academic Computing Services | Phone: (604)291-3930 (604)464-4991 |
| Simon Fraser University | |
| Burnaby, BC, Canada. V5A 1S6 | shep...@sfu.ca |
| Disclaimer: In No Way am I speaking for my Employers or Simon Fraser |
| University. |
The rumours are true. You can ftp pascal source code which includes all
the login stuff, including encryption, from ftp.uu.net. Get the
self-extracting archive file published/byte/mar93/logon.exe.
Supposedly, according to Novell Tech Support, the algorithm is
non-reversible. Which only means that you can't take the encrypted
password and from that determine what the password is. This by no means
will stop a "brute force" search of possible combinations. You will
know when you get it right.
Mark A. Morrell Disclaimer: _I_ probably don't even believe it.
"In the beginning, the universe was created. This made a lot of people
very angry, and has been widely regarded as a bad idea." - Douglas Adams
It's more than rumor. The code is available, and I have it, but it is of little
use for decrypting passwords. It is a one-way encryption algorithm, and the
passwords CANNOT be unencrypted by anyone. The server cannot decrypt them to
check when you login. Instead, it encrypts the password you enter and compares
the encrypted password you entered with the encrypted password stored in
On another note, several people have reccemmended runnign SECURITY.EXE. Note
that security will only check for REALLY OBVCIOUS passwords (none, and the
User's password being the same as the ID, I believe) ... it will not check
for the user's name, or his/her spouses name, or a really common work, etc.
- Brett (rfra...@cs.umr.edu)
So.... if it's non-reversible, it means the algorithm is written in a way
such that two different passwords could generate the same encoded
password... which leads back to a discussion here about a month ago
regarding more than one password working on an account. However, I keep
reading that the Migrate utility to Netware 4.0 appears to also migrate
password information, whch was a big hassle when it didn't when going to
3.11. Does that mean that they use the same encryption algorithm? If so,
then if the 3.11 encryption algorithm is available, so is the one for 4.0
(i.e., they are the same). So... guard your 4.0 backups as well!
No, it means that somebody finally got smart and realized that, if you copy the
encrypted password *and* the context used to encrypt candidates for comparison,
you have effectively moved the reference copy of the password without knowing
the cleartext. Lots of pretty secure OSes work this way.
Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@]
Internet: IMH...@INDYVAX.IUPUI.EDU BITNET: IMHW400@INDYVAX
Celebrate freedom: read a banned newsgroup.
>reading that the Migrate utility to Netware 4.0 appears to also migrate
>password information, whch was a big hassle when it didn't when going to
My analysis of the MIGRAT utility showed that it does NOT migrate passwords.
There wasn't an earlier version of MIGRAT to confuse me, was there?
>3.11. Does that mean that they use the same encryption algorithm? If so,
>then if the 3.11 encryption algorithm is available, so is the one for 4.0
>(i.e., they are the same). So... guard your 4.0 backups as well!
sure, guard your backups, but not for the encoded password info. just for
the regular data.
Does this mean that there could be more than 1 password that
can log a user into his/her account ?
Please correct me if I am wrong.
>Does this mean that there could be more than 1 password that
>can log a user into his/her account ?
Yes. And there very likely is. Finding it might be tough, though. Its not
really a security risk, though, as there are still many, many valid passwords.
- Brett (rfra...@cs.umr.edu)
>>3.11. Does that mean that they use the same encryption algorithm? If so,
>>then if the 3.11 encryption algorithm is available, so is the one for 4.0
>>(i.e., they are the same). So... guard your 4.0 backups as well!
>sure, guard your backups, but not for the encoded password info. just for
>the regular data.
If the password algorithm provided in logon.exe encrypts cleartext passwords
to the the same ciphertext found in net$val.sys, then given
A) net$val.sys (Backed up every full backup)
B) A large dictionary.
C) A Novell version of the Unix Crack,
Then with any moderately large Database of users, a significant
percentage of the passwords would quite likely be cracked. (A large
number of users don't choose difficult to guess passwords).
(Take Word 1 cleartext, encrypt, compare with cyphertext
Take Word 2 .....
Keep trying until you run out of words or get a match.)
Any research been done on the Novell Encryption Algorithm.
There is a commercial package available, called `BindView+' which allows
you to view the Bindery in human-readable form, add objects, delete objects,
change property values etc. etc., all using either the C-Worthy interface, or
something like it.
One of it's useful sounding features is scanning for insecure passwords - it
will do a pass through the Bindery, and comparing the password property value
to a list of pre-encrypted items for all users (user's login name, firstname,
lastname etc., plus standard dictionary words, plus any user-defined words
(e.g. company name etc.)) - Sounds to me that such as operating could take an
`Extended Period of Time' ;-)
I've never actually seen this product, but it won a lot of product awards.. I
don't have any company details to hand, but if anyone wants them, I'm sure I
can search our magazine library for the relevant magazine..
Hope this helps,
- Colm Toomey -
C N E
> I know what algorithm is used (look for dutiws.twi.tudelft.nl anon
> ftp /pub/novell)
> it is non reversible because some strings have the same encryted text
> as a result.( but it can be implemented a lot faster than the unix
> password encryption (des) so password hacking will be very possible).
Ok... this is something I've been wondering about for a bit. People say
the NW password encryption is non reversible because you can have more
than one string that results in a specific password. Ok, then couldn't
it be possible to reverse the algorithm to get ONE of the strings
possible, since it can't tell the difference? I'm not an encryption,
Novell, etc. expert at all, but... just curious.
Marc Slemko | ma...@alive.ersys.edmonton.ab.ca
Edmonton, Alberta, Canada | No big long title--just ME!
In article <930408.201331.0...@alive.ersys.edmonton.ab.ca>
ma...@alive.ersys.edmonton.ab.ca (Marc Slemko) writes:
| say the NW password encryption is non reversible because you can
| have more than one string that results in a specific password.
The people saying this are essentially wrong. It might very well be
true that the Netware password encryption allows more than one
password to result in the same encryption string or vice versa, but
this is *not* why the algorithm is said to be one way.
The algorithm is "one way" in the sense that it is *computationally*
infeasible to reverse the transformation performed by the algorithm.
In theory, of course, every such transformation is reversible in some
sense. If I had the time and the computing power, I could calculate
the transformation of every 8 character password (assuming the
passwords were limited to 8 characters). Since there are finitely
many such passwords, I would finish in a finite amount of time (though
it might be a great many years). Once I had assembled all such
encryption results, I could sort them in order of the resulting
encrypted value, and simply look up the right password for any
encrypted value I desired. I might not get the original password, if
the transformation was not one-to-one, but I'd get a password that
would work for my purposes, as you've pointed out.
Password encryption algorithms work because they are chosen so that
the only way to get the original password is the (prohibitively
time-consuming) method described above. For example, suppose I used
the following password "encryption" algorithm:
(1) Take an 8 character uppercase password
(2) Discard the first character
(3) Reverse the remaining characters
(4) Add the letter "Z"
Let's say I had the encrypted value "KROWDOOZ". I could, if I wanted,
apply the encryption algorithm to every password starting with
AAAAAAAA -> AAAAAAAZ
AAAAAAAB -> BAAAAAAZ
AAAAAAAC -> CAAAAAAZ
AOODWORK -> KROWDOOZ !!! GOT IT !!!
Note that "AOODWORK" isn't the only password the works: so do
"GOODWORK" and "FOODWORK", for example. This transformation isn't
one-to-one. Many passwords (26 actually) will map to the same
encrypted password, so the algorithm isn't truly "reversible". But
this doesn't mean it is a "one way" transformation in the sense
described above. There is a computationally feasible method of
reversing (in a sense) the transformation:
(1) Reverse the letters of the 8 character encrypted string
In this case, the reverse transformation is even more simple
computationally than the forward transformation. For the above
example, it gives the password "ZOODWORK", which works as well as
"GOODWORK". That's why this is a really bad encryption scheme. ;)
To illustrate a "one way" encryption scheme, let me draw a (slightly
imperfect) physical analogy. Let's say I had a very long string of
Christmas tree lights with about 1,000,000 pinpoint bulbs on it. And
let's say I had a control box where I could type in a number from
000000 to 999999 which would light up the corresponding bulb on this
string. Now, let's say I scrunched this long string of lights into a
ball and suspended it from the ceiling in front of a silk screen so
that, when I activated a bulb and stood behind the screen, a pinpoint
of light would be projected onto the screen by the bulb.
I would propose the following encryption scheme. The unencrypted
password would be a number from 1 to 1000000 designating one of the
bulb codes. The encrypted password would be the position of the
pinpoint of light on the silk screen. Every different bulb would have
a pinpoint somewhere on the screen, let's assume. Some bulbs might
shine on exactly the same pinpoint position, just as several Netware
passwords might map to the same encrypted representation, but this
wouldn't have to happen for my encryption scheme to work.
Now, let's say I picked a password code and drew a little "x" exactly
where my pinpoint of light hit the screen. Then, I invite you into
the room and tell you to reverse the process: determine, from my
encrypted "password", which light bulb I must have activated.
How would you do this? The bulbs are all scrunched up in a tiny ball!
You might guess, "I'll bet 555001 is the right bulb!" You'd try it,
and it would be very close to my "x". Now what? It must be "555002",
right? Unfortunately, because the string of lights is wound up like
spaghetti, "555002", even though it's adjacent to "555001" on the
string of bulbs, happens to be on the other side of the ball, and a
completely different position is lit when you activate "555002".
Your only solution is to try thousands and thousands of bulbs until
you hit on the right one. A "one way" function in action!
The field of mathematics that deals with the behaviour of functions
like this is called "complexity theory", I believe. The idea behind
creating a good encryption algorithm is to use a function that is
similar to the bulb scrunching effect: if done correctly, it can make
it impossible to find a simple reverse transformation.
P.S. Another good Christmas light technique would be to wrap the
Christmas lights tightly around two pegs on opposite ends of a board:
:|__|: <=== peg
: :O <=== string (:) of lights (O) wrapped
: : around pegs
: __ :
O:| |: <=== peg
Provided certain constraints concerning the distances between pegs and
the distances between bulbs hold, the vertical position of a glowing
light measured from the bottom peg, for example, provides a good
numerical encryption that's hard to reverse.
Why do I bring up a second example when the tangled ball works fine?
Because this second example is very similar to the one-way
transformation used for RSA public key encryption which involves
multiplying two numbers (the bulb number by the inter-bulb spacing) to
produce a large product which is divided by a third number (the
inter-peg length) to get a remainder (the distance of the pinpoint
from the lower peg). Currently, there is no known way to reverse this
process for well-chosen numbers without resorting to the brute force
This is exactly what I was concerned about when I initially asked about all
this. I say that because I got lots of mail -- even from some employees at
Novell -- saying, "just run SECURITY.EXE and it'll take care of it".
CRACK does some very interesting tests for passwords. It's test method can
be "programmed", if you will. Basic tests include sticking in numerics for
those sillier people... like "3mice" or "golf18". It also has a list of
common first names that it checks!
I also have a UNIX box at home. I ran CRACK on the password file, and got a
LOT of matches within 12 hours... and it's only a 15 MIP machine. Take any
off-the-shell 50MHz i486(tm) -- about 25-30 MIPS -- and you've got a REAL
big security problem. At least Novell allows for up to 255-character
>CRACK does some very interesting tests for passwords. It's test method can
>be "programmed", if you will. Basic tests include sticking in numerics for
>those sillier people... like "3mice" or "golf18". It also has a list of
>common first names that it checks!
The important issue here is to guard net$val.sys