> the ideal is not just having an app that generates a token but one that generates a specific type of token depending on what type of transaction you're performing and won't accept, for example, a login token when adding a new payee.
I think at least some UK banks will do this. When I've done it using a card + card reader, you select the option to choose which type of operation you're trying to do. And if you're just trying to login it just displays a rolling code, but for authorisation of particular events it will take the form of a challenge/response, i.e. you have to select the operation on the card reader + enter a code provided from the site. This should I think prevent _simple_ replay attacks.
I even think for some transactions such as transfers over a certain amount, you have to enter the amount into the reader as part of the code generation.
Yes, my AIB card reader works like this. When transferring money to an unknown account I also need to enter the amount and "sign" that with the card reader. For adding a new payee it's a challenge/response.
I think at least some UK banks will do this. When I've done it using a card + card reader, you select the option to choose which type of operation you're trying to do. And if you're just trying to login it just displays a rolling code, but for authorisation of particular events it will take the form of a challenge/response, i.e. you have to select the operation on the card reader + enter a code provided from the site. This should I think prevent _simple_ replay attacks.
I even think for some transactions such as transfers over a certain amount, you have to enter the amount into the reader as part of the code generation.