View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010401 | Taler | merchant backend | public | 2025-09-12 17:34 | 2025-10-16 21:52 |
| Reporter | sebasjm | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Summary | 0010401: do not ask mfa timeout for the same AC | ||||
| Description | similar to "timestamp_timeout" on sudo if the merchant backend has already ask for MFA it should not ask for a period of time, configurable in taler-merchant.conf similar to sudo timestamp_timeout this is problematic when creating an account, is being ask 3 times on (1) account creation (2) login (3) adding a bank account. my suggestion is to associate with the access token as follows: * between (2) and (3) we have the access token than can be used as link for which the MFA should not be asked. * between (1) and (2) we don't have a token but the account creation already provides the password so maybe the endpoint for self-provision can return an access token? (just for the sake of not asking mfa in the login step) not sure, or maybe the login endpoint can receive the challenges IDs solved by the account creation step, (re using the recently solved challenges) * the ac token can be marked as 'mfa validated' with true/false * the timestamp_timeout can be translated into the token duration (when the server is asked for a token with duration X and timestamp_timeout is Y the server reply the token with duration min(X,Y) ) * when the SPA refresh the token the 'mfa validated' is NOT carried on to the next token | ||||
| Tags | No tags attached. | ||||
| related to | 0010498 | resolved | sebasjm | merchant should log in user after self provisioning |
| related to | 0010497 | resolved | Christian Grothoff | merchant backend should allow adding first bank account without requiring 2FA |
|
|
I like more the idea of associating the timeout with the challenge ID instead of the access token. If the "timestamp_timeout" is implemented as challenge duration and that duration also in the response then I can save those challenge ID in the localStorage of the SPA and reuse is for some new request and the server can decide if those challenge are good enough or the client requires new ones. |
|
|
another place when this is problematic is on the "change password page". Here when the user hit 'change password' button the SPA will: 1) test the old pwd with https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-private-token 2) update the password if this is valid https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-private-auth 3) create the new AC with the new pwd https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-private-token Step 1 is there because allowing user to change the PWD without knowing the old one is a security issue (someone can change your pwd if the session was one in a minute of distraction) and the `private/auth` API doesn't ask for it Step 3 is there because there was the idea that changing the password will invalidated previous tokens (not sure if this is true) So __maybe__ I can remove those and only keep step (2) but not ideal. |
|
|
Actually, this is by design and IMO shouldn't actually change. As for over-doing it, we can consider exceptions, like if no bank accounts are configured yet, no MFA needed (but then require it on account deletion?). For your last example, right now changing the password does NOT invalidate tokens. Also, you can still do (1) and if you get back 202 accepted you know the password is valid! You just don't get a new token. Easy! |
|
|
On the sequence of "(1) account creation (2) login (3) adding a bank account." -- I think it's OK, users *rarely* create accounts, and it's not bad if they immediately learn that they need the 2nd factor to login. As for (3), I think it's still good and we actually should start sending the account that is being added in the message sent to the user, so that it's super-clear what they'd be authorizing, like if they have a malicious MiTM-SPA! |
|
|
> I think it's OK, users *rarely* create account No, this is the FIRST impression of the person trying to create an account and maybe the most critical. If an user is being ask 3 times in less than a minute about "is this really your phone number?" is a really bad ux. Don't event considering that SMS may be charged or email can go to spam. In a v2 I would like to have only ONE form and the 3 steps being completed in one click (the spa calling all the endpoints for the 3 steps) so the user know upfront all the information needed. Without changing the design this kind of solutions are impossible.. here or elsewhere. > super-clear what they'd be authorizing, like if they have a malicious MiTM-SPA! Not sure, the challenge is authorized in the SPA and if you reload you have to start it again (receiving a new code). You can't ACK from the email/phone out of context from where the operation started so is really hard for the user taking the code and going again into the web page and not knowing what is actually executing. IF this is a problem this needs to be solved in the SPA UI. I still hold the suggestion of changing the design for better UX. |
|
|
0010498 was a hacky way of to solve this: - adds a request param that sigan the server that the client wants a login token - the request param is not a duration, doesn't allow "forever" (which is the default duration for the spa) - can't specify scope and description of the token (so a token creation will be necessary after) |
|
|
Well, we can easily allow the duration to be specified as 'forever', and to pass additional arguments for the scope. Note that a description is automatically generated. I'm not sure how useful all of these are, as the scope is set to SPA, which is almost always what you want after creating an instance, and the description is set appropriately as well. So not sure how useful it would be to ask the user even more questions during setup to set these to something else. Now, maybe you can apply i18n to the description in the SPA (since you have the language and the backend does not!). Regardless, I really don't see us adding scope, duration or description to the SPA. So are these truly useful to add to the protocol? I can do it... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-09-12 17:34 | sebasjm | New Issue | |
| 2025-09-12 18:03 | sebasjm | Note Added: 0025902 | |
| 2025-09-12 19:49 | sebasjm | Note Added: 0025903 | |
| 2025-09-13 00:26 | Christian Grothoff | Note Added: 0025904 | |
| 2025-09-13 00:29 | Christian Grothoff | Note Added: 0025905 | |
| 2025-09-13 00:29 | Christian Grothoff | Status | new => acknowledged |
| 2025-09-17 21:14 | sebasjm | Note Added: 0025938 | |
| 2025-10-14 20:00 | sebasjm | Relationship added | related to 0010497 |
| 2025-10-16 16:25 | sebasjm | Relationship added | related to 0010498 |
| 2025-10-16 16:28 | sebasjm | Note Added: 0026189 | |
| 2025-10-16 21:52 | Christian Grothoff | Note Added: 0026190 |
