On 2/05/2014 13:06 pm, Marcus Brinkmann wrote:
> On 05/01/2014 10:25 AM, Ben Laurie wrote:
>> On 1 May 2014 08:19, James A. Donald <jam...@echeque.com> wrote:
>>> On 2014-04-30 02:14, Jeffrey Goldberg wrote:
>>>>
>>>> On 2014-04-28, at 5:00 PM, James A. Donald <jam...@echeque.com> wrote:
>>>>
>>>>> Cannot outsource trust  Ann usually knows more about Bob than a
>>>>> distant
>>>>> authority does.
>>>>
>>>>
>>>> So should Ann verify the fingerprints of Amazon, and Paypal herself?
>>>
>>>
>>> Ann should be logging on by zero knowledge password protocol, so that
>>> the
>>> entity that she logs on to proves it already knows the hash of her
>>> password.
>>
>> EXACTLY!!!
>>
>>> ZKPP has to be in the browser chrome, not on the browser web page.
>>
>> This seems obvious, but experiments show users do not understand it.
>> We have yet to find a satisfactory answer to a trusted path for
>> ordinary users.
> 
> So where it really mattered we got two-factor authentication (by mobile
> phone) instead.


Right, the European solution, send the Tx to the phone by SMS and get
the user to type in a code that authenticates that Tx only.


Pop quiz:  does the SMS/Tx system still work if we strip HTTPS off the
browser?


> I like the trade-off.  Using another untrusted path on
> a different network and machine for a probabilistic guarantee seems more
> reasonable to me than trying to build a trusted path on a single
> machine, which was ambitious at the best of times, before we knew for a
> fact that we can not trust a single embedded integrated circuit in any
> device in the world.  And that is not even considering the usability and
> accessibility issues of all the fancy trusted path solutions that I've
> seen.
> 
> Security researchers can not even guarantee that the status light of the
> camera is on when it is recording images.



iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to