Re: An attack on paypal

2003-06-15 Thread Matthew Byng-Maddick
On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote:
 An e-gold-specific or paypal-specific client can tell,
 because it can remember that it's trying to see the real thing,
 but the browser can't tell, except by bugging you about
 Hi, this is a new site that's giving us a new cert placebo box.

Don't knock this warning, it might be enough of an indication to the user
that something is not quite right. But I've logged into e-gold before,
and it never said this It certainly should be. In most browsers,
though, there isn't even that, by default, at least, IMLE.

MBM

-- 
Matthew Byng-Maddick [EMAIL PROTECTED]   http://colondot.net/

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


Re: An attack on paypal

2003-06-12 Thread Nomen Nescio
Steven M. Bellovin wrote:
 Let me point folk at http://www.securityfocus.com/news/5654
 for a related issue.  To put it very briefly, *real* authentication is
 hard.

It may be that real authentication is hard, but the unbelievably sloppy
practices of domain name registrars doesn't prove the case.

Imagine if property ownership were recorded with the same degree of rigor.
I'm sorry, sir, but you don't own your house any more.  We received a
typewritten letter with your name on it saying you were transferring
ownership to ShoppingMall Inc.  The demolition teams are moving in,
and I'm afraid you'll have to be out by Friday.

Domain names are handled carelessly while real estate is not, due to
many factors.  Probably one of the main ones is the relative immaturity
of the domain name system compared to the centuries of experience we
have evolving mechanisms to deal with real property.

Clearly the registrars are making little or no effort to authenticate
domain name transfers at present.  At one time you could specify that only
messages signed with a given PGP key would authorize a transfer, but that
precaution has apparently disappeared, no doubt due to lack of interest
and the costs of support.  Maybe this could be something that a registrar
could use to differentiate itself from the many otherwise-identical
competitors in the market: we won't let your domain names get stolen.
What a novel concept.

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


Re: An attack on paypal

2003-06-12 Thread Matt Crawford
 Matt Crawford [EMAIL PROTECTED] writes:
 ... Netscrape ind Internet Exploder each have a hack for
 honoring the same cert for multiple server names.  Opera seems to honor at
 least one of the two hacks, and a cert can incorporate both at once.
 
/C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services
/CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov
/CN=bravo.fnal.gov/CN=charlie.fnal.gov
 
 Just to clarify this, so you need a multivalued CN, with one containing the
 expression (a|b|c) and the remaining containing each of a, b, and c?
 Is it multiple AVAs in an RDN, or multiple RDNs?   (Either of these could be
 hard to generate with a lot of software, which can't handle multiple AVAs in
 an RDN or multiple same-type RDNs).  Which hack is for MSIE and which is for
 Netscape?

Each CN is in a single-element RDN as usual. Netscape honors only the
first CN in the SubjectDN, but will treat it as a restricted regex
(shell-like * wildcard, alternation and grouping). IE checks the
server name against each CN's individually.

This was mainly determined by experimentation.  I think we did find a
limit on how long that first regex could be, but I don't remember
what it was.  Longer than my example, but short enough that some of
our bigger virtual-hosting servers were inconvenienced by it.

Openssl has no qualms about multiple same-type components.  You just
have to use the somewhat documented

0.commonName = ...
1.commonName = ...
2.commonName = ...

in the configuration file.

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


Re: An attack on paypal

2003-06-12 Thread David Honig
At 03:38 PM 6/11/03 -0600, Anne  Lynn Wheeler wrote:
even before e-commerce, the real 
BBB process was that people called up the BBB and got realtime information 
 i.e. it was an online, realtime process.

the equiivalent for an online, internet paradigm (as opposed to something 
left over from the offline email genre of at least 10--15 years earlier) 
was that the browswer tab;e pf trusted entities were of online authorities 
(as opposed to certificate manufacturing) and if you cared, you clicked 
thru to the BBB and got realtime information about the merchant in question 
(being equivalent to when people call the BBB to actually get some level of 
real input  as opposed to just a fuzzy comfort fealing).

When I buy $20 of gas with non-bearer credentials (ie, credit card), 
the vendor does a real-time check on me.  Seems fair/useful to be able
to do same on them.  I suppose eBay's feedback suffices... if their
last N feedbacks are negative, I might go elsewhere.







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


Re: An attack on paypal

2003-06-12 Thread Anne Lynn Wheeler
At 05:34 PM 6/11/2003 -0700, David Honig wrote:
When I buy $20 of gas with non-bearer credentials (ie, credit card),
the vendor does a real-time check on me.  Seems fair/useful to be able
to do same on them.  I suppose eBay's feedback suffices... if their
last N feedbacks are negative, I might go elsewhere.
we sort of tried that ... however the financial justification sort of fell 
apart. the big thing about BBB is being able to trust some merchant that 
you have absolutely no knowledge about. However, the actual buying patterns 
are extremely skewed ... with well over 80 percent of the transactions 
either repeat or with some organization that there is other avenues of 
trust propagation  and involving a very small number of very large 
merchants.  The BBB model tends to work with higher value, infrequent 
transaction. The remaining online, merchant market segment not covered via 
other trust processes, tended to represent a small percentage of total 
transactions, spread over a very large population of very small merchants, 
and frequently low value.

eBay is an attempt to provide an alternative delivery for such market 
segment  and the issue is how does eBay operations break even 
financially on a BBB like offering. The first filter is to quickly catch 
major scamming  operations ... and differentiate between the one-off 
transactions.
--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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


Re: An attack on paypal

2003-06-12 Thread tom st denis

--- James A. Donald [EMAIL PROTECTED] wrote:
 --
 On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote:
  Let me point folk at http://www.securityfocus.com/news/5654 
  for a related issue.  To put it very briefly, *real*
  authentication is hard.
 
 I don't think so.
 
 Verisign's authentication is notoriously worthless and full of
 holes, yet very few attacks have been based on getting
 certificates issued to wrong party, or on stealing poorly
 defended and readily accessible certificates, even though that
 is quite easy to do.

On the whole PKI as used today is fairly useless.  I mean just because
Company A signed/issued me a key doesn't mean I'm a nice guy nor a
legit business.  All it means is I paid money to have another company
sign my key.

What *would* be more useful is a model of web-o-trust.  E.g. you make
up your own key.  Then you import public keys from third-party auditors
you trust.  Overtime the auditors will visit the business and if they
like it they will sign the key. 

So say you trust auditors A, B and C and I trust auditors B, C and D. 
Well chances are if company Z is good the will be audited by at least
one of the auditors we have in common.  

Unfortunately there is easy corruption in this model so you would have
to keep tabs on your auditor yourself.   However, in this model it
wouldn't cost money [hey everything net-related should cost money
right?] and would actually be meaningful.

Tom

__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

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


Re: An attack on paypal

2003-06-12 Thread Adam Selene
 IE checks the server name against each CN's individually.

I found that by experimentation too. I have VBScript sample on how to generate
such a CSR request for IIS using the CryptoAPI.

Furthermore, IE does not care if the CNs have different domains.

e.g.

/CN=www.domain.com/CN=www.domain.net/CN=www.domain.org

-or even-

/CN=www.domain.com/CN=www.cypherpunks.com/CN=www.microsoft.com

You can self-sign such a cert with OpenSSL just fine. Whether you can get a real
CA to sign such a thing is another matter.

Adam


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


Re: An attack on paypal

2003-06-11 Thread Eric Rescorla
Sunder [EMAIL PROTECTED] writes:

 The worst trouble I've had with https is that you have no way to use host
 header names to differentiate between sites that require different SSL
 certificates.

 i.e. www.foo.com www.bar.com www.baz.com can't all live on the same IP and
 have individual ssl certs for https. :(  This is because the cert is
 exchanged before the http 1.1 layer can say I want www.bar.com 
 
 So you need to waste IP's for this.  Since the browser standards are
 already in place, it's unlikely to be to find a workaround.  i.e. be able
 to switch to a different virtual host after you've established the ssl
 session.  :(
This is being fixed. See draft-ietf-tls-extensions-06.txt

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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


Re: An attack on paypal

2003-06-11 Thread Anne Lynn Wheeler
At 10:56 AM 6/11/2003 -0400, Sunder wrote:
In either case, we wouldn't need to worry about paying Verisign or anyone
else if we had properly secured DNS.  Then you could trust those pop-up
self-signed SSL cert warnings.
actually, if you had a properly secured DNS  then you could trust DNS 
to distribute public keys bound to a domain name in the same way they 
distribute ip-addresses bound to a domain name.

the certificates serve two purposes: 1) is the server that we think we are 
talking to really the server we are talking to and 2) key-exchange for 
establishing an encrypted channel. a properly secured DNS would allow 
information distributed by DNS to be trusted  including a server's 
public key  and given the public key  it would be possible to do 
the rest of the SSL operation (w/o requiring certificates) which is 
establishing an agreed upon session secret key.
--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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


Re: An attack on paypal (trivia addenda)

2003-06-11 Thread Anne Lynn Wheeler
somewhat related to the early posting in this m.l. about distributed 
computing systems conference and possible interest from security and 
cryptography sections.

when my wife and I were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
we were working with two people in the following meeting in ellison's 
conference room
http://www.garlic.com/~lynn/95.html#13

who the following year, left and joined a small client/server startup and 
were responsible for something called the commerce server (the company also 
had this thing called https/SSL). we then worked with these two people on 
the implementation for payments for the thing called the commerce server 
and well as the infrastructure regarding
trusting online merchants (as part of promoting this whole thing that came 
to be called electronic commerce):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and more recent posting in the same thread that I had also posted about 
buffer overflows and the multics study:
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day

in any case, one of the jokes has been there are actually only 200 people 
in the industry.

in any case, back to the recent related thread on distributed system operation:
http://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003j.html#7 A few Z990 Gee-Wiz stats
and past posts discussing the BBB aspects for online electronic commerce:
http://www.garlic.com/~lynn/aepay3.htm#sslset2 SSL  SET Query ... from 
usenet group
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S.  Ireland use digital 
signature
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An 
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An 
Artifact...
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs  baby steps
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs  AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft 
jumped in 2002
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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


Re: An attack on paypal

2003-06-10 Thread Bill Frantz
At 5:12 PM -0700 6/8/03, Anne  Lynn Wheeler wrote:
somebody (else) commented (in the thread) that anybody that currently
(still) writes code resulting in buffer overflow exploit maybe should be
thrown in jail.

A nice essay, partially on the need to include technological protections
against human error, included the above paragraph.

IMHO, the problem is that the C language is just too error prone to be used
for most software.  In Thirty Years Later:  Lessons from the Multics
Security Evaluation,  Paul A. Karger and Roger R. Schell
www.acsac.org/2002/papers/classic-multics.pdf credit the use of PL/I for
the lack of buffer overruns in Multics.  However, in the Unix/Linux/PC/Mac
world, a successor language has not yet appeared.

YMMV - Bill


-
Bill Frantz   | Due process for all| Periwinkle -- Consulting
(408)356-8506 | used to be the | 16345 Englewood Ave.
[EMAIL PROTECTED] | American way.  | Los Gatos, CA 95032, USA



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


Re: An attack on paypal -- secure UI for browsers

2003-06-10 Thread Sunder
Yes, NOW if you can load yourself into kernel space, you can do anything
and everything - Thou Art God to quote Heinlein.  This is true of every
OS.  Except if you add that nice little TCPA bugger which can verify the
kernel image you're running is the right and approved one. Q.E.D.

Look at the XBox hacks for ideas as to why it's not a trival issue, but
even so, one James Bond like buffer overflow in something everyone will
have marked as trusted (say IE 8.0, or a specially crafted Word 2005
macro), and the 3v1l h4x0r party is back on and you iz ownz0red once more.

It's not enough to fear Microsoft, you must learn to love it.  Give us 2
minutes of hate for Linux now brother!


--Kaos-Keraunos-Kybernetos---
 + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of   /|\
  \|/  :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\
--*--:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech.  \/|\/
  /|\  :Found to date: 0.  Cost of war: $800,000,000,000 USD.\|/
 + v + :   The look on Sadam's face - priceless!   
[EMAIL PROTECTED] http://www.sunder.net 

On Tue, 10 Jun 2003, Rich Salz wrote:

 But if the system is rooted, then the attacker merely has to find the
 today's secret word entry in the registry and do the same thing.
 Unless Windows is planning on getting real kernel-level kinds of protection.
 
  It was none other than Microsoft's NGSCB, nee Palladium.  See
  http://news.com.com/2100-1012_3-1000584.html?tag=fd_top:
 
 See previous sentence. :)



Re: An attack on paypal

2003-06-08 Thread Tim Dierks
At 02:55 PM 6/8/2003, James A. Donald wrote:
Attached is a spam mail that constitutes an attack on paypal similar
in effect and method to man in the middle.
The bottom line is that https just is not working.  Its broken.

The fact that people keep using shared secrets is a symptom of https
not working.
The flaw in https is that you cannot operate the business and trust
model using https that you can with shared secrets.
I don't think it's https that's broken, since https wasn't intended to 
solve the customer authentication / authorization problem (you could try to 
use SSL's client certificates for that, but no one ever intended client 
certificate authentication to be a generalized transaction problem).

When I responded to this before, I thought you were talking about the 
server auth problem, not the password problem. I continue to feel that the 
server authentication problem is a very hard problem to solve, since 
there's few hints to the browser as to what the user's intent is.

The password problem does need to be solved, but complaining that HTTPS or 
SSL doesn't solve it isn't any more relevant than complaining that it's not 
solved by HTML, HTTP, and/or browser or server implementations, since any 
and all of these are needed in producing a new solution which can function 
with real businesses and real users. Let's face it, passwords are so deeply 
ingrained into people's lives that nothing which is more complex in any way 
than passwords is going to have broad acceptance, and any consumer-driven 
company is going to consider easy to be more important that secure.

Right now, my best idea for solving this problem is to:
 - Standardize an HTML input method for FORM which does an SPEKE (or 
similar) mutual authentication.
 - Get browser makers to design better ways to communicate to users that 
UI elements can be trusted. For example, a proposal I saw recently which 
would have the OS decorate the borders of trusted windows with facts or 
images that an attacker wouldn't be able to predict: the name of your dog, 
or whatever. (Sorry, can't locate a link right now, but I'd appreciate one.)
 - Combine the two to allow sites to provide a user-trustable UI to enter 
a password which cannot be sucked down.
 - Evangelize to users that this is better and that they should be 
suspicious of any situation where they used such interface once, but now 
it's gone.

I agree that the overall architecture is broken; the problem is that it's 
broken in more ways than can just be fixed with any change to TLS/SSL or HTTPS.

 - Tim



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


Re: An attack on paypal

2003-06-08 Thread Anne Lynn Wheeler
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote:
HTTPS works just fine.
The problem is - people are broken.
At the very least, verisign should say ok so '..go1d..' is a valid server
address, but doesn't it look suspiously similar to this '..gold..' site over
here? for https://pseudo-gold-site/ - but really, if users are going to
fill in random webforms sent by email, they aren't going to be safe under
any circumstances; the thing could send by unsecured http to any site on the
planet, then redirect to the real gold site for a generic transaction
completed or even failed screen
A world where a random paypal hack like this one doesn't work is the same as
the world where there is no point sending out a Nigerian as you will never
make a penny on it - and yet, Nigerian is still profitable for the con
artists.
in a world where there are repeated human mistakes/failures  at some 
point it is recognized that people aren't perfect and the design is changed 
to accommodate peoples foibles. in some respects that is what helmets, seat 
belts, and air bags have been about.

in the past systems have designed long, complicated passwords that are hard 
to remember and must be changed every month. that almost worked when i 
person had to deal with a single shared-secret. when it became a fact of 
life that a person might have tens of such different interfaces it became 
impossible. It wasn't the fault of any specific institution, it was a 
failure of humans being able to deal with large numbers of extremely 
complex, frequently changing passwords. Because of known human foibles, it 
might be a good idea to start shifting from an infrastructure with large 
numbers of shared-secrets to a non-shared-secret paradigm.

at a recent cybersecurity conference, somebody made the statement that (of 
the current outsider, internet exploits, approximately 1/3rd are buffer 
overflows, 1/3rd are network traffic containing virus that infects a 
machine because of automatic scripting, and 1/3 are social engineering 
(convince somebody to divulge information). As far as I know, evesdropping 
on network traffic  doesn't even show as a blip on the radar screen.

In the following thread on a financial  authentication white paper:
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication 
white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication 
white paper

there is point made that X9.59 standard doesn't directly address the 
Privacy aspect of security (i.e. no encryption or hiding of data). However, 
the point is made that it changes the paradigm so that the financial 
account number no longer represents a shared-secret and that it can be 
supported with two-factor authentication  i.e. something you have token 
and something you know PIN. The something you know PIN is used to 
enable the token, but is not a shared secret. Furthermore, strong 
authentication can be justification for eliminating the need for name or 
other identification information in the transaction.

However, if X9.59 strong authentication is used with two-factor 
authentication and no identification information is necessary  then it 
would make people more suspicious if privacy information was requested. 
Also, since privacy information is no longer sufficient for performing a 
fraudulent transaction, it might mitigate that kind of social engineering 
attack.

The types of social engineering attacks then become convincing people to 
insert their hardware token and do really questionable things or mailing 
somebody their existing hardware token along with the valid pin (possibly 
as part of an exchange for replacement). The cost/benefit ratio does start 
to change since there is now much more work on the crooks part for the same 
or less gain. One could also claim that such activities are just part of 
child-proofing the environment (even for adults). On the other hand, it 
could be taken as analogous to designing systems to handle observed failure 
modes (even when the failures are human and not hardware or software). 
Misc. identify theft and credit card fraud reference:
http://www.consumer.gov/idtheft/cases.htm
http://www.usdoj.gov/criminal/fraud/idtheft.html
http://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to 
hit $2 trillion
http://www.garlic.com/~lynn/subpubkey.html#fraud

Slightly related in recent thread that brought up buffer overflow exploits
http://www.garlic.com/~lynn/2003j.html#4 A Dark Day
and the report that multics hasn't ever had a buffer overflow exploit
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from 
the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from 
the Multics Security Evaluation

somebody (else) commented (in the thread) that anybody that currently 
(still) writes 

Re: An attack on paypal

2003-06-08 Thread Dave Howe
 in a world where there are repeated human mistakes/failures 
 at some point it is recognized that people aren't perfect and the design
 is changed to accommodate peoples foibles. in some respects that is what
 helmets, seat belts, and air bags have been about.

The problem is here, we are blaming the protective device for not being able
to protect against the deliberate use of an attack that bypasses, not
challenges it - by exploiting the gullibility or tendency to take the path
of least resistance of the user.
The real weakness in HTTPS is the tendency of certificates signed by Big
Name CAs to be automagically trusted - even if you have never visited that
site before.  yes, you can fix this almost immediately by untrusting the
root certificate - but then you have to manually verify each and every site
at least once, and possibly every time if you don't mark the cert as
trusted for future reference.
To blame HTTPS for an attack where the user fills in a web form received via
html-rendering email (no https involved at all) is more than a little unfair
though.

 in the past systems have designed long, complicated passwords that are
 hard to remember and must be changed every month. that almost worked when
 a person had to deal with a single shared-secret.
 when it became a fact of life that a person might have tens of such
 different interfaces it became impossible. It wasn't the fault of any
 specific institution, it was a failure of humans being able to deal with
 large numbers of extremely complex, frequently changing passwords.
 Because of known human foibles, it might be a good idea to start shifting
 from an infrastructure with large numbers of shared-secrets to a
 non-shared-secret paradigm.

I am not aware of one (not that that means much, given I am a novice in this
field)
Even PKI relies on something close to a shared secret - a *trustworthy* copy
of the public key, matching a secret copy of the private key. In x509, this
trustworthyness is established by an Ultimately Trusted CA; in pgp, by the
Web Of Trust, in a chain leading back to your own key; in SSH, by your
placing of the public key into your home dir manually (using some other form
of authentication to presumably gain access)
in each of these cases, the private key will almost invariably be protected
by a passphrase; at best, you can have a single passphrase (or even single
private key) to cover all bases.. but that just makes that secret all the
more valuable.

 at a recent cybersecurity conference, somebody made the statement that (of
 the current outsider, internet exploits, approximately 1/3rd are buffer
 overflows, 1/3rd are network traffic containing virus that infects a
 machine because of automatic scripting, and 1/3 are social engineering
 (convince somebody to divulge information). As far as I know, evesdropping
 on network traffic  doesn't even show as a blip on the radar screen.
That is pretty much because defence occupies the position of the interior -
attackers will almost invariably attack weak points, not strong ones. It is
easy to log and calculate how many attacks happen on weak points, but
impossible to calculate how many attacks *would* have happened had the
system not been in place to protect against such attacks, so the attackers
moved onto easier targets.
It makes little sense to try and break one https connection (even at 40 bit)
if by breaking into the server you get that information, hundreds of others
(until discovered) and possibly thousands of others inadvisedly stored
unprotected in a database.

snip
 The types of social engineering attacks then become convincing people to
 insert their hardware token and do really questionable things or mailing
 somebody their existing hardware token along with the valid pin (possibly
 as part of an exchange for replacement). The cost/benefit ratio does start
 to change since there is now much more work on the crooks part for the
 same or less gain. One could also claim that such activities are just part
 of child-proofing the environment (even for adults). On the other hand, it
 could be taken as analogous to designing systems to handle observed
 failure modes (even when the failures are human and not hardware or
 software). Misc. identify theft and credit card fraud reference:

Which again matches well to the Nigerian analogy. Everyone *knows* that
handing over your bank details is a Bad Thing - yet they still do it.


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