mailing list archives
RE: Token based OTP: SafeWord or SecurID?
From: Ben Nagy <ben.nagy () marconi com au>
Date: Mon, 27 Nov 2000 10:34:00 +1030
From: John Adams [mailto:jna () retina net]
Sent: Saturday, 25 November 2000 8:53
To: Ben Nagy
Cc: 'Tommy Ward'; ark () eltex ru; firewall-wizards () nfr net
Subject: RE: [fw-wiz] Token based OTP: SafeWord or SecurID?
There was a fair amount of papers and discussions surrounding SecurId
around 1995/1996. Adam Shostack whote 'Apparent weaknesses in
Dynamics Client/Server Protocol', available at:
It's pretty good, although without any knowledge of the
(as it's still private), most of the attempts in the paper
Depends what you mean by pretty good. Yes - it's very clueful and
interesting. It does not, however, appear to "work" in any real way.
One thing that I do note, however, is that the use of DES as a transport
encryptor between the ACE client and server is very ugly. These DES keys
are, however, ephemeral. If anyone knows much about how they're generated
and the degreee of forward secrecy provided I'd like to hear about it.
Interestingly, though, and I'd love a cryptographer to correct me, now that
the server response includes "a value dependant on the client's secret key"
(from Brainard) I don't see why we need to encrypt the transport at all. I
would, however, then assume that we need a client / server shared secret of
more than 56 bits.
In fact, if we're doing shared secret authentication between client and
server, signed Diffie-Hellman would probably Work Just Fine, but I guess
that would have required a complete rewrite of the protocol whereas adding a
few bits of hash to the server response is a couple of hours of patching.
Also, a serious bug (copied here from the 1996 paper) was
patched in the
Security Dynamics was first notified of this bug in July
1996[...but it was already fixed...]
Details about when this happened were not provided.[...]
If you believe the chronology in the email from Vin McLellan you quote
below, then it was actually fixed in 1994, so the bare quote you provide is
actually a bit misleading.
In addition, that was NOT a bug in the hash algorithm. As I read it, it was
a bit of lazy protocol analysis that would allow a malicious user who had a
large amount of control over the channel between the ACE client and server
to spoof authorization messages to invalid login attempts. And even then it
required access to the shared DES key.
That doesn't frighten me a great deal. If an attacker has that much control
over the trusted LAN they don't need to break in via dialup.
There's a ton of links on this at:
Two more things that interested me, reading through the Shostack paper:
In the Shostack paper, Adam says:
It needs to be collision resistant because the server claims to not accept
previously used tokencodes (FAQ 4.12).
To which John Brainard (perplexingly) responds:
Since the F2 function is used only to disguise the pseudorandom PASSCODE
value, it is not clear what the impact of such a collision would be.
I think that the guys might have been talking about different parts of the
protocol. Adam is talking (I think) about the impact of collision in the
token hashing algorithm, while John is rebutting about collisions in the F2
hash between the ACE client and server.
The token hash collision possibility is interesting, but a collision is
fairly unlikely (one in 10^passcode digits or so) and in the event of such a
collision the user simply reauthenticates.
Secondly, Steve Bellovin recently said:
And you're not going to brute-force the algorithm.
Apart from the key being too long, it doesn't show all of the output.
Check me on this, Steve - just because the token doesn't show all the has
output does not mean that you can't brute force it in O(2^secret bits)
(which I believe is 64) at worst. You just have to check your guess with a
different timestamp or two every time you think you've got the correct seed.
Network Integration Specialist
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
firewall-wizards mailing list
firewall-wizards () nfr com