Bounty for completion of native JavaScript steem signer
I've spent a couple of days porting the transaction signing part of steemjs-lib and steemit from node to native js, but I'm at a point where I just can't see Buffer() functions any more. I hit a roadblock with the bytebuffer library not loading properly, and decided it's time to call for support.
The conversion from passwords and WIF keys to private keys is working, and the basics for signing are laid out, or at least located in the other libs. I set up a 250$ bounty at bountysource and will of course add the SD rewards of this post. Click that link for details and code, and contact me with any questions you may have to get this done!
@williambanks has taken on the challenge. He estimates 5 days of work for him alone. Anyone interested is invited to work with him and share the bounty.
Yep! I'm breaking the work down into a project. Opening issues on github as we speak.
https://github.com/steembots/steemsign/issues
Feel free to hop in and claim some, you get up to a 12 hour lock on any issue you want to tackle.
Pay will be proportional to the number of issues you tackle and complete over the next 5 days. So no worries and a lot of this can be done in parallel.
@trogdor has been rocking this hard and completing tasks so much faster than I can code review. I just wanted to invite everyone to congratulate him.
@pharesim This is very nearly code complete. Would you please check https://github.com/steembots/steemsign and let us know if that part is working correctly for your use case?
The only remaining issues are ECC and serializing. They will very likely be closed in the original time frame. I'm going to hold off on isolating the signing process into a webworker and using crypto.subtle for key protection because those really are implementation specific details that will just over complicate things at this point. Also chrome doesn't support passing a typed array to a webworker for some stupid reason.
His is EXACTLY what steem is set up to do. Hopefully the rewards from this post assist your bounty, not only bringing the right persons attention to you, but also providing the money to back the work needed! Love it when everything works as it should!
Funny, I just posted something like this here:
https://steemit.com/steem/@steemitbounties/calling-all-steemit-nerds-and-designers-if-we-build-it-they-will-come-steemit-bounties
Please correct me if I'm wrong, but can't SVK's JS libraries already be used to sign transactions?
I didn't manage to browserify it, and didn't find anyone who did. If someone has, I'm very interested in utilizing it for now, and I think I'm not the only one. Join #steemjs on steemit.chat!
Also, I prefer small native solutions that fit basic requirements to huge bundles covering all corner cases.
It just so happens that only like 5 minutes ago I added a browserify build for natebrune in steemit.chat, you can find it here:
https://github.com/svk31/steemjs-lib/tree/master/build
Now it's certainly a work in progress as I haven't actually tested it myself yet, I'll see if I can add an example html file using it later today or tomorrow.
Well I'm working on this bounty too and saw your browserify build come across right after I pulled your code in to look at doing exactly that.
Want me to test it for you while I'm in here?
Feel free to use whatever you want from my code. The code from steemit.com is surely more robust but mine might be easier to work with since it's in library form.
If you feel like testing it then yea go for it :)
@svk yeah that and you know what a comment looks like and aren't afraid to use it :D
So what @pharesim is asking for here is a flat project that doesn't need npm or browserify.
Obviously that's going to be a lot of work, but it is something that can be done by a team of 4 or so reasonably competent people in a couple of days.
Mostly a matter of normalizing all these libraries built for node into something browser compatible without resorting to browserify or npm.
If anyone wants to join in on getting this built for him I'm more than willing to split the bounty equally with everyone. I had assumed it was just a typedbuffer issue, but it's a lot more indepth than that.
@svk it builds under browserify, on a clean checkout however the websocket library you're using is native code and not pure js, this may keep it from running. I can't think of a reason to use native code for websockets anymore. Is this just dependency hell or was it something specific this lib brings to the table?
More info on this BTW
http://stackoverflow.com/questions/29741158/how-to-use-websocket-npm-library-in-browser
The library uses a node web socket library for use in Node.js since there's no native websocket support there. But in browsers it will use the built in websocket but wrapped with ReconnectingWebsocket. Is that what you meant?
@svk actually that might be what I meant, I just remember there being issues with node websocket under browserify. Haven't had my morning coffee yet though.
JS isn't my daily language anymore.
@svk I'm going over your library with a fine toothed comb and a couple interns.
I'd very much like to thank you for this library. It's as close to perfect as I've seen JS come. You rocked this stuff. Even I'm learning new things from it. I especially like how you don't import the kitchen sink into everything. Great work!
Thanks, I have been in the process of wrapping up a few things to finally give me some time to sit down and get some things coded. Need more hours in the day :) I will be sure to stop on over at #steemjs.
Great initiative, @pharesim, let me know if you want me to wrap browserify version which I use in Steem Mobile with as little dependencies as possible.
@good-karma and @svk
Would you guys mind hopping over to
https://github.com/steembots/steemsign/issues
And doing a sanity check on the issues, just make sure I didn't miss anything and feel free to open up any extra issues you can forsee. The more the merrier at this point.
I tried to make these tasks of equal weight but also things that could be worked in parellel in order to maximize efficiency, but looking at the dep graphs on some of this stuff I just want to make sure I'm not banging my head on Amdahl's law here.
So if anything else can be split into work modules for these guys feel free to toss some more issues on the pile. Rather close 10,000 issues than miss something important even once.
i know im replying to a post from 1 months ago but its facinating see the behind thee scenes of steemit work, these posts will be history, showing how a website reallly had dedicate peopel runing decetrallized nodes and kept steemit up and running and thank god for cheap fast technology these days!
solid state drives alsomke things alot easier and the more steemit nodes around the world the better! we will grow a massive network! and steemit sers tend to be bitcoin or altcoin miners as welll!
i cant wait to get involved myself and have servers ready to becoome a steemit witneess an i just cant wautto make a documentary onsteemit witness nodes and the inner workings of a steemit blockchain network, and make a bitcoin Movie pixar style using golem network to render it!
@pharesim Grr you had to post this just before bedtime for me...
I'll byte :)
Do you care about the specific way you're going with this, or just that it works? You seem to be going about it a bit sideways.
@pharesim one final thing, are you trying to do this in a completely cross browser way? I ask because crypto.subtle is a javascript inbuilt function that could be used to secure the keys while in localstorage, but not every browser is quite there yet. Most are but it can be hit and miss. http://caniuse.com/#search=crypto
The advantage here is that the browser sandboxes the hell out of the encryption key used to encrypt the private keys. So no XSS stuff and no malicious script later imports either, can really come in and dink around with the crypto stuff.
Please correct me if I am mistaken, but seems to me that the browser sandboxing the signing private key won’t protect against an attacker’s XSS script which invokes the crypto API for signing.
I should also elaborate, that the encryption key, is protected by the sandbox which allows that key to only encrypt and decrypt content. It will not allow any script to change the parameters of the key, or expose / disclose the key contents. The key is created with these permissions and the sandbox is default deny for anything that wasn't explicitly allowed.
This encryption key is used to encrypt the signing keys, and the decrypt operation is further sandboxed by happening inside of a webworker.
Then end result is that while an XSS might be able to get you to sign something you didn't intend, it cannot extract the key.
If you make the web worker accept a PIN or password in order to do high value operations and use window.prompt to acquire the user's consent, you then at least alert the user that someone is asking them to sign something. This defeats XSS.
@anonymint Replying over here because we hit the comment depth limit.
An attacker wouldn't be able to intercept the actual dialog from the browser and input the PIN to authorize the transaction programmatically.
The very best they could do is push a dialog and try to collect the information themselves. But that would do them no good because the webworker is a process isolate.
If done correctly, it wouldn't be frequent enough to be a major irritant. Just something to notify them that someone has sent a message to the worker requesting a signature. It couldn't just be affirmatively dismissed. They would either need to input the PIN or decline the transaction.
So the salient point is the browser will prompt the user for each signing. So this means the user would have to confirm via prompt to the browser for each posting action such as voting, posting and editing a comment, etc..
That is a significant irritant¹ to the users as compared to perhaps just doing better security. There is a trade-off.
For the more infrequent cases of signing for money transfers where a browser prompt would not be an irritant¹, do you think we could trust sandboxing the money signing private key? I would think hackers would then have the incentive to target the browser and the user's computer. But I guess it is no worse than having the user enter their signing key for money actions every time, because a hacker can still try to intercept these. Really for money signing, it seems hardware wallets are the way to go for larger balances.
Note for those hoped for microtransactions ecommerce in the future where money transfers signing will be frequent, then a prompt from the browser for each one might be an irritant. A better solution may be to have smaller balances for that private key and just use the better security strategy.
¹ Not only an irritant but users may become so accustomed to dismissing these prompts as quickly as possible, that they maybe can be fooled into acknowledging them when the hacker has issued one.
It's protecting the keys and raising the bar.
As long as the latest FF and Chrome (bonus: Safari) support it it's fine. We have to use the latest technology here :)
My goal was to have a wrapper that can sign transactions and forward them to my steemjs. I don't rule out better alternative approaches though.
Hello. Excuse my disturbing you. I would like to get your opinion on this. https://steemit.com/steemit/@acidsun/steemit-t-shirts-accessories-design-from-acidsun
holy curations rewards batman!
Hey man, I am not familiar with the terminology, what is it exactly your doing? - Nolan
Also, did you mine to get that 1,000,000? I am fairly new to steemit I just turned 15 yesterday :P I
@pharesim How will this be used/incorporated into the Steemit environment? I am a big fan of digital signatures, when they are done right. (I am a security guy)
This will be used to sign transactions with the private key, so you don't have to send your key to the server of service providers. Just like steemit does it, but as a seperate library for everyone to use.
@pharesim: Do you know how the steemit.com website stores our private keys in memory? Are they using any form of local storage, or is it just held in a global variable that survives across all the events?
I'm a backend developer, but AFAIK we use local storage to serve the posting key. When active/owner keys are needed (e.g. for transfers or markets), the user's asked for their password, which is used to re-derive the key. The active/owner keys themselves are never stored. (This was a recent change implemented as part of the response to the attack ~3 weeks ago.)
Thanks for the response. I'm just concerned about moving forward with this strategy (holding key in local storage) because I have read a good deal that this approach is vulnerable to XSS attacks.
Is there way to sign transaction without user's password but only private key of posting/active/owner, etc ? Thanks!
No, didn't check that yet. Only the conversion parts.
What I found with a quick search was https://github.com/steemit/steemit.com/blob/master/app/components/modules/LoginForm.jsx#L64 - there's the "stay logged in" in local storage as far as I understand. Didn't find the credentials though...
Nice. Sounds more efficient. My concern would be for the security of a potentially exposed private key. Nasty things happen when those are compromised. Please keep the community updated on the security being instituted to protect such valuable bits. Doing so may keep the natives from becoming restless.
I wish I could up vote this a hundred times.
Getting all of this native JS is literally the key to unlocking a lot of potential applications.
Hope someone motivates to get up for work. Thanks for opportunity for the bounty.
great post!