[154028] in North American Network Operators' Group
Re: LinkedIn password database compromised
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Thu Jun 21 11:07:51 2012
Date: Thu, 21 Jun 2012 08:05:37 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <4FE33320.8030408@armoredpackets.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I want to start by saing, there are lots of different security problems
with accessing a "cloud service". Several folks have already brought up
issues like compromised user machines or actually verifing identity.
One of the problems in this space I think is that people keep looking
for a silver bullet that magically solves all the problems. It doesn't
exist. We need a series of technologies that work with each other.
In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wro=
te:
> How will this prevent man in the middle attacks, either at the users=20
> location, the server location, or even on the compromised server itself=
=20
> where the attacker is just gathering data. This is the same concerns we=
=20
> face now.
There is a sign up problem. You could sign up with a MTM web site,
which then signs you up with the real web site.
There are a number of solutions, you can try and prevent the MTM attack
with something like DNSSEC, and/or verify the identity of the web site with
something like X.509 certificates verified by a trusted party. The
first relationship could exchange public keys in both directions, making
the attack a sign-up attack only, once the relationship is established
its public key in both directions and if done right impervious to a MTM
attack.
Note that plenty of corporations "hijack" HTTPS today, so MTM attacks
are very real and work should be done in this space.
> Second is regarding the example just made with "bicknell@foo.com" and=20
> superman@foo.com. Does this not require the end user to have virtually=
=20
> endless number of email addresses if this method would be implemented=20
> across all authenticated websites, compounded by numerous devices=20
> (iPads, Smartphones, personal laptop, work laptop, etc..)
Not at all. Web sites can make the same restrictions they make
today. Many may accept my "bicknell@ufp.org" key and let me us
that as my login. A site like gmail or hotmail may force me to use
something like bicknell@gmail.com, because it actually is an e-mail,
but it could also give me the option of using an identifier of my
choice.
While I think use of e-mails is good for confirmation purposes, a
semi-anonymous web site that requires no verification could allow
a signup with "bob" or other unqualified identifier.
It's just another name space. The browser is going to cache a mapping
from web site, or domain, to identifier, quite similar to what it does
today...
Today:
www.facebook.com, login: bob, password: secret
Tomorrow:
www.facebook.com, key: bob, key-public: ..., key-private: ...
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBT+M4QbN3O8aJIdTMAQLffA//TMK460QycNAG2LV5+kCQ5m4ALEkMLbnE
rV2qPwJJLTphEAFvY75MXqf65HIjusjcqUpCALyx+3fiLGA2rpiRiU6eCLjcECJI
5kJ6TtfeEHtio5XWj1kIPuTJ/+uSLXf7u/tiJoID4CwPNK7jbvs4EwVTImw5l1hH
WpxiROU3qZAlpCUdgpMrD4ZwbY+LlnW+XoCmdQpEoCk9hLQu0qyXZtaHFrOEwrG9
+6RWmI7AjgFy4QSSB7X5RvJY+v4z3RAHUX1SAfs3G8jxbsI7zEh37y4MAG586nxS
LxAVVpWLErKWALWsxMtdgQ9CJKcDedLHgdF2BrS2v6ZgfK8ubQTpSCLGLbBKPpK+
famYDbOx18xUmDtMQhl4YlNPAeq4GpRLAjk9fZs61QI3lsyFZnsfGFXzsy/09upI
/IdQFidSRAFMiGonOE6ulu18DUp05OebuQH0RVxb1Sy48Ao0CzD7DasVkvBqGmr3
wvExXBnrgkfkJtoPfgRmJgs4YylEqMQ3kVUwsTe1UB8fACmrUDym7Nb+Dn9Met8f
69yUWTpRRHWpokH9hrbP8Q9hmtd4nBgDDL1C/xCCjVtZe5qaE6RDdywFpzEBB4Jj
i5v9pbNU3RYuNNwPq2IvSvGFAcQ+tAnE809mLvuDCs0oV/uC6CNLGeKcUrYOuYeS
Mkdxe/10/Mc=
=/IxW
-----END PGP SIGNATURE-----
--cWoXeonUoKmBZSoM--
