Securid
Engineer
Securid besides what is on the vendor's web site? I'd like to know whether
the technology is really up to speed in handling security and the hacking
talent that exists out there. I'm also looking for information regarding
it's ease of administration or lack there of.
If you don't know of any sites, but have worked with Securid and would like
to add some comentary, please feel free.
I'm considering using Securid for a proposal I'm working on. I'd like to get
more information about it though. I'd hate to waste my clients time and
money on a product that gives a false sense of security if it is not up to
the task.
-Engineer
Kevin Kadow
Engineer <blackja...@yahoo.com> wrote:
>Could anyone provide me the location of some intelligent information on
>Securid besides what is on the vendor's web site? I'd like to know whether
>the technology is really up to speed in handling security and the hacking
>talent that exists out there.
I won't duplicate what others have posted. SecurID is a One Time Password
(OTP) system, there are many other such systems available. Some are open
source (S/Key), some use public algorithms (MD5 mostly) some rely on a
trade secret (SecurID).
The algorithm used is a secret, from what little is known about it, their
may be a big problem when (not if) it becomes public knowledge how the
calculations are performed.
SecurID has support in more products than most competing products, such as
Cryptocard and Axent. There are S/key calculators for just about every PDA
and OS known, and it is free.
>I'm also looking for information regarding it's ease of administration or
>lack there of.
Any system administrator can handle it. They provide audit trails, but passing
out new tokens is not something you'd want to hand over to the help desk
without some training.
>If you don't know of any sites, but have worked with Securid and would like
>to add some comentary, please feel free.
The product does not totally eliminate the 'I forgot my password' problem,
people will lose their pins, break their cards, and require assistance in
using them, re-synchronizing, etc.
>I'm considering using Securid for a proposal I'm working on. I'd like to get
>more information about it though. I'd hate to waste my clients time and
>money on a product that gives a false sense of security if it is not up to
>the task.
The requirement that the 'pin' be transmitted in the clear with most of their
tokens is a problem- the PINpad avoids this issue, but is more expensive-
you can mix token types without any technical problems.
Anything is better than reusable passwords.
John Elsbury
complete.
The SecurID methodology is simply a way of providing a remote user with a
one-time password valid for a very limited time. The intention is twofold:
Firstly, using a variable instead of a fixed password reduces the
probability that an attacker knowing the login-ID can guess the password -
provided that the attacker cannot deduce or calculate the one-time password
based on transmitted information (perhaps accumulated over time). I have
not heard of any compromises of SecurID in this respect.
Secondly, using a variable password valid for a limited time reduces the
risk that an attacker can capture the password in transit and replay it
later, to gain access to a protected system.
Incidentally it tends to reduce the support "I forgot my password" cost
(and associated social engineering vulnerabilities) as well.
Note that this tool is not provided to protect against all attacks which
might be mounted by "hackers", however it would protect adequately against
those attacks based on monitoring, guessing or persuading end users to
divulge passwords. Note also that if you can steal a SecurID without the
"owner" noticing, and know their login and other access details, the system
dialled into won't know the difference. Other devices, such as Watchword,
use PINs to reduce this risk.
Note also that these devices are widely used in the financial industry to
provide strong authentication where large sums of money are being
transferred. SWIFT used to, and may still use, the Watchword for this.
If you want to make a front end safe from all possible "hacking" attacks
there are other technologies you should look at as well - firewalling,
configuration management, intrusion detection, etc.
I hope this helps
John
Engineer <blackja...@yahoo.com> wrote in message
news:8h0v9a$v5k$1...@node17.cwnet.frontiernet.net...
> Could anyone provide me the location of some intelligent information on
> Securid besides what is on the vendor's web site? I'd like to know whether
> the technology is really up to speed in handling security and the hacking
> talent that exists out there. I'm also looking for information regarding
> it's ease of administration or lack there of.
>
> If you don't know of any sites, but have worked with Securid and would
like
> to add some comentary, please feel free.
>
> I'm considering using Securid for a proposal I'm working on. I'd like to
get
> more information about it though. I'd hate to waste my clients time and
> money on a product that gives a false sense of security if it is not up to
> the task.
>
> -Engineer
>
>
Larry Kilgallen
> Note that this tool is not provided to protect against all attacks which
> might be mounted by "hackers", however it would protect adequately against
> those attacks based on monitoring, guessing or persuading end users to
> divulge passwords. Note also that if you can steal a SecurID without the
> "owner" noticing, and know their login and other access details, the system
> dialled into won't know the difference. Other devices, such as Watchword,
> use PINs to reduce this risk.
SecurID uses PINs also, if you pay the higher price to get the model
that has a keypad built in. If you are saying that SecurID should
not be offered in the cheaper model, all the folks who have chosen
that model would probably disagree.
Engineer
Thank you much for contributing.
Engineer
Chris Mattern
You don't have to get the SecurID with PIN to do this. My company uses
SecurID for outside access to the company Intranet. We have SecurID
in credit-card size cards that give a new 6-digit code every minute on
an LCD readout. To sign on you need type in that code *and* your PIN
into the browser to get the webserver to talk to you. So someone who
has just the card has zilch, since the SecurID code alone won't get you in.
Chris Mattern
w
authentication, however a clever hacker could easily script a DoS attack if your
UserID scheme is known. After tries are exhausted users go into nexttokencode
mode, then locked out. Better than static passwords, but someone could easily
lock out your accounts.
Barry Margolin
>One important thing to consider....SecurID is extremely strong for
>authentication, however a clever hacker could easily script a DoS attack if your
>UserID scheme is known. After tries are exhausted users go into nexttokencode
>mode, then locked out. Better than static passwords, but someone could easily
>lock out your accounts.
I've also read papers describing some man-in-the-middle attacks that
SecurID is susceptible to.
I suggest the original poster perform a web search for SecurID to find the
analyses that have been done.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin
Jim Kates <jka...@intrasec.com> wrote:
>One of the interesting fundamental facts of security is that nothing is
>fool-proof. There are security vulnerabilities associated with token based
>security products, but think of what they are replacing.
Compared to static passwords, SecurID is obviously an improvement. But
there are other alternatives to static passwords, such as OPIE (nee S/Key)
and other token vendors. From that perspective, it's useful to wonder
about the security of SecurID compared to these other technologies.
Jim Kates
fool-proof. There are security vulnerabilities associated with token based
a static password that may or may not be changed to a passcode that is
changed regularly at set intervals (usually every sixty seconds). The point
is do you need a stronger level of authentication than a static password
provides and is the price (cost) of the token worth the cost. Other similar
solution are smart cards authentication devices and certificates. All with
strengths and weaknesses.
One of the points that you asked about was administration or lack there of.
Administration is a cost especially with lost tokens and establishing any
additional rules based on most authentication systems. However, some of this
has been automated. Furthermore the administration savings from password
resets can far out weigh the administration costs of one of these systems.
In any case adding stronger authentication to a proposal will show your
client a higher sense of security than implementing baseline password
practices.
Kevin Kadow
Barry Margolin <bar...@genuity.net> wrote:
>In article <YHzZ4.1301$wT6....@typhoon.tampabay.rr.com>,
>Jim Kates <jka...@intrasec.com> wrote:
>>fool-proof. There are security vulnerabilities associated with token based
>>security products, but think of what they are replacing.
>
>there are other alternatives to static passwords, such as OPIE (nee S/Key)
>and other token vendors. From that perspective, it's useful to wonder
>about the security of SecurID compared to these other technologies.
The S/Key algorithm (MD4 or MD5) is public, tested, and known to be secure,
or you can plug in SHA-1 or any other hash function into the (public domain)
framework.
The 'trade secret' behind SecurID is unknown to all but a few, all we have is
the testimony of a few experts who were shown the details under an NDA. From
what little is known about how SecurID works, when the algorithm does become
public knowledge, that may be enough to break the system.
There have been rumors of weakness in the algorithm in the past, since then
they have released new improved versions, with new improved secret algorithms.
The one thing that keeps myself and others from making an effort to crack the
SecurID algorithm is the sure knowledge that RSA Security (formerly Security
Dynamics) will sue anybody who publishes their secret formula- and win.
Alan J Rosenthal
>The one thing that keeps myself and others from making an effort to crack the
>SecurID algorithm is the sure knowledge that RSA Security (formerly Security
>Dynamics) will sue anybody who publishes their secret formula- and win.
Doesn't stop you from trying to crack it, only means you have to be more
careful with disseminating the results. They can't sue you for saying you've
cracked it if you're not lying.
Larry Kilgallen
That may be true in Canada, but in the US you can be sued for _anything_.
The safeguards you have relate only to whether they might _win_, but
that does not stop someone from suing you in the first place.
You could, for instance, sue me for disagreeing with you in this post.
(Please don't :-).
Barry Margolin
And the judge could throw it out and fine him for filing a frivolous
lawsuit. If there's absolutely no merit to the lawsuit, it's generally
unwise to sue.
What they're more likely to do is *threaten* to sue you. If this
intimidates you into backing down, they don't have to try to convince the
judge that their suit isn't frivolous. If you don't have legal counsel on
staff, you might choose to back down rather than pay someone just to
determine if they have a chance if they sue you. On the other hand, you
might be able to get an organization like EFF or ACLU to cover the court
costs, so you'd call their bluff.
Barry Margolin
Kevin Kadow <kad...@elmhurst.msg.net> wrote:
>The 'trade secret' behind SecurID is unknown to all but a few, all we have is
>the testimony of a few experts who were shown the details under an NDA. From
>what little is known about how SecurID works, when the algorithm does become
>public knowledge, that may be enough to break the system.
>
>There have been rumors of weakness in the algorithm in the past, since then
>they have released new improved versions, with new improved secret algorithms.
The vulnerabilities I've read about had little to do with the secret
algorithm used to generate passcodes, they're about the network protocol
used to communicate with the ACE server. I don't know whether this is
considered a trade secret; if it was, I presume the author of the paper I
read reverse engineered it, so it's not much of a secret any more (it's not
hard to reverse engineer simple network protocols).
Alan J Rosenthal
>fl...@dgp.toronto.edu (Alan J Rosenthal) writes:
>> Doesn't stop you from trying to crack it, only means you have to be more
>> careful with disseminating the results. They can't sue you for saying
>> you've cracked it if you're not lying.
>
>That may be true in Canada, but in the US you can be sued for _anything_.
>The safeguards you have relate only to whether they might _win_,
Well then, this is similarly irrelevant in terms of whether it stops you
from trying to crack it. Because according to your statement, they could
sue you for *not* trying to crack it, too. This then gets factored out
and the question is what they could *successfully* sue you for (which,
obviously, is what I meant in the first place).
Vin McLellan
>>> Could anyone provide me the location of some intelligent
>>> information on Securid besides what is on the vendor's web site?
>>> I'd like to know whether the technology is really up to speed in
>>> handling security and the hacking talent that exists out there.
>>> I'm also looking for information regarding it's ease of
>>> administration or lack there of.
I missed this discussion of RSA's two-factor authentication token, the
SecurID; and the ACE/Server that supports it. Reading over the thread,
however, I noticed several unresolved questions and errors of fact which
I thought I might address, hopefully usefully.
A quick background summary: RSA's classic SecurID is at hand-held
authenticator (HHA) -- either a key fob or a credit-card size token --
which continuously displays a 6-8 digit "token code" in a small LCD on
the face of the token. The SecurID token-code (a pseudo-random
number)changes every 30 or 60 seconds, continuously, through the full
life-cycle of the token -- variously three, four, or five years.
The SecurID generates this series of PRN token-codes by continuously
processing a binary representation of "Current Time," and a
token-specific 128-bit secret key, though a cryptographic mechanism
called a hash or one-way function.
The SecurID is a two-factor personal authentication device. The three
methods by which a computer can authenticate any
previously-registered online persona, using shared secrets, are
"something known," "something held," and "something you are," a
biometric. "Strong authentication," by traditional Craft definition,
requires a computer to demand evidence of two of the three factors,
before it authorizes access to protected resources.
Despite claims to the contrary in this thread, there can be no
ACE/SecurID authentication unless the user submits both a memorized PIN
and the SecurID token-code. Two-factor authentication is fundamental to
the ACE design. A user to which a SecurID has been assigned is expected
to carry the token on his or her person; take reasonable measures to
physically safeguard it; and report its loss or theft immediately to his
employer.
When a user submits an authentication call, the ACE/Server uses the
submitted name to pull that user's record from its database to obtain
the user's PIN, and the secret key embedded in that particular SecurID.
The ACE/Server then calculates -- using the
SecurID hash, and the server's "Current Time" -- the numeric or
alpha-numeric token-code it expects (predicts) will be displayed on that
SecurID at this particular moment.
The Server then matches the PIN and token-code submitted by the remote
user with the PIN from its database and the token-code it calculated.
With a match, the user's ID is authenticated.
[This is slightly simplified. The ACE/Server also routinely
tracks the "drift" of the clock-chip installed in each SecurID
registered to it, relative to the ACE/Server's clock (which, for these
purposes, is presumed to be always accurate always.)
[This allows the Server to better predict what each token will use for
"Current Time." To minimized false rejections because of unpredicted
"clock drift," the ACE/Server actually calculates three successive
token-codes -- for what it expects this SecurID will use for "Current
Time," and for the minute before, and the minute after -- and will
accept a match against any of the three as valid.]
RSA has enjoyed a virtual lock on this type of "time-synch" token
because it has patents on the mechanism by which the time-chip in each
SecurID token is kept effectively synchronized with the clock in the
ACE/Server's host.
The SecurID was first brought to market in 1986. That's way back when,
two years before the Morris Worm, of legend and ancient lore, was set
loose on the Net.) In the past 14 years, RSA Security (formerly Security
Dynamics) has sold over 6 million SecurID tokens, and thousands of
ACE/Server installations, world-wide.
As anyone who tracks this niche market closely knows, ACE/SecurID is
still a popular and widely-trusted staple in the arsenal of infosec
managers. All US Senators carry SecurIDs; all White House staffers
carry SecurIDs, and many NSA, CIA, and DoD employees and staff carry
SecurIDs.
Historically, the fact that the user is able to handle the SecurID's
PIN/token-code combo like any traditional (longish) password gave
ACE/SecurID a significant ease-of-use advantage over other types of
authentication tokens -- notably Challenge/Response (C/R)tokens, which
generate a one-time password by encrypting a random challenge from their
authentication server at logon.
That advantage made the SecurID popular among token-holders, mere
users, and -- to the surprise of many -- that became a major factor in
the early success of ACE/SecurID. In later years -- particularly in the
big-site enterprise market where RSA and its competitors traditionally
focused their sales efforts -- the administrative strengths of the
RDBS-based ACE/Server became a much more important competitive issue.
For most of these years, the relative cryptographic strength of the
different types of HHA tokens was considered pretty much a wash. More
recently, the depreciation of DES and Paul Kocher's landmark work on
timing attacks on crypto hardware raised new threats and highlighted the
importance of the PIN -- which too many had taken for granted -- in
two-factor authentication.
As the HHA market evolved into Y2K, I think RSA's clearly defined
transition and migration path -- beyond token-based user authentication
and into smartcards, full PKI, and application-oriented PKI services --
also became an important competitive factor. RSA's Keon Servers
leverages the SecurID installed base to bootstrap ACE customers into PKI
and Cert management. Check out RSA's Keon "OneStep" announcements at
<www.rsasecurity.com>) RSA, of course, defined the architectural
options for modern cryptography with its proprietary PKCS series, the
basis for nearly all modern public-key crypto standards.
Others can perhaps better evaluate the efficiency and operational
stability of ACE/SecurID tech -- and the market as a whole judges the
cost/effectiveness of ACE/SecurID as compared to other vendors of HHA
tech -- but I think I should at least note that ACE has been steadily
enhanced over the past decade and a half.
ACE/Server 4.O, introduced last fall, quadrupled the throughput of
SecurID authentication calls in a typical server emvironment.
ACE/Server 4.1, introduced early this year, finally allows a single
database of user records to support both an ACE/Server and a RADIUS
server (a big win for net Admins), and many routine administrative and
reporting functions were made much faster. Details, which might be
important to the Engineer, are available at:
<www.rsasecurity.com/products/securid/rsaaceserver.html>
(The February issues of "SC," the largest US computer security mag,
gave ACE/SecurID 4.0 it's "Best Buy" laurel after comparing the RSA's
line against those of 15 smart card and token vendors. SC
<http://www.infosecnews.com/> praised the "scalability,
ease-of-deployment, and ease-of-use" of ACE/SecurID.)
Ok, so ACE/SecurID, as I hope I have illustrated, is a Grand Old Dame
in Infosec. As the network and infosec threats have evolved over the
past decade, RSA has layered additional defenses and administrative
functions into the ACE/Server, its RDBS, and the ACE client/server
protocol (introduced in '91) -- but the core SecurID token tech has
remained remarkably stable.
Despite claims to the contrary in this thread, the cryptographic hash
used to generate a SecurID's continuous series of 60-second token-codes
has not been changed, or upgraded, since it was first designed by John
Brainard, now Principal Research Engineer at RSA Labs, nearly 15 years
ago.
Yes, the Brainard hash used to generate the SecurID token-codes is
unpublished and RSA proprietary. So is another hash, F2, designed by Ron
Rivest Security Dynamics, and used in the ACE protocol. Amid the
rhetorical frenzy for "open source," it seems to be difficult for even
bright young technocrats to realized that when ACE/SecurID was first
brought to market in the 1980s, big customers (particularly in banking
and financial services) routinely demanded that infosec vendors pledge
to keep any cryptosystems used in their installations secret.
RSA has honored those committments -- but RSA (and Security Dynamics
before it) has always also publicly insisted that the "secrecy" of the
SecurID hash was never required by the ACE/SecurID design... and that
the publication of Brainard's SecurID hash would in no way diminish the
security or integrity of ACE authentication.
[Whistling in the face of the Perfect Storm: The question of _who_
evaluates a cryptosystem is more important than how many people get to
study it. The fact that a cryptosystem is unpublished is not a
meaningful measure of its cryptographic integrity. The discovery of
flaws <gasp> in open source crypto (sometimes after many years in the
field) has repeatedly demonstrated that publication of a cryptosystem is
not, in itself, a guarantee that the crypto will receive careful review,
let alone be quality code. The newsgroups can't seem to grasp this, but
the market does;-]
All things being equal, open source crypto is doubtless more attractive
than unpublished or proprietary crypto for many reasons -- but not
because it guarantees cryptographic quality.
The classic SecurID, built around Brainard's 1985 hash, will finally
begin to be phased out next year, to replaced by a new model SecurID
hardware token which will rely upon MIT Professor Ron Rivest's RC6 block
cipher to safeguard the token's secret key and the time-synch process.
RC6, of course, is RSA's widely-studied candidate to replace the DES in
the ongoing AES competition.
(Two years ago, John Brainard also published a paper describing the
cryptographic mechanics of a new RSApkc-based protocol that will replace
the ten year-old ACE protocol with ACE/Server v.5, and invited customer
and public review.)
As several posts from industry veterans pointed out, "strong" or
two-factor authentication is useful but certainly not sufficient to
provide network security or even just effective access controls. Good
infosec always depends on layers defenses; sometimes interlocked,
sometimes independent.
The SecurID's one-time password (OTP) guards against password theft and
replay attacks, but for protection against both traditional
eavesdropping and packet-level attacks like "TCP splicing" or session
hijacking, the network needs strong crypto.
RSA for years has strongly recommended that token-based authentication
be supplemented with SSH, a VPN, or network encryption -- but it is
obviously a local call whether the risk profile for a given environment
requires it. (I would be surprised if more than half the ACE
installations safeguard their communication channels with crypto.)
Most commercial VPN products, like most commercial firewalls, ship with
an ACE/Agent embedded in their code. [See the list of the 150-odd remote
access, firewall, VPN, and network-application products which ship
"SecurID-Ready," to coin a phrase;-) out of the box:
www.rsasecurity.com/partners.]
The ACE protocol.
Barry Margolin <bar...@genuity.net> recalled that there were a couple
of famous research papers which had suggested that there were
vulnerabilities in the ACE protocol. The ACE protocol is a control
channel used for communication between ACE/Agents (typically embedded in
third-party products like firewalls) and the ACE/Server.
There were two prominent critiques of the ACE protocol published in the
mid-1990s, when the overwhelming dominance ACE/SecurID two-factor user
authentication -- industry estimates credited RSA with 70 percent of the
market for token-based authentication, for sites with over 1,500 seats
(dunno current numbers) -- spurred a half-dozen organized efforts to
crack or deconstructively analyze ACE/SecurID by Gray Hats, ACE
competitors, and sundry infosec consultants looking to count coup.
Adam Shostack, now at Zero Knowledge Systems -- then, a prominent
consultant, and founder of the ACE-focused "SDAdmin" mailing list --
presented "Apparent Weaknesses in the Security Dynamics' Client/Server
Protocol," at a DIMACS workshop in October of 1996. Shostack's text is
at: <http://www.homeport.org/~adam/dimacs.html> See also a notable
pre-publication letter to Mr. Shostack from RSA's John Brainard, at:
<http://www.homeport.org/~adam/brainard.html>
Mr. Shostack reverse-engineered version 1.2 of the ACE protocol to
identify a subtle flaw in the protocol which Security Dynamics (which
had just purchased RSA) had discovered in a routine internal security
review, and fixed, a year earlier. The problem had been patched in a
free "mandatory" upgrade to ACE v.1.3 -- flagged as necessary to address
unspecified security issues and a couple of bugs. (By the fall of '96,
RSA was shipping ACE/Server
v.2 and about to announce ACE version 3.)
In September, 1996, "PieterZ" of Secure Networks Inc.,(now part of
NAI,) had also published a white paper: "Weakness in SecurID." PieterZ's
paper was a more tactical analysis which suggested a variety of
potential attacks on the ACE protocol. See:
<http://www.tux.org/pub/security/secnet/papers/secureid.pdf>.
As the author of a then-popular FAQ on ACE/SecurID, and as a consultant
to RSA, I challenged a lot of Mr. Z's assumptions and arguments in some
widely-reprinted exchanges. See:
<http://www.dataguard.no/bugtraq/1996_3/0458.html> and
<http://www.dataguard.no/bugtraq/1996_3/0474.html>.
Both critiques of ACE/SecurID attracted a lot of attention, then and
since, from potential customers doing due diligence. YMMV, but I -- and,
apparently, most of RSA's ACE/SecurID customers -- felt that the
SecurID, and two-factor authentication, weathered the storms quite well.
Two year later, in 1998 SANS PowerTool Survey, ACE/SecurID won the
highest level of approval, in a poll of SAN corporate network and
security managers, of all network security products. In what I thought
was the most impressive endorsement ever for ACE/SecurID,
92 percent of the SANS network managers who had hands-on experience with
the ACE/Server said that they actively recommmended ACE/SecurID to their
peers as a critical component for network security. See:
<http://www.sans.org/newlook/publications/powertools.htm>
Market share is not the same as technical excellence, as we all know.
It means a lot more, however, when the guys who use and depend upon a
product declare that they understand it, trust it, recommend it, and
count on it to evolve to meet their needs.
The SecurID hash.
Kevin Kadow <kad...@elmhurst.msg.net> suggested that ACE-protected
site and SecurID users are at great risk just because the SecurID relies
upon the proprietary and unpublished Brainard hash.
>> The 'trade secret' behind SecurID is unknown to all but a few, all
>> we have is the testimony of a few experts who were shown the
>> details under an NDA. From what little is known about how SecurID
>> works, when the algorithm does become public knowledge, that may
>> be enough to break the system.
This is unscented bullshit. Gimme a break, Dr. Who!
(A cautionary note may be appropropriate -- for those who believe that
"open source" crypto is inherently more security than any unpublished or
merely peer-reviewed cryptosystem -- but it is rash and naive for Mr. K
to add pizzazz to such a warning with wholly unsupportable allegations
that the SecurID hash is flawed and reversible. Indeed, liable to
implode if exposed to light.)
"Little," indeed, does Mr. Kadow know, if he believes that if or when
the SecurID hash becomes public knowledge, "that may be enough to break
the system."
Over the past 14 years, the ACE/SecurID system has been studied by
hundreds of crypto-savvy corporations, and numerous government agencies
in the US and overseas, many with deep cryptographic expertise. Most of
those companies and government agencies subsequently decided to purchase
ACE/SecurID, or approve the purchase by other agencies they advise.
Unfortunately, none gave press conferences when they finished their
review.
Never the less, some logical deductions are reasonable.
Any serious cryptanalytic evaluation requires -- as Mr. K should know
before he tosses around slimejuice cocktails -- that the investigators
must presume that any future attacker will have full and complette
knowledge of the Brainard hash used in the SecurID. (Look up Kerchoff's
Principles: the only presumed secret is the secret key. Period.) This
means there is a substantial body of opinion, from a lot of crypto
mavens, that the mere publication of the SecurID will not implode ACE
authentication;-)
> There have been rumors of weakness in the algorithm in the past,
> since then they have released new improved versions, with new \
> improved secret algorithms.
Not true. There have been rumors, yes -- because any security
technology that becomes this widely used collects rumors, but it is
simply not true that Brainard's SecurID hash has upgraded or changed or
replaced at any time in the past 14 years.
Mr. Kadow's information is just wrong.
In all these years, the only public comment I have ever heard from any
one of these corporate evaluations of the SecurID crypto came back in
1986, when Adam Shostack presented his paper on
"Apparent Weaknesses" at a DIMAC workshop on network security at
Rutgers. As is often the case with Rutger's events, the audience was
heavily seeded with AT&T staffers, and -- as it happened -- AT&T had
just finished an extensive evaluation of the ACE/SecurID technology and
had decided to buy in a big way.
After Mr. Shostack gave his presentation about how he had reverse
engineered the ACE protocol to an appreciative audience, Steve Bellovin
of AT&T Research -- an infosec luminary, then and now, and the guy who
had led the AT&T evaluation team on ACE -- rose to ask Adam a few
friendly questions. In a reply to one of them, Adam explaining that he,
along with some crypto-capable friends, was still picking apart ACE code
to get to the Brainard's hash, in the hope that it might prove a weak
point for cryptanalytic attack.
"Don't bother," Bellovin told him with a smile. Bellovin said that
AT&T's best cryptographers had studied the Brainard hash carefully and
in depth and had concluded that it was more that sufficient for this
application. No one would reverse the SecurID's one-way function, said
Bellovin, because the mechanics of the hash were so "lossy" -- which
means that too much information, too many bits, were simply discarded at
various stages in the hash calculation.
Without the benefit of similar advice, Mr. Kadow remains ambitious,
albiet suitably paranoid:
> The one thing that keeps myself and others from making an effort to
> crack the SecurID algorithm is the sure knowledge that RSA Security
>(formerly Security Dynamics) will sue anybody who publishes their
> secret formula- and win.
Knock yourself out;-) The current issue of 2600 has a extensive report
on the SecurID architecture (which I imagine will sell more than a few
additional tokens;-) and includes an offer from one of the hacker
commentators to provide a "borrowed" copy of RSA's ACE/Server code --
which obviously includes the Brainard hash -- to anyone who wants to
investigate features like the SecurID's one-way function.
I don't know what RSA would do if someone was dumb enough to sign their
name to a publication of the SecurID hash. I suppose they would have to
do something, but the whole scenario sounds pretty silly in the Year 2K.
If someone is smart enough to try to crack or reverse the Brainard hash
-- and the mathematics of a good hash are relatively straightforward; it
is supposed to be irreversible, not just difficult -- I'll bet he could
figure some untraceable way to get the SecurID hash anonymously
published on the net. My eight year-old son, Joshua, born a Cypherpunk
<Gawd help me>, could show him how;-)
The whole point of such an endeavor, of course, would be to set the
stage so that some budding genius could demonstrate some new
multi-dimensional mathematical magic which would allow our him to
reverse Brainard's SecurID hash, right? ("Cracking" an algorithm, per
se, is not a crime, so I wouldn't worry about a suit at that stage;-)
None of this is news to RSA, which has watched several pieces of
valuable IP (e.g., Rivest's RC4, the "algorithm none dare name") be
laundered by the Net. It might be worth noting, however, that most of
what modern cryptanalysis has used to define weakness in
apparently-strong hashes -- Rivest's MD2, MD4, and MD5, for instance,
which have all been depreciated as more advanced techniques of analysis
became available -- is irrelevant to the function of the SecurID hash.
The function of the SecurID hash is very limited; it only has to be
irreversible. It is only because hashes are today so often used in MD or
message digest functions that we depreciate or discard them if it
becomes possible to identify "collisions:" more than one combination of
inputs which result in an identical output.
In the SecurID application, such collisions are not important. A
successful attack would have to discover the secret key used as input.
That's a much more difficult cryptanalytic challenge -- or, at least,
that appears to have been the opinion of the CIA technical evaluation
team that put a SecurID keyfob on the key ring of the CIA Director.
SHA-1 or any of Rivest's hashes could have been used to replace the
Brainard hash (albiet with considerable disruption) at any time over the
past decade, but RSA Labs -- and Prof. Rivest -- said it was
unnecessary. RSA's customers, duely advised by their own crypto staff,
generally believed them.
I beg the pardon of the newsgoup for the length of this note and the
burden on the bandwidth, but I didn't want to leave so many
misconceptions about a widely-used security tech unchallenged. My
opinions should be taken with a grain of salt, of course, since I
have been a consultant to SDTI and RSA since the late Bronze Age.
Suerte,
_Vin
----
"Cryptography is like literacy in the Dark Ages. Infinitely
potent, for good and ill... yet basically an intellectual construct,
an idea, which by its nature will resist efforts to restrict it to
bureaucrats and others who deem only themselves worthy of such
Privilege." _A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <v...@shore.net> + Boston, USA *
Barry Margolin
> I missed this discussion of RSA's two-factor authentication token, the
>SecurID; and the ACE/Server that supports it. Reading over the thread,
>however, I noticed several unresolved questions and errors of fact which
>I thought I might address, hopefully usefully.
What is your relationship with RSA? Your message seemed to be laced with a
bit of marketing hype. In fact, the style of the first segment seems like
a big quote out of a journal paper (are the parts in [brackets] your
additional commentary?).
> [This allows the Server to better predict what each token will use for
>"Current Time." To minimized false rejections because of unpredicted
>"clock drift," the ACE/Server actually calculates three successive
>token-codes -- for what it expects this SecurID will use for "Current
>Time," and for the minute before, and the minute after -- and will
>accept a match against any of the three as valid.]
That's what I was told when I first started using SecurID about a decade
ago. But I've noticed with our current system that if I'm keying my PIN
onto the card just as the display flips over from one token code to the
next, the passcode is almost always rejected by the ACE/Server. So it
doesn't seem to like the adjacent code like I think it should. I doubt
that the card's clock is getting significantly out of sync with the
ACE/Server, as I usually use the card at least once a day during the week
(we're using it through the TACACS server that our backbone routers use).
[enormous snip]
> I beg the pardon of the newsgoup for the length of this note and the
>burden on the bandwidth, but I didn't want to leave so many
>misconceptions about a widely-used security tech unchallenged. My
>opinions should be taken with a grain of salt, of course, since I
>have been a consultant to SDTI and RSA since the late Bronze Age.
OK, I guess that answers my first question.
Larry Kilgallen
> In article <39528181...@shore.net>, Vin McLellan <v...@shore.net> wrote:
>>SecurID; and the ACE/Server that supports it. Reading over the thread,
>>however, I noticed several unresolved questions and errors of fact which
>>I thought I might address, hopefully usefully.
>
> bit of marketing hype. In fact, the style of the first segment seems like
> a big quote out of a journal paper (are the parts in [brackets] your
> additional commentary?).
<snipping the rest>
> [enormous snip]
>
>> I beg the pardon of the newsgoup for the length of this note and the
>>burden on the bandwidth, but I didn't want to leave so many
>>misconceptions about a widely-used security tech unchallenged. My
>>opinions should be taken with a grain of salt, of course, since I
>>have been a consultant to SDTI and RSA since the late Bronze Age.
>
> OK, I guess that answers my first question.
I met Vin McLellan about 15 years ago, so I watch for his posts.
I do not recall him ever posting in a thread about SecureID without
mentioning his sometime connection with whatever the vendor's name
is that year.
(Whoops, I should lay off the snide remarks about name changes to
someone from BBN/GTE/Genuity :-)
Larry Kilgallen
Vin McLellan
1. Except for special orders, RSA doesn't yet sell 5-year tokens.
SecurIDs are still sold with pre-set life-cycles of 2, 3, and 4 years.
2. The secret key in the RSA SecurID is 64 bits, not 128 bits. It is
widely expected that the next generation of SecurIDs will be able to use
both 64-bit keys, in the current mode, and 128-bit keys. I was thinking
ahead and mistyped;-)
3. RSA has not announced the specs for the next generation of
SecurID tokens. While many RSA customers expect a new (but backward
compatible) SecurID next year, the timing and final design are by no
means set.
Mea culpa. Mea maxima culpa.
Barry Margolin <bar...@genuity.net> asked:
> What is your relationship with RSA?
Public policy consultant. Gunslinger. Amateur industry historian;-) I
do not speak for RSA, as I hope is obvious -- but I do speak and write
about RSA a fair amount, in addition to other work. The politics of
commercial crypto is a rich and fascinating topic -- and I was writing
about the need for "strong authentication" tokens even before Bob Bosen
dreamed up the C/R token; before Ken Weiss invented the SecurID too.
The Engineer was right, btw. Vendors don't offer this sort of open
discussion of strengths and weaknesses, past and present, on their
websites. It's only available out here, in the collective memory we
sustain in forums like this.
> Your message seemed to be laced
> with a bit of marketing hype. In fact, the style of the first segment
> seems like a big quote out of a journal paper (are the parts in
> [brackets] your additional commentary?).
Only a bit of marketing? Good.
It is really_ difficult to avoid sounding like a shill while offering
relevant facts about an active product in a competitive marketplace,
particularly when you start out with a broad request for background data
about a vendor's craftmanship, state-of-the-art status, and how a
security product measures up against hostile threat profiles.
(Not to mention the issues and offshoot raised in a dozen scattered
replies, which had tossed up bits of odd history; impassioned
denunciations; flammable crypto politics; and vague references to
alternative technologies;-)
I might have responded to the individual messages, but it seemed to me
that what was lacking among them was a sense of technical and historical
context. Offering something like that also seemed the best way to frame
a useful reply to The Engineer's original query (particularly since I
was a bit player in the earlier debates about ACE/SecurID that had
already been briefly mentioned.)
Before I could do that, I realized that I better explain the basics.
(I presume that for every graybeard like Barry, Larry, and me, there
are probably 100,000 readers of comp.security.misc who haven't the
faintest idea how a SecurID works, how the ergometrics featured in RSA's
success with the SecurID, etc.)
Funny you should say it read like a journal article. In the e-mail
response, I got one manuscript to review, and two separate requests to
reprint or rewrite my rambling retrospective in various journals.
Anyway, the words are all mine -- shot from the hip, so to speak, after
I spent a half hour digging up URLs for (non-postscript versions of) the
papers you had referred to in passing.
With more time, I could have written it shorter; spell-checked and
edited it better -- maybe even caught <groan> my glaring error about the
64-bit SecurID seed. However, I like to think The Engineer, and those
with similar needs, still found my reply responsive to his inquiry... if
maybe a bit more;-)
Criticism, corrections, and other comments are always welcome.
Obiwankenobi
Hash: SHA1
Hi
You can also have it with 4 digits, not only 6-8. Although 4 digits
is quite dangerous for brute forcing.
Bye, Obiwankenobi
- ---------------------------------------------------------
Email: obiwan...@deathstar.ch
Web: http://www.deathstar.ch
Messenger: obiwank...@hotmail.com
PGP Public Key: http://www.deathstar.ch/about/files/Obiwankenobi.asc
PGP Key: C280 EC1C 42F0 F838 1AF5 9824 47AA 28DA C96D 9977
May the force be with you !
- ---------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBOVSVU0eqKNrJbZl3EQJE6QCg6H2foSP51VXC09/Tv9cy9skXrOEAoIri
R965L2w1WnnJTnx/BMt5Bb7f
=e7sA
-----END PGP SIGNATURE-----
Kevin Kadow
break authentication systems for my clients. I don't suggest that I have any
special knowledge of the SecurID product, I'm just a customer of theirs.
I do my SecurID logins through SSH, encrypted with IDEA, primarily because
I don't like the idea of sending the PIN in the clear, while the users prefer
the keyfob tokens.
> Despite claims to the contrary in this thread, there can be no
>ACE/SecurID authentication unless the user submits both a memorized PIN
>and the SecurID token-code. Two-factor authentication is fundamental to
>the ACE design. A user to which a SecurID has been assigned is expected
>to carry the token on his or her person; take reasonable measures to
>physically safeguard it; and report its loss or theft immediately to his
>employer.
...
> For most of these years, the relative cryptographic strength of the
>different types of HHA tokens was considered pretty much a wash. More
>recently, the depreciation of DES and Paul Kocher's landmark work on
>timing attacks on crypto hardware raised new threats and highlighted the
>importance of the PIN -- which too many had taken for granted -- in
>two-factor authentication.
The PIN is the same every time, and is almost universally transmitted in the
clear (one exception is the SecurID 'PINpad'). The PIN is easily compromised.
>> The 'trade secret' behind SecurID is unknown to all but a few, all
>> we have is the testimony of a few experts who were shown the
>> details under an NDA. From what little is known about how SecurID
>> works, when the algorithm does become public knowledge, that may
>> be enough to break the system.
>
> This is unscented bullshit. Gimme a break, Dr. Who!
A hash can be brute-forced- the tokens implemented it on hardware that retailed
under $100 a decade ago, and I don't need to 'break the system' in realtime.
I can capture authentications with timestamps of many of the target user's
sessions (tens, dozens, hundreds), then take my time working out the key.
> (A cautionary note may be appropropriate -- for those who believe that
>"open source" crypto is inherently more security than any unpublished or
>merely peer-reviewed cryptosystem -- but it is rash and naive for Mr. K
>to add pizzazz to such a warning with wholly unsupportable allegations
>that the SecurID hash is flawed and reversible. Indeed, liable to
>implode if exposed to light.)
I am not a big fan of the 'Open Source' movement, but I'm even more wary of
'trade secrets' in the area of computer security.
>"Little," indeed, does Mr. Kadow know, if he believes that if or when
>the SecurID hash becomes public knowledge, "that may be enough to break
>the system."
I didn't say _WILL_, I said _MAY_. But knowing that it's a hash of the
output of a clock is enough for me to say that it "may be enough".
>> There have been rumors of weakness in the algorithm in the past,
>> since then they have released new improved versions, with new \
>> improved secret algorithms.
>
> Not true. There have been rumors, yes -- because any security
>technology that becomes this widely used collects rumors, but it is
>simply not true that Brainard's SecurID hash has upgraded or changed or
>replaced at any time in the past 14 years.
>
> Mr. Kadow's information is just wrong.
Okay, I've been told wrong. I had received new tokens, accompanied by a
software upgrade and a note that the tokens received would not function with
a non-upgraded ACE. This was in the distant past, so I could be wrong as to
why the 'new tokens' were a problem.
> Without the benefit of similar advice, Mr. Kadow remains ambitious,
>albiet suitably paranoid:
>
>> The one thing that keeps myself and others from making an effort to
>> crack the SecurID algorithm is the sure knowledge that RSA Security
>>(formerly Security Dynamics) will sue anybody who publishes their
>> secret formula- and win.
...
> I don't know what RSA would do if someone was dumb enough to sign their
>name to a publication of the SecurID hash. I suppose they would have to
>do something, but the whole scenario sounds pretty silly in the Year 2K.
Bullshit. Being sued by a corporation for revealing the secret of their
encryption 'sounds pretty silly'? You must not read the newspapers.
> If someone is smart enough to try to crack or reverse the Brainard hash
>-- and the mathematics of a good hash are relatively straightforward; it
>is supposed to be irreversible, not just difficult -- I'll bet he could
>figure some untraceable way to get the SecurID hash anonymously
>published on the net. My eight year-old son, Joshua, born a Cypherpunk
><Gawd help me>, could show him how;-)
Some of us don't believe in publishing our findings under assumed names.
> The whole point of such an endeavor, of course, would be to set the
>stage so that some budding genius could demonstrate some new
>multi-dimensional mathematical magic which would allow our him to
>reverse Brainard's SecurID hash, right? ("Cracking" an algorithm, per
>se, is not a crime, so I wouldn't worry about a suit at that stage;-)
You may know cryptography, but you might want to ask a lawyer before making
suggestions about trade secrets, software licenses, and the law. Were a
licensed user of ACE/Server to 'break the system', RSA would sue, and win.
> The function of the SecurID hash is very limited; it only has to be
>irreversible. It is only because hashes are today so often used in MD or
>message digest functions that we depreciate or discard them if it
>becomes possible to identify "collisions:" more than one combination of
>inputs which result in an identical output.
>
> In the SecurID application, such collisions are not important. A
>successful attack would have to discover the secret key used as input.
>That's a much more difficult cryptanalytic challenge -- or, at least,
>that appears to have been the opinion of the CIA technical evaluation
>team that put a SecurID keyfob on the key ring of the CIA Director.
Are you sure? the input of the function is a clock- collisions could be very
important, and you just need find ONE in the future lifetime of the token.
Sure, this might give you a 60-second window at 3:17AM on January 23, 2003
where you could log in as the user- is that acceptable risk?
Larry Kilgallen
> The PIN is the same every time, and is almost universally transmitted in the
> clear (one exception is the SecurID 'PINpad'). The PIN is easily compromised.
You seem to have knowledge about relative sales of the various models
that I lack. Certainly you cannot reveal your sources, but presuming
your statistics are correct about sales since the PINpad model was
revealed:
You seem to be commenting about the intelligence
of the buying public, rather than about the vendor.
I would discount the possibility that sales agents of the vendor are
trying to steer customers toward the cheaper model.
Vin McLellan
> > [...] To minimized false rejections because of
> >successive token-codes -- for what it expects this SecurID will use
> >for "Current Time," and for the minute before, and the minute after
> >-- and will accept a match against any of the three as valid.]
Barry Margolin <bar...@genuity.net> replied:
> That's what I was told when I first started using SecurID about a
> decade ago. But I've noticed with our current system that if I'm
> keying my PIN onto the card just as the display flips over from one
> token code to the next, the passcode is almost always rejected by
> the ACE/Server. So it doesn't seem to like the adjacent code like I
> think it should. I doubt that the card's clock is getting
> significantlyout of sync with the ACE/Server, as I usually use the
> card at least once a day during the week (we're using it through the
> TACACS server that our backbone routers use).
I don't think your problem has anything to do with the synchroneity of
the clocks in your SecurID and the ACE/Server' host. It's been a while
since I've played with a PINpad token, but I believe the situation you
describe is just an awkward artifact of the design used for these
tokens.
(It is your PINpad SecurID -- not the remote ACE/Server -- which is
rejecting your PIN, right? Blanking briefly? Then forcing you to wait a
moment to reenter your PIN?)
A PinPad SecurID is designed to add the PIN not to the token-code which
is, at that moment, being displayed on the token's LCD screen -- it adds
your PIN to the _next_ token-code, and then displays the combined sum as
your one-time password.
If I understand your problem correctly, I think your PinPad SecurID
rejects your PIN, and stalls, because it is in the process of
calculating the next token-code.
The SecurID doesn't hold the "current" token-code in memory, so it
can't add the PIN to that -- and it doesn't yet have the _next_
token-code, so it can't add the PIN to that, either.
The PINpad SecurID was one of the many things I didn't address
in my earlier overwritten exegesis. Glad you mentioned it again;-)
With a PinPad SecurID -- for those unfamiliar with these tokens -- a
user taps his PIN into the token via a keypad built into face of the
credit-card-sized SecurID. The token adds his PIN (no carry) to the
pseudo-random (PRN) token-code, and displays the combined result as the
SecurID's one-time password.
When a static number (like your PIN), gets added to a PRN (like a
SecurID token-code), the sum is always a pseudo-random number -- which
makes it impossible for an eavesdropper to extract the PIN. This process
sacrifices the ease-of-use advantage of the SecurID over C/R tokens, but
it clearly offer more security for the user's PIN.
A PinPad SecurID is designed to protect the user's PIN from being
sniffed and snatched, which otherwise might be possible if a user's PIN
and SecurID's token-code are simply concatonated and transmitted over a
unencrypted circuit to the ACE/Agent.
(Between the ACE/Agent and the ACE/Server, of course, all messages
associated with the authentication service are encrypted.)
The PINpad SecurID -- just because it offers additional
protection to only the PIN (and not the whole communications session) --
is kind of a mid-range security mechanism.
In many traditional applications, a SecurID user simply prepends
the PIN to the SecurID token code and send off both to an ACE/Agent, and
thence to the ACE/Server.
In a unencrypted environment, the PIN is obviously vulnerable to a
sniffer or wiretap.
Despite this vulnerability, however, the token's one-time password
often was (and is) seen as an ample defense against low-level
adversaries, those unlikely to tap a telephone line, or bug the terminal
server. In this low-threat environment, the PIN is seen largely as a
safeguard against misuse of a lost or stolen token.
The PINpad SecurID was designed to address a somewhat more
demanding threat scenario: a environment where the bad guys may tap
phones, or sniff data-traffic, to collect PINs... with an eye to some
future physical theft of a specific SecurID.
Many corporate or government ACE installations issued both classic
SecurID cards or keyfobs, and PINpad SecurIDs, and supported various
levels of authentication security for different users, different
environments.
Of course, even the PINpad SecurID can only enhance the security of the
authentication service, per se. It does not secure either the network
connection or the data transmitted over it.
"Strong authentication" -- no matter what bells and whistles are
attached -- can't block wiretappers, sniffers, or other on-line monitors
from listening to anything transmitted on a data channel. Nor can it
block active packet-level attacks like "session hijacking."
To address those threats, you need strong crypto.
And ironically, when you encase the data flow in strong crypto, the
classic SecurID -- in all its glorious simplicity -- again becomes fully
the equal of the PINpad SecurID... and then some.
Obi-Wan <obiwan...@deathstar.ch> reported that RSA will still sell
SecurIDs with LCDs with space for as few as four characters, which
physically limits the length of the token-code on those SecurIDs to four
digits (or alphanummeric characters.)
/> You can also have it with 4 digits, not only 6-8. Although 4 digits
/> is quite dangerous for brute forcing.
Frankly, I'm surprised -- but I guess, if you are the buyer, you can
spec your order anyhow.
I know RSA began strongly recommending 6-8 digit (or alphanumeric)
token-codes probably 6-7 years ago.
OTOH: different environments; different threat scenarios; different
requirements.
One of the most useful proverbs in this business, dating back 40 years
or so, reminds us that it is difficult, if not impossible, to say
anything useful about a security machanism until you understand the
context and specific environment in which it will be used.
Vin McLellan
> > [...] To minimized false rejections because of
> >successive token-codes -- for what it expects this SecurID will use
> >for "Current Time," and for the minute before, and the minute after
> >-- and will accept a match against any of the three as valid.]
Barry Margolin <bar...@genuity.net> replied:
Vin McLellan
Considering an attack on the SecurID hash which generates the 60-second
token-code, Kevin Kadow <kad...@elmhurst.mag.net> wrote:
> A hash can be brute-forced- the tokens implemented it on hardware that retailed
> under $100 a decade ago, and I don't need to 'break the system' in realtime.
>
> I can capture authentications with timestamps of many of the target user's
> sessions (tens, dozens, hundreds), then take my time working out the key.
With a big enough hammer, you can break anything. Any cipher or hash
can be brute-forced, at least theoretically.
I do think, however, that you are vastly underestimating the scale of
the effort involved, and the nature of the results, were you to be
ultimately successful.
> I didn't say _WILL_, I said _MAY_. But knowing that it's a hash of the
> output of a clock is enough for me to say that it "may be enough".
You repeatedly misstate the problem.
The SecurID token-code is _not_ just a hash of clock output (i.e., a
binary representation of Current Time.)
"Current Time" and a token-specific 64-bit secret key are _both_ put
through Brainard's one-way function to generate a 6-8 digit SecurID
token-code.
Even if you get a true copy of the SecurId algorithm; and even if you
also obtain an accurate representation of what that particular token had
used as Current Time when it generated a particular token-code -- your
brute-force attack would still have to search through a solution space
equal to all possible combinations of the 64-bit secret key used to
generate a particular token-code.
Big task.
Surete,
_Vin
Kevin Kadow
> With a big enough hammer, you can break anything. Any cipher or hash
>can be brute-forced, at least theoretically.
particularly difficult to attack. And attacking hashed authentication systems
is not cutting edge crytography.
Is Brainard really that much better than DES?
> I do think, however, that you are vastly underestimating the scale of
>the effort involved, and the nature of the results, were you to be
>ultimately successful.
The whole concept is not new to me- I covered this same ground with Network
Associate's "Gauntlet" in Bugtraq over a year ago, the primary difference
being that SNK-004 and Cryptocard use DES, for which brute-force attacks are
well known.
>> I didn't say _WILL_, I said _MAY_. But knowing that it's a hash of the
>> output of a clock is enough for me to say that it "may be enough".
>
> You repeatedly misstate the problem.
>
> The SecurID token-code is _not_ just a hash of clock output (i.e., a
>binary representation of Current Time.)
>
> "Current Time" and a token-specific 64-bit secret key are _both_ put
>through Brainard's one-way function to generate a 6-8 digit SecurID
>token-code.
Okay, I glossed over details. I am familiar with several token systems based
on a fixed shared secret and a challenge or timestamp, passed through a hash
to produce a 6-8 digit token-code. For example, Cryptocard, Axent, Safeword,
ActivCard and other X9.9 tokens compete in the same market as SecurID. Most
of these use some multiple-DES scheme rather than a secret hash algorithm.
Are they better or worse than SecurID? I cannot say.
> Even if you get a true copy of the SecurId algorithm; and even if you
>also obtain an accurate representation of what that particular token had
>used as Current Time when it generated a particular token-code -- your
>brute-force attack would still have to search through a solution space
>equal to all possible combinations of the 64-bit secret key used to
>generate a particular token-code.
>
> Big task.
This isn't significantly different from some other authentication protocols
which I have considered in detail in the past, aside from the hash used: