[17028] in cryptography@c2.net mail archive
RE: two-factor authentication problems
daemon@ATHENA.MIT.EDU (Gabriel Haythornthwaite)
Mon Mar 7 11:23:40 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Reply-To: <gabriel@castelain.com.au>
From: "Gabriel Haythornthwaite" <gabriel@castelain.com.au>
To: "'Matt Crawford'" <crawdad@fnal.gov>,
"'Ed Gerck'" <egerck@nma.com>
Cc: <cryptography@metzdowd.com>
Date: Mon, 7 Mar 2005 15:51:07 +1100
In-Reply-To: <f041ebdf457acb1964be50a0a2aeda74@fnal.gov>
You're quite correct Matt,
Which is why IMHO you can only really get true "non-repudiation" through =
use
of PKI. And more specifically:
- where the key pair was generated by the end-user, and
- where the server has stored a copy of the transaction - digitally =
signed
by the end user - which it can reproduce in court. =20
In this case, a corrupt operator could not have faked the transaction =
even
if they had wanted to.=20
RSA SecureID and OATH technology have some great virtues:
- they cost nothing to integrate at the client end - there is no client
"footprint" so there's nothing to go wrong
- they are relatively easy to understand and use
- they're unquestionably better than reliance on user IDs and passwords.
What they won't do is:
- provide non-repudiation
- defend against man-in-the-middle attacks, or
- provide a robust defence against phishing scams
And for these reasons I suspect their days are numbered.
All the best,
Gabriel Haythornthwaite
gabriel@castelain.com.au
Phone: +61 412 544 632
Fax: +61 2 9798 3935
www.castelain.com.au
> -----Original Message-----
> From: owner-cryptography@metzdowd.com=20
> [mailto:owner-cryptography@metzdowd.com] On Behalf Of Matt Crawford
> Sent: Monday, 7 March 2005 1:38 PM
> To: Ed Gerck
> Cc: cryptography@metzdowd.com
> Subject: Re: two-factor authentication problems
>=20
>=20
>=20
> On Mar 5, 2005, at 11:32, Ed Gerck wrote:
>=20
> > The worse part, however, is that the server side can always=20
> fake your=20
> > authentication using a third-party because the server side=20
> can always=20
> > calculate ahead and generate "your next number" for that=20
> third-party=20
> > to enter -- the same number that you would get from your=20
> token. So, if=20
> > someone breaks into your file using "your" number -- who is=20
> > responsible? The server side can always deny foul play.
>=20
> Huh? The server can always say "response was good" when it wasn't=20
> good. Unless someone reclaims the server from the corrupt=20
> operator and=20
> analyzes it, the results are the same.
>=20
>=20
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to=20
> majordomo@metzdowd.com
>=20
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
