It means that they were incompetent. There are three posibilities:
- More than one person had access to the private keys and one of them disagreed with stealing funds.
- The account was created by anonsteem, the owner of anonsteem kept a copy of the private keys.
- The owner of the community321 account was/is a double agent.
Either way it shows that the people running the hardfork/theft don't know anything about account security.
That's a possibility, although I don't think that to be likely.
Then the story would become crazier than crazy.
So better always change your private keys, but is there a really secure way for it?
@anonsteem created the
@community321account 12 days ago.https://steemd.com/tx/a0ebc4761c92f197b0bc76bab5fc95c59eef19ad
However, shortly before the Steem HF23, community321 appears to have changed the keys in https://steemd.com/tx/e6d0d03d4d3c8e2d05f7d636a13f2a4422e0b52b (10 minutes prior to the fork):
If Sun changed the keys, this would indicate anonsteem was not behind the STEEM rescue. However, it's possible anonsteem could have submitted this account update transaction, which would mean Sun is now unable to transact with community321. @onthewayout does that make sense?
Pretty interesting.
So, essentially, if an account is created by a third party application or website, they could possibly have access to the keys?
You should ALWAYS change your keys, regardless of how you get them.
We can't stress this enough.
It's possible but we would have to see the code that is being used on the web page. If it is open source and we can review that the keys are generated locally on the users browser then it's unlikely. However if the user receives the keys by other means (like email) then it is possible for the third party to keep a copy of the keys.
The published open source code (if there is any) may not be the actual code that runs the web site. Also, the owners of the site can change the code at any time, and there is no way for us to know what code was used at the time of creation of community321 account.
That's the problem with trusting webapps, and it applies to any web application that asks for keys (steemit.com, steemitwallet.com etc. — they too could have been temporarily compromised at some point in the past).
That is true, only if you inspect the code running on a web app can you have some security but not everyone has the necessary knowledge to do it.
Las dapp de terceros deben enfatizar a los nuevos usuarios el cambio de sus llaves una vez realizado el registros.
Pero quizás esto es inseguro también...