On this section, SteemConnect will be used to illustrate a behavior that may take place on any other STEEM client, so take SteemConnect ONLY as an example.
Actual behavior
Steem Clients, like SteemConnect which supports the "Create Account with Delegation" functionally, should not, be in charge of password structure.
Since the password structure is not checked, using a valid WIF private key as password, would result in the following logic:
Step 1: STEEM user creates an account with a delegation, but instead of a common password, he inputs another valid WIF private key.
Step 2: The library in charge of broadcasting the operation, treats the password as a normal password and derives a private key, from another private key.
Step 1: There is an attempt to use the input value as a WIF private key.
Step 2: Since both are valid WIF private keys, the parsing attempt is successfully.
Step 3: The password, thread as the matching private key for the account public key, will not match, meaning authentication / login will fail.
Expected behavior
When using a single input field for both password or WIF private key, the provided value, should be treated as password first, then as WIF private key.
OR
More elegantly, Instead of assuming password or WIF private key, and failing after check against a single format, both must be tried.
How to reproduce
1: Generate a random WIF private key, using suggest_brain_key from wallet (or any other compatible implementation).
2: "Create an Account with Delegation", using the private key from previous step output. (SteemConnect is the easier to test this).
3: Try to login on SteemConnect.com or Steemit.com using your "WIF formatted password".
Recording Of The Bug
Is not relevant, from the technical point of view to record the screen because this problem is related to underlying logic. The user interface itself behaves like it was intended to.
Reference End-User Solution
While the issue may not be immediately fixed, for people reaching this report while reproducing it, by accident, those are the private key derivation steps need for being able to log in on the created account:
1: Get a Javascript environment running.
2: Re-derive the private-key itself using:
/**
* The owner account is the type you will use to log in and change the password at Steemit.
*/
steem.auth.toWif(account-username, password-wif, 'owner');
Alternative method: This codepen has SteemJS and you need to replace the values and get the actual account WIF.
Disclaimer
On this section, SteemConnect will be used to illustrate a behavior that may take place on any other STEEM client, so take SteemConnect ONLY as an example.
Actual behavior
Steem Clients, like SteemConnect which supports the "Create Account with Delegation" functionally, should not, be in charge of password structure.
Since the password structure is not checked, using a valid WIF private key as password, would result in the following logic:
At login time, both Condenser and SteemConnect, there's the following flow:
Expected behavior
When using a single input field for both password or WIF private key, the provided value, should be treated as password first, then as WIF private key.
OR
More elegantly, Instead of assuming password or WIF private key, and failing after check against a single format, both must be tried.
How to reproduce
Recording Of The Bug
Is not relevant, from the technical point of view to record the screen because this problem is related to underlying logic. The user interface itself behaves like it was intended to.
Reference End-User Solution
While the issue may not be immediately fixed, for people reaching this report while reproducing it, by accident, those are the private key derivation steps need for being able to log in on the created account:
Alternative method: This codepen has SteemJS and you need to replace the values and get the actual account WIF.
Posted on Utopian.io - Rewarding Open Source Contributors