Re: How to send user authentication.

Bill Frantz (frantz@netcom.com)
Mon, 14 Sep 1998 23:50:46 -0800

• Next message: Sparkes, Ian, ZFRD AC: "At 18:22 14.09.98, you wrote:"
• Previous message: C Matthew Curtin: "Re: tristrata"
• In reply to: Mike Stay: "tristrata"

At 1:37 PM -0800 9/9/98, Daniel R. Oelke wrote:
>I am trying to find a protocol that will work in the following
>situation. I'm well aware of some potential weaknesses, but the
>threat I have treats these as acceptable. (threats like
>using playbackable username/passwords)
>
>Alice logs into computer system A. She executes a command on
>comptuer system A that is to transfer a file to (or from) system B.
>System B needs to be able authenticate Alice with no additional input
>from Alice. i.e. like being able to do an rcp command. To be
>able to do this, Alice must have the same username/password on
>both systems. System A can then send the username and some type
>of authentication info to system B.
>
>Computer system A & B use a traditional username/password system
>of authentication. The passwords are stored in a database as one-way
>hashes with salt. System A will usually have a different salt value
>from System B (seperate databases).
>
>Since system A & B have different salts, the hash values will be
>different on both systems. So, the only way to send authentication
>info to B would be to keep in RAM Alice's cleartext password so it
>can be hashed with B's salt value prior to sending to B. I don't
>like this idea for obvious reasons.
>
>Another solution would be to have a common user database, but
>other system requirements have ruled this out.
>
>Another solution is to store and send the passwords always in
>the clear, but this is very scary and a problem in
>my threat model.
>
>So, any other ideas or pointers into Appliced Crypto on how I can
>do the authentication without common databases, or cleartext
>passwords being stored in RAM.
>
>Any and all help would be appreciated.

These ideas are based on the techniques used by Tymshare to solve similar
problems in the late 1960s. I've updated them with some crypto BS so they
will work on open networks.

Since system A and B both "know" Alice's username and password, they have
to trust each other with regard to Alice's privileges. This means that if
they can set up an authenticated path (the crypto BS) between themselves,
they can exchange authentication information about Alice, even if they have
"forgotten" her password.

If the entire user directory is shared between the two systems, the
authenticated path is all you need. If there are users who aren't on both
systems, or who have different passwords, you may need a list on system A
of which users it trusts system B to authenticate and a similar list on
system B.

-------------------------------------------------------------------------
Bill Frantz | If hate must be my prison | Periwinkle -- Consulting
(408)356-8506 | lock, then love must be | 16345 Englewood Ave.
frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA

• Next message: Sparkes, Ian, ZFRD AC: "At 18:22 14.09.98, you wrote:"
• Previous message: C Matthew Curtin: "Re: tristrata"
• In reply to: Mike Stay: "tristrata"