Re: [Cfrg] aPAKE Analysis

[Björn Haase <[e-mail]>]

Hi Jonathan,

we seem to have very different use-cases.

>You write on slide 22 that the user expects the dialogue immediately on the Hello Retry,
>but very few users will be familiar with that flow.
>They expect to see a fully rendered page with two boxes in which they are to type their
>username and password, not an undecorated pop-up.

Indeed what I am suggesting is to have this login page displayed as part of browser controls or even better by OS or a password manager’s controls and not by the remote server’s html.

I could imagine that one possibly could add some small SVG icon on the login screen (that’s what we do for our E+H Bluetooth app) but indeed the login window might be rather un-decorated, as it is part of the browser GUI/skin. Making it part of a window external to the https:// main application region could also be considered a security feature. The end-user could more easily distinguish a control from the browser/OS from what is shown in the browser application.

A user might even choose his own skin (unknown to the adversary) of the window, making phishing attacks more difficult. The attacker would have to find out, how the specific user’s login window looks like.

In our setting this would be perfectly suitable from a usability point of view.

Also one of our main problems is that we could not expect the server to have any valid Web-Certificate installed! Thus, for some IoT device for which a web certificate was not bought and maintained, we would just not have the option to establish any https:// connection through the normal WEB-PKI certificate process! A well-configured browser would just not allow for a connection!

>Training users in this system will also make them more vulnerable to malicious sites that render a >blank page and throw a pop-up asking for a username and password.

I don’t see that there would be any need for “user training” for the “login window in browser” feature. Moreover a site screen should (IMO) not be considered to provide *any* security feature. Any “reasonable” attacker would make his fishing web page look just like the honest server!

>From a user's perspective,  they go to a website that renders normally, and then they then login using >a username and password box.

As mentioned before this approach mandatorily requires a valid Web-PKI certificate in the first place. Secondly this approach would allow an attacker to just use a normal http:// GUI control for standard un-protected text for fishing the password. How would the user be able to distinguish a web page that sends the clear-text password directly to the server from a page that uses a secure aPAKE?

In my opinion a solution using a specific browser or OS-based GUI window for the login could be made more secure. A small site icon might be fine, but this could possibly even be sent by the server in its HelloRetry when using an appropriate compression format such as SVG.

The main problem that I see with your suggestion is that it works only, if the server has a valid trusted Web-PKI certificate *in addition* to the aPAKE solution.

This might be the case for some “conventional” Web-Applications, but not the case for de-centralized Web servers in IoT devices (e.g. a control valve in an industry installation or some household IoT equipment).

Yours,

Björn.


Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone] | Fax: [phone]
[e-mail] |  www.conducta.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.