TL;DR: Do not rely on the pending pool for any security purposes. The pending pool access is meant to allow you checking your own transactions. It does not provide any security guarantee.
I see many ways the above can go wrong, even if signatures are checked before entering the pending pool (which may be the case right now but which is not at all guaranteed by the blockchain in the future).
Here are some.
A transaction in the transaction pool may not be finalized
For example, the block proposer for the next block sees the transactions in a different order (this can happen even if all the nodes are completely honest due to network delays), and the transaction you are checking is preceded by:
- a rekey transaction of the account
- a closing transaction of the account
- or any other transaction that may invalidate the transaction.
This would invalidate your transaction.
An attacker can make you believe they control escrow accounts from applications
Currently a transaction will definitely be accepted in the transaction pool if its signature (i.e., ED25519 signature, multisig, or logic sig) is valid.
But a common pattern for escrow accounts (at least before AVM1.0) was to have the escrow account controlled by a smart signature that just requires the transaction to be called in a group of transactions where the first transaction call some smart contract application.
This is for example how the Yieldly escrow works.
Now, because the application in the group will check that you are allowed to do the operation, the actual transaction group would fail. But it would only fail when trying to finalize the transaction, not in the transaction pool!
More generally, logicsig/smart signatures may not check for the note field
Many logicsigs/smart signatures may just not check the note field when approving transaction, either because there is no security issue or because there is actually a need to allow an arbitrary note (this need most likely would come when used with a smart contract in a transaction group though).
Such smart signature accounts could also be claimed by an attacker.
Authentication is a very difficult topic in general
Using your method as a way to authenticate an account in general seems quite dangerous to me even if no smart contracts existed.
Here is an attack: suppose you wrote a dApp that requires users to authenticate their account.
What I can do as an attacker is to create another seamlessly safe dApp, for example for compounding rewards. I will ask my dApp users to sign in advance compounding transactions for the next year and then send the transactions for them.
This is a completely reasonable design and the user may trust me.
Now, the trick is that I can include your random note in this transaction.
Almost no users will realize this is dangerous when signing the transactions.
Actually, I can even justify the use of this random note: this is what goal does by default!
In other words, you cannot rely on the fact that a user is able to generate a correct transaction to show ownership of an account in a completely secure way.
To allow that securely, we need to design a secure standard that prevents this kind of man-in-the-middle attack. The kind of messages to be signed would be quite different (i.e., not transactions) and would include the origin of the request. (This is just a draft idea that requires a lot more investigation as secure authentication is an extremely complex subject.)
If you cannot wait for such a standard, you may require signature by the account of a special note that explicitly state that this is for your dApp and with a random value (at least 10-byte entropy).
You should manually verify this is a valid ED25519 signature or multisig.
You should systematically reject smart signatures.
You should check for potential rekeying on the blockchain.