Re: data rape once more, with feeling.

2008-10-27 Thread John Gilmore
Usability research about how to track web users?  How Google-like.
Can't you just dump a 25-year cookie on them from twelve different 
directions, and be done with it?

 Federated Login has been a holy grail in the identity community
 for a long time.  We have known how to do the technical part for a
 long time.  However the industry has constantly tried, and failed,
 to find a model that was (1) simple for end users, and (2) had a
 reasonable trust model between the RP (the relying party, which is
 the site you want to log into) and the IDP (the identity provider,
 who will identify you to the RP).

Explicitly ignoring the trust model between the end users and the RP,
and the trust between the end users and the IDP.  Why should end users
trust your web site?  Why should they trust an IDP like Google?

It's not that every website that requires a login is a privacy swamp.
But the big ones pretty much all are, and those are the ones who want
to impose this new model without bothering the end user's little head
about whether he should trust them.

And if every little wiki that just uses logins to slightly limit spam
today, began using federated identity, then ALL of them would become
privacy swamps.

 For example, the site might require users to agree to a Terms of Service.

Let's see an example of how you're automating how the USER might
require the SITE to agree to a Terms of Service.  Doesn't seem to be
part of the model, which is that the SITE has something valuable it
needs lawyers to protect, while the USER is just an
eyeball-with-attached-wallet to be sold to the highest bidder.

 When users are presented with a traditional signup page that asks
 for E-mail, password,  password confirmation, it is quite common
 for 30-50% of users to not finish the process.

I wonder why not!  Perhaps they do not want to be tracked, numbered,
wiretapped, monitored, herded, logged, datamined, folded, spindled,
and mutilated.  Perhaps they just want to look at a web site without
tying their reading habits to their social security number and
their medical records.

Similar percentages describe how many people lie through their teeth
to get into random websites.  So half won't even login, half of those
will lie like hell; a quarter of the people either think you're
trustworthy, or are too stupid to care.  Which fraction is federated
identity aimed at?  Catching the liars, i.e. fencing in the people
who actually take care to protect their privacy?  Yeah, those are
the guys this community wants you to screw as hard as you can. :-(

 In this scenario, buy.com could detect that the domain name is for
 an IDP that it trusts.  It could then redirect the user to AOL to
 verify their identity.  Assuming the user approves sharing their
 identity, then the user will be redirected back to buy.com which can
 automatically create an account for them, and log them in.

That's an interesting assumption.  Why would you assume that AOL would
give users the choice?  AOL is not famous for choice.  Wouldn't AOL
just read the user's 25-year AOL cookie, and redirect the browser back
to buy.com with full account information supplied, without any
interaction with the user at all?  AOL could probably even charge the
RP a few bucks for doing so.  How simple.  How evil.  Franchising your
privacy violations.

 The RP can control what IDPs it trusts, and even switch their users
 back to legacy logins if the IDP becomes untrustworthy

You can pretty well guarantee that RP websites will somehow decline to
trust any IDP that provides privacy to the end user -- like
mailinator.com, for example.  A few web sites that send you an email
to verify you are who you say you are already blacklist mailinator,
though it's usually easy to bypass the blacklist by using one of its
alternative domain names.

John

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


Re: once more, with feeling.

2008-10-24 Thread Ben Laurie
Peter Gutmann wrote:
 If this had been done in the beginning, before users -- and web site
 designers, and browser vendors -- were mistrained, it might have worked.
 Now, though?  I'm skeptical.
 
 For existing apps with habituated users, so am I.  So how about the following
 strawman: Take an existing browser (say Firefox), brand it as some special-
 case secure online banking browser, and use the new developments solution
 above, i.e. it only talks mutual-auth challenge-response crypto and nothing
 else.  At that point you've reduced Reformat user and reinstall browsing
 habits to Train users to only use safe-browser when they do their banking,
 i.e. 'Never enter banking details using anything other than safe-browser'.
 Even if you only get a subset of users doing this, it's still a massive attack
 surface reduction because you've raised the bar from any idiot who buys a
 phishing kit to having to perform a man-in-the-browser attack.

We've been debating this a lot at Google lately. One argument that I
have increasing sympathy with is that SSO (or if you want to be modern,
federated login) provides an opportunity to change the playing field
sufficiently that we can reprogram users to be less vulnerable to
phishing - or just switch them to protocols that make phishing irrelevant.

To that end, we've released some usability research...

http://google-code-updates.blogspot.com/2008/09/usability-research-on-federated-login.html

Obviously the end game here is that the user only has to protect his
login to a small number of sites - i.e. those that provide the IdP. Once
we get there, perhaps users can be persuaded to authenticate to those
sites using something stronger than username/password.

A sidenote that provides me with some amusement: although the modern
trend is towards using OpenID, no-one wants to use it in the mode it is
designed for, i.e. where the user can pick any old IdP and the RP will
just trust it. In practice where we seem to be headed is that RPs will
trust some smallish number of trusted IdPs. This is, of course, exactly
what the Liberty guys have been working on all along. I predict that
over time, most of the elements of Liberty will be incorporated into OpenID.

Which makes me think that if Liberty had done what it claimed to be
doing when it started, i.e. be a community-based, open-source-friendly
protocol suite, it would have worked much better.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

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

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


Re: once more, with feeling.

2008-10-24 Thread Tom Scavo
On Sun, Oct 12, 2008 at 7:39 AM, Ben Laurie [EMAIL PROTECTED] wrote:

 One argument that I
 have increasing sympathy with is that SSO (or if you want to be modern,
 federated login)

Federated identity is the fancy modern term for cross-domain SSO.

 Obviously the end game here is that the user only has to protect his
 login to a small number of sites - i.e. those that provide the IdP. Once
 we get there, perhaps users can be persuaded to authenticate to those
 sites using something stronger than username/password.

I think this is putting the cart before the horse.  Today I don't see
many IdPs (OpenID, SAML, or otherwise) that support more than
username/password.  Until that happens, the relying party will
continue to maintain its own username/passwords since there's little
incentive to federate.

 A sidenote that provides me with some amusement: although the modern
 trend is towards using OpenID, no-one wants to use it in the mode it is
 designed for, i.e. where the user can pick any old IdP and the RP will
 just trust it. In practice where we seem to be headed is that RPs will
 trust some smallish number of trusted IdPs. This is, of course, exactly
 what the Liberty guys have been working on all along. I predict that
 over time, most of the elements of Liberty will be incorporated into OpenID.

I mostly agree with this observation, but I'd replace the word
Liberty with SAML throughout the above paragraph.  The Liberty
Identity Federation Framework (ID-FF) was donated to the OASIS
Security Services Technical Committee in late 2003.  This gave rise to
SAML V2.0 in March 2005.  For all practical purposes, Liberty ID-FF is
dead.

If RPs end up trusting a small number of IdPs, then there is much to
be gained (obviously) by being one of those IdPs.  Thus there are
strong forces at work to *prevent* federated identity from taking hold
since everyone is competing to be one of those IdPs.  I wonder what it
will take to break the log-jam that holds back the anticipated rise of
federated identity?

 Which makes me think that if Liberty had done what it claimed to be
 doing when it started, i.e. be a community-based, open-source-friendly
 protocol suite, it would have worked much better.

I'm not sure I follow that line of reasoning.  Are you referring to
Liberty the specification or Liberty the implementation?  In any
event, it is better to talk about SAML, not Liberty, since the latter
is history with respect to browser-based federated identity.

I agree with you that the goal is to replace username/password with
something stronger, but evidently neither OpenID nor SAML are helping
us get there.  I still have some hope that information cards will make
a dent in this problem, but who knows.

Tom

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


Re: once more, with feeling.

2008-09-24 Thread D. K. Smetters



Peter Gutmann wrote:


For existing apps with habituated users, so am I.  So how about the following
strawman: Take an existing browser (say Firefox), brand it as some special-
case secure online banking browser, and use the new developments solution
above, i.e. it only talks mutual-auth challenge-response crypto and nothing
else.  At that point you've reduced Reformat user and reinstall browsing
habits to Train users to only use safe-browser when they do their banking,
i.e. 'Never enter banking details using anything other than safe-browser'.
Even if you only get a subset of users doing this, it's still a massive attack
surface reduction because you've raised the bar from any idiot who buys a
phishing kit to having to perform a man-in-the-browser attack.



We did a version of this for CEAS this year (paper here:
http://www.parc.com/research/publications/details.php?id=6496).

I agree, I think it's not hard to come up with an 
architecture that increases user security, while reducing 
the amount they have to learn. Though, as per Perry's 
comment, you do need to be able to say that *some* (not 
all) of the software on your machine is not totally 
borked... (an interesting question is: how much, and what).

--Diana

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


Re: once more, with feeling.

2008-09-24 Thread Peter Gutmann
Combining several replies into one...

Nicolas Williams [EMAIL PROTECTED] writes:
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote:
 The major obstacle is that the government would want a strong binding
 between sim cards and true names, which is no more practical than a
 strong binding between physical keys and true names.

I've a hard time believing that this is the major obstacle.
[...]
First, there's a business model problem.  Every one wants in: the cell phone
manufacturer, the software developer, the network operators, and the banks.
With everyone wanting a cut of every transaction done through cell phones the
result would likely be too expensive to compete with credit cards, even after
accounting for the cost of credit card fraud.

In my experience that's the brontosaurus in the room.  There are vendors out
there that'll do cellphone auth (basic SMS-based out-of-band transaction
authorisation), the technology's in place, the problem is that once everyone
has taken their cut it's no longer economical.  To some extent the technology
still sucks quite a bit (e.g. RSA's SMS-based system takes the bank-side
information Request authorisation for transfer of $10,000 from your bank
account to the bank account of J.Random Retailer and turns it into Enter the
following PIN to unlock all further debits from your account until it's
empty), but we're getting there.

The killer is the cost involved.  Access to the mobile networks is expensive
enough that I've seen solutions in some countries like buying SMS capacity in
bulk from foreign providers (it's cheaper to send the texts from a provider on
the other side of the world than to do it locally) to the extreme step of
setting up (or perhaps buying up) your own cellular network.

James A. Donald [EMAIL PROTECTED] writes:

There is always the give-your-password-over-the-phone attack, but the fact
that phishers seeking WoW gold actually have to use the give-your-password-
over-the-phone attack against WoW players shows the potency of a deliberately
non standard, difficult to forge, user interface.

Can you describe the WoW interface?  It sounds like they've taken advantage of
the greenfields approach and built something different that's secure from the
start, but I'm not familiar with how it works.

We need a similarly concise yet precise statement of what is wrong with the
sort of things we are now doing - a list of principles of cryptography that
working systems exemplify, and failed systems violate.

It's already been done, in situation-specific ways:

Marcus Ranum's Six Dumbest Ideas in Computer Security,
http://www.ranum.com/security/computer_security/editorials/dumb/index.html

Microsoft/Scott Culp's Ten Immutable Laws of Security,
http://technet.microsoft.com/en-us/library/cc722487.aspx

My own Ten Inescapable Truths of Security UI,
http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf (last three slides)

IanG [EMAIL PROTECTED] writes:

I think if there is a lot of money in it, there are some innovative solutions
to making the obvious advice easier.  I particularly like the Dutch central
bank's approach here:

https://financialcryptography.com/mt/archives/001059.html

... if you can stand the clickfest that's required to get there with FF3
(sigh).

Peter.

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


Re: once more, with feeling.

2008-09-23 Thread Peter Gutmann
Leichter, Jerry [EMAIL PROTECTED] writes:

The sitation today is (a) the decreasing usefulness of passwords - those
anyone has a chance of remembering are just to guessable in the face of the
kinds of massive intelligent brute force that's possible today and (b) the
inherently insecure password entry mechanisms that we've trained people to
use.

It's actually not that bad, we have some really good password managers that
can take care of this for us, alongside quite a bit of research from HCI
people that examine their effectiveness.  By password manager I mean one
that generates a strong password for you and supplies it as required, not the
noddy managers built into things like web browsers, look at something like
Roboform for an example of what I mean.  The problem is that I don't know of
any application that natively uses them, there are between half a dozen and a
dozen Firefox plugins and third-party apps (it varies over time) that all
provide enhanced password-handling capabilities but the browser itself still
has the incredibly clunky 1.0 manager that it's always had (not specifically
picking on FF here, all the others are just as bad, the difference is that FF
has a pile of functioning plugins and usability research that demonstrate how
to get it right).

The problem isn't with passwords, it's with developers: Passwords are insecure
because developers have chosen to make them insecure.  We have mechanisms to
address a lot of the problems with passwords but no-one ever uses them.  Even
suggesting some of these things is hard ehough, the response to What about
using security measure X which addresses problem Y isn't to use measure X but
to find some obscure corner case where X won't work, declare the problem
unsolveable, and keep on doing the same thing that already didn't work the
last 100 times we tried it.

Peter.

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


Re: once more, with feeling.

2008-09-23 Thread James A. Donald

Leichter, Jerry wrote:

The problem is what that something else should be.  Keyfobs with
one-time passwords are a good solution from the pure security point
of view, but (a) people find them annoying; (b) when used with
existing input mechanisms, as they pretty much universally are, are
subject to MITM attacks.  The equivalent technology on a USB plugin
is much easier on the user in some circumstances, but is subject to
some bad semantic attacks, as discussed here previously.  Also, it's
not a great solution for mobile devices.

DoD/government uses smartcards, but that's probably not acceptable to
the broad population.  There's been some playing around with cellphones
playing the role of smartcard, but cellphones are not inherently secure
either. 



Cellphones are not inherently secure, but *could* be inherently secure. 
 Each cellphone sim card has a unique identity.  It is possible to 
guarantee that a message goes to or from a cellphone containing a 
particular sim card - but present phone software provides no means to do 
this.


If a cellphones has nfc communications capable of talking to a pc, then 
the whole interaction could be made painlessly automatic - touch your 
cellphone to the pc nfc sensor to login to the website, touch it to the 
security door to unlock the security door, touch it to the cash 
register, observe the indicated payment on the cellphone screen, and 
press OK, touch it to the screenless, keyboardless atm, and the 
interaction comes up on your phone screen instead of the ATM screen, 
touch cellphones to pay money from one individual to another.


The major obstacle is that the government would want a strong binding 
between sim cards and true names, which is no more practical than a 
strong binding between physical keys and true names.


Absent useful cellphone software, passwords must suffice.  With a limit 
on the number of guesses before people get locked out, passwords *do* 
suffice - but then we need a means to unlock the account, and a means of 
password recovery.


Although cellphones and email are insecure, a use once short lived 
password emailed or instant messaged to the user is secure enough. 
Trouble is, what happens if the user's email account is stolen?


I had this problem.  I was using my hotmail account as the password 
recovery account for various high value domain names.  Someone called up 
hotmail's password recovery, and human engineered a password reset out 
of the hotmail staff, and then used email based password recovery to 
seize my domain names.  I eventually got them back, using reset 
passwords snail mailed to my physical post office box, and now  the 
email account associated with my domain names is at a service that 
provides no password recovery mechanism - and therefore provides an 
attacker with a very large number of opportunities to guess, requiring 
an insanely strong password.


Snail mail to a post office box is a secure password reset mechanism, 
short of a well timed physical attack on the post office.


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


Re: once more, with feeling.

2008-09-23 Thread James A. Donald

Peter Gutmann wrote:

The problem is that the default has always been to be insecure, and there's no
effective way to get people to move to the secure non-default, or at least
none that isn't relatively easily circumvented by a bit of creative thinking
and/or social engineering. 


If the user is used to logging in by a user interface that is not easy 
for forge remotely - click on bookmark to bring up a user interface that 
is difficult to remotely forge - then this does indeed work.


There is always the give-your-password-over-the-phone attack, but the 
fact that phishers seeking WoW gold actually have to use the 
give-your-password-over-the-phone attack against WoW players shows the 
potency of a deliberately non standard, difficult to forge, user interface.


WoW security does not stop phishing, but it makes phishers work for 
their money. WoW keeps telling users never give your password to 
another person, no one at WoW will ever ask you for your password. 
Obvious advice, easy to understand and follow.




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


Re: once more, with feeling.

2008-09-23 Thread Nicolas Williams
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote:
 The major obstacle is that the government would want a strong binding 
 between sim cards and true names, which is no more practical than a 
 strong binding between physical keys and true names.

I've a hard time believing that this is the major obstacle.  We all use
credit cards all the time -- apparently that's as good a strong binding
between [credit] cards and true names and as the government needs.  (If
not then throw in cameras at many intersections and along freeways, add
in license plate OCR, and you can tie things together easily enough.
Wasn't that a worry in another recent thread here?)

More likely there are other problems.

First, there's a business model problem.  Every one wants in: the cell
phone manufacturer, the software developer, the network operators, and
the banks.  With everyone wanting a cut of every transaction done
through cell phones the result would likely be too expensive to compete
with credit cards, even after accounting for the cost of credit card
fraud.  Credit card fraud and online security, in any case, are pretty
low on the list of banking troubles these past few weeks, and not
without reason!

Second, there's going to be standard issues.

Third the nfc technology has to be commoditized.

Fourth there's cost of doing an initial rollout of the POS nfc
terminals and building momentum for the product.  Once momentum is there
you're done.  And there's risk too -- if you fail you lose your
investment.

...

 Trouble is, what happens if the user's email account is stolen?

Touble is: what happens if the user's cell phone is stolen?

Nico
-- 

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


Re: once more, with feeling.

2008-09-23 Thread Perry E. Metzger

James A. Donald [EMAIL PROTECTED] writes:
 If the user is used to logging in by a user interface that is not easy
 for forge remotely - click on bookmark to bring up a user interface
 that is difficult to remotely forge - then this does indeed work.

It might have been secure enough back in the days before almost every
machine was infected by things like drive-by malware. Now that the
hardware the user is on can no longer be trusted, this would only
raise the bar slightly, and cause the bad guys, who already own half
the machines on the net, to work a few more hours.

I won't say such a thing would be bad if it already existed, but it
seems like it would no longer be enough.

Perry

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


Re: once more, with feeling.

2008-09-22 Thread Leichter, Jerry
On Sun, 21 Sep 2008, Eric Rescorla wrote:
|   - Use TLS-PSK, which performs mutual auth of client and server
|   without ever communicating the password
|  Once upon a time, this would have been possible, I think.  Today,
|  though, the problem is the user entering their key in a box that is
|  (a) not remotely forgeable by a web site that isn't using the
|  browser's TLS-PSK mechanism; and (b) will *always* be recognized by
|  users, even dumb ones.  Today, sites want *pretty* login screens,
|  with *friendly* ways to recover your (or Palin's) password, and not
|  just generic grey boxes.  Then imagine the phishing page that
|  displays an artistic but purely imaginary login screen, with a
|  message about NEW!  Better naviation on our login page!
| 
| This is precisely the issue.
| 
| There are any number of cryptographic techniques that would allow
| clients and servers to authenticate to each other in a phishing
| resistant fashion, but they all depend on ensuring that the
| *client* has access to the password and that the attacker can't
| convince the user to type their password into some dialog
| that the attacker controls. That's the challenging technical
| issue, but it's UI, not cryptographic.
The sitation today is (a) the decreasing usefulness of passwords -
those anyone has a chance of remembering are just to guessable in the
face of the kinds of massive intelligent brute force that's possible
today and (b) the inherently insecure password entry mechanisms that
we've trained people to use.  Perhaps the only solution is to attack
both problems at the same time:  Replace passwords with something
else, and use a different, more secure input mechanism at the same
time.

The problem is what that something else should be.  Keyfobs with
one-time passwords are a good solution from the pure security point
of view, but (a) people find them annoying; (b) when used with
existing input mechanisms, as they pretty much universally are, are
subject to MITM attacks.  The equivalent technology on a USB plugin
is much easier on the user in some circumstances, but is subject to
some bad semantic attacks, as discussed here previously.  Also, it's
not a great solution for mobile devices.

DoD/government uses smartcards, but that's probably not acceptable to
the broad population.  There's been some playing around with cellphones
playing the role of smartcard, but cellphones are not inherently secure
either.  There's also the related problem of scalability to multiple
providers:  I only need one DoD card, which might be acceptable, but if
every secure web site wants to give me their own, I have a problem.  Of
course, various federated identity standards are already battling it
out, but uptake seems limited.  Besides, that can only be one element of
the solution - if I use a traditional password to get to my federated
identity token, I've made the old problem much worse, not better.

Some laptops and keyboards and even encrypted USB memory sticks are
getting fingerprint scanners as standard hardware.  *If* these
actually work as advertised - not a good bet, based on history so
far - these could be an interesting input mechanism.  Since there
are no expectations today that the fingerprint data will be
available to any web site that asks, one could perhaps establish
a standard for controlling this in an appropriate way, with a
built-in, unforgeable display.  With microphones and, increasingly,
cameras as widely-available components, one might define a similar
special input mode around them and look to voice or face recognition.

Or maybe we could even leverage the increasing interest in special
outside-the-main-OS basic displays one sees on laptops.  (I'm sure it
just thrills Microsoft to see Dell putting a tiny Linux implementation
in each laptop)

These are all just possibilities, and whether any of them (or some other
approach) actually gains broad acceptance is, of course, totally up in
the air.  Right now, while in the aggregate the problems with ID theft
are bad and getting worse, relatively few individuals feel the pain,
nor is there much in the way to offer them.  Until one or the other
of these changes - and most likely, both - the old password in some
window or another model will likely stick around.

-- Jerry

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


Re: once more, with feeling.

2008-09-21 Thread Steven M. Bellovin
On Thu, 18 Sep 2008 17:18:00 +1200
[EMAIL PROTECTED] (Peter Gutmann) wrote:

 - Use TLS-PSK, which performs mutual auth of client and server
 without ever communicating the password.  This vastly complicated
 phishing since the phisher has to prove advance knowledge of your
 credentials in order to obtain your credentials (there are a pile of
 nitpicks that people will come up with for this, I can send you a
 link to a longer writeup that addresses them if you insist, I just
 don't want to type in pages of stuff here).
 
Once upon a time, this would have been possible, I think.  Today,
though, the problem is the user entering their key in a box that is (a)
not remotely forgeable by a web site that isn't using the browser's
TLS-PSK mechanism; and (b) will *always* be recognized by users, even
dumb ones.  Today, sites want *pretty* login screens, with *friendly*
ways to recover your (or Palin's) password, and not just generic grey
boxes.  Then imagine the phishing page that displays an artistic but
purely imaginary login screen, with a message about NEW!  Better
naviation on our login page!

If this had been done in the beginning, before users -- and web site
designers, and browser vendors -- were mistrained, it might have
worked.  Now, though?  I'm skeptical.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

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


Re: once more, with feeling.

2008-09-21 Thread Eric Rescorla
At Sat, 20 Sep 2008 15:55:12 -0400,
Steven M. Bellovin wrote:
 
 On Thu, 18 Sep 2008 17:18:00 +1200
 [EMAIL PROTECTED] (Peter Gutmann) wrote:
 
  - Use TLS-PSK, which performs mutual auth of client and server
  without ever communicating the password.  This vastly complicated
  phishing since the phisher has to prove advance knowledge of your
  credentials in order to obtain your credentials (there are a pile of
  nitpicks that people will come up with for this, I can send you a
  link to a longer writeup that addresses them if you insist, I just
  don't want to type in pages of stuff here).
  
 Once upon a time, this would have been possible, I think.  Today,
 though, the problem is the user entering their key in a box that is (a)
 not remotely forgeable by a web site that isn't using the browser's
 TLS-PSK mechanism; and (b) will *always* be recognized by users, even
 dumb ones.  Today, sites want *pretty* login screens, with *friendly*
 ways to recover your (or Palin's) password, and not just generic grey
 boxes.  Then imagine the phishing page that displays an artistic but
 purely imaginary login screen, with a message about NEW!  Better
 naviation on our login page!

This is precisely the issue.

There are any number of cryptographic techniques that would allow
clients and servers to authenticate to each other in a phishing
resistant fashion, but they all depend on ensuring that the
*client* has access to the password and that the attacker can't
convince the user to type their password into some dialog
that the attacker controls. That's the challenging technical
issue, but it's UI, not cryptographic.

-Ekr

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


Re: once more, with feeling.

2008-09-19 Thread Peter Gutmann
IanG [EMAIL PROTECTED] writes:

Any evidence of that?  [People buying certs using stolen credit cards]

I don't know if anyone tracks the exact count (apart from the 2005 figure of
(at least) 450 recorded incidents of secure phishing) but every now and then
you get reports of particular ones that stand out, e.g. the Sunbelt discussion
of the Gromozon distributors signing their malware,
http://www.haloscan.com/comments/alexeck/6460991926610320702/ (the cert
purchase was eventually traced back to a victim in Florida)... sorry, I don't
catalogue them all, just watch them drift by every now and then and that one
came to mind.  In fact didn't our esteemed moderator mention running into one
of these via spammed email just a few months back?

In any case with the assistance of services like http://scanlab.name/ for the
ID and any one of the incorporation brokers operating in the US (I
particularly like the appropriately-named
http://www.startanamericancompany.com/, you can do it for far less via US
brokers but then if you're paying with soemone else's credit card cost isn't
really an issue) how long do you think it'd take to create an official US
corporation that qualifies for an EV cert?  I think the main reason we haven't
seen more of this is:

- There's no need for it, usability evaluation tests have shown that EV certs
  have no effect on security so there's no point in going to the trouble
  (cybercrooks are cheapskates).

- It's much easier to use an exploit toolkit like MPACK or whatever to hit an
  EV-certified site for a genuine organisation than it is to bother with your
  own EV cert.  Since an EV cert only says that the CA did a little bit more
  than almost no checking at all of credentials but doesn't tell you anything
  about the site, the easiest way to get an EV cert is to use someone else's
  (AV vendors report peaks of up to 10,000 fresh malware infection sites via
  legit compromised servers a day, which is bad news for the only enter your
  credit card details on sites you trust education effort).

Peter.

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


Re: once more, with feeling.

2008-09-18 Thread Peter Gutmann
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:

As to technical options to accomplish this

The mechanisms for this actually already exist, they're just not used.  First
of all, you need to admit that you have a problem: SSL certs by themselves are
more or less useless in providing assurance, the phishers are buying genuine
CA-issued certs for soundalike domains using stolen credit cards just as
easily as legit sites are buying certs for genuine domains, and no amount of
signature checking and CRLs and other PKI paraphernalia will fix that.  As
Matt Blaze once said, A commercial CA will protect you from fraud by anyone
whose money it refuses to accept, which was meant tongue-in-cheek at the time
but given current practice by phishers that's exactly what a commercial CA
will do, and no more.

It's only once developers have accepted this that you can start looking for a
real solution:

- Use TLS-PSK, which performs mutual auth of client and server without ever
  communicating the password.  This vastly complicated phishing since the
  phisher has to prove advance knowledge of your credentials in order to
  obtain your credentials (there are a pile of nitpicks that people will come
  up with for this, I can send you a link to a longer writeup that addresses
  them if you insist, I just don't want to type in pages of stuff here).

- Implement key-continuity at the client, i.e. warn if submitting a password
  or credit card number to a site you've never visited before; display the
  password in cleartext if submitting over a non-SSL connection (this is
  better than any explicit warning); (insert standard list, I have a whole
  pile of these, including responses to objections).

- Use a service like Perspectives,
  http://www.cs.cmu.edu/~perspectives/index.html, to catch here-today-gone-
  tomorrow phishing sites (this is actually a service that someone like Google
  could provide, they crawl the web anyway so keeping track of how long a
  server key's been in use should be a relatively minor change to the existing
  process.  Anyone from Google security reading this list?).

- ... and many more, I won't list them all here.

So it's a two-step process, the first of which is to admit that you have a
problem.  As EV certs have shown, we haven't really even reached that first
step yet.

Peter.

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


Re: once more, with feeling.

2008-09-18 Thread Darren J Moffat

Dirk-Willem van Gulik wrote:

  ... discussion on CA/cert acceptance hurdles in the UI 

I am just wondering if we need a dose of PGP-style reality here.

We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst
they all appear use the same technology - the assurances, UI, operational
regimen, 'investment' and user expectations are way different:

^^^
I seriously doubt that even a single digit percentage of end users out 
on the internet know anything about the different types of certificates 
used in SSL/TLS and what they mean.   I know none of my family (other 
than my wife: but given she worked for a large CA doing authentication 
and verification) knows what SSL really means never mind what the 
different types of cert are supposed to indicate and what to do about 
them, yet they buy stuff on the internet.  It doesn't mean they are 
ignorant it is just the normal case.



So my take is that it is pretty much impossible to get the UI to do
the right thing - until it has this information* - and even then
you have a fair chunk of education left to do :). 


Even if you got the UI to do the right thing it still doesn't mean 
anything real about trust all it really means is how much money was 
invested in getting the cert and setting up the correct information 
about the company identity behind it.



--
Darren J Moffat

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


Re: once more, with feeling.

2008-09-17 Thread Dirk-Willem van Gulik

 ... discussion on CA/cert acceptance hurdles in the UI 

I am just wondering if we need a dose of PGP-style reality here.

We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst
they all appear use the same technology - the assurances, UI,  
operational

regimen, 'investment' and user expectations are way different:

A)  Symbolic Locks (think bicycle locks in Amsterdam, or the little
plastic luggage locks people use) - just a bit of reassurance
that snooping is not trivial.

= so you'd just want your browser to indicate something about
SSL, just like you causally mention mime-type or port-number.

B)  Some sort of assurance that you are talking to whom you think you
are talking to - and that such is the case next time round. And
in a grown up sort of way - but no need to go the investment
to have some paid minder reassuring you that there is no
monster under the bed. E.g. some privacy, say on an online forum.

= so in this case you'd probably want a near friction less
or perhaps even invisible initial persistent accept and
some sort of low-key warning if the cert or chain changed
over time beyond some range.

C)  Fair assurance that you are talking with whom you think
you are talking to - is really that entity - and some
trust. E.g. the canonical credit card payment case.

= behaviour as we have today.

D)  Proper TLS; where both each end of the connection has a well
defined idea of the reliability. E.g. the authenticate
properly with an x509 to a server with a cert against
an explicit list of CA's which are carefully selected
by the 'powers that be' and with full CRLs.

Unfortunately there is currently no way for the server to indicate any
of this; or the user to indicate what his or her expectations are.

So my take is that it is pretty much impossible to get the UI to do
the right thing - until it has this information* - and even then
you have a fair chunk of education left to do :).

But without it - the entire discussion is moot.

As to technical options to accomplish this - it would not be hard
to *_socialise_* a few small technical hints: i.e if it is a
straight  self-signed server, certificate, with minimal data - assume
A; case C is easy; and in case 'D' one would care enough to have
a proper set-up.

That just leaves case B - and distinguishing it from a failed C.  And
that is hard. Especially as a messy B should not compromise a C.

So I guess that needs some very clear marker from the site owner. Which
could be as simple as insisting on things like an funky DN, a CN with
the FQDN set to something like 'ad-hoc', a concept that a certificate
with just a CN, but no other O, OU, L or C fields.

And obviously one could try to boil the ocean; write a small RFC
detailing some OID to put in the certificate for case A  B :) - and
include the fewlines of openssl in the document to make your own
'B' certificate.

Key would not be the technical aspect - but socialising it with enough
webmaster folks** that there is enough of a mass to tempt them
browser boys. And that is the going to be the very hard part :)


Dw

*)  I strongly think that the current plug-ins which check if a
certificates fingerprint is the same from multiple vantage
points around the internet is really quite orthogonal to this
issue. So no solace there.

**) And capitalise on the fact that they need to recreate their  
certificates

as most folks seem to stick to the default 365 days.

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


Re: once more, with feeling.

2008-09-11 Thread Peter Gutmann
James A. Donald [EMAIL PROTECTED] writes:

Visualize Obama, McCain, or Sarah Palin setting up your network security.
Then realize that whoever they appoint as Czar in charge of network security
is likely to be less competent than they are.

You're think about this from the wrong angle.  We don't need to legislate
network security because, as you say, we'll never get a workable law, and even
if we did we really have no idea how to build secure systems that users would
actually want to use (although there are some good hypotheses out there).

What we need is real-world controls (that have nothing to do with computers)
to rein in the free hand that computerisation has given to attackers.  Credit
freezes are the first step, although even then it's been a massive battle and
most likely Congress will eventually pass a law that neutralises the various
state laws, as it has for numerous other laws in the past (and even some of
the state laws have been watered down with thaw provisions that take you
right back to square one).

Some examples that come to mind immediately for fighting phishing:

- Credit freezes that are real freezes, and require a physical bank visit with
ID to thaw.

- COB and credit-limit-increase freezes that require physical presence to
change (the first thing phishers do when they get your CC info is to wind the
credit limit up to max and change the billing address).  The once a blue moon
that you might want to change these details it's really not to hard to drop by
a bank for a minute or two to authorise things.

- Ability to specify floor limits for spending independent of the credit
limit, e.g. with a credit limit of $10K you can't spend more than $2K
domestically and $1K internationally.

I think that should give you a general idea of where this is going.  At the
moment the banks' fraud-guessing systems are really just that, guessing
systems, and from numerous reports and assorted anecdotal evidence they're not
very effective.  The user holds the position of the interior, they know
better than any guessing system what's appropriate and what isn't for their
financial transactions.  The rampant exploitation of the banking system by
crooks works because all of the above are totally uncontrolled, and banks have
no interest in controlling them.  That's what we need legislation for, not to
require two-factor-authentication-that-isn't and other gimmicks but to get the
banks and credit-reporting agencies to install effective internal controls.

Peter.

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


Re: once more, with feeling.

2008-09-10 Thread Dave Howe
Darren J Moffat wrote:
 Warnings aren't enough in this context [ whey already exists ] the
 only thing that will work is stopping the page being seen - replacing
 it with a clearly worded explanation with *no* way to pass through
 and render the page (okay maybe with a debug build of the browser but
 not in the shipped product).

One thing that concerns me is that in the new release of firefox, there
appears to be NO way to get to a site that has a bad certificate (or
self signed certificate) other than overriding the warning permanently -
no ok let me see it, I have seen the warning and want to look just this
once that the remember mismatched domains plugin for 2.x gave you.

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


Re: once more, with feeling.

2008-09-10 Thread Paul Hoffman

At 11:21 PM +0100 9/9/08, Dave Howe wrote:

Darren J Moffat wrote:

 Warnings aren't enough in this context [ whey already exists ] the
 only thing that will work is stopping the page being seen - replacing
 it with a clearly worded explanation with *no* way to pass through
 and render the page (okay maybe with a debug build of the browser but
 not in the shipped product).


One thing that concerns me is that in the new release of firefox, there
appears to be NO way to get to a site that has a bad certificate (or
self signed certificate) other than overriding the warning permanently -
no ok let me see it, I have seen the warning and want to look just this
once that the remember mismatched domains plugin for 2.x gave you.


That may concern you, but I consider it a feature. Instead of 
teaching users to always click through the damn dialog boxes, FF3 
says if you fell for it once, you're going to always fall for it so 
we won't teach you bad habits. There are arguments for either 
strategy.


Given that few or none of us on this list are actually trained 
interface experts, I'm sure we could debate this until Perry pulls 
the moderator switch again. The salient point is that people who have 
more stake in the game (Mozilla Inc.) have spent longer thinking 
about this than we give them credit for and come to the design 
decisions that they have.


--Paul Hoffman, Director
--VPN Consortium

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


Re: once more, with feeling.

2008-09-10 Thread Joss Wright
Dave Howe wrote:
 
 One thing that concerns me is that in the new release of firefox, there
 appears to be NO way to get to a site that has a bad certificate (or
 self signed certificate) other than overriding the warning permanently -
 no ok let me see it, I have seen the warning and want to look just this
 once that the remember mismatched domains plugin for 2.x gave you.
 

I'm running Firefox 3.0.1 on (Gentoo) Linux and had coincidentally just
gone through this process.

When adding an exception for a site with an invalid security certificate
there is a checkbox at the bottom of the Add Security Exception window
that gives you the option to permanently store the exception. It is
checked by default, but the option not to do so is there (and works!)

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


Re: once more, with feeling.

2008-09-10 Thread William Allen Simpson

James A. Donald wrote:

Peter Gutmann wrote:
Unfortunately I think the only way it (and a pile of other things as 
well) may get stamped out is through a multi-pronged approach that 
includes legislation, and specifically properly thought-out 
requirements 



I agree.   I'm sure this is a world-wide problem, and head-in-the-sand
cyber-libertarianism has long prevented better solutions.  The market
doesn't work for this, as there is a competitive *disadvantage* to
providing improved security, and it's hard to quantify safety.

Remember automotive seat-belts?  Air-bags?  Engineers developed them,
but the industry wouldn't deploy because the market failed to demand
safety.  That is, long-term safety would cut into short-term profits.

The corporate world actually led the public to believe (through
advertising) that they were sufficiently safe without them.  Only
legislation and regulation resulted in measurably greater safety.

M$ has long advertised (falsely) that safety was their concern, and their
systems were already safe.  We all know how that worked out


The average cryptographic expert finds it tricky to set up something 
that is actually secure.  The average bureaucrat could not run a pie 
stand.  Legislation and so forth requires wise and good legislators and 
administrators, which is unlikely.



So, what campaigns are you working on currently to improve this?

I've educated dozens of U.S. legislators over the years  Indeed, the
original funding for my NSFnet work 20 years ago was funded by the Michigan
House Fiscal Agency, and my early IETF work was funded by the Levin (Senate)
and Carr (House) campaigns.


Visualize Obama, McCain, or Sarah Palin setting up your network 
security.  Then realize that whoever they appoint as Czar in charge of 
network security is likely to be less competent than they are.



The problem, as always, is enough folks that are competent in both
computer security *and* political action.

Cannot say much about McCain/Palin, but the Obama folks have been fairly
computer literate from the beginning.  Not always as security conscious as
I'd like, but some seem to be receptive.  Unlike McCain (who needs help to
get his email), Obama himself seems from reports to be tech-savvy.

We either have to educate more political folks about computer security,
or more security folks have to become active in politics.  The former is
the never-ending long-term problem, while the latter is an effective
sort-term solution.

At the IETF, we used to have a t-shirt, with 9 layers instead of 7.  The
top was Political, with you are here next to it.

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


Re: once more, with feeling.

2008-09-10 Thread Perry E. Metzger

[Moderator's note: with my other hat on, let me say that although I'm
a libertarian, I do not want to have this mailing list fill with
libertarianism vs. statism arguments. I'm going to cut this off pretty
quickly. --Perry-as-moderator]

William Allen Simpson [EMAIL PROTECTED] writes:
 I agree.   I'm sure this is a world-wide problem, and head-in-the-sand
 cyber-libertarianism has long prevented better solutions.  The market
 doesn't work for this, as there is a competitive *disadvantage* to
 providing improved security, and it's hard to quantify safety.

I have to disagree, for a wide number of reasons. I'll avoid getting
too deeply into them them here.

 The average cryptographic expert finds it tricky to set up something
 that is actually secure.  The average bureaucrat could not run a pie
 stand.  Legislation and so forth requires wise and good legislators
 and administrators, which is unlikely.

 So, what campaigns are you working on currently to improve this?

 I've educated dozens of U.S. legislators over the years  Indeed,
 the original funding for my NSFnet work 20 years ago was funded by
 the Michigan House Fiscal Agency, and my early IETF work was funded
 by the Levin (Senate) and Carr (House) campaigns.

And yet, in spite of the efforts people make, we still have
significant problems, don't we? It doesn't take great genius to
understand why current spam legislation is flawed, but I haven't seen
it fixed even though you will be hard pressed to find many people who
claim to love spam. We have lots of legislation against various forms
of computer crime and yet we have virtually no prosecutions even
though something like half of the computers in the country have been
broken in to. We also used to have quite reasonable wiretap laws in
this country which were blown out of the water when political
expediency demanded it.

I contend that none of this is an accident, or particularly easy to
change.

 Visualize Obama, McCain, or Sarah Palin setting up your network
 security.  Then realize that whoever they appoint as Czar in charge
 of network security is likely to be less competent than they are.

 The problem, as always, is enough folks that are competent in both
 computer security *and* political action.

I don't see how that is going to change.

One can hope for an ideal, substantially superior world, but generally
speaking human beings have to live with the world that we have, and
most importantly with the behavior patterns of real people.

The core of the libertarian view on this and many other topics is not
that it wouldn't be wonderful if we had perfect legislation enforced
by perfect policemen, but that we must acknowledge that in the real
world we will get the result of a very flawed and problematic
political process which will be enforced humans rather than angels.

On the political process side, large companies with powerful interests
will be immediately involved once the topic of mandatory security
standards comes to the fore. Many of those companies will see
lobbyists as cheaper than IT infrastructure. There will also be those
who see legislation as an opportunity to cash in -- they will try to
twist the laws in such a way as to make a buck, by mandating solutions
they think will profit them. Some people in our profession may even
decide to do what cosmetologists, private investigators and even
doctors have done in the past, and reduce competition by requiring
licensing as a way of preventing others from entering in to their
field. We will also find that the people writing the regulatory
standards may very well be the sort who are not entirely right
minded -- not everyone in this field can even understand why http: is
a bad transport for bank login pages, so we can't expect that everyone
in the field can recognize good regulations.

I suspect the difference between one's aspirations and the output of
this process will be much like the difference between a dog before and
after it falls into a meat grinder. Much of the underlying material
remains, but the parts are no longer arranged into something you would
consider a faithful pet.

On the enforcement side, we will suddenly find ourselves in a
situation where people who are far from the best technically will be
asked to examine extremely complicated computer systems and to decide
whether to penalize firms for failing to properly comply with very
complicated regulations. I will not belabor the point -- having seen
the results of this in much less technical areas, like finance, I must
say that I do not have very high hopes for the outcome of the process.

Again, it is easy to say there ought to be a law!, and it is much
harder to get the right law into place, and even then almost
impossible to get it properly enforced. I have very few hopes for this
path.

Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending 

Re: once more, with feeling.

2008-09-10 Thread Nicolas Williams
On Wed, Sep 10, 2008 at 01:29:32PM -0400, William Allen Simpson wrote:
 I agree.   I'm sure this is a world-wide problem, and head-in-the-sand
 cyber-libertarianism has long prevented better solutions.  The market
 doesn't work for this, as there is a competitive *disadvantage* to
 providing improved security, and it's hard to quantify safety.

Or maybe there's a civil liability law issue that causes the market to
fail in this instance.

Nico
-- 

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


Re: once more, with feeling.

2008-09-10 Thread Dave Howe
Paul Hoffman wrote:
 At 11:21 PM +0100 9/9/08, Dave Howe wrote:
 Darren J Moffat wrote:
  Warnings aren't enough in this context [ whey already exists ] the
  only thing that will work is stopping the page being seen - replacing
  it with a clearly worded explanation with *no* way to pass through
  and render the page (okay maybe with a debug build of the browser but
  not in the shipped product).

 One thing that concerns me is that in the new release of firefox, there
 appears to be NO way to get to a site that has a bad certificate (or
 self signed certificate) other than overriding the warning permanently -
 no ok let me see it, I have seen the warning and want to look just this
 once that the remember mismatched domains plugin for 2.x gave you.
 
 That may concern you, but I consider it a feature. Instead of teaching
 users to always click through the damn dialog boxes, FF3 says if you
 fell for it once, you're going to always fall for it so we won't teach
 you bad habits. There are arguments for either strategy.

True enough, but the clickthru bandits will just see a button that
reads to them make this error go away then next time will forget they
did it - and will take the fact that they went straight into the site to
mean the problem was fixed or simply not remember there ever was a
problem.

In the meantime, a choice I *used to have* is now taken from me, in the
interests of selling more EV certificates.

 Given that few or none of us on this list are actually trained interface
 experts, I'm sure we could debate this until Perry pulls the moderator
 switch again. The salient point is that people who have more stake in
 the game (Mozilla Inc.) have spent longer thinking about this than we
 give them credit for and come to the design decisions that they have.

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


Re: once more, with feeling.

2008-09-09 Thread Cat Okita

On Mon, 8 Sep 2008, Adam Shostack wrote:

What makes now the perfect time to address an issue which has been
present for quite soem time?


I'd turn that question around, and ask what makes now such a bad time to
address an issue that's been present (and not addressed) for quite some
time... ?

Surely the recent DNS fiasco was enough of an illustration of the merits
of not worrying about something that's been a well known issue for ages...

cheers!
==
A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now.

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


Re: once more, with feeling.

2008-09-09 Thread Peter Gutmann
Darren J Moffat [EMAIL PROTECTED] writes:

I believe the only way both of these highly dubious deployment practices will
be stamped out is when the browsers stop allowing users to see such web pages.

Unfortunately I think the only way it (and a pile of other things as well) may 
get stamped out is through a multi-pronged approach that includes legislation, 
and specifically properly thought-out requirements rather than big-business- 
bought legislation like UCITA/UCC or easily-circumvented recommendations like 
the FFIEC ones (the banks quickly discovered that by redefining two-factor 
auth to mean twice as much one-factor auth they could meet the requirements 
without having to do anything to improve security).

I'm saying that under the influence of Zero Day Threat by Byron Acohido and
Jon Swartz, which looks at some of the financial and credit-reporting industry
practices that make identity fraud possible.  If you haven't read this
already, go and get it now, apart from the annoyingly frequent context-
switching between threads (one every few pages instead of the more usual one
per chapter) it's a very scary read.  Given what it reveals about how the US
financial/credit reporting industry works it should really be subtitled We're
all going to die, since there's no obvious handbrake mechanism present in the
system to slow down identity theft - the rate-limiting step is the fact that
the crooks simply can't use all the stolen identities they have, not any
security measures that may be present.  If you don't believe me, visit any of
the hits from the following search:

  http://www.google.com/search?q=fullz+dumps

(that's the easiest way to demo the problem to the masses without requiring
people to learn to read cyrillic first :-).

Yup, we're all going to die.

So that there becomes a directly attributable financial impact to the sites
that deploy in that way.

The financial impact point is the key word, at the moment it's cheaper and
easier for the banks/credit reporting companies to be non-compliant/insecure
than it is for them to be secure.  I'm not sure that the browser is the most
effective way to hit them over this though.

Discuss :-).

Peter.

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


Re: once more, with feeling.

2008-09-09 Thread dan

Peter Gutmann writes, in part:
-+
 | ... - the rate-limiting step is the fact that
 | the crooks simply can't use all the stolen identities
 | they have, not any security measures that may be present.
 | ...


To my knowledge, you are correct.  It seems that the
price of stolen credentials (on the black market) is
falling, which, as with the street price of heroin, would
tend to indicate that the opposition is winning.

I have a slide for this somewhere (not on this machine)
and will dig it up if needed, but the disparity between
actual crime and a naive estimate of the opportunity for
crime seems to be widening.  If correct, then such a
disparity would either indicate that our countermeasures
are winning -or- the predators are leaving prey on the
field.  I'm sadly of the opinion that it is the latter.

In their Internet Security Threat Report, Symantec used
to publish the number of bots detected.  The last one of
those I have at hand showed a leveling out of the number
found de novo per unit interval (per month).  Again, this
permits two interpretations; on the one hand, we are winning
in that we are preventing the problem from worsening while
on the other hand it can be read to mean that as fast as
we remove bots from hosts that other hosts are botted
and, as such, the supply of bots being stable implies
that it is easy enough to replace them that the lost of
an individual host does not slow down our opposition.
What does (in the Symantec graphs) vary is the variance
of in-and-out-flow, but not the fraction that are botted.
This would tend to strengthen the argument that any
periodic sweep of bots off networks is compensated
for relatively quickly.  In public health, widely
varying incidence (new infection rate) but stable
prevalence (infected fraction) tends to indicate
a high degree of infectability and not a particularly
effective immune response.  We see this in a way in
the AIDS data -- every advance in treatability seems
to be followed by increases in risky behavior while
prevalence remains to a degree stable.

This idea of replacement of cured machines by infected
machines seems corroborated in a different way as well.
The opposition seems to have lately decided that the
advantages of stealth outway the advantages of persistence,
which is to say that in-core-only infection is now the
preferred mechanism and not writing to disk so as to
preserve infected status through a reboot cycle.  If
this is correct, then it signals that the opposition
can replace machines lost through reboot easily enough
that the availability of penetrated machines can be
better enhanced through making infections harder to
find (latent, in medical parlance) than through making
a once penetrated machine stay penetrated as to do the
latter you have to expose yourself to periodic clean-up
of that which is persistent (on disk).

For anyone looking ahead, the interaction between this
phenomenon (if it is indeed a phenomenon) and the growing
role of virtual machines should be of intense interest.

Inferentially yours,

--dan

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


Re: once more, with feeling.

2008-09-09 Thread James A. Donald

Peter Gutmann wrote:
Unfortunately I think the only way it (and a pile of other things as well) may 
get stamped out is through a multi-pronged approach that includes legislation, 
and specifically properly thought-out requirements rather than big-business- 
bought legislation like UCITA/UCC or easily-circumvented recommendations like 
the FFIEC ones (the banks quickly discovered that by redefining two-factor 
auth to mean twice as much one-factor auth they could meet the requirements 
without having to do anything to improve security).


The average cryptographic expert finds it tricky to set up something 
that is actually secure.  The average bureaucrat could not run a pie 
stand.  Legislation and so forth requires wise and good legislators and 
administrators, which is unlikely.


Visualize Obama, McCain, or Sarah Palin setting up your network 
security.  Then realize that whoever they appoint as Czar in charge of 
network security is likely to be less competent than they are.




I'm saying that under the influence of Zero Day Threat by Byron Acohido and
Jon Swartz, which looks at some of the financial and credit-reporting industry
practices that make identity fraud possible.  If you haven't read this
already, go and get it now, apart from the annoyingly frequent context-
switching between threads (one every few pages instead of the more usual one
per chapter) it's a very scary read.  Given what it reveals about how the US
financial/credit reporting industry works it should really be subtitled We're
all going to die, since there's no obvious handbrake mechanism present in the
system to slow down identity theft - the rate-limiting step is the fact that
the crooks simply can't use all the stolen identities they have, not any
security measures that may be present.  If you don't believe me, visit any of
the hits from the following search:

  http://www.google.com/search?q=fullz+dumps

(that's the easiest way to demo the problem to the masses without requiring
people to learn to read cyrillic first :-).

Yup, we're all going to die.


So that there becomes a directly attributable financial impact to the sites
that deploy in that way.


The financial impact point is the key word, at the moment it's cheaper and
easier for the banks/credit reporting companies to be non-compliant/insecure
than it is for them to be secure.  I'm not sure that the browser is the most
effective way to hit them over this though.

Discuss :-).

Peter.

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



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


once more, with feeling.

2008-09-08 Thread Perry E. Metzger

I was shocked that several people posted in response to Peter
Gutmann's note about Wachovia, asking (I paraphrase):

What is the problem here? Wachovia's front page is only http
protected, but the login information is posted with https! Surely this
is just fine, isn't it?

I'm not going to explain why this is wrong. It should be obvious. If
it isn't obvious to you, you should try thinking like an attacker for
a few moments. If it still isn't obvious to you why this is very bad,
read the list archives.

(I won't be forwarding followups to this unless they are unusually
interesting.)

Perry
-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: once more, with feeling.

2008-09-08 Thread Darren J Moffat

Perry E. Metzger wrote:

I was shocked that several people posted in response to Peter
Gutmann's note about Wachovia, asking (I paraphrase):

What is the problem here? Wachovia's front page is only http
protected, but the login information is posted with https! Surely this
is just fine, isn't it?


[snip]


(I won't be forwarding followups to this unless they are unusually
interesting.)


Hopefully this is interesting enough to get forwarded on...

Sadly this practice is all too common, and often goes hand in hand with 
the other cardinal sin of https that of mixed http/https pages.


I believe the only way both of these highly dubious deployment practices 
will be stamped out is when the browsers stop allowing users to see such 
web pages. So that there becomes a directly attributable financial 
impact to the sites that deploy in that way.


As much as I like Firefox  Safari [ the only two browsers I use now ] 
this has to be led by Microsoft with Internet Explorer since that will 
have the biggest impact, given IE 8 is in beta this seems like a perfect 
opportunity to get this in as a change for the next version.


Warnings aren't enough in this context [ whey already exists ] the only 
thing that will work is stopping the page being seen - replacing it with 
a clearly worded explanation with *no* way to pass through and render 
the page (okay maybe with a debug build of the browser but not in the 
shipped product).



--
Darren J Moffat

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


Re: once more, with feeling.

2008-09-08 Thread Paul Hoffman

At 4:16 PM +0100 9/8/08, Darren J Moffat wrote:

Hopefully this is interesting enough to get forwarded on...


Ditto. :-)

Warnings aren't enough in this context [ whey already exists ] the 
only thing that will work is stopping the page being seen - 
replacing it with a clearly worded explanation with *no* way to pass 
through and render the page (okay maybe with a debug build of the 
browser but not in the shipped product).


It depends on how we think change can be achieved. Until now, people 
designing pages using bad security practices balanced their laziness 
with the fact that their content would be displayed anyway so 
whatever. You are proposing moving to the other extreme. Given how 
easy your solution would be for browser vendors to implement, we have 
to assume that they have considered it and rejected it.


A less extreme solution would be to make the warning the user sees on 
a mixed-content page more insulting to the bank. This page contains 
both encrypted and non-encrypted content and is inherently insecure. 
The owner of this web site has clearly made a very poor security 
decision in showing this page to you. It is likely that other pages 
on this site also have similarly poor security. Knowing this, do you 
wish to continue anyway?


--Paul Hoffman, Director
--VPN Consortium

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


Re: once more, with feeling.

2008-09-08 Thread Arshad Noor

Paul Hoffman wrote:


A less extreme solution would be to make the warning the user sees on a 
mixed-content page more insulting to the bank. This page contains both 
encrypted and non-encrypted content and is inherently insecure. The 
owner of this web site has clearly made a very poor security decision in 
showing this page to you. It is likely that other pages on this site 
also have similarly poor security. Knowing this, do you wish to continue 
anyway?




A more optimal solution is to have this vulnerability accepted by
the OWASP community as a Top 10 security vulnerability; it will
have the appropriate intended effect since mitigation to the OWASP
defined vulnerabilities is required in PCI-DSS:

6.5 Develop all web applications based on secure coding guidelines
such as the Open Web Application Security Project guidelines

https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
http://www.owasp.org/index.php/Top_10_2007

Arshad Noor
StrongAuth, Inc.

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


Re: once more, with feeling.

2008-09-08 Thread Darren Lasko
Arshad Noor wrote:
 A more optimal solution is to have this vulnerability accepted by
 the OWASP community as a Top 10 security vulnerability; it will
 have the appropriate intended effect since mitigation to the OWASP
 defined vulnerabilities is required in PCI-DSS:
 
 6.5 Develop all web applications based on secure coding guidelines
 such as the Open Web Application Security Project guidelines
 

Isn't this vulnerability already in the Top 10, specifically A7 - Broken 
Authentication and Session Management (
http://www.owasp.org/index.php/Top_10_2007-A7)?

From the Protection section for A7:

Do not allow the login process to start from an unencrypted page. Always 
start the login process from a second, encrypted page with a fresh or new 
session token to prevent credential or session stealing, phishing attacks 
and session fixation attacks.

Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America

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


Re: once more, with feeling.

2008-09-08 Thread Arshad Noor

Darren Lasko wrote:

Arshad Noor wrote:


6.5 Develop all web applications based on secure coding guidelines
such as the Open Web Application Security Project guidelines



Isn't this vulnerability already in the Top 10, specifically A7 - Broken 
Authentication and Session Management (

http://www.owasp.org/index.php/Top_10_2007-A7)?



I was just informed of this 10 minutes ago, privately.

Not sure how I missed this the last time I read the document
(perhaps because I was focusing on remediating an application
related to two other vulnerabilities on a project), but the
bank examiners also apparently missed this for Wachovia.

While login pages are not required to be PCI-DSS compliant
(since they generally do not deal with credit card numbers,
it has been my impression that many companies are adopting
OWASP guidelines for all their web-projects.  Perhaps its
taking time for some more than others.

Arshad Noor
StrongAuth, Inc.

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


Re: once more, with feeling.

2008-09-08 Thread Adam Shostack
On Mon, Sep 08, 2008 at 04:16:46PM +0100, Darren J Moffat wrote:
| 
| I believe the only way both of these highly dubious deployment practices 
| will be stamped out is when the browsers stop allowing users to see such 
| web pages. So that there becomes a directly attributable financial 
| impact to the sites that deploy in that way.
| 
| As much as I like Firefox  Safari [ the only two browsers I use now ] 
| this has to be led by Microsoft with Internet Explorer since that will 
| have the biggest impact, given IE 8 is in beta this seems like a perfect 
| opportunity to get this in as a change for the next version.

Not speaking for my employer here.

Most browser vendors try to display pages as best they can.  Both end
users and businesses get very upset at browser makers who push
security improvements by breaking existing practices.

If such changes were to happen, then they should either be emergency
(seems unlikely, given how long this has been around) or planned and
communicated.  Adding something high impact after beta 2 doesn't seem
like good communication.

What makes now the perfect time to address an issue which has been
present for quite soem time?

Adam

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