On-line Bank Auth. Was: Privacy

Mo,

What you are saying about banks in the UK is applicable to Scandinavia
as well with a few exceptions.

I have always wondered why a regulated, (usually) very rich, and
global industry sector never spent a single cent on creating a
generally useful 2FA solution.  From what I can see they hardly
cooperate even on a national basis.

IMO the complete absence of a cheap, generally available, and
fully end-user provisionable token is a core reason why for
example PKI for consumers is going so slow.

Let's say that you have a small enterprise running Windows
and AD.  In spite of the fact that "CertServ" is included
in W2KSR2, there is no way you could give your users tokens
without installing quite alien software as well as hiring a
*really pricey smart card consultant*.

Banks have bigger resources than small enterprises but they still
face the problem that they must support a lot of unmanaged platforms,
all requiring pretty unique token drivers.

The NSTIC people do probably not realize that the cost per seat
for the PIV program probably exceeded $500 (including all) which
is *way* outside what the commercial sector is interested in.

I find governments (in general) fairly lax about cost (and
convenience) aspects when it comes to authentication.  They have
as "a collective of bad buyers" effectively laid the foundation for
a non-functioning market with practically zero competition, and
extremely poor solutions like "CertEnroll".

Unless something radical is done, like my Open Hardware token
and provisioning concept, I think we'd better give up the PC
and focus on phones because embedded tokens completely relieve
us from middleware/reader/provisioning issues.  In fact, Apple
is already there:

http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

Anders


On 2011-07-29 18:05, Mo McRoberts wrote:
> Hi Francisco,
> 
> On 23 Jul 2011, at 19:58, Francisco Corella wrote:
> 
>> This has a privacy drawback.  When the user presents one of the
>> "shorter-lifetime certificates" to a relying party, the user also
>> sends the "self-asserted CA cert" with the "issuer pubkey".  So the
>> relying party learns "the real identity of the user".
> 
> Yup, you're entirely right — although I will contend that there are applications where a persistent cross-RP identity is desirable. I need to read up fully on Idemix to understand how it can fit into the picture. I don't think it's an binary choice thing, though.
> 
> I believe there are three sets of problems which are in effect separate, but are of course related:
> 
> 1. An improvement on the username/password (or typically, e-mail address and password) combination
> 
> 2. Avoiding privacy leakage where desirable (such as in the medical insurance case you've described)
> 
> 3. Authentication schemes strong enough for, e.g., banks
> 
> The status quo is clearly unacceptable on all counts; replayable credentials are trivially phished on a daily basis, and organisations which really do need strong crypto-based identification prefer to roll out their own stacks than use what exists in the browser today.
> 
> My focus *right now* is therefore on sketching out a framework upon which at least some progress can be made — improving the usability and workflow around self-signed certs for identification helps to eliminate usernames and passwords in a decentralised way, and wouldn't — I hope — preclude the use of non-/less-leaky credentials in some applications.
> 
> My view is that these usability issues are a serious stumbling-block with relatively little attention being paid to them by many smart people; it's great that privacy issues around generic PKI-based credentials are being researched and (hopefully) resolved, but it doesn't advance the state of play very much if nobody's gets as far as using them…
> 
> On the third point, this has proved to be pretty territory-specific. Banks in the UK, for example, don't bother with any of it and instead mandate 2FA with a completely standalone smartcard reader doing challenge/response (which, of course, avoids issues in PKI-land with the continual pull in opposite directions between private key storage policies and the need for flexibility).
> 
> M.
>

Received on Saturday, 30 July 2011 06:48:19 UTC