[Cryptography] SRP for mutual authentication - as an alternative / addition to certificates?

Carlo Contavalli ccontavalli at gmail.com
Tue Aug 4 22:24:40 EDT 2015


On Tue, Aug 4, 2015 at 6:57 PM, Ben Laurie <ben at links.org> wrote:
> On Tue, 4 Aug 2015 at 18:09 Carlo Contavalli <ccontavalli at gmail.com> wrote:
>>
>> On Mon, Aug 3, 2015 at 8:19 PM, Tony Arcieri <bascule at gmail.com> wrote:
>> > On Sun, Aug 2, 2015 at 9:54 AM, Carlo Contavalli <ccontavalli at gmail.com>
>> > wrote:
>> >>
>> >> Are there / why are not similar technologies used for web?
>> >
>> > Two words: user experience
>> >
>>
>> It's 2015 - I'm sure we could figure something out?
>>
>> Without thinking much...
>
>
> Right, because why bother to think about one of the longest standing
> security problems we have on the 'net? Obviously you should be able to fix
> that in your sleep.

meh :-( I just associated "user experience" with the stigma associated
with http authentication and various schemes based on it, which, among
many other drawbacks, look horrible to the end user, and just lead to
bad user experience.

But the bad user experience is not implicit to the use of an
authentication scheme, imho it's more the result of old standards,
lack of investment / interest / push in the implementations and
implicit difficulty of changing the current status.

> How about you don't think about this much: how do you prevent phishing in
> your scheme?

What I had in mind is the browser has built in support for
<authentication>. Just like the "https lock" or "green url bar", which
can hardly be manipulated by javascript or other code in the page,
presence of <authentication> tags results in a graphic feature _on the
browser_ that can't be manipulated by server provided code.

For example, URL bar becomes thicker, and displays an "username" and
"password" with a "lock next to it".

With a scheme like SRP, once the user presses enter to confirm
username and password, _the browser_ tries to perform SRP
authentication with the remote site. If the site is not who it claims
to be, or not the site the user registered against, authentication
would fail. Without disclosing the password of the user, and making it
really hard for a site to impersonate a different one.

The cost on the user is in making sure he is entering the username and
password only in "secure boxes", rather than random ones on the web
site.

Again, x509 and certificates would still play an important role, but
would reduce the surface of attack on returning users?

There is no perfect solution of course... is the incremental benefit
worth the work?

Carlo


More information about the cryptography mailing list