Re: How to fix authentication (was LinkedIn)

[AP NANOG <nanog () armoredpackets com>]

I still believe that the final solution should be some sort of two 
factor, something you know (i.e. a passphrase) and something you have 
(i.e. key / token / something which has been verified).

Up till recently RSA was a good platform, but was not very effective for 
smartphone use.

If there is no two factor methodology, which changes, being deployed 
then man in the middle will still work.  So will compromising systems 
and even compromised servers.

What if, and I am brainstorming here, what if there was a hardware 
device which plugged in via USB.  It was programed (i.e verified) in 
person, such as a key signing party.  The serial number of the hardware 
device was all that is stored in the "verified" database with say a 
generic email created at that time with the domain of the verifying 
group.  For example, your serial number is 12345, so the email would be 
generated as 12345 () foo com.  This device is hardware encrypted, and 
stores your password (priv key) in a one way encryption.  Then when you 
go to a website they can ask if you are verified by foo.com.  The users 
selects yes, then the website pulls the public key at that time.  Then 
asks you for your pin, password, pass-phrase, whatever, and at that time 
the users clicks a pretty eye candy button in the browser which looks 
for the USB device with the serial number from the database.  Once found 
it then starts a secure tunnel such as VPN (can be anything just using 
it as a methodology), and no data is transmitted until the tunnel and 
DNSSEC has been established.  Once established you can surf the site as 
normal.  All these connections and tunnels being setup by the browser 
using two factor authentication.  What you know being the public key 
with verification from foo.com, which was also verified in person with 
the foo.com email.  What you have which is the hardware token, again 
serial number verified and encrypted.  Combined to give you access and 
the browser does most the work.

Couple things I see as issues off the bat are:

   Cost of USB device
   Security controls over manufacturing
   In person verification, will require many locations and volunteers -
   Still involves the Human Factor of error or misuse
   Education of the users who are techie
   Browser security
   Browser plugin & functionality
   Change time limit and process (i.e. must be regenerated after x months)
   Complete Revocation of the token and notification to all websites
   using foo.com verification

Again I am just throwing an idea out there to see what others think, 
maybe pieces of everyone's idea may result in an effective solution :-)

Along the lines of iCloud, or any cloud based service.  I am by no means 
a fan of cloud services in any shape or form.  The risks are WAY to 
great to out weigh the benefits.  If someone has a good argument for 
"secure" cloud services I am open to hearing those, but that's an 
entirely different email thread :-)

- Robert Miller
(arch3angel)


On 6/21/12 8:23 AM, Alexander Harrowell wrote:
> On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote:
> > On Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth <jra () baylink com> wrote:
> > > ----- Original Message -----
> > > > From: "Leo Bicknell" <bicknell () ufp org>
> > > Yes, but you're securing the account to the *client PC* there, not
> to
> > > the human being; making that Portable Enough for people who use and
> > > borrow multiple machines is nontrivial.
> > Or a wizard in your browser/OS/whatever could prompt you to put in a
> > 'special' USB key and write the identity data there, making it
> > portable.  Or like my ssh keys, I have one on my home computer, one on
> > my work computer, one on my USB drive, etc...  If I lose my USB key, I
> > can revoke the SSH key and still have access from my home computer.
> >
> > And I'm sure someone would come up with the 'solution' where they
> > store the keys for you, but only you have the passphrase...ala
> > lastpass.
> >
> > -A
>
> As far as apps go, loads of them use OAuth and have a browser step in
> their setup.
>
>
> So this adds precisely one step to the smartphone sync/activation
> process - downloading the key pair from your PC (or if you don't have a
> PC, generating one).
>
>
> that covers vendor A and most vendor G devices. "what about the feature
> phones?" - not an issue, no apps to speak of, noOp(). "what about
> [person we want to be superior to who is always female for some
> reason]?" - well, they all seem to have iPhones now, so *somebody's*
> obviously handholding them through the activation procedure.
>
>
> obviously vendor A would be tempted to "sync this to iCloud"...but
> anyway, I repeat the call for a W3C password manager API. SSH would be
> better, but a lot of the intents, actions etc are the same.