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-04 23:54 |
| Reporter | vecirex | Assigned To | |||
| Priority | high | Severity | tweak | Reproducibility | always |
| Status | new | Resolution | open | ||
| 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 | new | Config option for support contacts needed |
|
|
@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-insenstivie, too. |
| 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 |
