-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
There is no good way to verify to the server that a the client browser actually has a user's private key #397
Comments
User never send his private keys to anyone. 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.
But then we've got to trust server. And what if one of our servers occurred dishonest? |
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. |
If I understand you correctly. You want extend steem account privalages by creating your own service based on the steem accounts? |
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. |
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>
.
|
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.
The text was updated successfully, but these errors were encountered: