Skip to content
This repository has been archived by the owner on Dec 15, 2021. It is now read-only.

More SEP10 edge cases #10

Open
msfeldstein opened this issue Jan 26, 2020 · 0 comments
Open

More SEP10 edge cases #10

msfeldstein opened this issue Jan 26, 2020 · 0 comments

Comments

@msfeldstein
Copy link
Contributor

The server is a signer on the account, and shouldn't be allowed to sign for the account to gain weight. The server shouldn't help a client authenticate.

There's a signer on the transaction that is not recognized as belonging to the account or the server, it should decline in that case. There's no big vulnerability here, I just think it's good practice to keep that behavior predicable and that's how stellar/go#2071 is implemented.

The account has 5 signers and 2 signers sign the transaction which meet the threshold.

The challenge transaction has no signatures.

The challenge transaction has only the server signature.

The challenge transaction has no signatures and the account also has no signers.

The challenge transaction has only the server signature and the account also has no signers.

The weights of the signers add to a number greater than 255.

A non-existent account can be auth'd with its master key.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant