Most systems still only offer username/password authentication, and most people are still happy to use it, even though everyone knows (for example, through daily media headlines) that there are pervasive user access security problems with it.
Why don't people use certificate-based access authentication?
This question is important for email security and also in other areas, such as web site and blog access.
We suggest that a proper answer requires thinking that has to be much more nuanced and sophisticated than just a discussion of usability versus security.
Such thinking should come also from analyzing online and offline feedback, as we need to approach the question as it is seen -- from many sides.
We have taken this approach in our paper, now updated, at http://email-security.net/papers/takefive.htm
Please provide your comment. You can also Read the Compact Version
Thank you!
Ed Gerck
Welcome to Email-Security. This is a technical development forum dedicated to a fresh exploration of the Internet email security issues of today, with website at http://email-security.net. Comments and paper contributions on the theme of email security are welcome. Papers will be peer-reviewed before publication. Product and service listings are also welcome, see website.
10 comments:
[online by Peter Thoenen]
Because it's different. I have this arguments all the time with SES's and flag officers who would rather type a 16 character complex password that a 4 character password with coupled hardware token.
[online by Lynn Wheeler]
long-winded x-over from sci.crypt posting
http://www.garlic.com/~lynn/2009r.html#32 SSL certificates and kyes
the question was asked several times in the mid-90s.
part of the answer was that even shorten digital certificate was typically 100 times larger than typical payment payload ... misc. past posts mentioning the enormous (certificate-base) payload bloat:
http://www.garlic.com/~lynn/subpubkey.html#bloat
and it was relatively trivial to demonstrates the actual certificates were redundant and superfluous. it was one of the reasons that in the mid-90s the x9a10 financial standard working group came up with a digitally signed financial transaction that didn't require an appended digital certificate (the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments).
http://www.garlic.com/~lynn/x959.html#x959
There was some efforts in the financial standard working group ... recognizing the enormous payload bloat penalty represented by digital certificates started a standardization effort for "compressed" digital certificates ... possibly hoping to get the enormous bloat down to only a factor of ten times. Using their techniques, I was able to show that it was possible to compress a digital certificate to zero bytes ... so rather than defining a standard for a financial transaction w/o any digital certificate ... it would be possible to have a financial transaction that mandated a zero-byte digital certificates (also avoiding the enormous payload bloat penalty). For some "certificate-less" posts/discussions:
http://www.garlic.com/~lynn/subpubkey.html#certless
For some other topic drift ... some old email proposing a PGP-like, publickey, certificateless operation
http://www.garlic.com/~lynn/2007d.html#email810506
http://www.garlic.com/~lynn/2006w.html#email810515
[online by Gordon Divitt]
I don't have the time or energy to read all the link but I have implemented PKI a couple of times in my career and find that the resistance is always around a) the complexity of establishing a CA and b) the need to 'absolutely' prove who you are to register for one
In other words folks saw the cure as worse than the disease
[online by Lynn Wheeler]
another part of the certificate-based payments from the mid-90s (besides the enormous payload bloat) was the proposal that 1) each consumer would pay $100 for their own certificate and 2) payment transactions with appended digital certificates would reverse the burden of proof in disputes (as enticements to get merchants to play). The issue then was why would every person in the world spend $100 per annum to have the dispute burden of proof shifted to them.
[online by Piers Wilson]
part of the issue is the need to store a private key; as this is often a file help at the client end you get the two problems of (a) securing the key file on an often insecure client system (b) allowing a user to connect from several different places (e.g. internet cafes) and having access to their key in such a way that it doesn't get copied and stored at every place they connect from.
Of course if I can get the key file you are then reliant on the user choosing a good password that I can't brute force off line.
there are solutions to this of course, such as smart cards (my personal favourite) but you need client devices (readers) and software and an issuing process that has some form of physical contact (even if its posting out the token/card).
[Online by Anthony Rivera]
I agree with Gordon; he hit the nail on the head with the remark that the cure was worse than the disease. It wasn't just consumers that were put off either; plenty of orgs gave up for the same reason.
[online by Lynn Wheeler]
when one of the certificate oriented payment specifications was 1st released ... we did a public-key profile for the end-to-end process and got somebody that was worked with public key library (they had done speedups on the standard library by factor of four times) do some benchmarks. when we reported the results ... we were told the numbers were too slow (instead of being told the numbers were four times too fast because of using a speeded up library). Six months later when some pilot projects were tested ... our earlier profile benchmark numbers were within a couple percent of measured (the speedups had been integrated into widely used public key library).
... in addition to appended certificates representing a 100-times payload bloat for standard payment transaction ... the certificate-related public key ops were also resulting in 100-times processing bloat.
[online by Matthias Hehn]
a lot of merchants I worked with tried implementing certificate based security, only to fail on the complexity of the matter. It usually takes a bigger company with a specific IT person that knows a lot about the matter and follows up if changes in the keystore( Certificate expires ... ) arise.
Also a performance issue as mentioned earlier
[online by Eric Goodman]
I could be over simplifing this concept, as I am no means well versed on Certificate based security. Has a simpler solution was introduced, 3D-Secure Authentication? From the above comments, The 3D-Secure process "seems" much simpler to integrate and it DOES introduce the shift in "burden of proof" from the merchant to the card issuing bank and the card holder.
Many people will weigh in on pros and cons of 3D-Secure, however, the major change was not the introduction of this concept, but Visa and MasterCard changed their card processing rules to shift all fraud liablity from the merchant to the issuer if 3D-Secure was simply attempted by the merchant. This means, the industry does not need card holder adoption to drive merchant benefit. All merchants will benefit from simply running 3D-Secure with or without card holder adoption.
However, card holder adoption is still ultimately needed for the longevity of the system or regulation through mandates from Visa/MasterCard will need to be introuduced to drive adoption.
[online by Gordon Divitt]
I believe the key to certificate based systems (PKI) is that they purport to absolutely prove that the person is who they claim to be - too high a hurdle for most problems
Post a Comment