[bug] can't go back to login screen if timeout of 2 password login reached

[thiswillbeyourgithub]

Hi,
I found a very small unexpected behavior. When loginng in using the two passwords method if too much time has elapsed between the two inputs PM will refuse the login and ask to re enter the first password. However there is no way to go back to the first login screen in the app (as far as I know) so the only way to login is to restart the app which is a minor annoyance.
I'm thinking the easiest way to fix it is to automatically reload the first login page after some time if the second password has not been entered.
Thanks for taking the time to read :)

[kontrollanten]

Thanks for reporting! I think that to automatically reload the first page if the second password hasn't been entered within a time interval may be a fragile solution. Even though I don't have any other good solution on my mind right now. Maybe we should add a button to reload the webview, that may help in other cases when the user wants to "reset" the state of the webview.

[thiswillbeyourgithub]

I agree it could be a fix for other problems too to add a reload button. Thanks :)

[kontrollanten]

I'll address that to @beatplus who's the UX star in the team.

[thiswillbeyourgithub]

@beatplus I would think that adding a "reload arrow" at the bottom left of the screen would be a good and esthetic use of the left bar otherwise just used by the accounts icon at the top (btw too bad we can't hide this bar, what a pity for those who use only one account) but I have no training whatsoever in UX :) xoxo

[mtaberna]

Hi!

Thanks for reporting and for the feedback. We can definitely add a refresh button or we could add a refresh option inside the tab's right click.

What are your thoughts?

[mtaberna]

Ps. There is a development version which allows to hide the tab

[thiswillbeyourgithub]

If you're the "UX star" you are definitely more qualified than me to ponder the best solution :) so I leave it up to you (that being said, I think both options would go well together ;) )

[mtaberna]

My UX experience is conspicuous by its absence, I'll locally test both approaches and decide then

[vladimiry]

Speaking of UX. Addition approach is implementing the automatic login, that would be able to handle all the scenarios: password, master password, and 2FA code.

[kontrollanten]

@vladimiry The drawback with that approach is that we need to handle the storage of the users details on their computers, which can open up for a lot of security issues.

[thiswillbeyourgithub]

If I may, the trade-off between "not typing one/two password/s" and "storing locally your password" is absolutely not worth it. Plus typing it repeatedly helps to memorize long ass passwords.

Also, wouldn't it defeat the purpose of 2FA than being able to login without entering anything ?

[vladimiry]

Consider the following arguments:

1. The desktop app keeps the accounts credentials encrypted. So a user can decrypt the accounts store only knowing the master password. So there is a need to remember a single master password rather than remembering all the passwords and dealing with 2FA tokens for all the accounts you added into the app. Such feature, in my opinion, would significantly improve the UX and it's a secure approach that doesn't weaken the security.
2. The UX can be improved even further with remembering the master password in the system's Keychain / Credential Vault. Of course, this option would be disabled by default and there would be an easily noticeable alerting hint: enabling this option weakens the security, so at your own risk. This is, for example, the same approach your browser goes with if you allow it to remember the passwords, with the only difference that you don't always see an alerting hint.

Also, wouldn't it defeat the purpose of 2FA than being able to login without entering anything ?

It would indeed not defeat the purpose of 2FA. The app would keep the 2FA secret seed in the encrypted store, close to the account's credentials. A secret seed is a piece of data that you see encoded in the form of QR code scanning it with your phone. So you can think as the desktop app acts exactly in the same way as your phone does. And it's indeed would be the absolutely same approach that phones go with since phones store your secret seed too and I guess in some cases depending on the used program your 2FA secret seed is not even encrypted on the phone, besides some 2FA phone programs even send your secret seed to the internet!

[kontrollanten]

@vladimiry I agree on your second argument. As long as it's disabled by default and that it informs the user that it will weaken the security, I think that can be a good option.

I think that many people avoids encrypted email because it's complexity, so if the choice is between weakened ProtonMail vs Gmail, I think weakened ProtonMail is a better choice.