[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography-randombit
Subject:    [cryptography] The Government and Trusted Third Party
From:       iang () iang ! org (Ian G)
Date:       2011-09-19 3:59:20
Message-ID: 4E76BE18.3080201 () iang ! org
[Download RAW message or body]

Hi James,

On 19/09/11 1:39 PM, James A. Donald wrote:
>> On 19/09/11 6:53 AM, James A. Donald wrote:
>>> These days, most retail transactions have a sign in.
>>>
>>> Sign ins are phisher food.
>>>
>>> SSL fails to protect sign ins.
>
> On 2011-09-19 1:12 PM, Ian G wrote:
>> Hence, frequent suggestions to uptick the usage of client certificates,
>> SRP, and SSL itself.
>
> Client certificates and SSL seem unlikely to protect sign in.


The point about SSL is two-fold:  using SSL solves a slew of other 
problems to do with cookies and hacking and so forth, as Peter points 
out.  I suppose we need a list :)

The second point is that as more and more people use SSL, there is more 
and more pressure on the vendors to address the UI.  Which leads into...

> The chairman of the board cannot handle a client certificate. He
> outsources that to someone in IT whose name he does not know. Not very
> secure.

The problem with client certs is that they are mostly saddled with a 
horrible UI.  If the UI was slick, it would work.

The experiments we've conducted over at CAcert indicate that when it is 
up and going, and the user base is forced by one means or another to 
migrate, a properly written client-cert login procedure is far nicer and 
more secure than a password system.

However, this requires to solve the chicken and egg problem.  We did 
that in CAcert by some serendipitous decisions.  How to do it in your 
org would be something else.

http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing



All of which are suggestions that there are low-hanging fruit.  Tweaks 
to make the system work without redesigning.


iang

[prev in list] [next in list] [prev in thread] [next in thread]