API should never transparently interpret "account" as a seed (Version: 1.9.4)

[intelliot]

Issue Description

In the API, seeds can be used in place of accounts. For example, when calling account_info, you can pass "account": "foo". The string "foo" is treated like a seed, so the method returns actNotFound (instead of actMalformed, as most developers would intuitively expect).

In the early days, this was a convenience to make testing easier. However, it is no longer a good idea, and it allows for poor security practices. It is controlled by the strict option on some methods.

Note, Clio currently does not behave this way. This results in a subtle incompatibility between Clio and rippled, even though Clio is intended to support (and eventually replace) the rippled API. The current thinking from the Clio team is that Clio should not behave this way, i.e. it should not "support" the ability to provide a seed in the "account" field of API requests.

Steps to Reproduce

Call account_info with "account": "foo".

Expected Result

The method should return actMalformed since "foo" is not a valid account.

Actual Result

The string "foo" is treated like a seed, so the method returns actNotFound.

Notes

This behavior, since it is available on public-facing servers like s2, allows bad actors to use servers to try to brute-force account seeds, for "free". However, this is not a worry, as accounts are not brute-forceable regardless. While we should have spam prevention (e.g. rate limiting), trying many seeds (with no entropy-reducing "hints") is not a viable attack for attempting to compromise an account.

Removing this behavior from the API is a breaking change. We could argue that it shouldn't be done without bumping the API version, and we are open to that (depending on user demand). However, in this instance, we doubt that anyone is using the API in the "legacy" way, and it is a huge security hole. It allows/encourages users to send secrets to places where they are not needed, where they could end up in logs, error messages, etc. There's no reason to take such a risk with a seed/secret, since only the public address is needed.

We prefer to break the insecure behavior (by making it safer), even if it means that some implementations may experience a breaking change and need to update. (And even that is unlikely.)

[jatinsahijwani]

I want to work on this issue, please guide me, i am a beginner

[intelliot]

@jatinsahijwani welcome! What kind of help are you looking for?

[intelliot]

will be fixed by #4404