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 wrote:
> How will this prevent man in the middle attacks, either at the users
> location, the server location, or even on the compromised server itself
> where the attacker is just gathering data. This is the same concerns we
> 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 "bickn...@foo.com" and
> super...@foo.com. Does this not require the end user to have virtually
> endless number of email addresses if this method would be implemented
> across all authenticated websites, compounded by numerous devices
> (iPads, Smartphones, personal laptop, work laptop, etc..)
Not at all. Web sites can make the same restrictions they make
today. Many may accept my "bickn...@ufp.org" key and let me us
that as my login. A site like gmail or hotmail may force me to use
something like bickn...@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: ...
--
Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
pgph9Oiiinnwc.pgp
Description: PGP signature
