Only problem is that cell phones have become so utterly complex (hosting
several processors and a plethora of software components) that it will never
become the trusted device that we once thought it could be...
Personal it is though
Jaap-Henk
On Sat, 09 Jul 2005 18:56:22 -0700 James A.
Actually, Dutch banks already give users the option to recieve one-time
pass-codes by SMS to authenticate internet banking transactions (instead of
sending a list of those codes on paper by ordinary mail in advance). So it's
less unrealistic than you think.
Jaap-Henk
On Sat, 09 Jul 2005
ref:
http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and
authentication
one of the issues raised in the x9.59
Jaap-Henk Hoepman wrote:
Actually, Dutch banks already give users the option to recieve one-time
pass-codes by SMS to authenticate internet banking transactions (instead of
sending a list of those codes on paper by ordinary mail in advance). So it's
less unrealistic than you think.
there is
the spring of 1995.
http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and
authentication
a trivial side-note ... since the SET specification wasn't issued by a
sanction standards body ... it wasn't a Standard in the official sense.
one of the operational differences between SET
If you had two products ... both effectively performing the same
function, one you already had deployed, which was significantly cheaper,
significantly simpler, and significantly faster, which one would you choose?
I was told that one of the reasons SSL took off was because Visa and/or MC
told
On Jul 14, 2005, at 8:13 PM, Rich Salz wrote:
If you had two products ... both effectively performing the same
function, one you already had deployed, which was significantly
cheaper,
significantly simpler, and significantly faster, which one would
you choose?
I was told that one of the
Rich Salz wrote:
I was told that one of the reasons SSL took off was because Visa and/or MC
told merchants they would for the time being treat SSL as card-present,
in terms of fraud penalties, etc. If this is true (anyone here verify?
My source is on the list if s/he wants to name themselves),
Perry E. Metzger wrote:
Ben Laurie [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Anonymity is a concern to me, too, but I suspect that it is hard to
get anonymity in a credit card transaction using current means, even
if the merchant isn't online. Pseudonymity, perhaps.
Can we not aim
a harder problem for early stage web merchants was getting a merchant
financial institution the merchant financial institution that
sponsors a merchant for payment transactions ... takes financial
responsibility for that merchant.
the standard procedure was to send somebody out to the retail
On 7/14/05, Anne Lynn Wheeler [EMAIL PROTECTED] wrote:
remember what Verisign was called before it was renamed Verisign?
Digital Certificates International, Inc.
Did you consult for First Data Corp. at the time?
Aram Perez wrote:
One other point, SET did NOT require certs for the consumers. The
client-merchant protocol supported clients without certs.
there was a later set-lite w/o certs for clients ... but the original
specification had client certs as part of the core process.
note that the SET
Ram A Moskovitz wrote:
Did you consult for First Data Corp. at the time?
some reference:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
little later, we got to review chaum and brand stuff. brand had done a
take-off on chaum's stuff so that if somebody
I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that we're
talking about credit instruments,
Wasn't that a goal of SET?
/r$
--
Rich Salz Chief Security Architect
DataPower Technology
Rich Salz [EMAIL PROTECTED] writes:
I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that we're
talking about credit instruments,
Wasn't that a goal of SET?
Some of it was, yah. I don't claim that any of this is
Rich Salz wrote:
Wasn't that a goal of SET?
there was an observation that SET possibly wouldn't divulge your account
number until the merchant had been determined to be some entity
registered as a merchant (akin to the SSL domain name infrastructure
certificates ... if a spoofed site didn't use
On Jul 14, 2005, at 6:23 AM, Perry E. Metzger wrote:
Rich Salz [EMAIL PROTECTED] writes:
I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that
we're
talking about credit instruments,
Wasn't that a goal of SET?
Some
Pat Farrell wrote:
On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote:
I think that by eliminating the need for a merchant to learn
information about your identity ...
Wasn't that a goal of SET?
As I recall, the goal of SET was to have a standard
that was not invented by CyberCash. (I may
Aram Perez wrote:
While the SET protocol was complicated, it's failure had nothing to do
with that fact or the lack of USB on PCs. You could buy libraries that
implemented the protocol and the protocol did not require USB. IMO, the
failure had to do with time-to-market factors. In the late
Pat Farrell wrote:
As others have said, and in the spirit of the subject
of this thread, SET failed for many reasons, many
of them economic. There was little effort made
to bribe the merchants, I think there was talk of
a 26 basis point change in the discount rate,
which the banks thought
At 2:48 PM -0700 7/12/05, Bill Stewart wrote:
It'd be nice if good crypto and authentication methods
could create a market for improved products
It can, it does, and it's called significantly reduced risk-adjusted
transaction cost in financial econ-speak. Maybe the marketing droids need
to come
Well, whether you like the cell phone as
the out-of-band second-factor, you can now
unlock your front door with it...
http://weblog.physorg.com/news2334.html
--dan
-
The Cryptography Mailing List
Unsubscribe by sending
Perry E. Metzger wrote:
Florian Weimer [EMAIL PROTECTED] writes:
* Perry E. Metzger:
Nick Owen [EMAIL PROTECTED] writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to
Ben Laurie [EMAIL PROTECTED] writes:
That could be fixed. I think the right design for such a device has
it only respond to signed and encrypted requests from the issuing
bank directed at the specific device, and only make signed and
encrypted replies directed only at the specific issuing
In Brazil there's alot of trojans similar to the one Steven mentioned,
almost all of them targeted at diferent national banks.
A while back they worked as external pop-ups as we named them. That is
they appeared on top of the browser appearing visually like when you are
asked for your
Perry E. Metzger wrote:
Ben Laurie [EMAIL PROTECTED] writes:
That could be fixed. I think the right design for such a device has
it only respond to signed and encrypted requests from the issuing
bank directed at the specific device, and only make signed and
encrypted replies directed only at
Perry E. Metzger wrote:
By the way, I note as an aside that this also means (in my opinion)
that certificates are no longer an interesting technology for
payments protocols, because in a purely online environment, you
never need a third party x.509 certificate in the course of the
payments
Perry E. Metzger wrote:
Ah, I see what you mean.
Sadly, I don't think there is much to be done about that, but I think
that (personally) I'd only end up with two of the things. If they can
be made credit card sized, I don't see this as worse than what I have
to carry now.
there are a
Ben Laurie [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Anonymity is a concern to me, too, but I suspect that it is hard to
get anonymity in a credit card transaction using current means, even
if the merchant isn't online. Pseudonymity, perhaps.
Can we not aim higher than merely doing
At 09:29 PM 7/9/2005, Perry E. Metzger wrote:
The Blue Card, so far as I can tell, was poorly thought out beyond its
marketing potential. I knew some folks at Amex involved in the
development of the system, and I did not get the impression they had
much of a coherent idea of what the
On Tue, Jul 12, 2005 at 02:48:02PM -0700, Bill Stewart wrote:
| At 09:29 PM 7/9/2005, Perry E. Metzger wrote:
| The Blue Card, so far as I can tell, was poorly thought out beyond its
| marketing potential. I knew some folks at Amex involved in the
| development of the system, and I did not get the
as always.
Cheers, Scott
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Saturday, July 09, 2005 6:32 PM
To: cryptography@metzdowd.com
Subject: Re: the limits of crypto and authentication
Nick Owen writes:
| I think that the cost
I think the failure of Amex Blue is due to poor timing and the
requirement for hardware on the end-user's PC. At the time of it's
introduction ecommerce and online banking were just getting started and
consumers were more worried about whether the store was real or not than
having their card
Perry E. Metzger wrote:
Far better would be to have a token with a display attached to the
PC. The token will display a requested transaction to the user and
only sign it if the user agrees. Because the token is a trusted piece
of hardware that the user cannot install software on, it provides
Steven M. Bellovin wrote:
There's been a lot of discussion about how to strengthen cryptography
and authentication, to get away from problems of phishing, pharming,
etc. But such approaches can take you only so far, as this link
indicates:
http://www.lurhq.com/grams.html
Briefly, it's a
I think the difference now is the number of vendors entering the market,
the variety of solutions ( and their relative security), and demand
outside of Europe. When we started in mid-2001, we were looking at the
existing hardware guys and that is it. Now there a handful of
venture-backed
* Perry E. Metzger:
Nick Owen [EMAIL PROTECTED] writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.
Far better would be to have a token with a display
Take a look at Boojum Mobile -- it is
precisely the idea of using the cell
phone as an out-of-band chanel for an
in-band transaction.
http://www.boojummobile.com
In the foreseeable future, this approach won't stop fraudulent
transactions because the one-time password does not depend on the
On Sun, 10 Jul 2005, Amir Herzberg wrote:
But... crypto and authentication, imho, are the best tools to prevent
such malware from being installed.
I disagree. Limited authority is the best way to prevent such malware
from being installed (and, if installed, from causing harm).
The premise
[EMAIL PROTECTED] writes:
Take a look at Boojum Mobile -- it is precisely the idea of using the cell
phone as an out-of-band chanel for an in-band transaction.
http://www.boojummobile.com
Banks here have been using it to authenticate higher-value electronic
transactions as well. The way it
Nick Owen wrote:
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking. Also, the more uses for the
token, the more shared the costs will be. The question to me is will
the FIs go with a anything beyond secure cookies, IP address
On Saturday 09 July 2005 23:31, [EMAIL PROTECTED] wrote:
Nick Owen writes:
| I think that the cost of two-factor authentication will plummet in the
| face of the volumes offered by e-banking.
Would you or anyone here care to analyze
what I am presuming is the market failure
of Amex
[EMAIL PROTECTED] writes:
Nick Owen writes:
| I think that the cost of two-factor authentication will plummet in the
| face of the volumes offered by e-banking.
Would you or anyone here care to analyze
what I am presuming is the market failure
of Amex Blue in the sense of its chipcard
Florian Weimer [EMAIL PROTECTED] writes:
* Perry E. Metzger:
Nick Owen [EMAIL PROTECTED] writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.
Far better
another characteristic of the PKI x.509 identity certificate activity
(besides attempting to create mass world-wide confusion regarding the
difference between identification and authentication ... and trying to
get govs. to mandate that x.509 identity certificates, grossly
overloaded with personal
Peter Gutmann wrote:
[EMAIL PROTECTED] writes:
Take a look at Boojum Mobile -- it is precisely the idea of using the cell
phone as an out-of-band chanel for an in-band transaction.
http://www.boojummobile.com
Banks here have been using it to authenticate higher-value electronic
Perry E. Metzger wrote:
However, you need both the end to end communication and the hardware
token with built in display and keyboard.
there is two issues for digital signatures ...
1) something you have authentication and
2) proof to the relying party as to the integrity level of the
There's been a lot of discussion about how to strengthen cryptography
and authentication, to get away from problems of phishing, pharming,
etc. But such approaches can take you only so far, as this link
indicates:
http://www.lurhq.com/grams.html
Briefly, it's a Trojan that waits for you to
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.
Steven M. Bellovin wrote:
There's been a lot of discussion about how to strengthen cryptography
and
In message [EMAIL PROTECTED], Nick Owen writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.
How does the user know which transaction is really being
To validate the transaction, a receipt could be sent to the user
encrypted by the server's public key. If the receipt is correct, the
user enters their PIN to 'sign' the transaction.
I'm assuming an asymmetric authentication system here outside the
browser. The attacker would have to steal the
Steven M. Bellovin wrote:
There's been a lot of discussion about how to strengthen cryptography
and authentication, to get away from problems of phishing, pharming,
etc. But such approaches can take you only so far, as this link
indicates:
http://www.lurhq.com/grams.html
Briefly, it's a
* Steven M. Bellovin:
In message [EMAIL PROTECTED], Nick Owen writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.
How does the user know which transaction
FTR, e-gold were aware of the general makeup of this
threat since 1998 and asked someone to look at it. The
long and the short was that it was more difficult to solve
than at first claimed, so the project was scrapped. This
was a good risk-based decision. The first trojans that I
know of for
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking. Also, the more uses for the
token, the more shared the costs will be. The question to me is will
the FIs go with a anything beyond secure cookies, IP address validation
and unique
Nick Owen [EMAIL PROTECTED] writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.
Far better would be to have a token with a display attached to the
PC. The
Florian Weimer writes:
|
| It would seem simple to thwart such a trojan with strong authentication
| simply by requiring a second one-time passcode to validate the
| transaction itself in addition to the session.
|
|
| How does the user know which transaction is really being
Nick Owen writes:
| I think that the cost of two-factor authentication will plummet in the
| face of the volumes offered by e-banking.
Would you or anyone here care to analyze
what I am presuming is the market failure
of Amex Blue in the sense of its chipcard
and reader combo?
--dan
* Nick Owen:
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking.
I doubt this is true. In Germany, we already use some form of
two-factor authentication for Internet banking transaction (account
number/password and a one-time
--
Ian Grigg [EMAIL PROTECTED]
In the payments world we've known how to solve all
this for some time, since the early 90s to my
knowledge. The only question really is, have you got a
business model that will pay for it, because any form
of token is very expensive, and the form of token
60 matches
Mail list logo
