Mailing List Archive

On Thu, Jun 21, 2012 at 12:56 PM, Rich Kulawiec <rsk@gsp.org> wrote:
> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:
>
> (on the use of public/private keys)
>
>> The leaks stop immediately.  There's almost no value in a database of
>> public keys, heck if you want one go download a PGP keyring now.
>
> It's a nice thought, but it won't work.   There are two large-scale
> security problems which prevent it from working:
>
> 1. Fully-compromised/hijacked/botted/zombied systems.  Pick your term,
> but any estimate of this population under 100M should be laughed out
> of the room.  Plausible estimates are now in the 200M to 300M range.
> Any private key present on any of those is accessible to The Bad Guys
> whenever they can trouble themselves to grab it.  (Just as they're
> already, quite obviously, grabbing passwords en masse.)
>
> 2. Pre-compromised-at-the-factory smartphones and similar.  There's
> no reason why these can't be preloaded with spyware similar to CarrierIQ
> and directed to upload all newly-created private keys to a central
> collection point.  This can be done, therefore it will be done, and when
> some security researcher discovers it, the usual excuses and justifications
> will be made by the designated spokesliars for the companies involved...
> which will of course keep right on doing it, albeit perhaps with more
> subterfuge.
>
> Problem #1 has been extant for ten years and no (meaningful) progress
> whatsoever has been made on solving it.
>
> Problem #2 is newer, but I'm willing to bet that it will also last
> at least a decade and that it will get worse, since there are
> substantial economic incentives to make it so.

In both cases, the evildoers may only gain access to a
passphrase-protected private key. That doesn't help if the private
key is generated on a compromised system, but it helps if the system
is compromised after the private keys are generated, or if the private
key is generated elsewhere and loaded onto the compromised system.
And it doesn't help if the passphrase is easily guessed.

Cheers,
Dave Hart

----- Original Message -----
> From: "Tei" <oscar.vives@gmail.com>

> If anyone have a really good idea how to fix this mess, It will be a
> good idea to contact with Jeff Atwood (of codehorror.com and
> stackoverflow.com fame). He and other people is working on a new
> internet approach to discussions. Think forums 2.0. If this new pet
> rock succeed, could change how the world use, eerrh... forums. We
> could hit two problems with the same rock.

Those who do not understand Usenet are condemned to reinvent it. Poorly.
-- after henry@utzoo

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On Thu, Jun 21, 2012 at 08:33:47AM +0900, Randy Bush wrote:
> would be interested to hear smb on this.

+1. I've been reading and thinking about:

http://www.ietf.org/id/draft-bellovin-hpw-01.txt

for quite some time, and I recommend that others interested in
this topic do the same.

---rsk

Rich Kulawiec <rsk@gsp.org> wrote:
>
> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:
>
> (on the use of public/private keys)
>
> > The leaks stop immediately. There's almost no value in a database of
> > public keys, heck if you want one go download a PGP keyring now.
>
> It's a nice thought, but it won't work. There are two large-scale
> security problems which prevent it from working:
>
> 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term,
> but any estimate of this population under 100M should be laughed out
> of the room. Plausible estimates are now in the 200M to 300M range.
> Any private key present on any of those is accessible to The Bad Guys
> whenever they can trouble themselves to grab it. (Just as they're
> already, quite obviously, grabbing passwords en masse.)

The proverbial 'so what' applies?

IF the end-user system is compromised, it *doesn't*matter* what kind of
security is used, THAT USER is compromised.

However, there is a _MASSIVE_ difference with respect to a 'server-side'
compromise. One break-in, on *one* machine, can expose tens of millions,
(if not hundreds of millions) of user credentials.

>
> 2. Pre-compromised-at-the-factory smartphones and similar. There's
> no reason why these can't be preloaded with spyware similar to CarrierIQ
> and directed to upload all newly-created private keys to a central
> collection point.
>
> Problem #1 has been extant for ten years and no (meaningful) progress
> whatsoever has been made on solving it.

'male bovine excrement' applies to this strawman argument.

Leo made no claim of describing a FUSSP (final ultimate solution to stolen
passwords). What he did describe was a methodology that could be fairly
easily implemented in the real world, =and= which effectively eliminates
the risk of _server-side_ compromise of a master 'password-equivalent' list.

Leo's proposal _does_ effectively address the risk of server-side compromise.
If implemented, it would effectively eliminate "more than half" of the

Still playing devils advocate here, but does this still not resolve the
human factor of "Implementation"?

--

- Robert Miller
(arch3angel)

On 6/22/12 7:43 AM, Robert Bonomi wrote:
> Rich Kulawiec <rsk@gsp.org> wrote:
>> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote:
>>
>> (on the use of public/private keys)
>>
>>> The leaks stop immediately. There's almost no value in a database of
>>> public keys, heck if you want one go download a PGP keyring now.
>> It's a nice thought, but it won't work. There are two large-scale
>> security problems which prevent it from working:
>>
>> 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term,
>> but any estimate of this population under 100M should be laughed out
>> of the room. Plausible estimates are now in the 200M to 300M range.
>> Any private key present on any of those is accessible to The Bad Guys
>> whenever they can trouble themselves to grab it. (Just as they're
>> already, quite obviously, grabbing passwords en masse.)
> The proverbial 'so what' applies?
>
> IF the end-user system is compromised, it *doesn't*matter* what kind of
> security is used, THAT USER is compromised.
>
> However, there is a _MASSIVE_ difference with respect to a 'server-side'
> compromise. One break-in, on *one* machine, can expose tens of millions,
> (if not hundreds of millions) of user credentials.
>
>> 2. Pre-compromised-at-the-factory smartphones and similar. There's
>> no reason why these can't be preloaded with spyware similar to CarrierIQ
>> and directed to upload all newly-created private keys to a central
>> collection point.
>>
>> Problem #1 has been extant for ten years and no (meaningful) progress
>> whatsoever has been made on solving it.
> 'male bovine excrement' applies to this strawman argument.
>
> Leo made no claim of describing a FUSSP (final ultimate solution to stolen
> passwords). What he did describe was a methodology that could be fairly
> easily implemented in the real world, =and= which effectively eliminates
> the risk of _server-side_ compromise of a master 'password-equivalent' list.
>
> Leo's proposal _does_ effectively address the risk of server-side compromise.
> If implemented, it would effectively eliminate "more than half" of the

Leo,

This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.

Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.

If it does not use self-generated unsigned keys, it will never fly.

---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org


> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell@ufp.org]
> Sent: Wednesday, 20 June, 2012 15:39
> To: nanog@nanog.org
> Subject: Re: LinkedIn password database compromised
>
> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda
> wrote:
> > Key management: doing it right is hard and probably beyond most end users.
>
> I could not be in more violent disagreement.
>
> First time a user goes to sign up on a web page, the browser should
> detect it wants a key uploaded and do a simple wizard.
>
> - Would you like to create an online identity for logging into web
> sites? Yes, No, Import
>
> User says yes, it creates a key, asking for an e-mail address to
> identify it. Import to drag it in from some other program/format,
> No and you can't sign up.
>
> Browser now says "would you like to sign up for website 'foobar.com'",
> and if the user says "yes" it submits their public key including the
> e-mail they are going to use to log on. User doesn't even fill out
> a form at all.
>
> Web site still does the usual e-mail the user, click this link to verify
> you want to sign up thing.
>
> User goes back to web site later, browser detects "auth needed" and
> "public key foo" accepted, presents the cert, and the user is logged in.
>
> Notice that these steps _remove_ the user filling out forms to sign up
> for simple web sites, and filling out forms to log in. Anyone who's
> used cert-based auth at work is already familiar, the web site
> "magically" knows you. This is MUCH more user friendly.
>
> So the big magic here is the user has to click on "yes" to create a key
> and type in an e-mail once. That's it. There's no web of trust. No
> identity verification (a-la ssl). I'm talking a very SSH like system,
> but with more polish.
>
> Users would find it much more convenient and wonder why we ever used
> passwords, I think...
>
> --
> Leo Bicknell - bicknell@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/

> 2. Pre-compromised-at-the-factory smartphones and similar. There's
> no reason why these can't be preloaded with spyware similar to CarrierIQ
> and directed to upload all newly-created private keys to a central
> collection point. This can be done, therefore it will be done, and when
> some security researcher discovers it, the usual excuses and justifications
> will be made by the designated spokesliars for the companies involved...
> which will of course keep right on doing it, albeit perhaps with more
> subterfuge.

> Problem #2 is newer, but I'm willing to bet that it will also last
> at least a decade and that it will get worse, since there are
> substantial economic incentives to make it so.

This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different.

---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org

On 06/23/2012 05:52 PM, Keith Medcalf wrote:
> Leo,
>
> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback).

What is their leverage to extort? A web site just needs to make the
client and server end agree on a scheme, and they control both ends.
They can't force me to use their scheme any more than they can force
me to not use Basic and use their scheme instead. Keep in mind that
asymmetric keys do not imply certification, and asymmetric keys are
cheap and plentiful -- as in a modest amount of CPU time these days.

Mike

> You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user.
>
> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage.
>
> If it does not use self-generated unsigned keys, it will never fly.
>
> ---
> () ascii ribbon campaign against html e-mail
> /\ www.asciiribbon.org
>
>
>> -----Original Message-----
>> From: Leo Bicknell [mailto:bicknell@ufp.org]
>> Sent: Wednesday, 20 June, 2012 15:39
>> To: nanog@nanog.org
>> Subject: Re: LinkedIn password database compromised
>>
>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda
>> wrote:
>>> Key management: doing it right is hard and probably beyond most end users.
>> I could not be in more violent disagreement.
>>
>> First time a user goes to sign up on a web page, the browser should
>> detect it wants a key uploaded and do a simple wizard.
>>
>> - Would you like to create an online identity for logging into web
>> sites? Yes, No, Import
>>
>> User says yes, it creates a key, asking for an e-mail address to
>> identify it. Import to drag it in from some other program/format,
>> No and you can't sign up.
>>
>> Browser now says "would you like to sign up for website 'foobar.com'",
>> and if the user says "yes" it submits their public key including the
>> e-mail they are going to use to log on. User doesn't even fill out
>> a form at all.
>>
>> Web site still does the usual e-mail the user, click this link to verify
>> you want to sign up thing.
>>
>> User goes back to web site later, browser detects "auth needed" and
>> "public key foo" accepted, presents the cert, and the user is logged in.
>>
>> Notice that these steps _remove_ the user filling out forms to sign up
>> for simple web sites, and filling out forms to log in. Anyone who's
>> used cert-based auth at work is already familiar, the web site
>> "magically" knows you. This is MUCH more user friendly.
>>
>> So the big magic here is the user has to click on "yes" to create a key
>> and type in an e-mail once. That's it. There's no web of trust. No
>> identity verification (a-la ssl). I'm talking a very SSH like system,
>> but with more polish.
>>
>> Users would find it much more convenient and wonder why we ever used
>> passwords, I think...
>>
>> --
>> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>
>