View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011198 | Taler | merchant backoffice SPA | public | 2026-03-04 23:23 | 2026-03-06 15:37 |
| Reporter | vecirex | Assigned To | |||
| Priority | low | Severity | text | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Target Version | post-2.0 | ||||
| Summary | 0011198: Design Document for password reset flow needed | ||||
| Description | As seen today during a 1:1 meeting w/ @cm_7, the current PW reset workflow has various issues; we also guess that already in one case of an interested customer, the current workflow created issues: 1. By saying, one wants to have the PW reset, the user is directly prompted to just set a new password for any given username; we think, this is unusual and might create a wrong sense of security even if immediately after doing this, two additional factors (for my.taler-ops.ch: email and SMS) are required (no longer an issue: no button pressing needed anymore; automatic delivery). 2a. If the wrong username was picked in 1. (as it exactly happened twice for @cm_7 himself, trying to reset an own instance on my.taler-ops.ch), you can still enter a new password; only after this was done, query is done if the instance denoted by username exists. For a real-world merchant this certainly is annoying and we believe the interested customer mentioned above might not have known anymore exactly what the username was. 2b. As a subproblem, we also saw that the username is case-sensitive, which is also unusual; usernames and thus instances like "company", "Company" or "COMPANY" (and everything in between) should denote the same instance, given also URLs are case-insensitive. Also a real-world customer might not know anymore if he used capital letters (e.g., as the first letter) or not. Having the current error, the instance doesn't even exist if not entered exactly the same way as when the instance was created, can lead to some kind of panic, if the merchant already has many transactions and tries to login to see them. 3a. By doing 2. repeatedly (and this can be automated), incentive might created to query for existing instances. 3b. Of course, by looking at the payment URL of merchants which are open about having Taler as a payment system, existing instances can also be found out; if such a list is collected, DoS can be carried out, annoying at least users. If 3. to be solved in deployment: Additional ticket should be created here to introduce a rate limiting; also a FLOSS captcha which cannot easily be solved by "AI" systems might be of use. Suggestions: - MFA auth codes should be entered before being able to set any new password; other services send out links to have the password reset, we don't need this, but 1. is really a strange approach, also (typically) not found in the wild. We should rather stick to patterns which are known. - It needs to be decided if 3. is a problem; if we decide, it's not, it should not be possible to enter a password for an instance where the system already knows it won't work out. This will certainly annoy real-word customers, which might think about setting a new (nice) password, and then everything just vanishes. | ||||
| Tags | No tags attached. | ||||
| related to | 0011199 | assigned | Christian Grothoff | Config option for support contacts needed |
| related to | 0010401 | acknowledged | do not ask mfa timeout for the same AC |
|
|
@cm_7: I added you as observer, as you need to be able to help out customers; and you can also participate in a user-friendly solution of this! :) |
|
|
Add point 2b.; subproblem. Maybe additional ticket needed, as also related to taler-merchant DB: instances' names / id names should be case-insensitive, too. |
|
|
I agree 1. can be changed in the SPA asking the username again but using what you have in the login form by default (essentially allowing to modify it but also showing that this is the user) Looks like people don't read the title ;) 2a. can be change in the SPA by querying the backend when the user clicks "forgot password". Then we prevent showing the reset form if the user doesn't exist > MFA auth codes should be entered before being able to set any new password I think is a good point: don't make the user type the password before verify since the verification can fail. By how the MFA is implemented there is no way to ask for the password AFTER the MFA is completed because solving the challenge allows to repeat the original request with the __same payload__. I have argue to make it work like `sudo` to be able to reuse the a validated access token for a period of time. See 0010401 But it will also require some other changes. |
|
|
On 2b: URLs are *not* case-insensitive -- only domain names are. As for asking for the password last, **that** would be insecure. Sure, lots of sites do this, but that's actually less secure. Basically, an attacker can have you go through the entire process and only grab the last credential and change your password with just a single factor. With our approach, we require the user to commit to what they want to do (and can in each MFA authentication step refer to the full change the user will eventually approve). Now, we can argue if this level of security is needed, but it is actually better if the backend could give the user details (we could, for example, share a random letter of the future password in the SMS) about the change that is about to be authorized instead of having the user pass some challenges with limited (or even no knowledge) of what they are actually authorizing. |
|
|
On 2a: There are systems that give you even less information. We already decided that it was acceptable to leak the existence/non-existence of the account here. Giving out a list of all accounts in the system so people can more easily attack them is going to far. The alternative would have been to just ask for the TANs (without sending any) and always returning 403 forbidden instead of 404. That'd be even more secure (no information leakage), so went for allowing 404, but telling users what logins are available is too much. |
|
|
3b: I don't see a DoS potential here. That's nonsense. Rate limiting exists, just inside MFA, not for the main page. |
|
|
*IF* case-sensitivity is an issue, I think the best way to solve it might be in the SPA, basically forcing it to lower-case all entered usernames/login names. The backend can stay case-sensitive, and normal users would implicitly always use lower-case. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-03-04 23:23 | vecirex | New Issue | |
| 2026-03-04 23:23 | vecirex | Description Updated | |
| 2026-03-04 23:25 | vecirex | Note Added: 0027991 | |
| 2026-03-04 23:35 | vecirex | Description Updated | |
| 2026-03-04 23:35 | vecirex | Note Added: 0027992 | |
| 2026-03-04 23:38 | vecirex | Description Updated | |
| 2026-03-04 23:38 | vecirex | Description Updated | |
| 2026-03-04 23:40 | vecirex | Description Updated | |
| 2026-03-04 23:51 | vecirex | Relationship added | related to 0011199 |
| 2026-03-04 23:54 | vecirex | Description Updated | |
| 2026-03-04 23:54 | vecirex | Description Updated | |
| 2026-03-05 13:14 | sebasjm | Note Added: 0027998 | |
| 2026-03-05 13:16 | sebasjm | Relationship added | related to 0010401 |
| 2026-03-06 02:03 | vecirex | Note Edited: 0027992 | |
| 2026-03-06 15:30 | Christian Grothoff | Note Added: 0028014 | |
| 2026-03-06 15:33 | Christian Grothoff | Note Added: 0028015 | |
| 2026-03-06 15:35 | Christian Grothoff | Note Added: 0028016 | |
| 2026-03-06 15:36 | Christian Grothoff | Note Added: 0028017 | |
| 2026-03-06 15:37 | Christian Grothoff | Priority | high => low |
| 2026-03-06 15:37 | Christian Grothoff | Severity | tweak => text |
| 2026-03-06 15:37 | Christian Grothoff | Status | new => acknowledged |
| 2026-03-06 15:37 | Christian Grothoff | Target Version | => post-2.0 |
