Conference noted::hackers_v1

The bad thing is that there are FAR FEWER MEMORABLE ALGORITHMS than there
are MEMORABLE PASSWORDS, hence this makes guessing EASIER!

/Bevin

 I dunno if I agree with .1 -- I can think of quite a few possible algorithms.
Going through say, 40 of the most obvious is a time-consuming task.  And there
are even ways to disguise the fact that a password algorithm is needed --
for example, by repeated the "username-password" sequence three times with
nonsense lines and then requiring a specific answer (such as the system date).

 One objection to the method did arise: now the System manager's task switches
from maintaining passwords to maintaining algorithms...

    I disagree with .1 -- there are many many MANY more
    algorithms than passwords, and it's easier to remember
    a few different algorithms than a lot of different
    passwords.  I compare a FEW algorithms with a LOT of
    passwords because the algorithms are 'more secure' --
    drawn from a larger space. 

    RE .-1: Why do you say system management will have to
    manage algorithms instead of passwords?  Our system
    management doesn't manage passwords now -- at best we
    see a request every couple of months for US to change
    our passwords.  Of course, you may be thinking of a
    paranoid system management. (But, they are only
    paranoid if nobody IS trying to break in).  I do expect
    system management at a secure government facility (for
    example) to start thinking about this and get help if
    they are not competent to do it themselves.  (The first
    time no-one can log in because system management blew a
    program will either (1) get this idea tossed out or (2)
    force system management to get help and to test each
    new algorithm.) 

Andy V

This has been beaten to death in the SECURITY notes file.

The major disadvantage is that the security depends on a secret algorithm;
anyone able to read the algorithm is then able to breach the security.

You get advantages only when used over insecure lines, so that a "password" is
never transmitted in plaintext.  However, complex algorithms and keys (passwords
if you like) are needed.  The algorithms are too tedious for humans.  And this
effectively forms an encrypted data link.

Overall, it's an appealing idea that just doesn't pan out.  Sorry.

					- Gilbert

	RE: .-1:
	
	Why is a secret algorithm any LESS secure than a secret password?

	What makes a password as secure as an algorithm?

	Why do you say that the method does not pan out?  Sounds like it
	has all of the features of passwords but with BETTER security
	over insecure lines AND harder to break by repeated guessing.
	Passwords selected by users are too often closely related to
	the person doing the choosing.... I expect that algorithms, being
	farther from natural language, would be easy to remember
	without being associated with familiar words.

	RE: algorithm passwords

	I first heard about this concept about six years ago.  One difference
	was that each person had a different algorithm... not a machine-
	wide one that changed periodically.

		-John A. Wasser

Reading VMS sources and SYSUAF.DAT won't let you to determine passwords.
Passwords are not stored; instead a trap-door function of the passwords is
stored.  Even given the trap-door algorithm, and the value of the trap-door
encrypted password, determining the original password is computationally
infeasible. 

Reading a "secret" algorithm (which may depend on a "challenge") gives away any
security.  Relying on "secrecy" is almost as bad as no security at all.
Scavenging command files for access control strings was a popular and lucrative
pastime; most DEC employees learned the better part of valor, after receiving
dunning mail from security-conscious system managers.

Although you can to create an algorithm such that the operating system itself
is unable to explicitly determine whether a correct response was given (i.e.,
it does a trap-door function before any comparisons), such techniques are
ill-suited for human use, and (except for depending on the "challenge") are
similar to the current authentication method. 

If DEC were to make 'twenty' such algorithms available, a cracker need only try
each in turn.  If customers were expected to develop their own, they'd better be
sure the algorithms (and their sources) aren't read or readable.


For authentication over a line that's insecure against reads, and which does
not evaporate if the algorithm is known, the user needs some secret information
(such as a "key").  The user should respond with some irreversible function of
the "challenge" and the "key".  The operating system does another irreversible
function (of the "response" and another "key") for the authentication. 

No human-computable algorithm seems to meet these criteria.  The closest thing
is a code-book, which is just like the current method, except that the current
method uses a one-entry code-book (i.e., it doesn't depend on the "challenge").

Note that if the communication line is insecure against reads, the algorithm may
also have been read.


If the user needs a "little black box" to determine the correct response, he
may just as well have real encryption (ala DES) in that little black box. 

Note that encryption services are not yet readily marketable.  Many companies
insure against such electronic security leaks, and while insurance companies
remain unconcerned, there's little impetus for their customers to improve their
electronic security.  IBM built such a box; it was a marketing dud.


If users use "guessable" passwords, that's too bad, and their own damned fault.
Presumably, they would also use simple, guessable pass-algorithms.

					- Gilbert


Again, please refer further comments to the SECURITY notes file, which contains
a variety of suggested algorithms, further arguments, and details.  A gamut of
security concerns is covered in that forum.

So VMS doesn't store the passwords, but rather the output of the
password run through some algorithm.  How does that make finding the
passwords computationally infeasable?  Judging by the rapid response
from VMS after I type my password while logging in, that function
only requires a small fraction of a second of CPU time.  Presuming
read access to the SYSUAF file, I could have a program take a 
dictionary and just run all the words and variations thereof through
the algorithm and look for matches.  That might take a few hours of
CPU, but I'll bet I would get a surprising amount of matches.  Only
people who pick good passwords peppered with numbers and other 
symbols, or not remotely resembling words, are immune from that
method of attack.  The paper "Password Security:  A Case History"
in the Unix doc set describes this approach and it's deterrents.

Agreed: passwords should not be words that can be found in
a dictionary.  They should also not be people's names.

With those restrictions, I can still come up with thousands 
of passwords.  Can you come up with thousands of non-obvious
algorithms? I doubt it.

Re:	.7

If you leave READ access to world on SYSUAF.DAT then you deserve to be
hacked! The encoding routine is both in the VMS source kit and on the
fiche and it just needs a little patience to type it in. Then guided
by one of the many online dictionaries and a list of names, you could
probably find the exact match very quickly.

This is very unfortunate as still too many people seem to have access to
SYSPRV or [1,4]. All it needs is one FS engineer to leave the console
unattended or to change the password to something easily remembered and
POW!

I don't like the idea of algorithms either. I can just imagine a system
manager busy with a calculator trying to work out the response to a
particular challenge. And then 10 to 1 he gets timed out!

Hugh.

Re: .7

A dictionary approach would work, but not as well as you may think.
The trap-door function uses the input password, a 16-bit random number
(stored in SYSUAF.DAT), and (methinks) the account name.

Thus, a separate pass over the dictionary is needed for each account.

Also, one of the security features in VMS V4 allows the system manager to
require occasional password changes for particular accounts, and allows him
to specify that certain accounts may only choose passwords provided by a
random-pronouncable-password-generator (not to worry, it's very random).

Re:	.-1

The V4 random pronouncable password generator is all very well, but half
the passwords are eminently forgettable. Therefore you end up with a
subset of the full capability (out of 5 attempts, only one seems to be
OK to remember).

Hugh.

A possible problem with "randomly generated passwords" is that, while there
may be billions and billions of possible words generatable, you can actually
only generate 2^N words, where N is the number of bits in the random seed.

	Karl.

N = 64.

Thus, if the password generator considers only one in a thousand passwords
pronouncable, the user considers only one in a thousand memorable, and the
generator "drops" 10 bits of the random number, you still have about 2^34
possible passwords, e.g., "billions and billions".

    Username: A_VESPER
    Password: (mumble)

    Greetings.  Your system manager has said that you need a 
    new password every so often, and that the password will
    be generated by a random password generator.  Your new password
    (for the next 10 minutes) will be:  MANTAGIOR

What am I going to do?  Write down that password before it
leaves the screen, then put it in my wallet!  To make it
more convenient maybe I will write it on a pad of paper
taped to my terminal. 

Security feature?  Only for the people trying to break in.

Andy V

Re: the current VMS trap-door function.  It takes the account name and the
password and catenates them to form a string.  This string is then wrapped-by
addition into a 64 bit quantity.  A random 'salt', stored in the UAF file
for this account, and selected at SET PASSWORD time, is added into the
quadword.

This quadword is then run thru a very weird mod 2^64 polynomial, and the
result of it stored in the SYSUAF file.

It is NOT cheap to compute.  Running a dictionary thru it, even using the
salt and the account name, would take a significant cpu hit (although these
days with the advent of ever faster/ever cheaper cpu's, its definitely VERY
viable for the serious penetrator).

/Bevin

VMS uses the USERNAME, not the ACCOUNT name in figuring out whether 
you entered the correct password or not.

tom p

	How are you going to tell the user about the your new fancy algorithm? 
 hope you use telepathy so that no one else will be able to listen in.

	If my system manager is going to change the algorithm every day, may 
be he should come to my office and whisper the new algorithm in my ear.

- Vikas

Whispering in your ear is less secure than the current algorithm.

 If I may interrupt again for a minute...

 I think the strength of the algorithm method is not its scope (i.e.,
"billyuns and billyuns") nor the difficulty of cracking a particularly
clever algorithm.  Its strength is the ease with which an algorithm is
remembered; therefore, the algorithm can be changed more often than
passwords are changed.  How often do you change your password?

 It was recommended that distribution of the algorithm be done off-line.
In highly security-conscious areas, such as the military, there are
TASO's (Terminal Area Security Officers).  At our site we call them "Group
Administrators".  Each person is responsible for 5-10 users in their area;
if they are given the algorithm, then they can pass it on to their users.
I suspect that frequent changes of the algorithm could at least slow down
penetration attempts.

"they are given *the* algorithm"?  And what is to keep someone else in my
group from logging in to my account under this scheme?

I never write down old passwords.  I wouldn't use the same one twice myself,
and assigned passwords are too random for them to ever come up twice.  I
would certainly share algorithms with other people (I can see the ARPAnet
bullitin board for it now).

Having one algorithm per machine means that everyone's files are wide open
to each other.  Having one algorithm per person means you have to come up
with several hundred algorithms at the same time.  Would you like to come
up with several hundred algorithms on short notice, such that people would
not be able to infer what scheme you were using to construct the algorithms,
and try to guess someone else's algorithm instance?  I can remember when
the administration on MARKET tried forcing people to choose passwords which
began with the third letter of their user name so that they could not
repeat the same password as before, to stop account hopping.  It took two
passwords to figure out the scheme.  It would have been pretty easy to
guess the password of someone whose third letter was "Q".  The same kind
of hacking would extend to algorithms.
				/AHM

 I probably wasn't too clear in my last reply.  Algorithms would 
probably be most useful (and secure) under the following conditions:

	o as an additional login check after the regular password
	  had been executed.  In this case, the algorithm could be
	  universal.

	o as an individual login check on an individual account.
	  Perhaps certain high-security accounts would have
	  algorithms.

 I don't envision individual algorithms for every account on a system: 
I suspect that the vast majority of users have neither the background 
nor desire to design their own algorithms, except on machines with an 
overwhelming number of hackers.

Yeah, I mean, I restrained myself when I read the reply long ago that said
"don't bother flaming, it's all been settled in Security Notes".  But the
problems I saw, and didn't comment on, kept getting ignored or debated, and
it was finally too much for me.  I don't think you raised anything I see as
a problem which didn't leak out of the earlier discussion.
				/AHM/SIGH

In the latest CACM (November) there are two letters concerning
PASS Algorithms.  James Haskett, the author of the original article,
defends himself quite well.

Where is the Security notesfile?  I haven't found a reference to it
anywhere.

Andy V

The security  notes file  is on  VORTEX but  you need  an account  and
password to get into  it.  You have to  find out who maintains it  and
see if he'll let you in.

tom_p

re: .25

The notes file is now on PARROT:: and is still protected.  

- Paul