Re: RSA SecureID on Solaris

From: Doug Hughes (doug@Eng.Auburn.EDU)
Date: 04/10/02

Date: Tue, 9 Apr 2002 21:07:55 -0500 (CDT)
From: Doug Hughes <doug@Eng.Auburn.EDU>
To: adam morley <>

On Mon, 8 Apr 2002, adam morley wrote:

> On Mon, Apr 08, 2002 at 02:20:18PM +0200, Norman Girard wrote:
> > Hi Adam,
> >
> > On Sat, 2002-04-06 at 20:46, adam morley wrote:
> [snip]
> > > Has anyone looked into how "secure" they are? Can one guess the number on the display, perhaps based on the serial on the back?
> > There's no relation between the seed and the serial number.
> > The synchronisation between the RSA ACE Server and the token is made by
> > an algoritm which takes two parameters in : a seed (64 bits) and the
> > current time (UCT).
> > Your tokens are provided with a floppy disk which contains an encrypted
> > flat file (.asc) you need to import to your ACE Server. The file
> > contains, for each token, the serial number (you can find on the back of
> > the token), the seed and few others parameters about the token (6 or 8
> > digits / 30 s, 1 min or 2 min / etc.).
> > The algorithm has been broken in December 2000 but you need to have the
> > seed in order to generate tokencodes. You can find more information
> > about this algorithm in :
> >
> so im currently reading this, and it occurs to me: if you know one token
> value, and the time of day you capture that token value, you can brute
> force to find the secret, if you know the algorithm (i take it its
> "known"?). then you can, effectively, clone the device, correct? I was
> hoping @stake would've released the follow up paper they talk about in the
> last paragraph, but it doesn't look like it (from their site) >

I think that's a bit of a logical leap. Yes, there are weaknesses, but as
far as I've read, brute forcing is still pretty hard.

> of course, this is all on the basis that a only ONE 64-bit secret will
> produce a given tokencode at time x. if there are two, i have to throw my
> hands up in the air and wave 'em like i just don't care. > > thoughts? >

It's still better than reusable passwords. Combine it with ssh and
it's pretty good.

Relevant Pages

  • Re: Password alternatives
    ... their algorithm remaining secret, which in terms of cryptography is bad ... I'm not an expert on tokens. ... Unlike passwords, biometrics do have the problem of False Accept Rate ... passphrases as a string of characters, ...
  • Re: compression type
    ... occurance of what repeats, for there to be a token, for how tokens ... see its construction algorithm. ... It's very limited to think that's the only way to compress, ... made different, to the other shape, where the math to say one shape ...
  • Re: compression type
    ... occurance of what repeats, for there to be a token, for how tokens ... for how a repeat occurance of a length of data can be said ... see its construction algorithm. ... can compress them even though there are no patterns, ...
  • Re: Error reporting, was Infinite look ahead required by C++?
    ... the tool isn't the same as the algorithm the tool uses. ... valid next tokens, used to choose between shifting and reducing. ... inherent part of LALR, but rather an optimisation specific to Bison? ... be reducing when in this context we should have applied an error. ...
  • Re: P = NP!
    ... on a public math forum, it seems his algorithm ... We start by, once again, referring to the DNF form even though we're explicitly told we're not trying to solve the DNF form. ... Oh, by the way, the algorithm is essentially "for all tokens in the expression, if one tcis true, then it's satisfiable." ... The first paragraph of the algorithm is easy enough to understand: go through the clauses from left to right, checking to see if each clause has a valid token. ...