Improve change password dialogue

[te-online]

Recently, a user came to me saying that he couldn't change his password.
Only later I found out that he pressed the “change password” button before even typing, because to him the inputs looked disabled.

The biggest issue is probably that we don't have labels here. I stumbled upon this myself, entering two times the new password, not seeing that the first field requires the current password.

Suggestions for optimization:

• Add labels to the input fields.
• Create two input fields for the new password, to make sure you typed it correctly.
• Ask for the current password with a modal dialogue like in the App Store when installing an app.

current change password form on the »personal« page

I know it would be really great to have a pull-request from me, but I can't do it at the moment – maybe someone else feels that this is an issue, too, and has the resources to quickly fix it. 😊 😳

@eppfel @jancborchardt ?

[nickvergessen]

Sounds good to me

[mallory]

I just want to bump @floeschie's issue on the usability flaw in hiding the password reset link until after a failed attempt. The login page must have the password reset link visible at all times. This is expected behaviour. Without it, administrators like me are spending too much time helping our users gain access. Not to mention that it subtly reinforces to new users (which is most users) that this new platform is too hard for them. Thank you!

[simison]

Heya @te-online and others! 👋

I feel like I could grab this as my first Nextcloud issue as I like to work both with code and design.

Looking at the code it looks like it would need a good overhaul, but I don't want to get too deep into it. I'm sure there are other more important issues to work on!

I'll do:

• Move labels from inputs to over the field and leave inputs empty
• add visibility toggle to old password field as well
• disable input button until both passwords are filled

Probably (not):

• add 3rd input field to confirm new password

Question:

• Does this need to support IE9 anymore? Edit: nope, IE11+

[jancborchardt]

@simison great! :) Agree with your suggestion for solution, and also with your doubt about adding a 3rd field (since we have the option to make the password visible).

[simison]

since we have the option to make the password visible).

and there's always the password recovery (and I second @chaoticfree, it should be visible at login page without needing to type in wrong pass). I didn't find an issue for that tho.

[nickvergessen]

and there's always the password recovery

Sadly not, 1. depends on the user backend, 2. with encryption enabled and without master key you just loose everything...

We could also just have new password and confirm and then use the modal which you have to enter when you are logged in for too long already.

[simison]

We could also just have new password and confirm and then use the modal which you have to enter when you are logged in for too long already.

True! On the other hand majority of apps/sites asks for the old password first and then new one. Mixing this other way around might be confusing as users expect to see an input for old password in the form.

WDYT? I'm not strongly invested in this so either way is fine! Just wanted to point this out.

Do you know where I could look for the code how to implement such modal?

[nickvergessen]

OC.Dialogs is the magic word in JS source code:

server/core/js/js.js

Line 1655 in 65d52a1

OC.PasswordConfirmation = {

server/core/js/oc-dialogs.js

Line 28 in a2f6fea

var OCdialogs = {

[te-online]

We could also just have new password and confirm and then use the modal which you have to enter when you are logged in for too long already.

True! On the other hand majority of apps/sites asks for the old password first and then new one. Mixing this other way around might be confusing as users expect to see an input for old password in the form.

Honestly, I can't tell if this idea is going to be confusing. I think, what we know is that the current implementation is confusing, because the current layout suggests a lot of stuff that isn't true (e.g. the two equally spaced input fields suggest you have to enter a new password twice here, because this pattern is known from other sites).

Personally, I would prefer two input fields to check whether you can actually type the password consistent repeatedly. It's an established pattern and users know and like or dislike it. I'd like to point out that it can be really frustrating to choose a complex password, save it and only notice when you re-login that the password you typed wasn't what you expected it to be. The double-check can mitigate a lot of these cases. And if you're using a password manager, you can fill in both fields at the same time automatically.

Regarding the „old password“ field: From a security perspective it might make sense to have such field. Although I wouldn't ask for the old password when the user just came from the login screen. This might be the use-case for a modal authentication box: Asking for re-authentication when changing your password is not done shortly after you authenticated yourself. But distinguishing between such cases can be a philosophy in itself. Just consider the case where an attacker gets your password, the first thing they'll do is change it – bottom line: We can only guess when it's safe to not ask for the old password, except:

• We could have general guidelines on when to re-ask for authentication that are based on some basic heuristics (e.g. x minutes after login)
• We could estimate the security implications of not asking for the old password

Unless none of the both exceptions is fulfilled, I'd argue for having one “old password” field and two input fields for the new password. Both have to be visually identifiable as what they do and between both blocks we need spacing to show that they ask for different things.

@simison Very cool that you're looking into this as your first nextcloud coding experience 😊

[simison]

@te-online thanks! :-)

think, what we know is that the current implementation is confusing, because the current layout suggests a lot of stuff that isn't true (e.g. the two equally spaced input fields suggest you have to enter a new password twice here, because this pattern is known from other sites).

Valid point! Thanks. So I think it's fair to summarise discussion, all things considered, the form should look like this:

[old] [new] [new confirm] [submit]

...this also seems like the quickest way to get this fixed without fiddling with modals. That can be the next improvement in some other PR.

Although I wouldn't ask for the old password when the user just came from the login screen.

I like the sentiment to make it easier for the user, but this would just make the feature way more complex to implement and it's better & safer to keep things simple.

Additionally not asking for old password is always a security issue (exploited via XSS or "forced browsing" vulnerabilities). Especially since I don't see any CSRF tokens being sent together with the password.

Password should always be asked when changing anything that can be used to gain access to the account (e.g. email or username).

---

(Yeah I know this discussion might seem like bikeshedding, but since this is a security feature, it's important.)

[jancborchardt]

Again: Needing to repeat a password is annoying, just like the pattern of repeating an email.

We will have a field for "Current password" and one for "New password", both with labels above the fielda and the eye-toggle to make the password visible.

[nickvergessen]

For email I agree completly. But for password seriously no one will use the eye button. They assume they didn't mistype ... AND their files are encrypted without a way to recover them...

I'd really prefer to have a confirmation when encryption is on, with recovery key being of. To get rid of those reports....

[te-online]

@jancborchardt Consider the fact that a user doesn't change a password very often. In my opinion the small amount of time spent to retype the password and the small annoyance outweigh the time to spend and the annoyance happening if you change your password to something unintentional. I'm with you in simplifying interfaces and getting rid of annoying processes, where it touches crucial day-to-day tasks, but I still believe that this annoying pattern has a value here.

That said, I appreciate any optimization of the form.

[jancborchardt]

@nickvergessen so when encryption is on, we could display a second field. But considering the small fraction of users who use encryption, this should not intrude on the regular UX.

[eppfel]

the small annoyance outweigh the time to spend and the annoyance happening if you change your password to something unintentional

This. Sometimes you have to stop the user or make him think about his action...

[MorrisJobke]

See also #5181 where it is highlighted, that the password input would be useful for accounts with encryption enabled.

[skjnldsv]

@skjnldsv skjnldsv self-assigned this on 25 Feb 2018

I need to stop doing that

[CarlSchwan]

Done with #33429