commit 4308863d8255d66cc635de39d1d6828fddbe794f parent 9c0c8489e6458c76f3b44ee366abe82cc14c2a13 Author: Christian Grothoff <christian@grothoff.org> Date: Tue, 11 Aug 2026 13:31:35 +0200 PIN to TAN Diffstat:
28 files changed, 173 insertions(+), 173 deletions(-)
diff --git a/src/challenger/cat-once.sh b/src/challenger/cat-once.sh @@ -3,7 +3,7 @@ # # Like cat.sh, but only for the first challenge: every later invocation # fails without delivering anything, simulating an SMS/e-mail gateway -# that went down between two PIN transmissions. +# that went down between two TAN transmissions. TARGET="$(echo $1 | jq -r ".filename")" if [ -e "${TARGET}.sent" ] then diff --git a/src/challenger/challenger-httpd_challenge.c b/src/challenger/challenger-httpd_challenge.c @@ -141,12 +141,12 @@ struct ChallengeContext uint32_t tan; /** - * How many attempts does the user have left on the current PIN? + * How many attempts does the user have left on the current TAN? */ uint32_t pin_attempts_left; /** - * How many times may a PIN still be transmitted for this validation? + * How many times may a TAN still be transmitted for this validation? */ uint32_t pin_transmissions_left; @@ -177,7 +177,7 @@ struct ChallengeContext bool address_refused; /** - * Should we retransmit the PIN? + * Should we retransmit the TAN? */ bool retransmit; @@ -192,7 +192,7 @@ struct ChallengeContext bool db_finished; /** - * True if we handed a new PIN to the transmission helper and it still + * True if we handed a new TAN to the transmission helper and it still * needs to be confirmed in the database once the helper succeeded. */ bool pin_pending; @@ -305,7 +305,7 @@ reply_error (struct ChallengeContext *bc, /** - * Function called when our PIN transmission helper has terminated. + * Function called when our TAN transmission helper has terminated. * * @param cls our `struct ChallengeContext *` * @param type type of the process @@ -460,7 +460,7 @@ send_tan (struct ChallengeContext *bc) char *cmsg; GNUNET_asprintf (&cmsg, - "PIN: %u", + "TAN: %u", (unsigned int) bc->tan); msg_len = strlen (cmsg); msg = cmsg; @@ -502,7 +502,7 @@ send_tan (struct ChallengeContext *bc) bc->cwh = GNUNET_wait_child (bc->child, &child_done_cb, bc); - /* The PIN is now in the hands of the helper; if it terminates + /* The TAN is now in the hands of the helper; if it terminates successfully, the main handler promotes it in the database. */ bc->pin_pending = true; MHD_suspend_connection (bc->hc->connection); @@ -1099,23 +1099,23 @@ CH_handler_challenge (struct CH_HandlerContext *hc, If merely the cooldown blocks the transmission, we fall through and report "transmitted":false with the retransmission_time. */ GNUNET_log (GNUNET_ERROR_TYPE_INFO, - "PIN transmission limit exhausted for this validation\n"); + "TAN transmission limit exhausted for this validation\n"); return reply_error (bc, MHD_HTTP_TOO_MANY_REQUESTS, TALER_EC_CHALLENGER_TOO_MANY_PIN_TRANSMISSIONS, - "client exceeded authorization attempts limit (too many PINs)"); + "client exceeded authorization attempts limit (too many TANs)"); } if (bc->retransmit) { GNUNET_log (GNUNET_ERROR_TYPE_INFO, - "Transmitting PIN\n"); - /* (Re)transmit PIN/TAN */ + "Transmitting TAN\n"); + /* (Re)transmit TAN */ send_tan (bc); if (GNUNET_YES == bc->suspended) { GNUNET_log (GNUNET_ERROR_TYPE_INFO, - "Suspending request after PIN transmission\n"); + "Suspending request after TAN transmission\n"); return MHD_YES; } /* Did we already try to generate a response? */ @@ -1128,9 +1128,9 @@ CH_handler_challenge (struct CH_HandlerContext *hc, if (bc->pin_pending) { - /* The helper terminated successfully (checked above), so the PIN really - went out and only now becomes the PIN we accept. Had the helper - failed, we returned 502 above and the previous PIN (if any) remains + /* The helper terminated successfully (checked above), so the TAN really + went out and only now becomes the TAN we accept. Had the helper + failed, we returned 502 above and the previous TAN (if any) remains valid. */ bc->pin_pending = false; for (unsigned int r = 0; r<MAX_RETRIES; r++) @@ -1159,7 +1159,7 @@ CH_handler_challenge (struct CH_HandlerContext *hc, "do_challenge_address_confirm_pin"); case GNUNET_DB_STATUS_SUCCESS_NO_RESULTS: /* Validation was solved or removed while we were transmitting; - there is nothing to promote, but the PIN did go out. */ + there is nothing to promote, but the TAN did go out. */ GNUNET_break_op (0); break; case GNUNET_DB_STATUS_SUCCESS_ONE_RESULT: diff --git a/src/challenger/challenger-httpd_config.c b/src/challenger/challenger-httpd_config.c @@ -36,7 +36,7 @@ * 7: added ``build_version`` field in ``/config`` * 8: HTTP status code and error code corrections: /token no longer * returns 409 and /info no longer returns 404; /solve tells a wrong - * PIN from one that could not be checked at all and answers every + * TAN from one that could not be checked at all and answers every * failure with the same body shape; /challenge and /solve use distinct * error codes for each way of running out of attempts; address * restrictions have their own error codes and a restriction we cannot diff --git a/src/challenger/challenger-httpd_solve.c b/src/challenger/challenger-httpd_solve.c @@ -63,7 +63,7 @@ struct SolveContext char *client_redirect_uri; /** - * 0-terminated PIN submitted to us. + * 0-terminated TAN submitted to us. */ char *pin; @@ -334,7 +334,7 @@ CH_handler_solve (struct CH_HandlerContext *hc, /* Only give up if *no* option remains: a /challenge retransmission resets auth_attempts_left to 3, so as long as the user may still - request another PIN transmission they can still succeed. */ + request another TAN transmission they can still succeed. */ if ( (0 == bc->addr_left) && (0 == bc->auth_attempts_left) && (0 == bc->pin_transmissions_left) ) @@ -349,35 +349,35 @@ CH_handler_solve (struct CH_HandlerContext *hc, ec = TALER_EC_CHALLENGER_TOO_MANY_ATTEMPTS; } /* Distinguish the three ways in which a /solve can fail. Only the - last one is actually about the PIN that was submitted; reporting - the other two as "the PIN code provided is incorrect" misleads + last one is actually about the TAN that was submitted; reporting + the other two as "the TAN code provided is incorrect" misleads the user. Each gets its own error code so that the user agent can - tell "provide your address first" from "wait or ask for a new PIN" - from "that PIN was wrong" without parsing the human-readable + tell "provide your address first" from "wait or ask for a new TAN" + from "that TAN was wrong" without parsing the human-readable hint. */ else if (no_challenge) { - /* No PIN was ever transmitted for this validation, so there is + /* No TAN was ever transmitted for this validation, so there is nothing to check; the user must POST /challenge first. */ GNUNET_log (GNUNET_ERROR_TYPE_INFO, - "PIN submitted before any challenge was transmitted\n"); + "TAN submitted before any challenge was transmitted\n"); http_status = MHD_HTTP_CONFLICT; ec = TALER_EC_CHALLENGER_NO_CHALLENGE_TRANSMITTED; } else if (exhausted) { - /* The PIN was not even looked at: no attempts left for it. The + /* The TAN was not even looked at: no attempts left for it. The user may still request a retransmission (otherwise we would have taken the terminal branch above). */ GNUNET_log (GNUNET_ERROR_TYPE_INFO, - "No attempts left to check the PIN\n"); + "No attempts left to check the TAN\n"); http_status = MHD_HTTP_TOO_MANY_REQUESTS; ec = TALER_EC_CHALLENGER_NO_PIN_ATTEMPTS_LEFT; } else { GNUNET_log (GNUNET_ERROR_TYPE_INFO, - "Invalid PIN supplied\n"); + "Invalid TAN supplied\n"); http_status = MHD_HTTP_FORBIDDEN; ec = TALER_EC_CHALLENGER_INVALID_PIN; /* The stored procedure only reports 'exhausted' on the request diff --git a/src/challenger/challenger.conf b/src/challenger/challenger.conf @@ -30,7 +30,7 @@ VALIDATION_DURATION = 1d # How long is an validation valid? VALIDATION_EXPIRATION = 365d -# Minimum time between two (re)transmissions of the PIN/TAN to the +# Minimum time between two (re)transmissions of the TAN to the # same address. The user may request the challenge be re-sent, but # not more often than this. Must be (much) smaller than # VALIDATION_DURATION. diff --git a/src/challenger/default-challenge-message.txt b/src/challenger/default-challenge-message.txt @@ -1 +1 @@ -Please enter the PIN {{pin}} to verify your address. +Please enter the TAN {{pin}} to verify your address. diff --git a/src/challenger/test-challenger-exhaustion.conf b/src/challenger/test-challenger-exhaustion.conf @@ -9,9 +9,9 @@ ADDRESS_TYPE = file-access # Base URL BASE_URL = http://localhost/ -# Short cooldown so that the exhaustion test can exercise a PIN +# Short cooldown so that the exhaustion test can exercise a TAN # retransmission without sleeping for minutes: the test waits the cooldown -# out once, to re-transmit a PIN for an address it does not change. Do +# out once, to re-transmit a TAN for an address it does not change. Do # not go below 1 s: with a sub-second frequency # '/authorize' aborts the daemon on an unguarded GNUNET_JSON_pack_timestamp. PIN_RETRANSMISSION_FREQUENCY = 5 s diff --git a/src/challenger/test-challenger-exhaustion.sh b/src/challenger/test-challenger-exhaustion.sh @@ -2,11 +2,11 @@ # This file is in the public domain. # # Regression test for finding 11: '/solve' must not declare the user -# permanently out of options while a PIN retransmission is still available. +# permanently out of options while a TAN retransmission is still available. # # A '/challenge' retransmission resets auth_attempts_left to 3, so a # validation with pin_transmissions_left > 0 can still be completed even -# when both the address budget and the current PIN's guess budget are +# when both the address budget and the current TAN's guess budget are # spent. Answering such a request with "users exhausted all possibilities # of passing the check" is wrong and the SPA presents it as terminal. # @@ -16,14 +16,14 @@ # retransmission to prove that the user really was not out of options. # # Reaching that state exploits that the two budgets are independent: the -# three address attempts of a validation each come with three PIN +# three address attempts of a validation each come with three TAN # transmissions, so spending every address attempt and every guess on the -# PINs they transmitted still leaves transmissions unspent. +# TANs they transmitted still leaves transmissions unspent. # # Also a regression test for finding 12: '/solve' must not answer every -# failure with 403 #TALER_EC_CHALLENGER_INVALID_PIN ("the PIN code +# failure with 403 #TALER_EC_CHALLENGER_INVALID_PIN ("the TAN code # provided is incorrect"). Running out of guesses is reported as 429 -# #TALER_EC_CHALLENGER_NO_PIN_ATTEMPTS_LEFT, submitting a PIN before any +# #TALER_EC_CHALLENGER_NO_PIN_ATTEMPTS_LEFT, submitting a TAN before any # challenge was transmitted is reported as 409 # #TALER_EC_CHALLENGER_NO_CHALLENGE_TRANSMITTED, and 'exhausted' is set on # the response that consumes the last attempt rather than on the one after @@ -132,8 +132,8 @@ function new_validation() { fi } -# submit_address $1=address-suffix. Leaves the freshly transmitted PIN in -# $PIN, whether a PIN was transmitted at all in $TRANSMITTED and the time +# submit_address $1=address-suffix. Leaves the freshly transmitted TAN in +# $TAN, whether a TAN was transmitted at all in $TRANSMITTED and the time # from which the next transmission is allowed in $RETRANSMISSION_TIME. function submit_address() { rm -f "${FILENAME}" @@ -151,12 +151,12 @@ function submit_address() { RETRANSMISSION_TIME=$(jq -r .retransmission_time.t_s < "$LAST_RESPONSE") # Every submission here transmits: changing the address refills the # transmission budget and clears the cooldown, and the retransmission - # at the end waits the cooldown out. Still, only pick up a PIN that + # at the end waits the cooldown out. Still, only pick up a TAN that # was really sent, so that expect_transmitted() below reports the # mismatch rather than awk reporting a missing file. if [ "$TRANSMITTED" = "true" ] then - PIN=$(awk '{print $5}' < "${FILENAME}") + TAN=$(awk '{print $5}' < "${FILENAME}") fi } @@ -188,24 +188,24 @@ function solve() { -w "%{http_code}" -s -o $LAST_RESPONSE) } -# Burn all three guesses for the currently transmitted PIN. +# Burn all three guesses for the currently transmitted TAN. function burn_guesses() { for i in 1 2 3 do - solve "$(( (10#${PIN} + i) % 100000000 ))" + solve "$(( (10#${TAN} + i) % 100000000 ))" if [ "$STATUS" = "200" ] || [ "$STATUS" = "302" ] then - exit_fail "/solve accepted a wrong PIN!" + exit_fail "/solve accepted a wrong TAN!" fi - # A wrong PIN really is a wrong PIN: 403 + CHALLENGER_INVALID_PIN. + # A wrong TAN really is a wrong TAN: 403 + CHALLENGER_INVALID_PIN. if [ "$STATUS" != "403" ] then - exit_fail "/solve: expected 403 for a wrong PIN. Got: $STATUS" $(cat $LAST_RESPONSE) + exit_fail "/solve: expected 403 for a wrong TAN. Got: $STATUS" $(cat $LAST_RESPONSE) fi CODE=$(jq -r .code < "$LAST_RESPONSE") if [ "$CODE" != "9758" ] then - exit_fail "/solve: expected code 9758 (INVALID_PIN) for a wrong PIN. Got: $CODE" + exit_fail "/solve: expected code 9758 (INVALID_PIN) for a wrong TAN. Got: $CODE" fi EXHAUSTED=$(jq -r .exhausted < "$LAST_RESPONSE") LEFT=$(jq -r .auth_attempts_left < "$LAST_RESPONSE") @@ -225,7 +225,7 @@ function burn_guesses() { done } -echo -n "PIN submitted before any challenge was transmitted ..." +echo -n "TAN submitted before any challenge was transmitted ..." new_validation solve "12345678" if [ "$(jq -r .no_challenge < "$LAST_RESPONSE")" != "true" ] @@ -235,7 +235,7 @@ fi CODE=$(jq -r .code < "$LAST_RESPONSE") if [ "$CODE" = "9758" ] then - exit_fail "/solve claims 'the PIN code provided is incorrect' although no PIN was ever sent" + exit_fail "/solve claims 'the TAN code provided is incorrect' although no TAN was ever sent" fi if [ "$STATUS" != "409" ] || [ "$CODE" != "9761" ] then @@ -243,14 +243,14 @@ then fi echo " OK" -echo -n "Driving validation to 'no addresses, no guesses, PIN left' ..." +echo -n "Driving validation to 'no addresses, no guesses, TAN left' ..." new_validation # Each of the three address submissions spends one of the three address # attempts and, because an address change refills the transmission budget -# and clears the cooldown, transmits a PIN for the new address -- which +# and clears the cooldown, transmits a TAN for the new address -- which # sets auth_attempts_left to 3, and burn_guesses spends those three # guesses again. After the third round the validation has no addresses -# and no guesses left, but PIN transmissions to spare. +# and no guesses left, but TAN transmissions to spare. for a in one two three do submit_address "${a}" @@ -270,11 +270,11 @@ then fi echo " OK (addresses_left=${ADDRESSES_LEFT}, auth_attempts_left=${ATTEMPTS_LEFT}, pin_transmissions_left=${TRANSMISSIONS_LEFT})" -echo -n "Wrong PIN must not be answered as terminal exhaustion ..." -solve "$(( (10#${PIN} + 1) % 100000000 ))" +echo -n "Wrong TAN must not be answered as terminal exhaustion ..." +solve "$(( (10#${TAN} + 1) % 100000000 ))" if grep -q "exhausted all possibilities" "$LAST_RESPONSE" then - exit_fail "/solve claims the user is out of options while a PIN retransmission is still available: $(cat $LAST_RESPONSE)" + exit_fail "/solve claims the user is out of options while a TAN retransmission is still available: $(cat $LAST_RESPONSE)" fi echo " OK" @@ -291,14 +291,14 @@ fi echo " OK" # Prove the user really was not out of options: retransmit and solve. -echo -n "Retransmitting the PIN ..." +echo -n "Retransmitting the TAN ..." await_retransmission submit_address "three" expect_transmitted "true" "the retransmission" echo " OK" -echo -n "Solving with the retransmitted PIN ${PIN} ..." -solve "${PIN}" +echo -n "Solving with the retransmitted TAN ${TAN} ..." +solve "${TAN}" if [ "$STATUS" != "200" ] then exit_fail "/solve: expected 200 OK after retransmission. Got: $STATUS" $(cat $LAST_RESPONSE) @@ -319,7 +319,7 @@ do expect_transmitted "true" "the submission of address '${a}'" burn_guesses done -# Spend what remains of the PIN transmission budget. burn_guesses() cannot +# Spend what remains of the TAN transmission budget. burn_guesses() cannot # be reused for the last round: once addresses, transmissions and guesses # are all spent, the response that consumes the final guess is already the # terminal one, so it is a 429 rather than the 403 burn_guesses() expects. @@ -335,7 +335,7 @@ do expect_transmitted "true" "a retransmission while spending the budget" for i in 1 2 3 do - solve "$(( (10#${PIN} + i) % 100000000 ))" + solve "$(( (10#${TAN} + i) % 100000000 ))" done done echo " OK" diff --git a/src/challenger/test-challenger-pinfail.conf b/src/challenger/test-challenger-pinfail.conf @@ -1,6 +1,6 @@ [challenger] -# Delivers the first PIN and then fails, see cat-once.sh. +# Delivers the first TAN and then fails, see cat-once.sh. AUTH_COMMAND = cat-once.sh # What address type are we validating? (SMS, e-mail, etc.) diff --git a/src/challenger/test-challenger-pinfail.sh b/src/challenger/test-challenger-pinfail.sh @@ -1,12 +1,12 @@ #!/usr/bin/env bash # This file is in the public domain. # -# Tests that a failed PIN transmission does not invalidate the PIN the +# Tests that a failed TAN transmission does not invalidate the TAN the # user already received. # -# Regression test: /challenge used to commit the new PIN (overwriting +# Regression test: /challenge used to commit the new TAN (overwriting # last_pin) before forking the AUTH_COMMAND helper, so a helper failure -# returned 502 *and* left the user without a usable PIN until the +# returned 502 *and* left the user without a usable TAN until the # retransmission cooldown elapsed. set -eu @@ -142,7 +142,7 @@ then fi echo " OK" -PIN=$(cat ${FILENAME} | awk '{print $5}') +TAN=$(cat ${FILENAME} | awk '{print $5}') # The helper now refuses to deliver anything (see cat-once.sh). sleep 1.5 @@ -159,28 +159,28 @@ then fi echo " OK" -# The PIN the user got in the first message must still work: the PIN of +# The TAN the user got in the first message must still work: the TAN of # the failed transmission never reached anybody. -echo -n "Solving with the PIN ${PIN} from the delivered message..." +echo -n "Solving with the TAN ${TAN} from the delivered message..." RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code}" -s -o $LAST_RESPONSE) if [ "$RESULT" != "302" ] then - exit_fail "Expected 302 (PIN still valid). Got: $RESULT" $(cat $LAST_RESPONSE) + exit_fail "Expected 302 (TAN still valid). Got: $RESULT" $(cat $LAST_RESPONSE) fi echo " OK" -# The flip side: deferring the new PIN must not keep the *old* PIN alive +# The flip side: deferring the new TAN must not keep the *old* TAN alive # across an address change. A changed address always (re)transmits -- the # change refills the transmission budget and clears the cooldown -- so -# before this patch the PIN on file was replaced in the same call. Now it +# before this patch the TAN on file was replaced in the same call. Now it # is only replaced once the helper confirms, and a helper failure must -# therefore leave the validation with no usable PIN rather than with the -# PIN that went to the address the user just replaced. +# therefore leave the validation with no usable TAN rather than with the +# TAN that went to the address the user just replaced. echo -n "Setup a second validation process..." STATUS=$(curl "${BURL}/setup/${CLIENT_ID}" \ @@ -195,7 +195,7 @@ fi NONCE=$(jq -r .nonce < "$LAST_RESPONSE") echo " OK" -echo -n "Transmitting a PIN for the first address..." +echo -n "Transmitting a TAN for the first address..." STATUS=$(curl "${BURL}/challenge/${NONCE}" \ -X POST \ -H "Accept: application/json" \ @@ -206,7 +206,7 @@ if [ "$STATUS" != "200" ] then exit_fail "Expected 200 OK. Got: $STATUS" $(cat $LAST_RESPONSE) fi -OLD_PIN=$(awk '{print $5}' < "${FILENAME2}") +OLD_TAN=$(awk '{print $5}' < "${FILENAME2}") echo " OK" # The helper refuses to deliver anything from here on (see cat-once.sh); @@ -225,32 +225,32 @@ then fi echo " OK" -echo -n "The PIN of the previous address must not solve the new one..." +echo -n "The TAN of the previous address must not solve the new one..." RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${OLD_PIN}" \ + --data-urlencode "pin=${OLD_TAN}" \ -w "%{http_code}" -s -o $LAST_RESPONSE) if [ "$RESULT" = "302" ] || [ "$RESULT" = "200" ] then - exit_fail "the PIN sent for the previous address attested the new one" + exit_fail "the TAN sent for the previous address attested the new one" fi echo " OK ($RESULT)" -# Regression test for finding 24: since the PIN is only promoted to +# Regression test for finding 24: since the TAN is only promoted to # 'last_pin' once the helper confirmed the transmission, a validation -# whose every transmission failed has no PIN on file at all -- 'last_pin' +# whose every transmission failed has no TAN on file at all -- 'last_pin' # is SQL NULL. The caller reads 'out_last_pin' through a non-NULLable # result spec, so the fall-through path of the stored procedure must not # hand it NULL; it did, and that turned an ordinary "no transmissions # left" answer into a 500. # The marker makes cat-once.sh fail from the very first invocation, so no -# PIN is ever confirmed for this validation. +# TAN is ever confirmed for this validation. touch "${FILENAME3}.sent" -echo -n "Setup a third validation whose PINs never get through..." +echo -n "Setup a third validation whose TANs never get through..." STATUS=$(curl "${BURL}/setup/${CLIENT_ID}" \ -H "Authorization: Bearer ${CLIENT_SECRET}" \ -d '' \ @@ -285,11 +285,11 @@ do done echo " OK" -# No PIN was ever transmitted and no transmission is left, so this takes +# No TAN was ever transmitted and no transmission is left, so this takes # the fall-through path with 'last_pin' still NULL. Note that this does # not depend on the cooldown: the empty transmission budget alone blocks # the (re)transmission. -echo -n "A further /challenge with no PIN on file must not be a server error..." +echo -n "A further /challenge with no TAN on file must not be a server error..." STATUS=$(curl "${BURL}/challenge/${NONCE}" \ -X POST \ -H "Accept: application/json" \ @@ -298,7 +298,7 @@ STATUS=$(curl "${BURL}/challenge/${NONCE}" \ if [ "$STATUS" != "429" ] then - exit_fail "Expected 429 (out of PIN transmissions). Got: $STATUS" \ + exit_fail "Expected 429 (out of TAN transmissions). Got: $STATUS" \ $(cat $LAST_RESPONSE) fi echo " OK" diff --git a/src/challenger/test-challenger-pinlimit.conf b/src/challenger/test-challenger-pinlimit.conf @@ -10,7 +10,7 @@ ADDRESS_TYPE = file-access BASE_URL = http://localhost/ # No cooldown between (re)transmissions, so that the test can exhaust -# the PIN transmission budget without sleeping. +# the TAN transmission budget without sleeping. PIN_RETRANSMISSION_FREQUENCY = 0 s [challengerdb-postgres] diff --git a/src/challenger/test-challenger-pinlimit.sh b/src/challenger/test-challenger-pinlimit.sh @@ -4,7 +4,7 @@ # Tests the per-validation message budget of a challenge. # # By design a validation allows a fixed number of *addresses* and, for each -# of them, a fixed number of PIN transmissions -- 3 x 3 -- so a user who +# of them, a fixed number of TAN transmissions -- 3 x 3 -- so a user who # mistyped their address is not made to wait out the cooldown of a message # that went to somebody else. The ceiling of nine messages is therefore # intended, but it is intended to be spread over three *distinct* addresses. @@ -16,7 +16,7 @@ # an address attempt to nothing but a reordered form submission (the daemon # itself re-appends 'read_only' as the last field). # -# Also checks the property that makes the 3 x 3 budget safe: a PIN that was +# Also checks the property that makes the 3 x 3 budget safe: a TAN that was # transmitted for one address must not solve the challenge once the address # has been changed. @@ -131,7 +131,7 @@ function submit() if [ "true" = "$(jq -r '.transmitted // false' < "$LAST_RESPONSE")" ] then SENT=$(( SENT + 1 )) - PIN=$(awk '{print $5}' < "${FILENAME}") + TAN=$(awk '{print $5}' < "${FILENAME}") fi } @@ -147,7 +147,7 @@ function expect_sent() { if [ "$SENT" != "$1" ] then - exit_fail "expected ${1} PIN transmissions after $2, counted ${SENT}" + exit_fail "expected ${1} TAN transmissions after $2, counted ${SENT}" fi } @@ -161,15 +161,15 @@ function expect_status() fi } -echo -n "Spending the three PIN transmissions of the first address..." +echo -n "Spending the three TAN transmissions of the first address..." for i in 1 2 3 do submit_address "one" - expect_status 200 "a PIN transmission of the first address" + expect_status 200 "a TAN transmission of the first address" echo -n "." done expect_sent 3 "three submissions of the first address" -PIN_ONE="${PIN}" +TAN_ONE="${TAN}" echo " OK" echo -n "A fourth transmission for that address must be refused..." @@ -180,7 +180,7 @@ echo " OK" # Same JSON value, fields in the other order. This is the regression: with # a textual comparison this counts as a new address, refills the budget and -# transmits a fourth PIN to the very same recipient. +# transmits a fourth TAN to the very same recipient. echo -n "The same address with its fields reordered is not a new address..." submit --data-urlencode "tag=one" \ --data-urlencode "filename=${FILENAME}" @@ -188,18 +188,18 @@ expect_status 429 "a reordered rendering of the current address" expect_sent 3 "a reordered rendering of the current address" echo " OK" -echo -n "Changing the address transmits and invalidates the previous PIN..." +echo -n "Changing the address transmits and invalidates the previous TAN..." submit_address "two" expect_status 200 "the first submission of the second address" expect_sent 4 "the first submission of the second address" RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: application/json" \ - --data-urlencode "pin=${PIN_ONE}" \ + --data-urlencode "pin=${TAN_ONE}" \ -w "%{http_code}" -s -o $LAST_RESPONSE) if [ "$RESULT" = "302" ] || [ "$RESULT" = "200" ] then - exit_fail "the PIN sent for the previous address solved the challenge" + exit_fail "the TAN sent for the previous address solved the challenge" fi echo " OK ($RESULT)" @@ -207,12 +207,12 @@ echo -n "Spending the rest of the designed 3 x 3 budget..." for i in 2 3 do submit_address "two" - expect_status 200 "a PIN transmission of the second address" + expect_status 200 "a TAN transmission of the second address" done for i in 1 2 3 do submit_address "three" - expect_status 200 "a PIN transmission of the third address" + expect_status 200 "a TAN transmission of the third address" done expect_sent 9 "three transmissions for each of three addresses" echo " OK (9)" diff --git a/src/challenger/test-challenger-pkce-downgrade.sh b/src/challenger/test-challenger-pkce-downgrade.sh @@ -157,13 +157,13 @@ then fi echo "OK" -PIN=$(cat ${FILENAME} | awk '{print $5}') +TAN=$(cat ${FILENAME} | awk '{print $5}') -echo -n "Initiating PIN ${PIN} submission..." +echo -n "Initiating TAN ${TAN} submission..." RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code} %{redirect_url}" -s -o $LAST_RESPONSE) STATUS=$(echo "$RESULT" | awk '{print $1}') TARGET=$(echo "$RESULT" | awk '{print $2}') diff --git a/src/challenger/test-challenger-pkce.sh b/src/challenger/test-challenger-pkce.sh @@ -136,13 +136,13 @@ then fi echo "OK" -PIN=$(cat ${FILENAME} | awk '{print $5}') +TAN=$(cat ${FILENAME} | awk '{print $5}') -echo -n "Initiating PIN ${PIN} submission..." +echo -n "Initiating TAN ${TAN} submission..." RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code} %{redirect_url}" -s -o $LAST_RESPONSE) STATUS=$(echo "$RESULT" | awk '{print $1}') TARGET=$(echo "$RESULT" | awk '{print $2}') diff --git a/src/challenger/test-challenger-resend.sh b/src/challenger/test-challenger-resend.sh @@ -1,14 +1,14 @@ #!/usr/bin/env bash # This file is in the public domain. # -# Tests that asking for a new PIN during the retransmission cooldown is +# Tests that asking for a new TAN during the retransmission cooldown is # answered with 200 and "transmitted":false, and not with a terminal -# "too many PINs" 429. +# "too many TANs" 429. # # Regression test: the handler stored the *guess* counter -# (auth_attempts_left) in bc->pin_attempts_left and read 0 as "the PIN -# transmission quota is exhausted", so after three wrong PINs the very -# next resend request was refused with 429 -- even though two PIN +# (auth_attempts_left) in bc->pin_attempts_left and read 0 as "the TAN +# transmission quota is exhausted", so after three wrong TANs the very +# next resend request was refused with 429 -- even though two TAN # transmissions were still available. set -eu @@ -137,10 +137,10 @@ then fi echo " OK" -PIN=$(cat ${FILENAME} | awk '{print $5}') -WRONG=$(( (PIN + 1) % 100000000 )) +TAN=$(cat ${FILENAME} | awk '{print $5}') +WRONG=$(( (TAN + 1) % 100000000 )) -echo -n "Burning the three PIN guesses..." +echo -n "Burning the three TAN guesses..." for attempt in 1 2 3 do STATUS=$(curl "${BURL}/solve/${NONCE}" \ @@ -150,16 +150,16 @@ do -w "%{http_code}" -s -o $LAST_RESPONSE) if [ "$STATUS" != "403" ] then - exit_fail "Expected 403 for a wrong PIN. Got: $STATUS" $(cat $LAST_RESPONSE) + exit_fail "Expected 403 for a wrong TAN. Got: $STATUS" $(cat $LAST_RESPONSE) fi echo -n "." done echo " OK" -# The user now asks for a fresh PIN, but the retransmission cooldown has -# not elapsed. Two PIN transmissions are still available, so this is a -# temporary "not now", not "you are out of PINs". -echo -n "Requesting a new PIN inside the cooldown..." +# The user now asks for a fresh TAN, but the retransmission cooldown has +# not elapsed. Two TAN transmissions are still available, so this is a +# temporary "not now", not "you are out of TANs". +echo -n "Requesting a new TAN inside the cooldown..." STATUS=$(curl "${BURL}/challenge/${NONCE}" \ -X POST \ -H "Accept: application/json" \ diff --git a/src/challenger/test-challenger-revisit.sh b/src/challenger/test-challenger-revisit.sh @@ -130,13 +130,13 @@ then fi echo "OK" -PIN=$(cat ${FILENAME} | awk '{print $5}') +TAN=$(cat ${FILENAME} | awk '{print $5}') -echo -n "Initiating PIN ${PIN} submission..." +echo -n "Initiating TAN ${TAN} submission..." RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code} %{redirect_url}" -s -o $LAST_RESPONSE) STATUS=$(echo "$RESULT" | awk '{print $1}') TARGET=$(echo "$RESULT" | awk '{print $2}') diff --git a/src/challenger/test-challenger-setup-address.sh b/src/challenger/test-challenger-setup-address.sh @@ -210,12 +210,12 @@ then fi echo " OK" -echo -n "The PIN sent to the fixed address solves the challenge ..." -PIN=$(awk '{print $5}' < "${FIXED_FILE}") +echo -n "The TAN sent to the fixed address solves the challenge ..." +TAN=$(awk '{print $5}' < "${FIXED_FILE}") STATUS=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: application/json" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code}" -s -o $LAST_RESPONSE) if [ "$STATUS" != "200" ] then diff --git a/src/challenger/test-challenger-token-errors.sh b/src/challenger/test-challenger-token-errors.sh @@ -184,11 +184,11 @@ if [ "$STATUS" != "200" ] then exit_fail "Expected 200 OK from /challenge. Got: $STATUS" $(cat $LAST_RESPONSE) fi -PIN=$(cat ${FILENAME} | awk '{print $5}') +TAN=$(cat ${FILENAME} | awk '{print $5}') RESULT=$(curl "${BURL}/solve/${SOLVED_NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code} %{redirect_url}" -s -o $LAST_RESPONSE) STATUS=$(echo "$RESULT" | awk '{print $1}') if [ "$STATUS" != "302" ] diff --git a/src/challenger/test-challenger.sh b/src/challenger/test-challenger.sh @@ -132,13 +132,13 @@ then fi echo "OK" -PIN=$(cat ${FILENAME} | awk '{print $5}') +TAN=$(cat ${FILENAME} | awk '{print $5}') -echo -n "Initiating PIN ${PIN} submission..." +echo -n "Initiating TAN ${TAN} submission..." RESULT=$(curl "${BURL}/solve/${NONCE}" \ -X POST \ -H "Accept: text/html" \ - --data-urlencode "pin=${PIN}" \ + --data-urlencode "pin=${TAN}" \ -w "%{http_code} %{redirect_url}" -s -o $LAST_RESPONSE) STATUS=$(echo "$RESULT" | awk '{print $1}') TARGET=$(echo "$RESULT" | awk '{print $2}') diff --git a/src/challengerdb/do_challenge_address.c b/src/challengerdb/do_challenge_address.c @@ -55,7 +55,7 @@ CHALLENGERDB_do_challenge_address ( 'now + retransmission_frequency': the value is compared against a timestamp in the *past*. GNUNET_TIME_absolute_subtract() saturates at zero rather than underflowing, so a FOREVER frequency degrades to - "never *re*transmit" (the initial PIN, sent when last_tx_time is still 0, + "never *re*transmit" (the initial TAN, sent when last_tx_time is still 0, is unaffected). */ struct GNUNET_TIME_Absolute retransmit_cutoff = GNUNET_TIME_absolute_subtract (now, @@ -156,7 +156,7 @@ CHALLENGERDB_do_challenge_address_confirm_pin ( " ,pending_pin=NULL" " ,auth_attempts_left=3" " WHERE nonce=$1" - /* nothing to promote if we did not just transmit a PIN */ + /* nothing to promote if we did not just transmit a TAN */ " AND pending_pin IS NOT NULL" /* never resurrect an already solved validation */ " AND auth_attempts_left >= 0" diff --git a/src/challengerdb/do_challenge_address.sql b/src/challengerdb/do_challenge_address.sql @@ -31,9 +31,9 @@ CREATE FUNCTION challenger_do_challenge_set_address_and_pin ( OUT out_state TEXT, OUT out_pin_transmit BOOLEAN, OUT out_auth_attempts_left INT4, - -- How many PIN transmissions are left *after* this call? Note that + -- How many TAN transmissions are left *after* this call? Note that -- this is a different budget from out_auth_attempts_left, which counts - -- the guesses the user has on the current PIN. + -- the guesses the user has on the current TAN. OUT out_pin_transmissions_left INT4, OUT out_client_redirect_uri TEXT, OUT out_address_refused BOOLEAN, @@ -103,7 +103,7 @@ out_solved=FALSE; -- challenger-httpd_challenge.c), so an unchanged address can come back here -- with its fields in a different order and silently cost an honest user one -- of their address attempts. Secondly, the budget is deliberately --- 'address_attempts_left' addresses times 'pin_transmissions_left' PINs +-- 'address_attempts_left' addresses times 'pin_transmissions_left' TANs -- each; if cosmetic variants counted as distinct addresses, all of those -- messages could be aimed at a single recipient. Comparing as JSONB also -- makes this agree with the C layer, which compares addresses with @@ -127,7 +127,7 @@ THEN -- We are changing the address, update counters. Refilling -- 'pin_transmissions_left' and clearing the retransmission cooldown is -- intentional: the user gets a fixed number of addresses and, for each - -- address, a fixed number of PIN transmissions, so that a user who + -- address, a fixed number of TAN transmissions, so that a user who -- mistyped their address does not have to wait out the cooldown of a -- message that went to somebody else. my_status.address_attempts_left @@ -137,11 +137,11 @@ THEN my_status.address = in_address::JSONB::TEXT; my_status.pin_transmissions_left = 3; my_status.last_tx_time = 0; - -- The PIN generated below is now merely 'pending' until the helper + -- The TAN generated below is now merely 'pending' until the helper -- confirms the transmission, so -- unlike before this patch -- this call - -- no longer necessarily overwrites 'last_pin'. The PIN on file went to + -- no longer necessarily overwrites 'last_pin'. The TAN on file went to -- the *previous* address, so it must be dropped here: if the helper then - -- fails, the user must be left without a usable PIN rather than with one + -- fails, the user must be left without a usable TAN rather than with one -- that attests an address it was never sent to. my_status.last_pin = NULL; my_status.pending_pin = NULL; @@ -155,10 +155,10 @@ IF ( (my_status.pin_transmissions_left > 0) AND (my_status.last_tx_time <= in_retransmit_cutoff) ) THEN -- Enough time has passed since the last transmission, so we are changing - -- the PIN, update counters. The new PIN is only stored as 'pending_pin': + -- the TAN, update counters. The new TAN is only stored as 'pending_pin': -- it is promoted to 'last_pin' (and 'auth_attempts_left' reset) by -- CHALLENGERDB_do_challenge_address_confirm_pin() once the AUTH_COMMAND - -- helper confirmed the transmission. Until then the PIN the user may + -- helper confirmed the transmission. Until then the TAN the user may -- already hold from an earlier transmission stays valid. my_status.pin_transmissions_left = my_status.pin_transmissions_left - 1; my_status.pending_pin = in_tan; diff --git a/src/challengerdb/do_insert_token.c b/src/challengerdb/do_insert_token.c @@ -57,7 +57,7 @@ CHALLENGERDB_do_insert_token (struct CHALLENGERDB_PostgresContext *ctx, caller maps to 'invalid_grant'. The 'auth_attempts_left < 0' guard is what restricts us to validations that were actually *solved*: -1 is the sentinel challenger_do_validate_and_solve_pin() writes once the user entered the - correct PIN. The 'address IS NOT NULL' guard additionally avoids violating + correct TAN. The 'address IS NOT NULL' guard additionally avoids violating the tokens.address NOT NULL constraint. Expiration and client are checked here as well and not merely by the get_validation_pkce() that preceded us: the two run in separate transactions, so anything we do not repeat is a diff --git a/src/challengerdb/get_validation_pkce.c b/src/challengerdb/get_validation_pkce.c @@ -93,7 +93,7 @@ CHALLENGERDB_get_validation_pkce ( " AND expiration_time > $2" " AND client_serial_id=$3" /* -1 is the sentinel challenger_do_validate_and_solve_pin() writes - once the correct PIN was entered; without this the /token endpoint + once the correct TAN was entered; without this the /token endpoint would happily mint a token for a validation where the user never proved anything. Must match the guard in do_insert_token.c. */ " AND auth_attempts_left < 0"); diff --git a/src/challengerdb/test_challenger_db.c b/src/challengerdb/test_challenger_db.c @@ -99,12 +99,12 @@ setup_client (void) /** - * Create a fresh validation for #client_id and have a PIN transmitted + * Create a fresh validation for #client_id and have a TAN transmitted * for it, leaving the validation in the state a user reaches by posting * an address to ``/challenge`` and then walking away. * * @param[out] nonce set to the nonce identifying the new validation - * @param[out] pin set to the PIN that was "transmitted" + * @param[out] pin set to the TAN that was "transmitted" * @return #GNUNET_OK on success */ static enum GNUNET_GenericReturnValue @@ -156,7 +156,7 @@ challenge_validation (struct CHALLENGER_ValidationNonceP *nonce, &address_refused, &solved); json_decref (address); - /* The PIN is only pending until its transmission is confirmed; this + /* The TAN is only pending until its transmission is confirmed; this stands in for a successful AUTH_COMMAND run. */ qs = CHALLENGERDB_do_challenge_address_confirm_pin (pg, nonce, @@ -184,7 +184,7 @@ challenge_validation (struct CHALLENGER_ValidationNonceP *nonce, * Enter @a pin for the validation under @a nonce and check it was accepted. * * @param nonce validation to solve - * @param pin PIN to enter + * @param pin TAN to enter * @return #GNUNET_OK on success */ static enum GNUNET_GenericReturnValue @@ -252,7 +252,7 @@ insert_token (uint64_t client, /** * Test that a validation for which the user never entered the correct - * PIN cannot be redeemed for an access token, and is not even visible to + * TAN cannot be redeemed for an access token, and is not even visible to * the ``/token`` lookup. Without the ``auth_attempts_left < 0`` guard * anyone able to compute the authorization code could mint an * attestation for an address nobody ever proved control over. diff --git a/src/include/challenger-database/do_challenge_address.h b/src/include/challenger-database/do_challenge_address.h @@ -33,25 +33,25 @@ * address did not change, the operation is successful even without * the counter change. * - * Note that a newly generated PIN is only stored as *pending*: it does not - * become the PIN we accept until + * Note that a newly generated TAN is only stored as *pending*: it does not + * become the TAN we accept until * #CHALLENGERDB_do_challenge_address_confirm_pin() is called, so that a - * failed transmission does not invalidate a PIN the user already holds. + * failed transmission does not invalidate a TAN the user already holds. * * @param cls * @param nonce unique nonce to use to identify the validation * @param address the new address to validate * @param retransmission_frequency minimum time that must have passed since the - * last transmission before the PIN is (re)transmitted to @a address again - * @param[in,out] tan set to the PIN/TAN last send to @a address, input should be random PIN/TAN to use if address did not change + * last transmission before the TAN is (re)transmitted to @a address again + * @param[in,out] tan set to the TAN last send to @a address, input should be random TAN to use if address did not change * @param[out] state set to client's OAuth2 state if available - * @param[out] last_tx_time set to the last time when we (presumably) send a PIN to @a address + * @param[out] last_tx_time set to the last time when we (presumably) send a TAN to @a address * @param[out] pin_transmit set to true if we should transmit the @a last_pin to the @a address * @param[out] auth_attempts_left set to number of attempts the user has left on this pin - * @param[out] pin_transmissions_left set to number of times a PIN may still be + * @param[out] pin_transmissions_left set to number of times a TAN may still be * transmitted for this validation; 0 means the user cannot request - * another PIN, while @a auth_attempts_left being 0 only means that the - * guesses on the *current* PIN are used up + * another TAN, while @a auth_attempts_left being 0 only means that the + * guesses on the *current* TAN are used up * @param[out] client_redirect_uri redirection URI of the client (for reporting failures) * @param[out] address_refused set to true if the address was refused (address change attempts exhausted) * @param[out] solved set to true if the challenge is already solved @@ -80,21 +80,21 @@ CHALLENGERDB_do_challenge_address ( /** - * Confirm that the PIN generated by the last + * Confirm that the TAN generated by the last * #CHALLENGERDB_do_challenge_address() call was actually transmitted to the - * address, and thus make it the PIN we accept from the user. Also resets - * the number of authentication attempts the user has on the new PIN. + * address, and thus make it the TAN we accept from the user. Also resets + * the number of authentication attempts the user has on the new TAN. * * Must only be called once the transmission helper terminated successfully; - * if it is never called, the previous PIN (if any) remains valid. + * if it is never called, the previous TAN (if any) remains valid. * * @param ctx database context to use * @param nonce unique nonce identifying the validation * @param[out] auth_attempts_left set to the number of attempts the user has - * on the now-current PIN + * on the now-current TAN * @return transaction status: - * #GNUNET_DB_STATUS_SUCCESS_ONE_RESULT if the PIN was promoted - * #GNUNET_DB_STATUS_SUCCESS_NO_RESULTS if there was no pending PIN, or the + * #GNUNET_DB_STATUS_SUCCESS_ONE_RESULT if the TAN was promoted + * #GNUNET_DB_STATUS_SUCCESS_NO_RESULTS if there was no pending TAN, or the * validation is unknown or already solved * #GNUNET_DB_STATUS_HARD_ERROR on failure */ diff --git a/src/include/challenger-database/do_solve_challenge.h b/src/include/challenger-database/do_solve_challenge.h @@ -28,13 +28,13 @@ /** - * Check PIN entered to validate an address. + * Check TAN entered to validate an address. * * @param cls * @param nonce unique nonce to use to identify the validation - * @param new_pin the PIN the user entered - * @param[out] solved set to true if the PIN was correct - * @param[out] exhausted set to true if the number of attempts to enter the correct PIN was exhausted before this call and @a new_pin was not evaluated + * @param new_pin the TAN the user entered + * @param[out] solved set to true if the TAN was correct + * @param[out] exhausted set to true if the number of attempts to enter the correct TAN was exhausted before this call and @a new_pin was not evaluated * @param[out] no_challenge set to true if we never even issued a challenge * @param[out] state set to client's OAuth2 state if available * @param[out] addr_left set to number of address changes remaining @@ -42,7 +42,7 @@ * remaining; only meaningful when @a solved is false (on the solved * path the stored procedure uses a -1 sentinel, which is normalized * to 0 here) - * @param[out] pin_transmissions_left set to number of times the PIN can still be re-requested + * @param[out] pin_transmissions_left set to number of times the TAN can still be re-requested * @param[out] client_redirect_uri set to OAuth2 client redirect URI * @return transaction status: * #GNUNET_DB_STATUS_SUCCESS_ONE_RESULT if the nonce was found diff --git a/src/include/challenger-database/get_validation_pkce.h b/src/include/challenger-database/get_validation_pkce.h @@ -33,7 +33,7 @@ * authorization code and the PKCE binding before minting an access token. * * Only returns validations that were actually *solved* (the user entered the - * correct PIN); an unsolved, expired or foreign validation is reported as + * correct TAN); an unsolved, expired or foreign validation is reported as * #GNUNET_DB_STATUS_SUCCESS_NO_RESULTS. The predicate must stay in sync with * the one in CHALLENGERDB_do_insert_token(). * diff --git a/src/include/challenger-database/update_validation.h b/src/include/challenger-database/update_validation.h @@ -49,10 +49,10 @@ * @a code_challenge is NULL * @param[out] last_address set to the last address used * @param[out] address_attempts_left set to number of address changing attempts left for this address - * @param[out] pin_transmissions_left set to number of times the PIN can still be re-requested + * @param[out] pin_transmissions_left set to number of times the TAN can still be re-requested * @param[out] auth_attempts_left set to number of authentication attempts remaining * @param[out] solved set to true if the challenge is already solved - * @param[out] last_tx_time set to the last time when we (presumably) send a PIN to @a last_address; 0 if never sent + * @param[out] last_tx_time set to the last time when we (presumably) send a TAN to @a last_address; 0 if never sent * @return transaction status: * #GNUNET_DB_STATUS_SUCCESS_ONE_RESULT if the validation exists and the * OAuth2 scope/state/redirect/PKCE parameters were recorded