RE: [security] Misuse of Steemconnect login (shouldn't ask active key for every login)
Hello, @blockchainstudio. Thank you for publishing this as a Utopian contribution. I see that you have made a lot of effort to describe your experience using the SC and have suggested a possible fix or workaround to the issue you have found.
Going to the content review, I must admit that this was a mixed bag for me. I had taken the chance to request an additional review from one of the project maintainers who was one of the devs behind the project. I'd like to quote some of your statement.
If active key is stolen, then all of your Steem and SBD can be stolen, and power-down can be initiated.
Of course, this is so true but this can not happen with the use of SC. If by any chance a hacker gets into a server hosting a major app a lot of people are already using, the only harm the attacker could cause is using all the account that have been authorized to cast votes, comment, and post. They can not access the user's funds nor can they initiate a power down as this requires an active key. SC only have access to your posting authority and not active. Trying to send funds requires you to confirm your details before the transaction becomes successful. The only transaction that does not require a user to re-enter their active key again comment, posting and voting and this is because you already gave the app your posting access. You might want to check out this issue to get a clearer picture of how keys are handled and why they are handled the way they are now.
After the initial authorization, users should be able to log in with their posting key.
I agree with this, but here comes my concern: Without saving the login session which will allow you to automatically login by simply clicking on your account profile, there is no way to check if the user trying to log in is a new user or an existing user, thus without saving the session, SC considers you as a new user and requests for your credentials again.
Which key is needed depends on scope for instance, scope=login requires only posting key.
I am happy that you mentioned this. I believe that developers are free to set the kind of auth they need from the users of their application as they want. I can see that you encountered a bug when you tried to tweak the busy login by using the saved session from steem-ua longin (which IMO should not be possible). I think this was expected. Perhaps there needs to be a better workaround to deny login access with a session that only has the posting key in it when the app which you are trying to log into already set the scope to entertain active key.
Above all, I do agree that users should be allowed to initiate transactions like posting, voting with simply using the posting key to log in, I believe that this is one of the issues SC is having and one of the reasons behind the development of SC3.
Talking about SC3, I believe that the PO is aware of this and working on a way to fix the issue. You can confirm that from this thread.
Considering the new proposed version of SteemConnect 3, a lot of this might not be relevant anymore since the user will only need to "follow" an app to authorize it. I mean, most of the issues you've raised here are already considered for SC3.
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Chat with us on Discord.
Hi @knowledges, again you're a human knowledge base :) I searched for a while and I even contacted steemconnect via GH, but I couldn't get any answer, so I made this post.
While I agree that it was suggested in the comment! you provided, which of course I didn't know of, proposing formally has its own merit. For instance, age-weighted score for utopian bot was proposed before, but after my proposal, https://steemit.com/utopian-io/@blockchainstudio/utopian-bot-sorting-criteria-improvement-to-prevent-no-voting-for-mid-score-postings, it had been actually implemented. But again regarding the score, I have no objection since it was known to the PO before.
Regarding the security. You misunderstood my intention. I actually worked for information security company before where I also worked on PKI system, so I'm quite familiar with the system. What I meant was NOT that SC stored active key so it's vulnerable. What I meant was, how do you enter your key? Most likely, copy&paste. That step is vulnerable. That's why there're even bots to steal the keys or notify the owner that keys are exposed. So requiring active key should be avoided if possible.
And the workaround shows that it's not difficult to implement. Of course, they may implement in SC3, but you know the last post was already 3 months ago, and this kind of security problem should be resolved very quick. Until SC3 is released with the feature, I believe you'll be more generous on my future suggestions :) Thanks again!
Thank you for your review, @knowledges! Keep up the good work!