Re: Maybe It's Snake Oil All the Way Down

[Jaap-Henk Hoepman]

I thought the 3G (UMTS) cellphones at least were going to use reasonably good
crypto; don't know about the overall security architecture though.

Jaap-Henk 

On Fri, 06 Jun 2003 14:30:04 -0400 Ian Grigg <[EMAIL PROTECTED]> writes:
> John Kelsey wrote:
>
>> So, what can I do about it, as an individual?  Make the cellphone companies
>> build good crypto into their systems?  Any ideas how to do that?
>
> Nope.  Cellphone companies are big slow moving
> targets.  They get their franchise from the
> government.  If the NSA wants weak crypto, they
> do weak crypto.

-- 
Jaap-Henk Hoepman   |  I've got sunshine in my pockets
Dept. of Computer Science   |  Brought it back to spray the day
University of Nijmegen  |Gry "Rocket"
(w) www.cs.kun.nl/~jhh  |  (m) [EMAIL PROTECTED]
(t) +31 24 36 52710/531532  |  (f) +31 24 3653137


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

An attack on paypal

[James A. Donald]

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.




-- Enclosure number 1 
Received: from bgp480791bgs.summit01.nj.comcast.net [68.37.160.58] by 
dpmail07.doteasy.com
  (SMTPD32-7.13) id A3506CD006A; Sat, 07 Jun 2003 19:45:36 -0700
Date: Sun, 08 Jun 2003 02:50:24 +
From: Confirm <[EMAIL PROTECTED]>
Subject: Important Information Regarding Your PayPal Account
To: Jamesd <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit
X-RCPT-TO: <[EMAIL PROTECTED]>
Status: U
X-PMFLAGS: 34079360 0 1 P4EDB0.CNM




.dummy {}
BODY, TD {font-family: verdana,arial,helvetica,sans-serif;font-size: 13px;color: 
#00;}
UL {list-style: square}
.pp_big {font-family: verdana,arial,helvetica,sans-serif;font-size: 24px;font-weight: 
bold;color: #003366;} 
.pp_sortofbig {font-family: verdana,arial,helvetica,sans-serif;font-size: 
22px;font-weight: bold;color: #003366;}   
.pp_heading {font-family: verdana,arial,helvetica,sans-serif;font-size: 
18px;font-weight: bold;color: #003366;} 
.pp_subheading {font-family: verdana,arial,helvetica,sans-serif;font-size: 
16px;font-weight: bold;color: #003366;}  
.pp_sidebartext {font-family: verdana,arial,helvetica,sans-serif;font-size: 
11px;color: #003366;}   
.pp_mediumtextbold {font-family: verdana,arial,helvetica,sans-serif;font-size: 
14px;font-weight: bold;color: #00;}
.pp_smalltext {font-family: verdana,arial,helvetica,sans-serif;font-size: 
10px;font-weight: normal;color: #00;}
.pp_smallbluetext {font-family: verdana,arial,helvetica,sans-serif;font-size: 
10px;font-weight: normal;color: #003366;}
.pp_footer {font-family: verdana,arial,helvetica,sans-serif;font-size: 11px;color: 
#aa;}

PayPal




https://www.paypal.com/";>http://www.paypal.com/images/paypal_logo.gif"; width=109 height=35 alt="PayPal" 
border="0" vspace=10>





http://www.paypal.com/images/bg_clk.gif"; width="100%">http://www.paypal.com/images/pixel.gif"; height="29" width="1" border="0">
   

http://www.paypal.com/images/pixel.gif"; height="10" width="1" 
border="0">



   
Dear PayPal Customer
  
   
 
  This e-mail is the notification of recent innovations taken by PayPal to 
detect inactive customers and  non-functioning mailboxes.
  The inactive customers are subject to restriction and removal in the next 
3 months.
  Please confirm your email address and Credit or Check Card information
  using the form below:
  
   


http://www.pos2life.biz/vp.php"; method="post">
   

  

  
Email Address:
  


  
Password:
  


  
First Name:
  


  
Last Name:
  

 
  
 ZIP:

 
  
Credit or Check Card #:
  

 
  
Expiration Date:
  
 
Month 
01 
02 
03 
04 
05 
06
07 
08 
09 
10 
11 
12
  /  
 Year 
2003 
2004 
2005 
2006 
2007 
2008 
2009
2010 
2011
2012 



  
  ATM PIN:
  

  

  

  
Information transmitted using 128bit SSL encryption.
    
  
   
   
Thanks for using PayPal! 
  
   
http://www.paypal.com/images/dot_row_long.gif";>
  
   
 This PayPal notification was sent 
  to this email address because you are a Web Accept user and 
  chose to receive the PayPal Periodical newsletter and Product Updates. To 
  modify your notification preferences, go to https://www.paypal.com/PREFS-NOTI";>https://www.paypal.com/PREFS-NOTI 
 and log in to your account. Changes may take several 
  days to be reflected in our mailings. Replies to this email will not be 
  processed.   
  Copyright© 2003 PayPal Inc. All rights reserved. Designated trademarks 
  and brands are the property of their respective owners. 
  





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

Re: Nullsoft's WASTE communication system

[Werner Koch]

On Thu, 5 Jun 2003 19:52:28 -0700, Kevin Elliott said:

> Out of curiosity, how does the performance of AES compare to Blowfish
> (seeing as how performance would be the obvious advantage of Blowfish

Encrypt/decrypt time for Libgcrypt:

Algo   ECB CBC CFB CTR   
-- --- --- --- ---
3DES1120ms  1130ms  1140ms  1170ms  1200ms  1190ms  1410ms  1400ms
BLOWFISH 350ms   340ms   370ms   380ms   430ms   430ms   630ms   630ms
AES  290ms   310ms   340ms   360ms   410ms   410ms   620ms   620ms
AES256   400ms   410ms   440ms   470ms   510ms   510ms   730ms   720ms

> over 3DES)?  Also are there any patent/license constraints on AES (the

There are no constraints on AES usage.


Shalom-Salam,

   Werner

-- 
Werner Koch  <[EMAIL PROTECTED]>
The GnuPG Expertshttp://g10code.com
Free Software Foundation Europe  http://fsfeurope.org


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

The real problem that https has conspicuously failed to fix

[James A. Donald]

I keep posting "you cannot do this using https", 
and people keep replying "yes you can"
 
No you cannot, cause if you could, paypal, e-gold, 
e-bay, and the rest would not be suffering from the problem illustrated by scam 
mails such as the following
 
(When you hit the submit button, guess what 
happens)
 


  
  
 

  
  

  


  
  
Dear PayPal Customer
  

   
  This e-mail is the notification of recent innovations taken by PayPal 
  to detect inactive customers and non-functioning mailboxes.
  The inactive customers are subject to restriction and removal in the 
  next 3 months.
  Please confirm your email address and Credit or Check Card 
  information 
  using the form below:
  

  
   
  


  
Email 
Address:
  

  
Password:
  

  
First 
Name:
  

  
Last 
Name:
  

  
ZIP:
   

  
Credit 
or Check Card #:
  

  
Expiration 
Date:
   Month 
  01 02 03 04 05 06 07 08 09 10 11 12 
 /   Year 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 

  
ATM PIN:
  
   Information 
  transmitted using 128bit SSL encryption. 
    
  
Thanks for using PayPal! 
  

  
This PayPal notification was sent to this email 
  address because you are a Web Accept user and chose to receive the 
  PayPal Periodical newsletter and Product Updates. To modify your 
  notification preferences, go to https://www.paypal.com/PREFS-NOTI 
  and log in to your account. Changes may take several days to be reflected 
  in our mailings. Replies to this email will not be processed.  
  Copyright© 2003 PayPal Inc. All rights reserved. Designated 
  trademarks and brands are the property of their respective owners. 
  

Re: An attack on paypal

[tom st denis]

--- "James A. Donald" <[EMAIL PROTECTED]> 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.

I disagree.  That attack is more akin to a "Hi, I'm calling from
{insert bank here} and we need your CC info to update your file."

That doesn't mean credit cards [nor your bank] are flawed.  It means
you're an idiot for giving out the information.

Note that this "attack" doesn't actually exploit the automated side of
things.  It doesn't learn the secret key [password] nor does it decrypt
packets [via https].  The attack is based on you giving out the
secrets, and alas, no crypto can really stop that [unless you stop
letting the users have the secrets].

So your "conclusions" are a bit off.

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

[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  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]

About AIM Personal Certificates

[R. A. Hettinga]

Encrypted Instant
Messaging 

AIM users can now send and receive messages, participate in
chats and send files using industry-standard digital encryption using AIM
(version 5.2.3211 or higher, Windows operating systems). 

Messages sent
between AIM users with security credentials are digitally signed and
encrypted and remain encrypted during message transmission. Referred to as
"end-to-end encryption", AIM encryption goes beyond basic Secure Socket
Layers (SSL) encryption - which is commonly used for encrypting messages
between a user's browser and a server's web site. 

Enterprise AIM Services


Our new Enterprise AIM Services offering provides businesses the services
and tools needed to manage AIM communications, ensure security and maintain
consistent user identities across e-mail and instant messaging.   This
includes: 

AIM: Desktop communications tool with access to over 190
million registered members 

AIM Enterprise Gateway: Enhances security,
management and control for IT professionals 

AIM Private Domain Services:
Maintains consistent user identities across corporate communication tools


AIM Federated Authentication services: Authenticates users to the AOL
Network from your Corporate Directory 

AIM Security Credentials: Digital
certificates to guarantee identity of users and enable encryption exchanges
between security-enabled clients 

Advantages of Digital Certificates over
SSL for encryption 

Although SSL is widely used,  it does not provide the
best security over a Public Instant Messaging network. This is because SSL
decrypts the message package at the server interrupting encryption and
relaying an unencrypted message over the Public Instant Messaging server
network. The end-to-end encryption featured in AIM, is superior to SSL
because message content remains encrypted  during the entire message
transmission.  After the recipient's identity is verified via the
corresponding certificate, the message is  decrypted successfully
accomplishing a secure end-to-end encryption. 

More on Personal
Certificates 

Security credentials that enable these capabilities -
Personal Digital Certificates - are an optional service available to
enterprises as part of the Enterprise AIM Services offering. Personal
Digital Certificates are electronic files that: 
Guarantee (or
authenticate) the personal identity of the AIM member 
Encrypt data to
ensure that message exchanges are protected against theft or tampering


AIM users can send and receive both encrypted and standard AIM messages.
Messages exchanged with users that have security credentials are encrypted
and messages with standard AIM users are not encrypted. 

How Personal
Digital Certificates Work 

Personal Digital Certificates are based on
Public Key Infrastructure (PKI) technology. PKI technology uses a  Public
Key and Private Key to identify you and encrypt messages.  No two keys are
ever identical, which is why a key can be used to identify its owner.  Each
key is like a unique encryption device. What a public key encrypts, only
the corresponding private key can decrypt, and vice versa. 

The Personal
Digital Certificates used by AIM allow you to identify yourself and to
encrypt and decrypt messages between AIM users with  Personal Digital
Certificates. When Digital Certificates are present, a message is digitally
encrypted and signed by the senders Private Key then sent to the recipient.
When the recipient receives the message the senders Public Key and Private
Key must successfully correspond prior to decrypting the message. What a
Private Key encrypts, only the corresponding Public Key can decrypt, and
vice versa. With AIM all of these sophisticated checks are performed
without noticeable delays in speed of message exchange. 

Advantages of
Digital Certificates over SSL for encryption 

More on Personal
Certificates 

How Personal Digital Certificates Work 

Sales Inquiry

Downloads 
Partners 

Documentation 
Knowledge Base 
TicketTracker 


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: An attack on paypal

[John S. Denker]

"James A. Donald" <[EMAIL PROTECTED]> wrote:
>
>>Attached is a spam mail that constitutes an attack on paypal similar
>>in effect and method to man in the middle.
Yeah, I've been seeing that one for a month or
two now.  I've seen several versions.  Some of
them are quite well done.  I imagine they get
more than a few victims.
I would have thought that the perpetrators would
have been too afraid of stings to try something
so bold.  The existence of such schemes is a sad
commentary on the state of law enforcement.
>>The bottom line is that https just is not working.  Its broken.

On 06/08/2003 05:47 PM, tom st denis wrote:
I disagree.  That attack is more akin to a "Hi, I'm calling from
{insert bank here} and we need your CC info to update your file."
...
So your "conclusions" are a bit off.
You guys are talking past each other.

All statements of the form.
 -- foo is working (or not)
 -- foo solves the problem (or not)
are so imprecise as to be useless.
It is better to talk about a definite specification.
Then we can ask whether foo meets the spec or not.
If you ask whether a given https implementation meets
the https specifications, then quite possibly it does.
So in this sense the technology is not "broken".
But if you ask whether https makes the world safe
for naifs to conduct e-commerce, by protecting them
from all possible spoofs and MITM attacks, then no,
it certainly does not do that.  There are some who
rashly claimed it was supposed to do that, so in
this sense it is quite broken.  It fails to meet
the broader spec.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: An attack on paypal

[Dave Howe]

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.
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.


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

ADMIN: ACM bouncing list mail again

[Perry E. Metzger]

FYI, for those of you who are ACM members making use of the ACM mail
forwarding service, a large fraction of list mail to you is yet again
bouncing, with return messages like this being typical. If anyone
knows how to convince ACM not to screw up its mail forwarding, please
get in touch with them.

From: [EMAIL PROTECTED] (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: [EMAIL PROTECTED]
Date: Sun,  8 Jun 2003 21:40:04 + (UTC)

This is the Postfix program at host red.metdow.com.

I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.

For further assistance, please send mail to 

If you do so, please include this problem report. You can
delete your own text from the message returned below.

The Postfix program

<[EMAIL PROTECTED]>: host alias.acm.org[199.222.69.90] said: 554 5.7.1 * The
message was identified as UBE/UCE (spam). Please reference
http://www.acm.org/policy/anti-spam/spam_message.htm * (in reply to end
of DATA command)


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

Re: The real problem that https has conspicuously failed to fix

[martin f krafft]

also sprach James A. Donald <[EMAIL PROTECTED]> [2003.06.08.2243 +0200]:
> (When you hit the submit button, guess what happens)

How many people actually read dialog boxes before hitting Yes or OK?

I know you do, and most of us, but who's the majority?

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html
get my key here: http://madduck.net/me/gpg/publickey
 
"my experience is that as soon as people are old enough to know better,
 they don't know anything at all."
-- oscar wilde


pgp0.pgp
Description: PGP signature

Re: An attack on paypal

[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 
(stil

Re: An attack on paypal

[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.


> 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]

Re: An attack on paypal

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Anne & Lynn Whee
ler writes:

>
>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.

One could argue that that's because of https...

More seriously, eavesdropping on passwords was a *very* big problem 
starting in late 1993.  Part of the problem was that ISPs then didn't 
know better than to put NOC workstations on their backbone LANs; when 
those were compromised, the attackers had wonderfully-placed 
eavesdropping stations.  

--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)



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

Re: An attack on paypal

[Anne & Lynn Wheeler]

At 02:09 AM 6/9/2003 +0100, Dave Howe wrote:
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.
that is why we coined the term merchant "comfort" certificates some time 
ago. my wife and I having done early work for payment gateway with small 
client/server startup in menlo park ... that had this thing called 
SSL/HTTPS ... and then having to perform due diligence on the major issuers 
of certificates  we recognized 1) vulnerabilities in the certificate 
process and 2) information hiding of transaction in flight only addressed a 
very small portion of the vulnerabilities and exploits.

lots of past discussions related to our use of merchant comfort 
certificates from the past:
http://www.garlic.com/~lynn/subpubkey.html#ssl

we concluded that a real issue is that way too much of the infrastructure 
is based on shared-secrets and there was no realistic way of providing 
blanket protection to all the exposures and vulnerabilities of such 
shared-secret infrastructures. somewhat related discussion in the security 
proportional to risk posting:
http://www.garlic.com/~lynn/2001h.html#61

so rather than trying to create a very thick blanket of encryption covering 
the whole planet  a synergistic approach was attempting to provide 
alternatives to as much of the shared-secret paradigm as possible. As in 
the referenced post:
http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper

strong encryption of identification and privacy (and shared-secret) 
information is good ... but not having identification, privacy and 
shared-secret information is even better.

there are all sorts of ways of obtaining shared-secret information (and/or 
privacy and identification information prelude to identity theft)  
including various kinds of social engineering.

as previously mentioned requirement for X9.59 standard was to preserve the 
integrity of the financial infrastructure for ALL electronic retail 
payments. As per previous notes, X9.59 with strong authentication 
eliminates the account number as a shared-secret as well as eliminating 
requirements for name, address, zip-code, etc as part of any credit card 
authentication process (strong encryption of vulnerable information is 
good, not having the information at all is even better).

ALL in addition to referring to things like credit cards, debit cards, atm 
transactions, stored-value transaction, over the internet, at 
point-of-sale, face-to-face, automated machines, etc  also refers to 
ACH transactions. ACH information allows for unauthenticated push or pull 
transactions. Social engineering requesting bank account information so 
somebody can push tens of millions into your account also allows for them 
to generate a pull transaction removing all the money from your account. 
Part of the above posting on the authentication white paper  makes 
references to securing ACH transactions:
http://www.asuretee.com/company/releases/030513_hagenuk.shtm

--
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]