[3247] in cryptography@c2.net mail archive
RE: Time Based Token?
daemon@ATHENA.MIT.EDU (Jacob Langseth)
Tue Aug 25 16:39:53 1998
From: Jacob Langseth <jlangseth@esisys.com>
To: "'tzeruch@ceddec.com'" <tzeruch@ceddec.com>
Cc: "'cryptography@c2.net'" <cryptography@c2.net>
Date: Tue, 25 Aug 1998 15:43:41 -0400
On Monday, August 24, 1998 9:12 PM, tzeruch@ceddec.com
[SMTP:tzeruch@ceddec.com] wrote:
> Now that I am playing with my palm III, something came up that made me
> think of that token which displays a different number every 30 seconds.
>
> Would something that would do a SHA1 of about 1K of random data (as a
> shared secret), and the current time be secure? Or would it have to be
> more elaborate?
I'm by no means an expert (just an interested person
beginning to become familiar with the field), but I
believe something a little more elaborate would be
necessary.
What you're proposing:
Client is authenticated by the server through verification
of credentials which consist of an SHA1 hash of a shared
secret and a timestamp.
The client sends the hash over the wire, the server generates
its own copy of the credentials, verifies that it matches the
client's, and authenticates accordingly.
Okay, this by itself wouldn't be terribly secure, as anyone
sniffing the wire could see the credentials sent, and potentially
use them themselves for authentication. This could be avoided
by either allowing only a single login per credential set - limiting
you to a single session w/in a [small] time frame - or by
incorporating the source ip or similiar info into the hash.
Assuming you want multiple simultaneous sessions and went
with the latter, it would provide reasonable security (hijacking
attacks aside) for preventing an attacker on a remote system
from simply replaying the credentials w/in the (albeit minute)
time window allowed by the time stamp.
Unfortunately, this doesn't provide any protection from someone
on the local system immediately replaying the credentials. I
realize this is almost a moot point in the context of a Palm III,
but if you were to use your authentication mechanism from a
multi-user system, it's something to consider.
An augmentation which might work a little better would be to
have the host send a challenge to the client, which is then
hashed w/ the client's shared secret and returned. Each
challenge would be valid for exactly one login, allowing for
multiple sessions from multiuser systems w/ the same
security granted by the above scheme used in a single user
context.
This system falls to any active network attack, but should
be relatively straight forward to implement. If you need
something which guards against network attacks, SRP
or SSH would be worth a look.
Corrections, critiques, improvements etc welcome,
I'm hear to learn.
Jacob
--
Jacob Langseth <jlangseth@esisys.com>
Enhanced Systems, Inc.
