[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A (not) new security idea

On Wed, 2004-10-13 at 20:06, Brian Fahrlander wrote:

> > The big issue (you knew there was one!) is you need some process in
> > place to recover when either your fob catastrophically fails or is
> > lost.  It also must be secure enough that if it is lost that no one else
> > could use it.  Which brings you back to using a highly secure password
> > or pass phrase and encryption that would take the NSA at least a week to
> > crack.  :)
>     Yeah, but with a fob, they might write down the passphrase at home,
> making it difficult to steal at work.  Even this provides an amount of
> security not offered with current systems.

Security wise it is always a bad idea to write down passwords or
passphrases.  The reality is that almost everyone does just that.  :)

Actually there are several different two factor authentication schemes
out there.  The idea of authenticating someone based on something they
have and something they know is pretty much the standard for really
secure systems.  

And I think that may be the issue with wide spread adoption of such a
system.  Most people feel that a password provides enough security for
their purposes.  And from past experience dealing with users if you make
a system to complex they won't use it.  This includes issues with
recovering from that catastrophic failure or lost passphrase.  

>     I've watched a lot of projects spring to life; the only thing
> different about this one is that the parts are there, we just need to
> glue'em together.  I think what we need most is a catchy name, then a
> press release, and eventually some programmers.  :>  At least, that's
> the way things like Samba, Sendmail, and Apache seemed to have come
> about.  (J/K!)

You must have a marketing background.  :^D

Personally I think a proof of concept would be the first thing.  Once
you have that then you can sort out the silly stuff like names and such.

>     On the web-side, we could introduce something in the browser strings
> that it normally sends the server.  Just add a key.  IIS and company can
> barf on it, but if a browser is sending that key, it's because a fob has
> been authenticated, and if a matching key is found, that user gets
> logged in.

Don't forget that you need to encrypt any thing you want to send like
that.  Probably you will want to consider using some kind of public key
setup so that you never pass the real password info over the network.  

>     Make this system, bang out the initial problems, and make it part of
> the distro, and you'll see people everywhere picking it up.  Even the
> legacy people.

Like I said before, getting wide spread adoption of something like this
will be a problem.  It will appeal to a select group at best.  Take a
look at selinux over the next year.  If/when that is enabled by default
I suspect you will see the most common question on the list is how to
disable it.  

I do have one idea that many people may find useful.  Using your idea of
a usb flash memory, figure out how to store your web browsers cache of
passwords on the flash memory.  Then no matter what machine you use you
plug in the flash and your browser has all the passwords for all the
sites you visit.  Would need to modify the browser to look for the cache
information on the flash memory.  Once you get the proof of concept
working then you need to add heavy duty encryption to the flash device
and a method to unlock it for use by the web browser.

>     What can I do to help?

Release a proof of concept of course! :)

Scot L. Harris
webid cfl rr com

No rock so hard but that a little wave
May beat admission in a thousand years.
		-- Tennyson 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]