Re: ID "theft" -- so what?

[Ian G]

Ben Laurie wrote:

Ian Grigg wrote:


Too many words?  OK, here's the short version
of why phising occurs:

"Browsers implement SSL+PKI and SSL+PKI is
secure so we don't need to worry about it."

PKI+SSL *is* the root cause of the problem.  It's
just not the certificate level but the business and
architecture level.  The *people* equation.



PKI+SSL does not _cause_ the problem, it merely fails to solve it. You 
may as well blame HTTP - in fact, it would be fairer.


Well, blaming a protocol which is an inanimate
invention of man is always unfair, but so is
avoiding the issues by quibbling on the meanings.

Blaming HTTP is totally unfair as it never ever
promised to protect against spoofs.

PKI+SSL promised to detect and cover spoofs.  In
fact, the original point of PKI was to close out
the MITM or spoof, and was then enlarged somewhat
confusingly to provide some sort of commerce
guarantee on the stated identity (c.f, Lynn's
amusing stories of CAs gone mad with dollarlust.)

Originally, Netscape's browser implemented the
complete anti-spoofing UI and included more info
on the screen.  This was then dropped in the
screen wars, against the advice of security
engineers at Netscape.  (Ref:  comments by Bob
R.)

So, to repeat:It's not the certificate
level but the business and architecture level.
The *people* equation.  It's the people who
implement the PKI+SSL model and don't do it
properly that are the root cause of phishing.

Petnames, Trustbar, DSS are some of the solutions
that work *positively* and *constructively* to
close the loopholes in the browser's implementation
of PKI+SSL.

iang

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Ben Laurie]

Ian Grigg wrote:

Too many words?  OK, here's the short version
of why phising occurs:

"Browsers implement SSL+PKI and SSL+PKI is
secure so we don't need to worry about it."

PKI+SSL *is* the root cause of the problem.  It's
just not the certificate level but the business and
architecture level.  The *people* equation.


PKI+SSL does not _cause_ the problem, it merely fails to solve it. You 
may as well blame HTTP - in fact, it would be fairer.


Cheers,

Ben.

--
>>>ApacheCon Europe<<<   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Alan Barrett]

On Fri, 22 Jul 2005, Jerrold Leichter wrote:
> The banks, operating through the clearing agents, could if they wished
> impose a requirement on the way names appear in billing statements,
> regardless of how the names appear on contracts.  Alternatively,
> they could at least require that an end-user-familiar name be made
> available in whatever database records all merchants, which the banks
> obviously have access to.

A bank once told me that it was impossible for them to convert from an
unintelligible name on a credit card statement into any other kind of
name whatsoever (and certainly not into an end-user-familiar name),
and impossible for them to show me a copy of any document whatsoever
that might be related to the charge; however, they said that if I
repudiated the charge, then they could get a copy of the voucher
or other documents.  So I repudiated the charge, but the bank was
still unable or unwilling to show me the promised copies of relevant
documents.  The merchant eventually contacted me about the repudiated
charge.

--apb (Alan Barrett)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Jerrold Leichter]

| Jerrold Leichter wrote:
| > It's also clear that they don't expect customers to look closely at, or
| > question, their bills.  If they did, they'd make sure that meaningful 
merchant
| > names appeared on the bills, or at least were available if you called to ask
| > about a charge.
| 
| a company can operate under possibly 3(?) different names ... a dba
| name, a legal name, and some sort of general use name. the legal name
| that a merchant signs a contract with a merchant financial institution
| ... can be totally different from the dba name.
| 
| i once found a legal name on a statement that was something like
| "minority women owned title ?-something, no. ??? company" ... which was
| totally different from the name on their store-front. I assumed that
| their legal name was to help highlight their classification when bidding
| on gov. contracts. the "no. ???" apparently was to differentiate them
| from other companies that had also included the same reference to their
| minority women owned status. I don't remember what the "title
| ?-something" was ... but it struct me as something where a minority
| female owned small company was given special treatment in gov. bids.
| 
| i don't think it is so much a short coming of the merchant/financial
| institution relationship ... it is just the general nature of the way
| the society operates.
The banks, operating through the clearing agents, could if they wished impose 
a requirement on the way names appear in billing statements, regardless of how 
the names appear on contracts.  Alternatively, they could at least require 
that an end-user-familiar name be made available in whatever database records 
all merchants, which the banks obviously have access to.

This is yet another situation where the banks are really the only ones who can 
fix something that hurts the customers and merchants.  In the past, I denied a 
charge to a company whose name I didn't recognize.  It turned out the charge 
was legitimate - it's just that the name and location listed for the company 
were completely unrelated to anything that appeared on their website. Once I 
denied the charge, the bank was done.  The vendor had to go through the 
expense of getting in touch with me, and then I had to write a letter to the 
bank authorizing the charge.  Meanwhile, the vendor was out the money.

-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Anne & Lynn Wheeler]

Jerrold Leichter wrote:
> It's also clear that they don't expect customers to look closely at, or
> question, their bills.  If they did, they'd make sure that meaningful merchant
> names appeared on the bills, or at least were available if you called to ask
> about a charge.

a company can operate under possibly 3(?) different names ... a dba
name, a legal name, and some sort of general use name. the legal name
that a merchant signs a contract with a merchant financial institution
... can be totally different from the dba name.

i once found a legal name on a statement that was something like
"minority women owned title ?-something, no. ??? company" ... which was
totally different from the name on their store-front. I assumed that
their legal name was to help highlight their classification when bidding
on gov. contracts. the "no. ???" apparently was to differentiate them
from other companies that had also included the same reference to their
minority women owned status. I don't remember what the "title
?-something" was ... but it struct me as something where a minority
female owned small company was given special treatment in gov. bids.

i don't think it is so much a short coming of the merchant/financial
institution relationship ... it is just the general nature of the way
the society operates.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Jerrold Leichter]

| one of the "business processes" is that somebody calls their issuing
| bank and disputes a charge by a specific merchant on such & such a date.
| the issuing bank eventually provides notice to the merchant (giving the
| account number, date, and purchase details). the merchant then looks for
| a transaction (in their transaction log) for that account number on that
| date. In some cases, the merchant bank processor may provide an online
| service for merchants ... where the merchant processor keeps the online
| merchant transaction log on behalf of merchants for things like dispute
| resolution (this may include things like online library of digital
| images of the original reciepts).
I just had that experience.  My bill contained one charge that made no sense
at all, and one for a local store whose name I don't know.  I called the
issuing bank.  They could provide essentially no useful information.  All they
could offer was to send me a copy of the original charge information - whatever
that is - which would take 4-6 weeks.  (How can *anything* take 4-6 weeks?  If
they had to get this from backup tapes out at Iron Mountain, OK - but for
charges made in the last month?)  I could tell that for one transaction, this
wasn't going to help at all:  The company was a computer supplier that works
mainly on-line or by phone.  (They may have a physical store in California.)
What "original records" could they have?

Anyhow ... I called the computer vendor, and they were able to search their
database on the CC account number.  It was, indeed, a fraudulent order -
shipped to a town 30 miles from me.

The other order - on the same day - remains a mystery.  It's at a record and
DVD store, but the only name they have is something like "Record and DVD
Store".  It *could* be a DBA for the local Tower Records; it could be some
unrelated store where the same guy who ordered the computer stopped in for
a couple of DVD's.

It's clear that the CC companies really don't care very much.  They are happy
to issue me a new account and dump the charges back on the vendors.  If I
choose to do the research and find out where the charged merchandise ended
up ... they'll take the data from me, but probably not do anything with it.
It's not costing *them* anything.

It's also clear that they don't expect customers to look closely at, or
question, their bills.  If they did, they'd make sure that meaningful merchant
names appeared on the bills, or at least were available if you called to ask
about a charge.
-- Jerry





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Anne & Lynn Wheeler]

Jerrold Leichter wrote:
> If this is all you need, then using a 1-way hash of the card number for
> identification and the card number itself for security would give you much
> of what you need.  There are databases out there which identify customers
> by their CC numbers, not because they are willing to use the stored CC
> number for charging, but just becauses it's a good unique ID.  If what were
> stored were the 1-way hash, there would be nothing worth stealing in the
> database.
> 
> This kind of thing is actually implemented, though people rarely think of it
> in these terms.  You can see it on many printed charge slip these days:  Your
> CC number no longer appears, being replaced by a one-way hash that produces 12
> X's and the last 4 digits of your number.  Hardly cryptographically strong in
> the usual sense, and not generally applicable, but for ID purposes - letting
> you identify which of your cards you used when making the charge - this
> particular one-way hash is perfectly good.  (It's also common on Web forms
> that tell you which of your cards a charge will be applied to.)

there was a vulnerability where attackers took the published algorithm
for valid account numbers and attacked using account numbers that
satisfied the published algorithm. somewhat as a result, guite some time
agao, the CVV field was added to the magstripe ... which could be
considered a kind of one-way hash of the contents of the magstripe ...
with some other stuff that is not predictable from the algorithm (as a
countermeasure to attacks from automatically generated account numbers).

one of the "business processes" is that somebody calls their issuing
bank and disputes a charge by a specific merchant on such & such a date.
the issuing bank eventually provides notice to the merchant (giving the
account number, date, and purchase details). the merchant then looks for
a transaction (in their transaction log) for that account number on that
date. In some cases, the merchant bank processor may provide an online
service for merchants ... where the merchant processor keeps the online
merchant transaction log on behalf of merchants for things like dispute
resolution (this may include things like online library of digital
images of the original reciepts).

There was a least one processing specification (possibly even mandatory)
during the 90s ... where each transaction was giving a unique
transaction identifier ... and transaction logs were only to be
referenced by the transaction identifier. However, consumers only
identified their account number by their account number ... and so
processes, like dispute resolution, continued to use the account number
as the identifier (and you need something else to be used for
authentication ... since the use of the account number as the identifier
is so ingrained into so many processes ... including the minds of the
consumers).

however, with regard to the magstripe, there are lots of widely
published reports about magstripe being skimmed at point-of-sale
devices, at ATM machines (and/or the value of the magstripe being
skimmed in transit) ... and counterfeit magstripe/cards being produced
for fraudulent transactions.

here is a news article from yesterday about magstripe from credit/debit
cards being skimmed (including the CVV field) and used to rewrite the
magstripe on (magstripe) gift cards:

Gift Cards Carrying Cloned Data Used To Steal Gas
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1121867212622215212&block=

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Jerrold Leichter]

| an analogy i've used recently with respect to userid/password paradigm,
| is that account numbers are being concurrently used for both the userid
| function (requiring security *integrity* but not security
| *confidentiality*) as well as the password function (requiring strong
| security *confidentiality*). as a result there are frequently
| diametrically opposing requirements where the muiltitude of userid-type
| business functions require access to the account number ... at the same
| time, the password-type functions require that the account number be
| kept strictly *confidential* and not be available at all
If this is all you need, then using a 1-way hash of the card number for
identification and the card number itself for security would give you much
of what you need.  There are databases out there which identify customers
by their CC numbers, not because they are willing to use the stored CC
number for charging, but just becauses it's a good unique ID.  If what were
stored were the 1-way hash, there would be nothing worth stealing in the
database.

This kind of thing is actually implemented, though people rarely think of it
in these terms.  You can see it on many printed charge slip these days:  Your
CC number no longer appears, being replaced by a one-way hash that produces 12
X's and the last 4 digits of your number.  Hardly cryptographically strong in
the usual sense, and not generally applicable, but for ID purposes - letting
you identify which of your cards you used when making the charge - this
particular one-way hash is perfectly good.  (It's also common on Web forms
that tell you which of your cards a charge will be applied to.)

-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Anne & Lynn Wheeler]

Jeffrey I. Schiller wrote:
> Btw. There are credit card issuers (AT&T Universal is one) that permits
> you to create a virtual one-time use credit card (with a time limit and
> $$ limit if you want).
> 
> So when I shop at a merchant I don't want to trust, I open another
> browser window and go to my issuers website and obtain a one-time card
> number and use it at the merchant site. I can usually see immediately
> after the purchase that the card has been used (on the issuers website)
> so I know the merchant is checking the card in real time.
> 
> Apparently there is wallet software that will do this in a more
> automated fashion, but it isn't available for my platform (non-Windows).

an analogy i've used recently with respect to userid/password paradigm,
is that account numbers are being concurrently used for both the userid
function (requiring security *integrity* but not security
*confidentiality*) as well as the password function (requiring strong
security *confidentiality*). as a result there are frequently
diametrically opposing requirements where the muiltitude of userid-type
business functions require access to the account number ... at the same
time, the password-type functions require that the account number be
kept strictly *confidential* and not be available at all.

the x9a10 working group was given the requirement to preserve the
integrity of the financail infrastructure for all retail payments. the
resulting x9.59 protocol
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

* allowed for single round-trip, straight-through processing found at
many point-of-sale ... w/o requiring extraneous protocol chatter

* created a strictly enformed separation of the account number as a
userid-type function from digital signature as a password-type function

this eliminated the strongly conflicting goals of very weak
*confidentiality* requirement for use of the account number in the
multitude of userid-type business processes at the same time having a
very strong *confidentiality* erquirement for the same account number in
 its role as passoword/authentication.

this had the downside that there was potentially a maximum of two PANs
allocated for the same account during some transition period (where both
legacy, conflicting use of an account number was required and the new
x9.59 use of an account number requiring separate authentication).

it was startling that some of the strongest foes of x9.59 claiming that
there wasn't large enuf PAN space available to have a maximum of two
PANs per account (during some transition periods) ... subsequently were
strong backers of one-time-use PANs ... which might result in
potentially hundreds of PANs being mapped to the same account.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Jeffrey I. Schiller]

Btw. There are credit card issuers (AT&T Universal is one) that permits
you to create a virtual one-time use credit card (with a time limit and
$$ limit if you want).

So when I shop at a merchant I don't want to trust, I open another
browser window and go to my issuers website and obtain a one-time card
number and use it at the merchant site. I can usually see immediately
after the purchase that the card has been used (on the issuers website)
so I know the merchant is checking the card in real time.

Apparently there is wallet software that will do this in a more
automated fashion, but it isn't available for my platform (non-Windows).

Jerrold Leichter wrote:

>| Date: Wed, 13 Jul 2005 16:08:20 -0400
>| From: John Denker <[EMAIL PROTECTED]>
>| To: Perry E. Metzger <[EMAIL PROTECTED]>
>| Cc: cryptography@metzdowd.com
>| Subject: Re: ID "theft" -- so what?
>| ...
>| Scenario:  I'm shopping online.  Using browser window #1, I
>| have found a merchant who sells what I want.   in the checkout
>| phase.
>| 
>| Now, in browser window #2, I open a secure connection to my
>| bank.  The bank and I authenticate each other.  (This is
>| two-way authentication;  one possible method is SSL certificate
>| on the bank's part, and a password or some such on my part.)
>| 
>| ...
>| As a refinement, I could ask the bank to issue a number that
>| was not only restricted to a single use, but also restricted
>| as to dollar amount.  As a further refinement, it could be
>| restricted to a particular merchant.
>| 
>| Everything to this point is upward-compatible with existing
>| systems.  The merchant doesn't even need to know there's
>| anything special about this card number;  the charge moves
>| through existing processing channels just like any other.
>| 
>| As a further refinement, once the system is established,
>| the merchant could provide, on the checkout page, a number
>| that encodes in some standard format various details of
>| the transaction:  merchant ID, date, dollar amount, and
>| maybe even a description of the goods sold.  I cut-and-paste
>| this code from the merchant to the bank, and let the bank
>| site decode it.  If it looks correct, I click OK and then
>| the bank generates a response that the merchant will
>| accept in payment.  If necessary I can cut-and-paste this
>| from the bank to the merchant ... but it would make more
>| sense for the bank to transmit it directly to the merchant.
>| This further increases security, and also saves me from
>| having to enter a lot of billing detail
>In effect, what you've done is proposed a digital model of *checks* to
>replace the digital model of *credit cards* that has been popular so far.
>In the old days, paper checks were considered hard to forge and you were
>supposed to keep yours from being stolen.  Your physical signature on the
>check was considered hard to forge.  Checks were constructed in a way
>that made made alteration difficult, binding the details of the transaction
>(the payee, the amount being paid) and the signature to the physical
>instrument.
>
>There was a time when checks were accepted pretty freely, though often with
>some additional identification to show that you really were the person whose
>name was on the check.
>
>Credit cards and credit card transactions never bound these various features
>of the transaction nearly as tightly.  Stepping back and looking at the
>two systems, it seems that using the check model as the starting point for
>a digital payment system may well be better than using credit cards, whose
>security model was never really as well developed.  When I handed a check to
>a vendor, I had (and to this day have) excellent assurance that he could
>not change the amount, and (in the old days) reasonable assurance that he
>could not create another check against my account.  (Given digital scanners
>on the one hand, and the "virtualization" of the check infrastructure, from
>the ability to initiate checking transactions entirely over the phone to
>check truncation at the merchant on the other, this is long gone.  It would be
>nice to recover it.)
>   -- Jerry
>
>-
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
>
>  
>

-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]




signature.asc
Description: OpenPGP digital signature

Re: ID "theft" -- so what?

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>The PKI that was designed to serve no very useful function other than make
>everyone in the world pay $100 a year to Verisign is dead.
>
>Yet the technology is potent, and the problems of identity and authenticity
>are severe.  We shall, bye and bye, see reliance on public keys.  Other
>things just don't work.

What makes you so sure of that?  When I looked at this ("Plug-and-play PKI: A
PKI your Mother can Use", available from my home page), I found that by the
time you'd hidden enough of the PKI complexity to make it user-friendly, you
had something that was indistinguishable from a username-and-password
interface.  Conversely, as soon as you start surfacing any of the PKI arcana,
it becomes unusable by the majority of users.

Currently the best way that I know of securing an SSL link is through the use
of TLS-PSK, which provides mutual authentication of client and server as part
of the TLS handshake without requiring any public-key technology at all.  This
also happens to be the most usable security technology around - even your
mother can use it, and since the TLS handshake will fail in a very obvious
manner if she connects to a spoofed site, there's no need to rely on users
mastering PKI/PKC arcana for the security to work.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Peter Gutmann]

John Kelsey <[EMAIL PROTECTED]> writes:

>One nontrivial reason is that many organizations have spent a lot of time and
>money building up elaborate rules for using PKI, after long negotiations
>between legal and technical people, many hours of writing and revising,
>gazillions of dollars in consultants' time, etc.  So, anytime you start doing
>anything involving public key cryptography, all this machinery gets invoked,
>for bureaucratic reasons.  That is, you've now trespassed on PKI turf, and
>you'll have to comply with this enormous set of rules.

I've seen this happen on many occasions, one example being the posting I made
to this list a few months ago where an organisation had spent so much money
setting up a PKI that they then had to use it (even though it was totally
unnecesary for what they were doing) simply because it was there.

>I know of a couple cases where this led to really irritating results.  In
>one, a friend of mine was using a digital signature to verify some fairly
>trivial thing, but was told it was against policy to use a digital signature
>without the whole PKI.

Been there, seen that.  You're well into layers 8 and 9 whenever anything
related to PKI is involved.  I think the fact that PKI is so strong at
enabling layers 8+9 is its great appeal to the inhabitants of said layers.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[James A. Donald]

   --
Aram Perez
> There are at least two public key infrastructures that 
> do NOT require CAs: PGP and SPKI.

SPKI seems to me committees pondering what they might do 
with public keys, rather than an infrastructure.

> But like in so many real life cases, the best 
> technology does not always win and we are stuck with 
> the system that garnered the most business/ economic 
> support

In real life the best technology usually does win.  CA 
based PKI has lasted so long because it has not come 
under real world attack by real world adversaries until 
recently.  Hypothetical problems have only recently 
become real, as at last people have come to base the 
movement of valuable goods on promises exchanged over 
the internet.

A problem with the dot com boom, with all booms, was 
premature investment, leading to malinvestment. Existent 
PKI is one more piece of malinvestment, one more boom 
hangover.   Such hangovers can last a long time - After 
eighty years we are still getting out from under the 
excessively vertical integration of car assembly lines 
established in the nineteen twenties, but since the 
physical obstacles to change are much less in this case, 
this hangover will not last nearly so long.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 Fa1OKlHyGdiwEhSvi7sXvTo92wIBZ573qPLTCeLo
 4TtZu3a5eWXjqK4Ol9jEIvUqnJ22YwURQUJdaf5xF



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Jerrold Leichter]

| Date: Wed, 13 Jul 2005 16:08:20 -0400
| From: John Denker <[EMAIL PROTECTED]>
| To: Perry E. Metzger <[EMAIL PROTECTED]>
| Cc: cryptography@metzdowd.com
| Subject: Re: ID "theft" -- so what?
| ...
| Scenario:  I'm shopping online.  Using browser window #1, I
| have found a merchant who sells what I want.   in the checkout
| phase.
| 
| Now, in browser window #2, I open a secure connection to my
| bank.  The bank and I authenticate each other.  (This is
| two-way authentication;  one possible method is SSL certificate
| on the bank's part, and a password or some such on my part.)
| 
| ...
| As a refinement, I could ask the bank to issue a number that
| was not only restricted to a single use, but also restricted
| as to dollar amount.  As a further refinement, it could be
| restricted to a particular merchant.
| 
| Everything to this point is upward-compatible with existing
| systems.  The merchant doesn't even need to know there's
| anything special about this card number;  the charge moves
| through existing processing channels just like any other.
| 
| As a further refinement, once the system is established,
| the merchant could provide, on the checkout page, a number
| that encodes in some standard format various details of
| the transaction:  merchant ID, date, dollar amount, and
| maybe even a description of the goods sold.  I cut-and-paste
| this code from the merchant to the bank, and let the bank
| site decode it.  If it looks correct, I click OK and then
| the bank generates a response that the merchant will
| accept in payment.  If necessary I can cut-and-paste this
| from the bank to the merchant ... but it would make more
| sense for the bank to transmit it directly to the merchant.
| This further increases security, and also saves me from
| having to enter a lot of billing detail
In effect, what you've done is proposed a digital model of *checks* to
replace the digital model of *credit cards* that has been popular so far.
In the old days, paper checks were considered hard to forge and you were
supposed to keep yours from being stolen.  Your physical signature on the
check was considered hard to forge.  Checks were constructed in a way
that made made alteration difficult, binding the details of the transaction
(the payee, the amount being paid) and the signature to the physical
instrument.

There was a time when checks were accepted pretty freely, though often with
some additional identification to show that you really were the person whose
name was on the check.

Credit cards and credit card transactions never bound these various features
of the transaction nearly as tightly.  Stepping back and looking at the
two systems, it seems that using the check model as the starting point for
a digital payment system may well be better than using credit cards, whose
security model was never really as well developed.  When I handed a check to
a vendor, I had (and to this day have) excellent assurance that he could
not change the amount, and (in the old days) reasonable assurance that he
could not create another check against my account.  (Given digital scanners
on the one hand, and the "virtualization" of the check infrastructure, from
the ability to initiate checking transactions entirely over the phone to
check truncation at the merchant on the other, this is long gone.  It would be
nice to recover it.)
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Ian Grigg]

On Thursday 14 July 2005 15:45, Aram Perez wrote:
> Why do cryptography folks equate PKI with  
> certificates and CAs?

Because it's the major example of what most would
agree is PKI, I'd guess.  When we talked to people
in the certs and CAs world, they call it PKI.  They
refer to lots of documents, which call it the PKI.  The
business model of PKI vendors used to at least be
partly based on selling certs.  It's an assumption
they make or made.

(John Kelsey answered this very well.)

> This fallacy is a major "root cause" of the   
> problem IHO. Why was the term "PKI" invented in the  late 70s/early  
> 80s (Kohnfelder's thesis?)?. Before the invention of asymmetric  
> cryptography, didn't those people who used symmetric cryptography  
> need an SKI (secret key infrastructure) to manage keys? But no one  
> uses the term SKI or talks about how to manage secret keys (a very  
> hard problem).

Exactly.

> Anytime you use any type of cryptography, you need an   
> "infrastructure" () to  
> manage your keys, whether secret or public. There are at least two  
> public key infrastructures that do NOT require CAs: PGP and SPKI. But


There is a sort of doublethink here - when people
look down their nose at PKI from the PGP side,
the PKI side is sometimes at pains to say that PGP's
WoT is a PKI.  Yet when the converse happens
and PGP pundits suggest using WoT with (e.g.,)
x.509 certs, the PKI people say "WoT is not PKI."

Personally, I call "what PGP does" a Web of Trust.
And I call what browsers do a PKI.  The fact that
there is "trust" in PKI and there is "infrastructure"
in WoT is an issue, yes, but we have to have some
sense of differentiation;  and those terms are what
the people in those fields tend to be comfortable
with.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[James A. Donald]

--
> > This is yet more reason why I propose that you 
> > authorize transactions with public keys and not with 
> > the use of identity information.

Dan Kaminsky <[EMAIL PROTECTED]>
> It's 2005, PKI doesn't work, the horse is dead.

The PKI that was designed to serve no very useful 
function other than make everyone in the world pay $100 
a year to Verisign is dead.

Yet the technology is potent, and the problems of 
identity and authenticity are severe.  We shall, bye and 
bye, see reliance on public keys.  Other things just 
don't work.

At present, the overwhelming majority of money transfers 
take place over non internet networks, and rely on non 
internet identity.  Inevitably, this will change, and 
that change will both necessitate, and be based on, the 
use of public key cryptography. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 Pmf2aYMPVGY8UHBvEyuLghf0GsgeyEonN9O9Ljh+
 4j9GQPHtedEznyhC2w4YbCu38yJe2dOsSNGUyV3fL



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Perry E. Metzger]

Ian Grigg <[EMAIL PROTECTED]> writes:
>> This is not a "new realization" -- this goes back a long way.
>
> OK, so maybe this part is the new realisation:

No, it isn't a new realization either, Ian. We all knew from nearly
the start that the model we were using in browsers was wrong. I don't
know anyone who defends it. Netscape threw SSL together in a hurry --
so much of a hurry that the first version of the protocol wasn't even
any good -- and threw a bunch of certs right into the browser to
bootstrap it, and no one has particularly liked the situation ever
since.

That doesn't mean that people are interested in throwing the baby out
with the bathwater, either, as you have in suggesting that people
should just send credit card numbers in the clear because passive
interception is (you have claimed) not an issue.

> Too many words?  OK, here's the short version
> of why phising occurs:
>
> "Browsers implement SSL+PKI and SSL+PKI is
> secure so we don't need to worry about it."

I am unaware of real security professionals who hold that opinion or
ever held it, or even a variation on it. Perhaps there are a handful
out there, but it isn't the majority.

Again, you are telling people what they already know.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[John Kelsey]

>From: Aram Perez <[EMAIL PROTECTED]>
>Sent: Jul 14, 2005 10:45 AM
>To: Cryptography 
>Subject: Re: ID "theft" -- so what?

>Why do cryptography folks equate PKI with
>certificates and CAs? 

One nontrivial reason is that many organizations have spent
a lot of time and money building up elaborate rules for
using PKI, after long negotiations between legal and
technical people, many hours of writing and revising,
gazillions of dollars in consultants' time, etc.  So,
anytime you start doing anything involving public key
cryptography, all this machinery gets invoked, for
bureaucratic reasons.  That is, you've now trespassed on PKI
turf, and you'll have to comply with this enormous set of
rules.

I know of a couple cases where this led to really irritating
results.  In one, a friend of mine was using a digital
signature to verify some fairly trivial thing, but was told
it was against policy to use a digital signature without the
whole PKI.  (I believe he changed the documentation, so that
he was using a "modular arithmetic checksum" instead of a
signature verification.) 

As a consultant, I designed and evaluated a lot of systems
that used public key cryptography.  None of the successful
ones tried to use the whole X.509 + CRL + CPS + everything
else overhead--typically, they just used a one-deep
hierarchy, where the keypair was put into the device by the
manufacturer along with a copy of the top-level public key
used to sign all device public keys.  This works, because it
doesn't try to incorporate the output of 20 years of
make-work programs in cryptography (they weren't intended
that way, but that's largely how they turned out), and it
doesn't try to incorporate every idea that might be useful
anywhere in the world into some very limited and simple
application.

>Aram Perez

--John Kelsey

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Aram Perez]

Why do cryptography folks equate PKI with  
certificates and CAs? This fallacy is a major "root cause" of the  
problem IHO. Why was the term "PKI" invented in the  late 70s/early  
80s (Kohnfelder's thesis?)?. Before the invention of asymmetric  
cryptography, didn't those people who used symmetric cryptography  
need an SKI (secret key infrastructure) to manage keys? But no one  
uses the term SKI or talks about how to manage secret keys (a very  
hard problem). Anytime you use any type of cryptography, you need an  
"infrastructure" () to  
manage your keys, whether secret or public. There are at least two  
public key infrastructures that do NOT require CAs: PGP and SPKI. But  
like in so many real life cases, the best technology does not always  
win and we are stuck with the system that garnered the most business/ 
economic support.


Respectfully,
Aram Perez

On Jul 14, 2005, at 6:19 AM, Perry E. Metzger wrote:


Ian Grigg <[EMAIL PROTECTED]> writes:


It's 2005, PKI doesn't work, the horse is dead.


He's not proposing PKI, but nymous accounts.  The
account is the asset, the key is the owner;


Actually, I wasn't proposing that. I was just proposing that a private
key be the authenticator for payment card transactions, instead of the
[name, card number, expiration date, CVV2] tuple -- hardly a
revolutionary idea. You are right, though, that I do not propose that
any PK_I_ be involved here -- no need for certs at all for this
application.

I don't claim this is a remotely original idea, by the way. I'm just
flogging it again.


But, thank the heavens that we now have reached
the point where people can honestly say that PKI
is the root cause of the problem.


"Root Cause of the Problem" isn't correct either. It is better to say
that PKI doesn't solve many of the hard problems we have, or, in some
cases, any problems -- it doesn't per se cause any problems, or at
least not many.

This is not a "new realization" -- this goes back a long way.

People were saying PKI was a bad idea a decade ago or more. A number
of the people here, including me, gave talks on that subject years
ago. I spoke against PKI during the debate I was invited to at the
Usenix Electronic Commerce Workshop in 1998 or so, and at many
opportunities before and since. Dan Geer has a pretty famous screed on
the subject. Peter Gutmann talks about the follies of X.509 so often
it is hard to keep up. I don't mean to single us out as visionaries --
we were just saying things lots of other people were also saying.

Honestly, where have you been?


Can you now tell the browser people?


I can smell the rest of this discussion right now, Ian. You'll
misunderstand the constraints the browser people are under, and start
claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm
not playing the game.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to  
[EMAIL PROTECTED]





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Ian Grigg]

(Dan, in answer to your question on certs, below.)


On Thursday 14 July 2005 14:19, Perry E. Metzger wrote:
> 
> Ian Grigg <[EMAIL PROTECTED]> writes:
> >> It's 2005, PKI doesn't work, the horse is dead.
> >
> > He's not proposing PKI, but nymous accounts.  The
> > account is the asset, the key is the owner;
> 
> Actually, I wasn't proposing that. I was just proposing that a private
> key be the authenticator for payment card transactions, instead of the
> [name, card number, expiration date, CVV2] tuple -- hardly a
> revolutionary idea. You are right, though, that I do not propose that
> any PK_I_ be involved here -- no need for certs at all for this
> application.
> 
> I don't claim this is a remotely original idea, by the way. I'm just
> flogging it again.

Well, that's helpful.  Having built one or two of
these things (and I know of 3 others on the list
that have done the same thing) it helps to know
we aren't starting from scratch.

> > But, thank the heavens that we now have reached
> > the point where people can honestly say that PKI
> > is the root cause of the problem.
> 
> "Root Cause of the Problem" isn't correct either. It is better to say 
> that PKI doesn't solve many of the hard problems we have, or, in some
> cases, any problems -- it doesn't per se cause any problems, or at
> least not many.
> 
> This is not a "new realization" -- this goes back a long way.


OK, so maybe this part is the new realisation:

The browser security model includes PKI for two
purposes - MITM protection and spoofing protection.
Ignoring MITM (today), the spoofing protection is
supposed to alert the user that the cert and the
site don't match.

Phishing is a spoof - the wrong site is used.  So
SSL+PKI should pick that up.  It isn't.  Why?
Simply put because the browser too easily lets
SSL's anti-spoofing protection not be seen.  It's
not being done properly.

Why is that?  Because the browser people are
under severe constraints - your words - and
nobody is correcting their missunderstandings.
No security folk, no security companies, no CAs,
just a few researchers (some lurking here...).

Too many words?  OK, here's the short version
of why phising occurs:

"Browsers implement SSL+PKI and SSL+PKI is
secure so we don't need to worry about it."

PKI+SSL *is* the root cause of the problem.  It's
just not the certificate level but the business and
architecture level.  The *people* equation.

> People were saying PKI was a bad idea a decade ago or more. A number
> of the people here, including me, gave talks on that subject years
> ago. I spoke against PKI during the debate I was invited to at the
> Usenix Electronic Commerce Workshop in 1998 or so, and at many
> opportunities before and since. Dan Geer has a pretty famous screed on
> the subject. Peter Gutmann talks about the follies of X.509 so often
> it is hard to keep up. I don't mean to single us out as visionaries --
> we were just saying things lots of other people were also saying.
> 
> Honestly, where have you been?

I've been over at Mozilla trying to tell them the PKI
isn't doing it's job.  Peter Gutmann and Amir Herzberg
have been there supporting this push.  They're not
visionaries either but at least they put their money
where their mouths are - trying to get Mozo people
to touch up the PKI + SSL code to deal with spoofing.

(Demos and code available on request )

We recently set up a new
group for all anti-phishing researchers so they could
congregate and cross-fertilise ideas in a scientific
fashion.  I'm proud to say that in less than one month
our understanding of phishing and the browser
security model has significantly advanced.

We've talked to dozens of programmers over on the
Mozilla camp, sadly without success and I think that's
because the crypto community has been relatively
silent on this issue.  Most over in the browser
community remain simply unaware and uneducated
on the reasoning behind the security model, and how
out of date it is.

So, where have you been, Perry?  If you wish to
patronize me (on a public list, with no right of reply!)
do so from a position of strength.

> > Can you now tell the browser people?
> 
> I can smell the rest of this discussion right now, Ian. You'll
> misunderstand the constraints the browser people are under, and start
> claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm
> not playing the game.

Perry, for the last few months or so the game
you have been playing is "disagree with Ian,
rag him in public, drop his posts."

I don't mind .. but as I showed above, you are
100% diametrically wrong about what it is I am
saying or likely to say.  Just so you're aware
that you're inventing the rest of the discussion
and disagreeing with your own invention...

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

--

Re: ID "theft" -- so what?

[Greg Troxel]

"Jörn" Schmidt <[EMAIL PROTECTED]> writes:

> The answer to this dilemma? I'm afraid this time it really is
> legislation. Frankly, I'm not even sure if that would work but, at this
> time, it's our best shot. Congress won't do anything about this unless
> a few representatives have their identities stolen and experience
> first-hand what a PITA it is to have to deal with the fallout.

I agree that legislative changes are necessary, but I think they are
fairly small.   Consider the following:

  Alice is a model citizen with a good credit history

  Bob "steals Alice's identity" by finding out semi-public static
  information

  Bob gets a loan from Charlie under Alice's identity, where Charlie
  transfers something of value to Bob and records a debt from Alice.

Here, Bob has committed a crime, and this being a crime isn't
controversial.  Until this point, Alice hasn't really been harmed
unless she tries to interact with Charlie herself.

  Charlie tries to collect from Alice, or
  Charlie reports that Alice owes a debt to a third party, or
  Charlie reports that Alice is in default to a third party.

In my view, _Charlie_ has comitted a tort against Alice because he has
been negligent (or at least incorrect) in issuing credit.  If Charlie
has decided to issue credit with minimal checks because the business
benefit of that is more than the fraud losses (similar to our credit
card system today), then it's only fair for Charlie to cover the full
burden to Alice, including all the effort of cleanup.  If Charlie
isn't being careful to the some degree, so that such incidents are
rare, triple damages are probably in order.  Even if Charlie is very
careful, actual damages should be paid.

A reasonable penalty for Charlie might be on the order of $1000
statutory damages plus $100/hr for any time over two hours Alice has
to spend dealing with the issue, plus any legal fees incurred if any
problems remain 30 days after the first report.  This puts the onus on
Charlie and the reporting systems will quickly adjust to enable
Charlie to withdraw the incorrect report completely and quickly.

Of course, Charlie should be able to recover all of his own costs, as
well as payments to Alice, in triplicate from Bob.
  
Many credit issuers willfully conduct their business with the
knowledge that this will occur.  So, as I see it the basic problem is
not one of security, but the fact that credit issuers etc. impose
costs on innocent third parties and get away with it.

-- 
Greg Troxel <[EMAIL PROTECTED]>

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Perry E. Metzger]

Ian Grigg <[EMAIL PROTECTED]> writes:
>> It's 2005, PKI doesn't work, the horse is dead.
>
> He's not proposing PKI, but nymous accounts.  The
> account is the asset, the key is the owner;

Actually, I wasn't proposing that. I was just proposing that a private
key be the authenticator for payment card transactions, instead of the
[name, card number, expiration date, CVV2] tuple -- hardly a
revolutionary idea. You are right, though, that I do not propose that
any PK_I_ be involved here -- no need for certs at all for this
application.

I don't claim this is a remotely original idea, by the way. I'm just
flogging it again.

> But, thank the heavens that we now have reached
> the point where people can honestly say that PKI
> is the root cause of the problem.

"Root Cause of the Problem" isn't correct either. It is better to say
that PKI doesn't solve many of the hard problems we have, or, in some
cases, any problems -- it doesn't per se cause any problems, or at
least not many.

This is not a "new realization" -- this goes back a long way.

People were saying PKI was a bad idea a decade ago or more. A number
of the people here, including me, gave talks on that subject years
ago. I spoke against PKI during the debate I was invited to at the
Usenix Electronic Commerce Workshop in 1998 or so, and at many
opportunities before and since. Dan Geer has a pretty famous screed on
the subject. Peter Gutmann talks about the follies of X.509 so often
it is hard to keep up. I don't mean to single us out as visionaries --
we were just saying things lots of other people were also saying.

Honestly, where have you been?

> Can you now tell the browser people?

I can smell the rest of this discussion right now, Ian. You'll
misunderstand the constraints the browser people are under, and start
claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm
not playing the game.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Ian Grigg]

On Wednesday 13 July 2005 23:31, Dan Kaminsky wrote:
> 
> >This is yet more reason why I propose that you authorize transactions
> >with public keys and not with the use of identity information. The
> >identity information is widely available and passes through too many
> >hands to be considered "secret" in any way, but a key on a token never
> >will pass through anyone's hands under ordinary circumstances.
> >
> >  
> >
> It's 2005, PKI doesn't work, the horse is dead.

He's not proposing PKI, but nymous accounts.  The
account is the asset, the key is the owner;  at the
simplest conceptual level it is the difference between
Paypal and e-gold.

But, thank the heavens that we now have reached
the point where people can honestly say that PKI
is the root cause of the problem.  Can you now tell
the browser people?

> The credit-card sized  
> number dispensers under development are likely to be what comes next.

Right, alongside nyms on a spectrum is big random
number-sized tokens.  If you want to get sexy, go
for the blinded ones.  It's all the same infrastructure,
we call it FC.

> Amusingly, your face is an asymmetric authenticator -- easy to 
> recognize, hard to spoof.

True, but also easy to copy and can be stolen.  For
some value, you don't want to go there.

https://www.financialcryptography.com/mt/archives/000440.html

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Perry E. Metzger]

Dan Kaminsky <[EMAIL PROTECTED]> writes:
>>This is yet more reason why I propose that you authorize transactions
>>with public keys and not with the use of identity information. The
>>identity information is widely available and passes through too many
>>hands to be considered "secret" in any way, but a key on a token never
>>will pass through anyone's hands under ordinary circumstances.
>
> It's 2005, PKI doesn't work, the horse is dead.

Who said PK_I_? I only mentioned P_K_. There is no need for an _I_
here -- a public key stored at the bank in a database is sufficient,
without any certificates at all. The token can store the bank's key
without any need for a cert, either. Neither needs to check the
"certification" of such keys -- the mere presence of the key in the
correct part of storage indicates it is valid, the same way that a
.ssh key file needs no certification, only existence.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Dan Kaminsky]

This is yet more reason why I propose that you authorize transactions
with public keys and not with the use of identity information. The
identity information is widely available and passes through too many
hands to be considered "secret" in any way, but a key on a token never
will pass through anyone's hands under ordinary circumstances.

 

It's 2005, PKI doesn't work, the horse is dead.  The credit-card sized 
number dispensers under development are likely to be what comes next.


Amusingly, your face is an asymmetric authenticator -- easy to 
recognize, hard to spoof.


--Dan


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[John Denker]

On 07/13/05 12:15, Perry E. Metzger wrote:

However, I would like to make one small subtle point. 
... the use of widely known pieces of information about
someone to identify them. 


Yes, there are annoying terminology issues here.

In the _Handbook of Applied Cryptography_ (_HAC_)
 -- on page 386 they say "The terms _identification_
  and _entity authentication_ are used synonymously
  throughout this book"  (which in fact they are :-)
 -- on page 24 they say the term _authentication_ is
  often abused.

It seems to me that the term _identification_ is even more
ambiguous and open to misunderstanding than "authentication"
is.  Overall, it's a quagmire.

In some circles, the notion of _identifying information_
is quite a weak notion, meaning sufficient information
to pick the desired entity out of a crowd.  More-or-less
synonymous notions include
 *) characterization
 *) description (sufficiently detailed to be unique)
 *) unverified _claim_ of identity
 *) pointer, indicator, index
 *) name, call-sign, handle
 *) record-locator, database-key
-- used as an index into the database,
-- *not* a key in the sense of lock-and-key
-- example: LOGNAME i.e. the first field in each
   record in the /etc/passwd database

In other circles, _identification_ refers to a much stronger
notion.  When the military speaks of IFF (identification,
friend or foe) they don't consider it sufficient for you
to be able to _describe_ a friend, they actually want you
to _be_ a friend.

As to whether the word _identity_ should refer to full-blown
entity authentication, or to a mere characterization or
call-sign ... that seems like an unanswerable question.

==> My recommendation:  Avoid using terms like "identity"
and "identification" entirely.
-- If you mean "entity authentication", use that term
 in preference to "indentification".
-- If you mean a mere description, handle, record-locator,
 etc. use those terms.

It would be nice to have a convenient catch-all term for
the whole category of notions like description, handle,
record-locator, et cetera.  I don't recommend calling them
"weak" identification, because the term "weak authentication"
has already been taken, and means something else, namely
passwords and the like (_HAC_ page 388).

The only time that you can even dream of using a detailed
description as a means of entity authentication is when
meeting face to face.  Somebody who fits my description
in full detail "probably" is me, although even that isn't
entirely certain.

On the other side of that coin, in a typical e-commerce
situation, allowing a description or a call-sign to serve
in place of entity authentication is ludicrous.  It means
that anybody who can describe me can impersonate me.  The
vulerability to replay attacks and MITM attacks is unlimited.

Typically a full-blown entity authentication starts with one
party making a _claim_ of identity which the other party
then _verifies_.   Unix login is a familiar example:  first
I give my LOGNAME and then I give the corresponding password.

The notion of "theft" of my LOGNAME is vacuuous.  My LOGNAME
(jsd) is known to everybody, good guys and bad guys alike.
As Spike said, so what?  My LOGNAME is nothing more than a
handle, a call-sign, a record-locator, used to look up the
appropriate record in places like /etc/passwd.

If you want to impersonate me, my computer requires you to
know not just my LOGNAME but also my password.  The way we
should treat passwords is verrry different from the way we
should treat call-signs.

Using this refined terminology, I can clarify what I was
trying to say yesterday:
 1) Being able to _describe_ me (height, weight, date of birth,
SSN, LOGNAME, and great-great-grandmother's maiden name) does
not mean you _are_ me.
 2) Even fully identifying and authenticating me as me doesn't
suffice to prove that wish to authorize this-or-that financial
transaction.  Who I *am* and what I wish to *happen* are
dramatically different notions.  Authenticating me as an entity
is not a proper substitute for authenticating the transaction
itself.  These notions are not unrelated, but they are not
identical, either.

In present-day practice, SSNs, credit card numbers, and
various bits of personal description are suspended in some
weird limbo: they are not nearly as secret as passwords
should be, yet they are still treated by some parties as
if they had magical entity-authenticating power and even
transaction-authenticating power.

So where do we go from here?  In general:
 -- When we think and when we speak, always distinguish
  handle versus entity authentication versus transaction
  authentication.
 -- Don't entrust our money to institutions that can't
  reliably make that distinction.
 -- Obtain legislation so that Muggles are protected, not
  just us.

Also:  A critical step that phishers must take in order to
exploit phished information is to check its validity.  Therefore
banks *must* be required to perform entity-

Re: ID "theft" -- so what?

[Matthew Byng-Maddick]

On Wed, Jul 13, 2005 at 12:15:48PM -0400, Perry E. Metzger wrote:
> John Denker <[EMAIL PROTECTED]> writes:
>> My point here is that knowing who I am shouldn't be a
>> crime, nor should it contribute to enabling any crime.
>> Suppose you know who I am.  Suppose you know my date of
>> birth, social security number, and great-great-grandmother's
>> maiden name.  As Spike said, so what?
> I tend to agree. It is equally ridiculous to use a credit card account
> number as the "secret" to authorize a transaction, since that "secret"
> has to be given out several times a day.

I went to pay my credit card bill today via a transfer out of my current
account. The amount was 714 quid or so. When I do this, I normally have
to sign a piece of paper to authorise the transaction - I'm happy with
this. In addition, I was also asked to confirm my date of birth and my
home postcode. (Just as a simple challenge, these are two data about me
that everyone on this list should quite trivially be able to find out).
Given the discussion, I commented that they weren't particularly secure
questions, so why bother asking them.  Apparently it's because my name
wasn't printed on the credit card bill. (HSBC have started printing it
in two sheets).

It didn't occur to her that she could quite easily have asked to see the
piece of plastic which is my credit card, which has the same numbers as
on the sheets, and my name. When I showed her that, she said "well, we
don't take credit cards as identification", and I pointed to the numbers
on the bill. I then got told that this only happened because the transaction
was between 500 and 1000 pounds. If it had been more, I would have needed
to show them a driving licence or passport (I don't drive, and I do now
have a passport, but there were several weeks where I was getting it
replaced recently - what if I'd needed to pay a large amount in, or if I'd
forgotten about it).

They also only bothered to tell me about this when I went there. I don't
routinely carry photo-ID and given the speed with which they processed the
queue, and the questions they asked. I suspect I'd have had a fairly major
strop.

>> And that is precisely where the problem lies.  Any
>> system that lets _identification_ serve as _authorization_
>> is so incredibly broken that it is hard to even discuss
>> it.  I don't know whether to laugh or cry.
> Again, yes.

I'm not so sure about this.

> However, I would like to make one small subtle point. In fact, what
> you are complaining about is not the use of identification for
> authorization -- that is a totally separate and equally sad discussion
> -- but the use of widely known pieces of information about
> someone to identify them. The issue is that the bank pretends only you

Very much so!

Cheers

MBM

-- 
Matthew Byng-Maddick  <[EMAIL PROTECTED]>   http://colondot.net/
  (Please use this address to reply)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Anne & Lynn Wheeler]

there are a couple issues

1) using any widely known information for authentication.

2) standard security kindergarten 101 requires that every unique
security domain requires a unique shared secret (if shared secret is
used for authentication)

3) any information that is used for authentication should be dedicated
for authentication and not widely used in large number of other business
processes (like account numbers)

4) static data authentication (whether unique or not) is subject to
skimming for various kinds of replay and impersonation attacks.

=

the issue with digital signatures and private keys ... is that the
digital signature can be unique per transaction ... and that the
mechanism which is used to originate the transaction (private key) is
never divulged ... countermeasure against the skimming attacks on
transaction origin.

note that there have been some poorly designed digital signature schemes
that separate the authentication from the transaction ... such that they
are subject to MITM-attacks

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Derek Atkins]

Quoting "Perry E. Metzger" <[EMAIL PROTECTED]>:


> So, rephrasing, the problem is not that secret information isn't a
> fine way to establish trust -- it is the pretense that SSNs, your
> mom's birth name or even credit card numbers can be kept secret.
>
> > Identifying information cannot be kept secret.
> 
> I'd amend that to "things like your name, your SSN or your account
> numbers cannot be kept secret..."

I think it's worse than that -- in reality it is any static piece of
information.  It doesn't matter WHAT that piece of information is.  You really
want a challenge-response system to prove both knowledge and liveness of the
information.
 
-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Perry E. Metzger]

John Denker <[EMAIL PROTECTED]> writes:
> My point here is that knowing who I am shouldn't be a
> crime, nor should it contribute to enabling any crime.
> Suppose you know who I am.  Suppose you know my date of
> birth, social security number, and great-great-grandmother's
> maiden name.  As Spike said, so what?

I tend to agree. It is equally ridiculous to use a credit card account
number as the "secret" to authorize a transaction, since that "secret"
has to be given out several times a day.

> It's only a problem if somebody uses that _identifying_
> information to spoof the _authorization_ for some
> transaction.

Yes.

> And that is precisely where the problem lies.  Any
> system that lets _identification_ serve as _authorization_
> is so incredibly broken that it is hard to even discuss
> it.  I don't know whether to laugh or cry.

Again, yes.

However, I would like to make one small subtle point. In fact, what
you are complaining about is not the use of identification for
authorization -- that is a totally separate and equally sad discussion
-- but the use of widely known pieces of information about
someone to identify them. The issue is that the bank pretends only you
would know your mother's maiden name, not that the bank would only let
you withdraw funds. A piece of information that is not widely known
but which can be used to establish your identity -- such as a private
key only you should know -- is probably fine.

So, rephrasing, the problem is not that secret information isn't a
fine way to establish trust -- it is the pretense that SSNs, your
mom's birth name or even credit card numbers can be kept secret.

> Identifying information cannot be kept secret.

I'd amend that to "things like your name, your SSN or your account
numbers cannot be kept secret..."

> There's no point in trying to keep it secret.  Getting a new SSN
> because the old one is no longer secret is like bleeding with
> leeches to cure scurvy ... it's completely the wrong approach.  The
> only thing that makes any sense is to make sure that all relevant
> systems recognize the difference between identification and
> authorization.

I have to agree yet again (with my caveats about the terminology you
are using).

This is yet more reason why I propose that you authorize transactions
with public keys and not with the use of identity information. The
identity information is widely available and passes through too many
hands to be considered "secret" in any way, but a key on a token never
will pass through anyone's hands under ordinary circumstances.


Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[J]

--- John Denker <[EMAIL PROTECTED]> wrote:

[...]
> It's only a problem if somebody uses that _identifying_
> information to spoof the _authorization_ for some
> transaction. [...]
> 
> Identifying information cannot be kept secret.  There's
> no point in trying to keep it secret.  Getting a new
> SSN because the old one is no longer secret is like
> bleeding with leeches to cure scurvy ... it's completely
> the wrong approach.  The only thing that makes any sense
> is to make sure that all relevant systems recognize the
> difference between identification and authorization.

See, that's precisely where the problems lies: I could not agree more
with you but the fact that you are completely, 100% right doesn't help
me one bit if T-Mobile's computer system requires that I give them my
SSN (which, by the way, may no longer be the case). 

And there's no point in arguing with the store manager because he
likely doesn't have the power to do anything about it anyway and
probably just doesn't care.

The fact of the matter is that you're making entirely too much sense.
;)

SSNs were never intended to be used for authorization. That's why it
explicitly said "For Social Security Purposes. Not for Identification"
on the bottom of old social security cards. 

These days, federal law says quite the opposite. USC 405 [C] and
subsequent sections state that it's okay for any state or government
agency to require an individual to provider their SSN  "[...] for the
purpose of establishing the identification of individuals affected by
such law [...]". In the Greate State of California, you can, for
instance, not even get a driver's license without telling the DMV your
SSN. Since I don't see a connection between said (semi-)randomly
assigned number and my ability to operate a motor vehicle, I'd have to
wager a guess and say that the CA DMV does indeed use social security
numbers for identification purposes. Fortunately, they don't just go
ahead and use your SSN as your driver's license number, too (IL, I
believe, used to do that). 

And the fact that many private businesses and schools still use SSNs as
unique identifiers and often display them quite prominently for the
world to see (eg. to people working in call centers half-way around the
world) makes matters even worse. 

Because you will often find that people treat you like you're going out
of your way to be a PITA if you refuse to give them your SSN. And
that's all fine and well as long as we're talking about the likes of
T-Mobile. Just use a different carrier, right? Well, they all (used to)
require that you give them your SNN. And so do most telcos, utility
companies, landlords, banks, public schools, community colleges, DMVs,
credit card companies, car dealerships (financing, etc.), cable
companies and pretty much any government agency (state and federal)
that issues any kind of license.

The answer to this dilemma? I'm afraid this time it really is
legislation. Frankly, I'm not even sure if that would work but, at this
time, it's our best shot. Congress won't do anything about this unless
a few representatives have their identities stolen and experience
first-hand what a PITA it is to have to deal with the fallout.

   -Jörn

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]