On 02/02/2011 06:41 AM, Gervase Markham wrote:
On 01/02/11 20:02, Marsh Ray wrote:
Whether or not client certs count as a second factor is somewhat
philosophical. In some sense, the private key stored in the browser
functions as another "something you know" like a password. If the PC is
pwned, they can get the private key too.
If your computer is pwned, you have lost.
Nice to talk with people who recognize that directly. :-)
I think we would save about half the money spent in the data security
industry if people would understand that concept.
Actually, there are some mitigations in very useful specific cases (but
traditional login session authentication is not one of them).
So I'm not worried about the
disadvantages of client certs from that perspective. I'm more worried
about their possible usability issues.
Those accounts would probably have to access a particular URL and be
banned from the main one. May or may not be an issue.
It is. Telling some people to use a different Bugzilla URL is not an
option. It breaks the handing-round of links.
To make it work with a single URL, the server will need to initiate a
TLS renegotiation after receiving the HTTP request. It needs to process
it enough to know that this is a user configured to require a client
cert, but not so much that he ends up executing any significant actions
from the request. So he needs a two-stage authentication; he needs to
know who he's expecting to be talking to before he knows how to fully
authenticate them.
This is all possible to do, but tricky. It's even harder because servers
don't usually provide a straightforward API for script environments to
turn around and request a renegotiation of the TLS connection part-way
through the processing of the HTTP request.
It also prevents TLS's session resumption optimization, but that's
probably not an objectionable slowdown on a simple app like Bugzilla.
Oooh oooh I do!
I work at PhoneFactor (phonefactor.com). We use any ordinary phone as
the second factor and can integrate with nearly anything. Most people
already have cell phones, which can save a lot of deployment pain.
We have contributors in almost every country in the world (although
perhaps not every country will need this because we don't have security
hackers everywhere). How do you deal with the international calls issue?
Yes, we have many customers in places around the world. Obviously there
are some small costs for a quick auth call or SMS, but we have multiple
providers and can route it the least expensive way automatically. Those
costs are not really something we mark up or try to profit on.
We also have a PhoneFactor Agent that runs on MS Windows, but of course
not everyone has that as part of their backend systems.
This is a necessary back end piece?
No, we could implement something directly with our XML-HTTPS SDK. For
example, we have a Wordpress plugin and we could probably make something
similar for Bugzilla.
On the other hand, the PhoneFactor Agent is a very useful "Swiss army
knife" for authentication systems. For example, if you had Bugzilla
configured to use RADIUS or LDAP authentication we could drop an Agent
in as a man-in-the-middle proxy and have it running quickly.
The Agent is also very useful for managing the association of usernames
and phone numbers and PINs. It also provides a user portal site which
allows users to self-enroll, change their own phone numbers and other
useful functions that cut down on the administration. Once you get into
hundreds of users, someone is losing their hardware token every day so
having that self-enrollment in place is a big relief.
The unique thing that a phone-based service can do is actually convey
and confirm information through an out-of-band channel. This can
actually mitigate the pwned PC scenario! It was developed with banking
transactions in mind, but it's generic. For example, you could set it up
so that a particular action (like say closing a bug) results in a phone
call or SMS that includes the bug # and the new state for the user to
accept or reject via this separate out-of-band channel.
As before, this can be done in the app code with the SDK or with an
Agent functioning as a reverse proxy with no code changes needed in the app.
- Marsh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
