0
$\begingroup$

My custom web server software uses a 'server identity' which is a public/private bitcoin keypair. It's for extremely limited resource environments ie..IOT, which is why I don't use a common stack with OAuth etc..

I use the private key to sign certain messages I send to the app clients, so they can verify authenticity. The server is very much stateless, I don't wish to store any more data that I need to (auth tokens).

Are there implications to just signing a message, sending it to client as token, which they will send back in the authorization header with an expire timestamp? I will verify on the server. Not storing any tokens.

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ Change your tags, it does not seem related to your question. Put digital signatures instead. $\endgroup$
    – Manish Adhikari
    Apr 10, 2021 at 15:52
  • 1
    $\begingroup$ IMO this question suits security.stackexchange.com more but I don't think it is off topic here either. $\endgroup$
    – Manish Adhikari
    Apr 10, 2021 at 15:54
  • 1
    $\begingroup$ How certain are you that no response you might give a client is something they could feed into the blockchain as a valid transaction affecting something dear to the service? $\endgroup$
    – JamesTheAwesomeDude
    May 10, 2021 at 19:20
  • $\begingroup$ This seems like, replay attacks have not been considered - or maybe not to the degree required. An attacker might impersonate the server. I hope this is not more than a toy project. $\endgroup$
    – tylo
    Sep 3, 2022 at 1:21

1 Answer 1

Reset to default
2
$\begingroup$

They should be. As long as your signature scheme is resistant to existential or at least selective forgery, [under chosen message attack]. Well, I am not sure if the scheme requires resistance to forgery under chosen message attack unless you set up your application in which your server works as a signing oracle but no worries, most state of the art signature schemes are resistant to existential forgery under chosen message attack. As long as you don't use outdated signature schemes, the ones that hash the message directly using MD5 or SHA1, the signature can be forged by creating hash collisions.

In fact that's what popular JWT tokens are. They are just base64 encoded json objects with some content (like who it is issued to, expiry time etc),which may or may not be encrypted, and appended with a signature of that content produced using server's private key (or alternatively contains a MAC of the object produced using a key secret to the server but this method has a disadvantage in that no one else can verify the authenticity of the token).

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.