View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010401 | Taler | merchant backend | public | 2025-09-12 17:34 | 2025-09-13 00:29 |
| 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. | ||||
|
|
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! |
| 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 |
