Re: Status of SRP

2006-06-07 Thread John Brazel



Jeffrey Altman wrote:

Solving the phishing problem requires changes on many levels:

(1) Some form of secure chrome for browsers must be deployed where
the security either comes from a trusted desktop or by per-user
customizations that significantly decrease the chances that the
attacker can fake the web site experience.  (Prevent the attacker
from replicating the browser frame, toolbars, lock icons,
certificate dialogs, etc.)

(2) Reducing the number of accounts and passwords (or other identifiers)
that end users need to remember.  With a separate identifier for
each and every web site it is no surprise that my extended family
can never remember what was used at each site.   Therefore, it is
not much of a surprise when a site says that the authentication
failed.

(3) Secure mechanisms must be developed for handling enrollment and
password changing.



  What we really need is something similar to the built-in remember
my password functionality of current web browsers: the browser keeps
track of a login/password/certified (ie TLS certificate-backed) DNS name
tuple, and if it ever spots the user entering said login/password into a
different website, brings up some form of dialog alerting the user to a
potential phishing attack.

The downside, of course, is that:

a) It wouldn't handle password changing,
b) Some people use the same login and password *everywhere*,
c) Once you change browsers or computers, all bets are off (because the
new browser doesn't know anything about which passwords you use where).

J.


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


Re: Status of SRP

2006-06-07 Thread Anne Lynn Wheeler

James A. Donald wrote:

The concept of trusted computing is an attempt to
address this problem - each application has exclusive
access to certain data, a trusted path to interact with
the user, and the ability to prove to servers what code
is being executed on the client. 


so they aren't exactly unrelated.

re:
http://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP

the financial standards x9a10 working group had been given the 
requirement to preserve the integrity for all retail payments. the 
result was the x9.59 payment standards for all retail payments.

http://www.garlic.com/~lynn/x959.html#x959

part of x9.59 retail payment standard requires the transaction to be 
authenticated. another part of the x9.59 retail payment standard 
requires that the account number in x9.59 retail payments can't be used 
in non-authenticated transactions. it as been recognized for a long time 
that a major source of account financial fraud  has been the data breaches

http://www.garlic.com/~lynn/subpubkey.html#harvest

and resulting fraudulent use of account numbers ... this is somewhat my 
old posting on security proportional to risk

http://www.garlic.com/~lynn/2001h.html#61

in effect, account numbers have been overloaded. on one hand, knowledge 
of account numbers have been sufficient for doing fraudulent 
transactions. as a result they have to be treated as shared secrets, 
kept confidential and never divulged. on the other hand, account numbers 
are required in a large number of business process as the fundamental 
cornerstone for transaction execution ... and are required to be widely 
available. as a result of these totally opposing requirements, i've 
periodically observed that the planet could be buried under miles of 
cryptography used in hiding account number, and it would still be unable 
to prevent leakage of account numbers. the x9.59 business rule 
recognizes this and changes the paradigm, eliminating the severe 
financial fraud vulnerability associated with divulging account numbers

(and/or data breaches involving account numbers).

another part of x9.59, in addition to providing for transaction digital 
signature as part of transaction authentication (and trying to close 
some of the barn door with the overloaded requirements placed on account 
numbers) was allowing for a second digital signature by the environment 
that the transaction originated in. this would provide the relying party 
additional information for performing risk assessment related to 
authorizing the transaction.


so later when this software company wanted to come up with something for 
content providers, they hired the chair of the x9a10 financial standards 
working group to move to redmond to be director of development.


for other drift on trusted computing ... there are capability based 
operating systems ... current example is capros ... which was spawned 
from eros, which was sort of spawned from keykos, which was spawned from 
gnosis ... recent post mentioning some capros, eros, keykos, gnosis, et 
all (and other related lore regarding secure and/or capability-based 
operating systems ... going back to deployments by commercial 
time-sharing service bureaus in the late 60s and their connections to 
some of the current efforts ... as well as connections to what i was

doing as an undergraduate in the 60s)
http://www.garlic.com/~lynn/2006k.html#37

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


Re: Status of SRP

2006-06-07 Thread Ka-Ping Yee
On Wed, 7 Jun 2006, John Brazel wrote:
 What we really need is something similar to the built-in remember
 my password functionality of current web browsers: the browser keeps
 track of a login/password/certified (ie TLS certificate-backed) DNS name
 tuple...
[...]
 The downside, of course, is that:

 a) It wouldn't handle password changing,
 b) Some people use the same login and password *everywhere*,
 c) Once you change browsers or computers, all bets are off (because the
 new browser doesn't know anything about which passwords you use where).

If you haven't looked at this yet, i think you'll find it interesting:

http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/

These design ideas are intended to address exactly the things you've
just mentioned.


-- ?!ng

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


Re: Status of SRP

2006-06-07 Thread James A. Donald

--
Anne  Lynn Wheeler wrote:
 part of x9.59 retail payment standard requires the
 transaction to be authenticated. another part of the
 x9.59 retail payment standard requires that the
 account number in x9.59 retail payments can't be used
 in non-authenticated transactions. it as been
 recognized for a long time that a major source of
 account financial fraud  has been the data breaches
 http://www.garlic.com/~lynn/subpubkey.html#harvest

Have any merchants adopted the X9.59 standard?

Is it in fact possible for a merchant to today take
orders over X9.59?

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 SCLw5bENxW3GhAPjMCCFxAZNTWWplgH3XHfzZejK
 4wUo1x4tRVdskoDX1ZgiomicCYwgwFPLepwR04i2a


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


Re: Status of SRP

2006-06-06 Thread Florian Weimer
* Anne  Lynn Wheeler:

 Florian Weimer wrote:
 FINREAD is really interesting.  I've finally managed to browse the
 specs, and it looks as if this platform can be used to build something
 that is secure against compromised hosts.  However, I fear that the
 support costs are too high, and that's why it hasn't caught on in
 retail online banking.

 if they can build a $100 PC ... you think that they could build a
 finread terminal for a couple bucks. sometimes there are issues with
 volume pricing ... you price high because there isn't a volume and
 there isn't a volume because you price high.

The problem is not hardware costs, but support costs.  You really
don't want to outsource this to the cheapest call center in the world.
Even relatively simple changes like the indexed TAN rollout are
rather expensive as a result.

 there is one issue missing from the actual FINREAD specification.

 when we were doing X9.59 financial standard ... we allowed for a
 digital signature for authentication as well as for a digital
 signature from the environment that the transaction was performed
 in. the issue from a relying party standpoint ... is what assurances
 do they have as to the actual environment that a transaction was
 executed in. consumers could claim they were using a FINREAD terminal
 when they weren't. counterfeit FINREAD terminals could be out in the
 wild.

You mean something like remote attestation?  I find it hard to believe
that this capability is available today in a relatively open
environment, on a platform supporting multiple applications developed
by different applications.

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


Re: Status of SRP

2006-06-06 Thread Anne Lynn Wheeler

Florian Weimer wrote:

You mean something like remote attestation?  I find it hard to believe
that this capability is available today in a relatively open
environment, on a platform supporting multiple applications developed
by different applications.


re:
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP

i got involved in tracking down a virus/trojan like problem in the 70s 
on the internal network

http://www.garlic.com/~lynn/subnetwork.html#internalnet

basically if you are going to allow loading of stuff that can do its own 
execution w/o many safeguards ... you are going to be extremely 
vulnerable to numerous kinds of attacks.


either you have to very tightly control what applications are loaded 
 or possibly do a fixed function deployment that can support 
multiple different applications ... possibly based on some form of data 
driven architecture (i.e. the data specification possibly adapts the 
functional operation to different applications w/o requiring loading of 
executable code).


we had done the AADS chip strawman was done this way ... basically 
single function operation w/o any ability to load executable code ... 
that was adaptable to a large number of different applications

http://www.garlic.com/~lynn/x959.html#aads

another possible solution is very strong partitioning of any loadable 
executable content that is allowed extremely limited/controlled capability.


in the 60s as an undergraduate, i had done a lot with extremely 
controlled partitioning ... which i learned much later got used in 
various environments that had extremely high integrity requirements ... 
random drift

http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

i had this discussion with the general manager of the business unit that 
included java and java virtual machine (when it was in its very early 
infancy) ... turns out that I had done some work with the person 
(general manager) nearly 20 years earlier in a different life.


many of the modern generation of POS terminals are trying to cope with 
this problem ... getting all sorts of frequent application downloads of 
various kinds ... and still attempting to operate within constraints of 
their trusted security module implementation.


basically if finread
http://www.garlic.com/~lynn/subpubkey.html#finread

is countermeasure to widely acceptable PC vulnerabilities (many that 
arise because of the ease and common practice of loading executable 
content) ... then if you deploy such a finread terminal that is operated 
using similar conventions ... then it will acquire similar vulnerability 
characteristics (as the environment that it is suppose to be a 
countermeasure for).


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


Re: Status of SRP

2006-06-04 Thread Jeffrey Altman
James A. Donald wrote:
 --
 Jeffrey Altman wrote:
 Unfortunately, SRP is not the solution to the phishing
 problem. The phishing problem is made up of many
 subtle sub-problems involving the ease of spoofing a
 web site and the challenges involved in securing the
 enrollment and password change mechanisms.
 
 With SRP, the web site cannot be spoofed, for it must
 prove it knows the  user's secret passphrase.

James, SRP can only prevent spoof's of successful authentications
and it can only prevent spoof's when it is actually used.

It cannot prevent spoof's of unsuccessful authentications and that
is where a huge part of the problem lies.  Consider the reaction
of many individuals when they receive a page that indicates that
their username and/or password are incorrect?

Sites that offer the common secret question(s) can be spoofed.
The attacker spoof's sits in the middle, captures the question from
the real site, the answer from the user, and if the real site says
that the new password is being sent, puts up a new page indicating
that the password should be changed online along with prompts for
private information that the attacker wants.

Stopping phishing with successful authentication is not even half
the problem.

Jeffrey Altman


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Status of SRP

2006-06-03 Thread James A. Donald

--
Jeffrey Altman wrote:
 Unfortunately, SRP is not the solution to the phishing
 problem. The phishing problem is made up of many
 subtle sub-problems involving the ease of spoofing a
 web site and the challenges involved in securing the
 enrollment and password change mechanisms.

With SRP, the web site cannot be spoofed, for it must
prove it knows the  user's secret passphrase.

Now Wagner keeps complaining that the users are complete
morons, who could be taken in by a very shoddy spoof,
and no doubt that is true, but right now it is possible
to make a very good spoof, and that can be fixed.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 K0DkzvBcnUAkU1t725Cg9Fmh6awjA9b9S8SmmanA
 4HYHXPVEWxmojVTOmRDh7L/Eu6KRWMz3WCh5tL2Eq


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


Re: Status of SRP

2006-06-03 Thread James A. Donald

--
Lance James wrote:
 Here's where SRP fails:

 1) SSL is built into the browser - doesn't stop
 phishers

SSL protects true names, SRP protects true
relationships.  Protecting true names turned out to be
not very useful.

 Hi, we're having a problem with your account system
 as our SRP database was corrupted, please login
 through the webpage to verify your information and
 reset your SRP account to working order.

They set up their SRP account through the chrome, not
through a webpage.  This attack fails to mimic what is
routine.  Phishing relies on mimicry and habit. The
poorer the mimicry, the less people are likely to fall
for it.  Certainly some people will fall for it, there
is a sucker born every minute, but right now we are
seeing phishing attacks that quite sophisticated people
fall for.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 7hBodKZ++GbmAsbf7YHZGQsErgEpvrEN+jMzkRVJ
 4jFzcd0zA2X0mdrrP52Wb9NZEOfARFgb0RMwwJCL7

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


Re: Status of SRP

2006-06-03 Thread Florian Weimer
* Ka-Ping Yee:

 Passpet's strategy is to customize a button that you click.  We
 are used to recognizing toolbar buttons by their appearance, so
 it seems plausible that if the button has a custom per-user icon,
 users are unlikely to click on a spoofed button with the wrong
 icon.  Unlike other schemes, such as special-looking windows or
 a custom image shown with the login form, this strategy requires
 the user to directly interact with the customized UI element.

I'm not sure if this can't be defeated by something like a Choose a
new funny icon for your security button! offer. 8-( However, this
points to a more general problem: We have no real-world studies how
users make their day-to-day trust decisions when using the Internet.

For example, if I need to judge the trustworthyness of a web page, a
large factor is the way I got there.  If it was a link from an email
message that looks like spam, or something that was returned by a
search engine, I'm rather sceptical.  This is why those 80% can't
tell a phishing page apart from the real one web-base studies are
quite worthless.  They simply do not present enough context.

| The field for entering your master password isn't labelled Enter
| your password: - instead, it's labelled Enter Betty's secret:.
| Since the persona differs from user to user, it's hard to even ask
| for the password because the spoofer doesn't know what to call it.

I suppose this can be circumvented if you you use email to lure the
victim to the fake web page and have obtained names matching the email
addresses.  Even if you want to present the full address to the
victim, you can buy this data from direct marketing companies, I
think.

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


Re: Status of SRP

2006-06-03 Thread Florian Weimer
* Anne  Lynn Wheeler:

 Florian Weimer wrote:
 If you've deployed two-factor authentication (like German banks did in
 the late 80s/early 90s), the relevant attacks do involve compromised
 customer PCs. 8-( Just because you can't solve it with your technology
 doesn't mean you can pretend the attacks don't happen.

 EU finread terminal was countermeasure to (widely held impression
 that) PCs are extremely vulnerable to compromise.

You say that as if that assumption were unrealistic.
Transaction-rewriting malware is out in the wild. 8-(

FINREAD is really interesting.  I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts.  However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.

 card authentication required pin entry to work ... and finread
 terminal had its own PIN-pad distinct the vulnerable PC
 keyboard. orientation was towards transaction authentication ... with
 the finread terminal also having its own display of what was being
 authentication.

The interesting part is that it's possible to create an application
that runs exclusively on the trustworthy component and presents the
actual transaction data to the user before it is signed.

Previous card readers/smart card combinations relied on host software
to provide the display contents, without any way to check that it
matches the blob that was to be signed.  Of course, it's still
possible to develop a FINREAD application that behaves that way,
perhaps in order to cut down development costs.  As usual, just
because it's FINREAD, it's not automatically secure (and a
transparent mode exists as well).

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


Re: Status of SRP

2006-06-03 Thread Ka-Ping Yee
On Thu, 1 Jun 2006, Jeffrey Altman wrote:
 Solving the phishing problem requires changes on many levels:

I agree.

 (1) Some form of secure chrome for browsers must be deployed where
 the security either comes from a trusted desktop or by per-user
 customizations that significantly decrease the chances that the
 attacker can fake the web site experience.

What do you think of the various trusted-path ideas that have been
proposed?  In particular i'm curious what you think of the solution
i currently favour (the customized toolbar button), but some of the
others certainly seem promising (such as PwdHash's special hotkey
at the beginning of a password).

 (2) Reducing the number of accounts and passwords (or other identifiers)
 that end users need to remember.

Password hashing is one way to deal with this.  In Passpet's case,
the password is generated by hashing a master secret with a label
that you provide for each site.

 (3) Secure mechanisms must be developed for handling enrollment and
 password changing.

With Passpet, you would click the button to fill in the password on a
new account registration form, which generates a unique password for
the site.  To change your password, you would go to the site's account
settings page, click the button to fill in your old password, edit the
site label, then click the button again to get a new password.

Does that address the issues you had in mind, or were you thinking of
other situations?


-- ?!ng

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


Re: Status of SRP

2006-06-03 Thread Anne Lynn Wheeler

Florian Weimer wrote:

FINREAD is really interesting.  I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts.  However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.


if they can build a $100 PC ... you think that they could build a 
finread terminal for a couple bucks. sometimes there are issues with 
volume pricing ... you price high because there isn't a volume and there 
isn't a volume because you price high.


there is one issue missing from the actual FINREAD specification.

when we were doing X9.59 financial standard ... we allowed for a digital 
signature for authentication as well as for a digital signature from the 
environment that the transaction was performed in. the issue from a 
relying party standpoint ... is what assurances do they have as to the 
actual environment that a transaction was executed in. consumers could 
claim they were using a FINREAD terminal when they weren't. counterfeit 
FINREAD terminals could be out in the wild.


part of the x9.59 financial standard looked at the assurance/integrity 
that a relying party might have with regard to the actual authentication 
... one factor, two factor, three factor ... and the actual 
assurance/integrity of the associated factors (or conversely, how 
vulnerable were the factors to compromise). this somewhat led into also 
having to consider the assurance/integrity environment that the 
authentication took place in (and what assurances would a relying party 
have with regard to the environment).


part of it has been some past inclination to just specify some standard 
... w/o regard to how a relying party might actual have assurances as to 
whether some standard or another was being followed in an open 
environment (and considering threat scenarios that might involve 
compromise/impersonation of various components).


for instance, there was a recent scenario in the UK where crooks were 
impersonating maint. people and were updating secure POS terminals with 
compromised components.



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


Re: Status of SRP

2006-06-03 Thread Anne Lynn Wheeler

Anne  Lynn Wheeler wrote:
if they can build a $100 PC ... you think that they could build a 
finread terminal for a couple bucks. sometimes there are issues with 
volume pricing ... you price high because there isn't a volume and there 
isn't a volume because you price high.


re:
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP

another aspect was that there was a program in the past to give away 
smartcards and card readers to consumers as part of doing smartcard 
financial transactions. the issue at the time was that deployed support 
for pc/sc standard only supported pc serial port interfaces ... and 
therefor the free card reader was a serial port device. there was an 
ensuing disaster as consumers tried to get the serial port device 
operational ... lots of stories of BSOD, having to re-install everything 
from scratch, etc. as the dust was settling, there was a quickly 
spreading opinion that smartcards (or at least smartcard readers) were 
not viable in the consumer market segment. it was during this period 
that m'soft even canceled its smartcard operating system project.


recent post discussing the subject:
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means 
Pressed Flowers



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


Re: Status of SRP

2006-06-02 Thread Jeffrey Altman
James A. Donald wrote:
 The obvious solution to the phishing crisis is the widespread deployment
 of SRP, but this does not seem to happening.  SASL-SRP was recently
 dropped.  What is the problem?

Unfortunately, SRP is not the solution to the phishing problem.
The phishing problem is made up of many subtle sub-problems involving
the ease of spoofing a web site and the challenges involved in securing
the enrollment and password change mechanisms.  SRP would allow a client
to know that a service is in fact the correct service when the
authentication succeeds.  However, it would not help in the situation
when the authentication fails.  This could be because the user is not
sure of what the password is or even sure which account name was being
used.

Solving the phishing problem requires changes on many levels:

(1) Some form of secure chrome for browsers must be deployed where
the security either comes from a trusted desktop or by per-user
customizations that significantly decrease the chances that the
attacker can fake the web site experience.  (Prevent the attacker
from replicating the browser frame, toolbars, lock icons,
certificate dialogs, etc.)

(2) Reducing the number of accounts and passwords (or other identifiers)
that end users need to remember.  With a separate identifier for
each and every web site it is no surprise that my extended family
can never remember what was used at each site.   Therefore, it is
not much of a surprise when a site says that the authentication
failed.

(3) Secure mechanisms must be developed for handling enrollment and
password changing.

Only then can we truly address the phishing problem.

Jeffrey Altman


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Status of SRP

2006-06-02 Thread Lance James
Here's where SRP fails:

1) SSL is built into the browser - doesn't stop phishers
2) Chrome or no chrome good luck getting it in there and having every
user understand it.
3) Traditional phishing works, but if you force them to change, the
malware propagation will only be higher than it is now, and I can give
you the numbers on how much data is stolen with malware (over 2 million
credit cards have been acquired since January via trojan software - how
do I know this, I monitor their blind drops constantly and one group's
daily take is over 150 megs of credentials on average.

SRP suffers from a rollback attack, chrome or no chrome - humans don't
know enough about this, and if the phisher does:

Hi, we're having a problem with your account system as our SRP database
was corrupted, please login through the webpage to verify your
information and reset your SRP account to working order.

Surprisingly, many would fall for this.

My 2 cents.

-Lance


James A. Donald wrote:
 --
 James A. Donald wrote:
   The obvious solution to the phishing crisis is the
   widespread deployment of SRP

 Lance James
  I disagree here, I don't think this will stop phishing
  for many reasons. Please explain how it would. It will
  stop man-in-the-middle attacks on the protocol, but
  phishers aren't attacking the protocols themselves.

 To be useful, SRP has to be in the browser chrome.

 Consider a typical e-gold phish
 : :You have just made a request to transfer all
 : :the funds in your account.  Please click here
 : :www.e-golb.com/cancel and login to cancel
 : :this request if it was made by someone other
 : :than yourself

 Assume e-gold was using SRP login.  The user would
 attempt to login to www.e-golb.com through SRP, and the
 login would fail.

  It's still single-auth and I can still obtain the user
  password via phishing.

 How?

 SRP never reveals the login.  It is zero knowledge.
 Instead, both parties prove to each other than they know
 the secret, without revealing the secret.

 The only way you can phish the user is to get him to not
 use SRP.  But if he is attempting to use SRP he is not
 typing the password into a web page, but into client
 software running on his own machine, which is going to
 look visibly different from any web page.

 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  bhZzlPU6DtnwH9s5+PxwPlwhgvD/8iFEI9LcuRXA
  4x54cCglld16xbMxUa/22CBHVIxtb7yqM78rQ9Ul1




-- 
Best Regards,
Lance James
Secure Science Corporation
www.securescience.net
Author of 'Phishing Exposed'
http://securescience.net/home/news/phishingexposed.html
**
* New IntelliFound Service 2 weeks free  *
* Real-Time Identity Surveillance Service*
* http://www.securescience.net/  *
**


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


Re: Status of SRP

2006-06-02 Thread Ka-Ping Yee
On Thu, 1 Jun 2006, Florian Weimer wrote:
  That is an all purpose argument that is deployed
  selectively against some measures and not others.

 If you've deployed two-factor authentication (like German banks did in
 the late 80s/early 90s), the relevant attacks do involve compromised
 customer PCs. 8-( Just because you can't solve it with your technology
 doesn't mean you can pretend the attacks don't happen.

You're both right.  The problem is that we are talking about
solutions but haven't yet agreed on a threat model to discuss.


-- ?!ng

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


Re: Status of SRP

2006-06-02 Thread James A. Donald

--
Ka-Ping Yee wrote:
 Passpet's strategy is to customize a button that you
 click.  We are used to recognizing toolbar buttons by
 their appearance, so it seems plausible that if the
 button has a custom per-user icon, users are unlikely
 to click on a spoofed button with the wrong icon.
 Unlike other schemes, such as special-looking windows
 or a custom image shown with the login form, this
 strategy requires the user to directly interact with
 the customized UI element.

This seems like a promising tactic, since a first step
in any process is look for the button.  If user does
not see the button, will be troubled, will stop and
think.

Any customization is an effective anti phishing measure:
Observe that eBay resists phishing by starting its
emails by addressing each user by logon name, and Amazon
resists phishing by extensively customizing its web page
to each user - by supplying non cryptographic evidence
of an existing relationship.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 O37xiq0aPJeqGc7fQTWWTY85hPPktIPGAwbDifVD
 4bDTmZTlI9gWsmLu9xhSdisgc26xogVtQOnIi5/DI


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


Re: Status of SRP

2006-06-02 Thread James A. Donald

--
Ka-Ping Yee wrote:
 Passpet's strategy is to customize a button that you
 click.  We are used to recognizing toolbar buttons by
 their appearance, so it seems plausible that if the
 button has a custom per-user icon, users are unlikely
 to click on a spoofed button with the wrong icon.
 Unlike other schemes, such as special-looking windows
 or a custom image shown with the login form, this
 strategy requires the user to directly interact with
 the customized UI element.

 The effectiveness of Passpet's approach is only
 hypothesized; it has never been formally tested, so i
 can't claim it works better.

 Cannot find a web page that presents passpet.

 See  http://usablesecurity.com/2006/02/08/how-to-prevent-ph
 ishing/

This seems like a highly effective cure for phishing,
and one that can be implemented on the individual level
- and unlike my proposed solution, your solution does
not require competent web masters, who tend to be in
short supply.  When do you hope to release an actual
working passpet?

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 2XJ1hBQB4Lh88oartvxNB9R47imTGm9ijr/vCQ5S
 4tw2qTJbgf91cRjr3IilUO+alJWC4QViGoIqSUjWI


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


Re: Status of SRP

2006-06-02 Thread Travis H.

On 5/30/06, Derek Atkins [EMAIL PROTECTED] wrote:

Quoting James A. Donald [EMAIL PROTECTED]:
 The obvious solution to the phishing crisis is the widespread
 deployment of SRP, but this does not seem to happening.  SASL-SRP was
 recently dropped.  What is the problem?

Patents.


Seconded.  When I was doing some software development, we investigated
strong password solutions, and to my knowledge they were all under the
shadow of patents.

In the end, it didn't matter, since I was using it in a distributed
IDS system, and users weren't necessarily going to be present, even at
boot.  For machine-to-machine authentication, they're irrelevant
(assuming a good source of unpredictability).  For everything but
first-time authentication between the browser and the site, and key
changes, they can be ignored in favor of cached keys (a la ssh) if you
can design a UI that presents them in an easy-to-understand manner.

Rumor has it that Vista will send every URL visited to Microsoft for
vetting against a blacklist ostensibly to protect users against
phishing*, which I suppose trades one problem for another, although
for most people's concerns it's probably a win, since they're running
a MS product in the first place.  It can allegedly be turned off.

[*] When it was announced that the low-cost Asian version of Windows
would only be able to run a limited number of programs at once (I
think it was four), MS's PR department described the limit as being
there to reduce confusion.  That's either insulting to all Asian's
intelligence, or everyone's, depending on how credulous you are.  I
wonder how much they get paid to come up with things like that.
--
Scientia Est Potentia -- Eppur Si Muove
Security guru for rent or hire - http://www.lightconsulting.com/~travis/ --
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

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


Re: Status of SRP

2006-06-02 Thread Anne Lynn Wheeler

Florian Weimer wrote:

If you've deployed two-factor authentication (like German banks did in
the late 80s/early 90s), the relevant attacks do involve compromised
customer PCs. 8-( Just because you can't solve it with your technology
doesn't mean you can pretend the attacks don't happen.


EU finread terminal was countermeasure to (widely held impression that) 
PCs are extremely vulnerable to compromise.


card authentication required pin entry to work ... and finread terminal 
had its own PIN-pad distinct the vulnerable PC keyboard. orientation was 
towards transaction authentication ... with the finread terminal also 
having its own display of what was being authentication. the transaction 
authentication orientation was countermeasure to session authentication 
orientation where PC compromises could operate within the boundaries of 
any authenticated session.


part of thread in sci.crypt mentioning finread terminal as 
countermeasure to (widely held view of) the ease of PC compromises

http://www.garlic.com/~lynn/2006k.html#46 Keylogger resistance
http://www.garlic.com/~lynn/2006k.html#52 Keylogger resistance

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


Re: Status of SRP

2006-06-01 Thread Victor Duchovni
On Wed, May 31, 2006 at 09:41:57AM +1000, James A. Donald wrote:

 The obvious solution to the phishing crisis is the widespread deployment 
 of SRP, but this does not seem to happening.  SASL-SRP was recently 
 dropped.  What is the problem?

The obvious solution is perhaps more difficult to deploy in an environment
where loss of ubiquitous access trumps security gains. It takes years to
*field* new infrastructure. When the designer calls the problem solved,
the real work begins, or not, if the market is not yet ready for the
solution.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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


Re: Status of SRP

2006-06-01 Thread Ka-Ping Yee
On Wed, 31 May 2006, James A. Donald wrote:
 The obvious solution to the phishing crisis is the widespread deployment
 of SRP, but this does not seem to happening.  SASL-SRP was recently
 dropped.  What is the problem?

Phishing can mean a few different things.  If by phishing you
mean the stealing of passwords, then yes, SRP would help to eliminate
that problem, but users could still be fooled into giving away their
SRP passwords if the user interface for entering the password is
convincingly imitated.

Some people use phishing to refer to the online capture of
identity-related information in general, in which case SRP falls
far short of a complete solution.  I think it's a difference in
philosophy: some see passwords as the ultimate goal; some see
passwords as one of many possible means to the ultimate end, which
is identity theft.

I'm working on Passpet, a password management tool that tries to
address several of the big phishing-related problems including
password capture and dictionary attack, and for the authentication
part i chose SRP.  So that's one place it's getting used, anyway.


-- ?!ng

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


Re: Status of SRP

2006-06-01 Thread Lance James
James A. Donald wrote:
 The obvious solution to the phishing crisis is the widespread
 deployment of SRP, but this does not seem to happening.  SASL-SRP was
 recently dropped.  What is the problem?

I disagree here, I don't think this will stop phishing for many reasons.
Please explain how it would. It will stop man-in-the-middle attacks on
the protocol, but phishers aren't attacking the protocols themselves.

It's still single-auth and I can still obtain the user password via
phishing. Please correct me if I'm wrong but phishing is before this
protocol will be accessed.

if Mallory convinces Carol to log into a spoofed site that looks like
Steve not running SRP, then u and x are obtained by Mallory. Mallory
simply logs into Steve with U and X.

In SRP what is preshared is g^x where x = H(s,p) where s is a salt and p
is the password.

p would be a weakness here because the user knows it, and in phishing,
if the user knows it, the user is vulnerable.

My 2 cents.

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




-- 
Best Regards,
Lance James
Secure Science Corporation
www.securescience.net
Author of 'Phishing Exposed'
http://securescience.net/home/news/phishingexposed.html
**
* New IntelliFound Service 2 weeks free  *
* Real-Time Identity Surveillance Service*
* http://www.securescience.net/  *
**


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


Re: Status of SRP

2006-06-01 Thread Lance James
Lance James wrote:
 James A. Donald wrote:
   
 The obvious solution to the phishing crisis is the widespread
 deployment of SRP, but this does not seem to happening.  SASL-SRP was
 recently dropped.  What is the problem?
 

   
I want to clarify, because by typing to fast, i think my variables may
be confusing since I was reading the spec of SRP from two diff docs.

u and x in my sentence was username and password not x being typical
derived secret.
what it should be is u and p. please note corrections.

Thanks.


 I disagree here, I don't think this will stop phishing for many reasons.
 Please explain how it would. It will stop man-in-the-middle attacks on
 the protocol, but phishers aren't attacking the protocols themselves.

 It's still single-auth and I can still obtain the user password via
 phishing. Please correct me if I'm wrong but phishing is before this
 protocol will be accessed.

 if Mallory convinces Carol to log into a spoofed site that looks like
 Steve not running SRP, then u and x are obtained by Mallory. Mallory
 simply logs into Steve with U and X.

 In SRP what is preshared is g^x where x = H(s,p) where s is a salt and p
 is the password.

 p would be a weakness here because the user knows it, and in phishing,
 if the user knows it, the user is vulnerable.

 My 2 cents.
   
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to
 [EMAIL PROTECTED]


 


   


-- 
Best Regards,
Lance James
Secure Science Corporation
www.securescience.net
Author of 'Phishing Exposed'
http://securescience.net/home/news/phishingexposed.html
**
* New IntelliFound Service 2 weeks free  *
* Real-Time Identity Surveillance Service*
* http://www.securescience.net/  *
**


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


Re: Status of SRP

2006-06-01 Thread Derek Atkins

Quoting James A. Donald [EMAIL PROTECTED]:

The obvious solution to the phishing crisis is the widespread 
deployment of SRP, but this does not seem to happening.  SASL-SRP was 
recently dropped.  What is the problem?


Patents.

-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: Status of SRP

2006-06-01 Thread Joseph Ashwood
- Original Message - 
From: James A. Donald [EMAIL PROTECTED]

Subject: Status of SRP


The obvious solution to the phishing crisis is the widespread deployment 
of SRP, but this does not seem to happening.  SASL-SRP was recently 
dropped.  What is the problem?


The problem is that you're attempting to treat the wrong aspect. Yes SRP 
verifies the server, but requiring even more work on the part of the client 
will not solve the problem. Attempting to use SRP to solve this problem is 
basically saying You must be this smart to be worth protecting.
   Joe 



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


Re: Status of SRP

2006-06-01 Thread Florian Weimer
* James A. Donald:

 The obvious solution to the phishing crisis is the widespread
 deployment of SRP, but this does not seem to happening.  SASL-SRP was
 recently dropped.  What is the problem?

There is no way to force an end user to enter a password only over
SRP.  That's why SRP is not effective against phishing (even the
mimicry variant).  In that regard, the password input field was a huge
mistake.  Fortunately, it doesn't matter because today, we must assume
that the client is thoroughly compromised, which means that entering
passwords over SRP isn't safe, either.

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


Re: Status of SRP

2006-06-01 Thread James A. Donald

--
Ka-Ping Yee wrote:
 Phishing can mean a few different things.  If by
 phishing you mean the stealing of passwords, then
 yes, SRP would help to eliminate that problem, but
 users could still be fooled into giving away their SRP
 passwords if the user interface for entering the
 password is convincingly imitated.

SRP necessarily runs in the chrome, in the client
software, not in the web page, therefore the chrome,
should put up an image that cannot be convincingly
imitated by html - for example, on windows, a non
rectangular login page, as with paradox's keygen, or as
with the infocard software, taking over the entire
screen, including covering the taskbar, which an html
page cannot do.

In order to imitate that, the attacker would need
control of the client machine

 I'm working on Passpet, a password management tool
 that tries to address several of the big
 phishing-related problems including password capture
 and dictionary attack, and for the authentication part
 i chose SRP.  So that's one place it's getting used,
 anyway.

Cannot find a web page that presents passpet.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 ybM860Mr+CSlXrrR8xph9v0B91GQWJBI8SAGwuFs
 4B8M3YBCebHr5lGeEDBz+TIrbMLygWsXUEGxXWNj5



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


Re: Status of SRP

2006-06-01 Thread James A. Donald

--
James A. Donald wrote:
  The obvious solution to the phishing crisis is the
  widespread deployment of SRP

Lance James
 I disagree here, I don't think this will stop phishing
 for many reasons. Please explain how it would. It will
 stop man-in-the-middle attacks on the protocol, but
 phishers aren't attacking the protocols themselves.

To be useful, SRP has to be in the browser chrome.

Consider a typical e-gold phish
: : You have just made a request to transfer all
: : the funds in your account.  Please click here
: : www.e-golb.com/cancel and login to cancel
: : this request if it was made by someone other
: : than yourself

Assume e-gold was using SRP login.  The user would
attempt to login to www.e-golb.com through SRP, and the
login would fail.

 It's still single-auth and I can still obtain the user
 password via phishing.

How?

SRP never reveals the login.  It is zero knowledge.
Instead, both parties prove to each other than they know
the secret, without revealing the secret.

The only way you can phish the user is to get him to not
use SRP.  But if he is attempting to use SRP he is not
typing the password into a web page, but into client
software running on his own machine, which is going to
look visibly different from any web page.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 bhZzlPU6DtnwH9s5+PxwPlwhgvD/8iFEI9LcuRXA
 4x54cCglld16xbMxUa/22CBHVIxtb7yqM78rQ9Ul1

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


Re: Status of SRP

2006-06-01 Thread James A. Donald

--
Florian Weimer wrote:
 There is no way to force an end user to enter a
 password only over SRP.

Phishing relies on the login page looking familiar.  If
SRP is in the browser chrome, and looks strikingly
different from any web page, the login page will not
look familiar.

 Fortunately, it doesn't matter because today, we must
 assume that the client is thoroughly compromised,
 which means that entering passwords over SRP isn't
 safe, either.

That is an all purpose argument that is deployed
selectively against some measures and not others.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 FngUFki/IKrJQzXmzcNmvTTH5ZAwHCQkTSIXkWVI
 4wPX3iZ25iE0SC3Pk6sdr5enUTiKLhPd829ew/9kX

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


Re: Status of SRP

2006-06-01 Thread Ka-Ping Yee
On Thu, 1 Jun 2006, James A. Donald wrote:
 SRP necessarily runs in the chrome, in the client
 software, not in the web page, therefore the chrome,
 should put up an image that cannot be convincingly
 imitated by html

Sure, i agree.  I only brought this up to point out that SRP
alone doesn't solve the problem; it remains an open question how
to best design a password entry field that defeats spoofing.  You
mentioned several techniques, and there are others, and so far we
don't know what works best for most users.

Passpet's strategy is to customize a button that you click.  We
are used to recognizing toolbar buttons by their appearance, so
it seems plausible that if the button has a custom per-user icon,
users are unlikely to click on a spoofed button with the wrong
icon.  Unlike other schemes, such as special-looking windows or
a custom image shown with the login form, this strategy requires
the user to directly interact with the customized UI element.

The effectiveness of Passpet's approach is only hypothesized; it
has never been formally tested, so i can't claim it works better.

 Cannot find a web page that presents passpet.

See http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/
for the original description of the ideas.  The design of Passpet
is a bit more refined now and will be published at SOUPS 2006.


-- ?!ng

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