How to fix authentication (was LinkedIn)
AP NANOG
nanog at armoredpackets.com
Thu Jun 21 16:15:52 UTC 2012
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 at 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 at baylink.com> wrote:
>>> ----- Original Message -----
>>>> From: "Leo Bicknell" <bicknell at 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.
More information about the NANOG
mailing list