There is no good way to verify to the server that a the client browser actually has a user's private key

[shawnpringle]

Expected behavior

There should be a call that can create a special value, which is proof that the client has a private key.

Actual behavior

We can send the private key over TLS to the server. That's proof.. This works but then it becomes opaque to the user what happens to the private key when sent out. We can create a transaction and sign it and send the transaction for verification on the server but it's rather complex to do so. We can just use the blockchain for session management, but then the session id needs to be public and signed and validated with a nonce rather than just once.

How to reproduce

Try to write a system where the website uses the Steem's usernames but doesn't rely on the Steem Connect third party where you want to validate with some server (other than blockchain operations).

Environment information

The server may not be using node, it may be using apache with Python or Perl or C++. Simplicity is key.

[BartolomeoItaliano]

User never send his private keys to anyone.
Transaction signing is local process of encryption your data with private key which can be decrypted with stored on blockchain public key, it proves your write to make transaction this way.

There is no process like "login" in blockchain technology, by login we name process of local comparison of owned by you private key with public key.

We can send the private key over TLS to the server.

But then we've got to trust server. And what if one of our servers occurred dishonest?
Currently if some server occured "dishonest" he could only stop adding transactions to blockchain and we can immediately throw him away. If servers would have possession of private keys he could even after being thrown from network use them against users.

[shawnpringle]

Thank you for replying Bartolomeltalia. I am afraid you didn't understand my concern or idea. All I want is to expose something in steem.auth. My idea is simply to expose signBuffer() from the Signature API as steem.auth.signBuffer() so that I can use it to prove to the server that the user really is the holder of the steem account claimed (without sending the private key).

If a user wants to have this change, this user can download my fork instead of the original. I will try to rebase with the original from time to time.

[BartolomeoItaliano]

If I understand you correctly. You want extend steem account privalages by creating your own service based on the steem accounts?

[shawnpringle]

Yes, I think that is a good description of what I want.

Another way of saying it is, if @ned uploads a file to Steemfiles, and you trust @ned and Steemfiles, you should be able to trust the file but Steemfiles needs a way to reliably validate that @ned is really @ned.

[BartolomeoItaliano]

Service like this is possible to create, but not easy (At least for me). You can encrypt http requests with user private key (they will become from this moment transaction) on your webpage. Send to your server and decrypt then using user public key.

If user will lie about his private key you will be unable to decrypt transaction.

[shawnpringle]

There is no routine for signing blobs that are publicly exported from steemjs itself. However, as part of its implementation there is. See my fork. It's only change is to export two functions that were previously not exported.

…

On Fri, 5 Oct 2018 02:51 Leather Dog Muksihs, ***@***.***> wrote: Why not simply do similar to steemit images? Have server send random blob to client. Client signs it with private key. Client sends the signed version back to server. Server verifies returned signed blob with public key. Server returns access token back to client. Client uses access token in combination with data to upload to server. Server verifies access token is not expired. if expired or unknown: reject, else: process. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#397 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AClXdat5dycNoRW3DCO7Sq-p0b5VIaQAks5uhvNugaJpZM4Vladu> .