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 i
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
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 20:38:38
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. Do
ndicates that browsers with ssl support appeared
late 1994 with big announcement 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
At 06:56 AM 7/14/2005, 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 ...
...
In all the discussion here, the thing that
strikes me is that we need to stop using secrets
as
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
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
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?
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
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
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),
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 re
> 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
to
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 thoug
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 la
Aram Perez <[EMAIL PROTECTED]> writes:
> 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
On Thu, 2005-07-14 at 18:43 +0200, Amir Herzberg wrote:
> Pat Farrell wrote:
> >
> > As I recall, the goal of SET was to have a standard
> > that was not invented by CyberCash. (I may be biased, I
> > worked at CyberCash at the time).
> This is incorrect. The main politics around SET was the arti
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 b
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
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 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 be biased, I
w
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
> 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 htt
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
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 t
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 technologies
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 mer
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
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
> payment
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 as badly as current systems do?
--
>>>Ap
Ben Laurie <[EMAIL PROTECTED]> writes:
>>>Not entirely clear what you mean by the "issuing bank" here, but I'm
>>>hoping you don't mean that the bank issues the device - that would be
>>>very tedious.
>>
>> Tedium is something that computers do very well. They don't care
>> about how much work the
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
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 cred
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 is
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
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 "unsubs
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 oper
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
transaction
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
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
[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 chipc
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 A
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 v
[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
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 th
> 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
* 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
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 softwar
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 Tro
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 provid
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 stole
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 of
--
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 t
* 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 passw
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
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 a
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.
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 imag
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 e-g
* 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
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 Tr
Nick Owen wrote:
> 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 attack
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 us
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 auth
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 authenticat
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 lo
67 matches
Mail list logo
