Category Archives: Uncategorized

Has identity verification on the web become a glass ceiling?

Leave a reply

As of 2013 here are 7.125 billion people in the world (World Bank) 39% of which are using the Internet (ITU). 318.9 million of these people live in the United States where as many as 74% use the Internet (Census).

Increasingly these people are accessing services that require them to prove their identity over the internet. This manifests itself in many ways, commonly in the United States this is done through use of Knowledge Based Authentication (KBA) where knowledge of details from users credit reports are leveraged to authenticate users. This approach has several serious problems:

  • In the United States alone 29% of people have no credit history at all (Gallup) making this approach inaccessible for these users,
  • A number likely much larger than this have such limited credit histories this approach to authentication is ineffective for them,
  • Numerous studies show the usability characteristics of these solutions are poor and result in user abandonment,
  • The limited data available in these credit reports and the way KBA is integrated into these services reduces both the security and privacy each time the information is used.

As a result services often times attempt to leverage a person’s pre-existing relationships with other services such as banks. This approach also have serious failings:

  • In the United States 7.7% of people are unbanked (FDIC) and 20% are underbanked,
    World-wide the number of unbanked is 35%,
  • For liability and business interest reasons almost no financial services organizations offer federated identity services for their customers,
  • When banks are used a concept of a “penny-test” is often used requiring disclosing sufficient information to enable them to potentially draw electronic checks from the persons account,
  • The infrequent nature of this transaction and inherent complexity of the task again has poor usability characteristics and results in transaction abandonment,
  • This leaves services attempting to rely on binding multiple social “identities” together to authenticate the user. Unfortunately these social “identities” are often no more than pseudonyms which do not meet the regulatory obligations that many businesses and agencies must meet. Additionally the binding of these identities together reduces the users privacy significantly in that it becomes trivial to track activities of that user across services.

This situation creates a socioeconomic glass ceiling where those who can not participate in these authentication systems do not have access to the lower cost and generally higher value services available on the Internet.

Additionally there is still a class of transactions where the existing mechanisms do not work (such as a person establishing their first bank account) and others that require the disclosure of more information than necessary to meet the authentication requirements (for example age verification).

Outside the United States the situation is even more grim where the the numbers of the unbanked are significantly higher and often privacy regulations prevent the use of many of the above approaches. As a result many services can not be brought online and those that can commonly rely on the lowest common denominator – proof of control of a simple email address.

This problem is made even more complicated when services need to verify professional accreditations or roles within an organization.

What do you think? Is this a real problem?

I think it is. I also think this is a solvable problem (for some value of solvable) but as of yet I do not see anyone building solutions that address this problem of initial identity verification effectively.

MUST STAPLE and PKI.js

Leave a reply

The other day I did a post on how to create a self-signed certificate using PKI.js in that sample we included a Basic Constraints extension but we could have also just as easily defined a custom or new certificate extension. For example thanks to #heartbleed folks are talking about MUST STAPLE again, this is an extension that was proposed several years ago that when present would indicate that clients should hard-fail instead of soft-fail with OCSP.

This proposal is based on a generic concept of expressing a security policy within the certificate. While the OIDs for this extension and the associated policy have not been defined yet one can easily construct a certificate using this extension with PKI.js:

cert_simpl.extensions.push(new org.pkijs.simpl.EXTENSION({
    extnID: "1.2.3", // No OIDs assigned yet
    critical: false,
    extnValue: (new org.pkijs.asn1.SEQUENCE({
        value: [
                   new org.pkijs.asn1.INTEGER({ value: 4 }),
                   new org.pkijs.asn1.INTEGER({ value: 5 }),
                   new org.pkijs.asn1.INTEGER({ value: 6 })
               ]
               })).toBER(false)
}));

NOTE: In the above snip-it we just made up two OID values, hopefully IANA will assign OIDs soon so it is possible for browsers and CAs to implement this extension formally.

Average CRL size and download time

1 Reply

The other day I had a great conversation with Robert Duncan over at Netcraft, he showed me some reports they have made public about CRL and OCSP performance and uptime.

One thing that I have been meaning to do is to look at average CRL size across the various CAs in a more formal way I just never got around to doing it; conveniently one of the Netcraft reports though included a column for CRL size. So while I was waiting for a meeting to start I decided to figure out what the average sizes were; I focused my efforts on the same CAs I include in the revocation report, this is what I came up with:

 

CA Average CRL Size(K) CRL Download Time @ 56k (s)
Entrust 512.33 74.95
Verisign 200.04 29.26
GoDaddy 173.79 25.42
Comodo 120.75 17.66
Cybertrust/Verizon 75.00 10.97
DigiCert 21.66 3.17
GlobalSign 21.25 3.11
Certum 20.00 2.93
StartSSL 9.40 1.38
TrendMicro 1.00 0.15

 

From this we can derive two charts one for size and another for download time at 56k (about 6% of internet users as of 2010):

clip_image002 clip_image004

 

I overlaid the red line at 10s because that is the timeout that most clients use to indicate when they will give up trying to download, some clients will continue trying in the background so that the next request would have the CRL already cached for the next call.

This threshold is very generous, after all what user is going to hang around for 10 seconds while a CRL is downloaded? This gets worse though the average chain is greater than 3 certificates per chain, two that need to have their status checked :/.

This is one of the reasons we have soft-fail revocation checking, until the Baseline Requirements were published inclusion of OCSP references was not mandatory and not every CA was managing their CRLs to be downloadable within that 10 second threshold.

There are a few ways CAs can manage their CRL sizes, one of the most common is simply roll new intermediate CAs when the CRL size gets unmanageable.

There is something you should understand about the data in the above charts; just because a CRL is published doesn’t mean it represents active certificates – this is one of the reasons I had put of doing this exercise because I wanted to exclude that case by cross-referencing the signing CA with crawler data to see if active certificates were associated with each CRL.

This would exclude the cases where a CA was taken out of operation and all of the associated certificates were revoked as a precautionary exercise – this can happen.

So why did I bother posting this then? It’s just a nice illustration as to why we cannot generally rely on CRLs as a form of revocation checking. In-fact this is very likely why some browsers do not bother trying to download CRLs.

All posts like this should end with a call to action (I need to do better about doing that), in this case I would say it is for CAs to review their revocation practices and how they make certificate status available to ensure it’s available in a fast and reliable manner.