-1

I am creating an API and I am thinking of using an encrypted value of some random password as the value to store for the plain text representation of my signing key. Is this just a vain attempt to make things look secure or is there any benefit to this?

edit
it's a private signing key for a JWT. Something I would be storing in a properties file or elsewhere. The API provides functionality for posting data to the server. I am specifically asking if using an arbitrarily generated bcrypt hash provides any benefit to use as the plain text value of my signing key.

  • 1
    Sorry, I can't quite follow you there. Your signing key is probably a private key. What should your API provide and how is the data provided supposed to be used by the users? Why is a signature neccessary and what is actually being signed? – GxTruth Feb 6 '18 at 8:48
  • @GxTruth Thanks, it's a private signing key for a JWT. Something I would be storing in a properties file or elsewhere. The API provides functionality for posting data to the server. My instinct was to encode some password and use the encoded value for they key. Then I had the thought that it doesn't matter if this is encoded or not because if someone gains access to it that's all they need. I suppose it would gain the benefit of being harder to guess – zero01alpha Feb 6 '18 at 13:01
  • Your server HAS to have access to the private key, as it is required to sign your JWTs. However, you NEVER need the private key to anybody. Your users need access to your public key (they should be able to check that it's your, i.e. using certificates), in order to verify the signature. Is this what you wanted to know? – GxTruth Feb 6 '18 at 13:04
  • @GxTruth No I'm just wondering if there is any real benefit to storing the plain text private key as an encoded string – zero01alpha Feb 6 '18 at 13:09
  • 1
    Encoding does not provide any security, as it is reversible without a key. If you store your private key in, say Base64 encoding, you may as well, store it in plain text. No security gained by this. – GxTruth Feb 6 '18 at 13:13
1

Taking your replies to comments into account, I'll try to provide an answer here.

For clarification, OP has a webservice handing out signed JSON Web Tokens and is worried about the security of his/her private key on the server. OP asked, whether encoding it is any good, answer to that is no. Encodings do not provide any security, as they are reversible without a key. If an attacker gains access to your encoded private key, there is nothing preventing him from decoding it.

Furthermore, OP asked, whether bcrypt is a secure way of storing the private key. Answer is also no. bcrypt is not an encoding or encryption function, but a cryptographic hash function. It takes an input and generates a secure salted cryptographic hash, which allows the server to compare it to other inputs and decide, whether both input are the same (i.e. matching a user's password while logging in, without having to store the password in plain text).

Hashing your private key renders it unusable, as it cannot be recovered and the hash cannot be used to sign or decrypt any messages.

Maybe you can store your private key in a file, only readable by the web server user (i.e. www-data, when using apache) or use other. However, if your cannot even trust your own server to this extend, maybe that's the point to start considering more security measures. Eventually you have to trust something.

Edit: OP indicated, that only the server is interested in the JWT itself, rendering signature verification by the user obsolete. In this case, the server can either generate a keypair just for itself, which seems like an overkill, if the signing and verifying server is always the same machine.

Considering that having one secret is sufficient for OP, HMAC or a similar key-based hash function might be a better choice here. The server has a secret key, which is used to create a hash of the JWT and verify it upon receiving the token from a user. Tampering is prevented by this technique.

An asymmetric approach might be better, if there is a single server/(micro-)service creating those tokens and other endpoints require the JWT signatures to be verified. An advantage is, that the "Token Factory" can be an even better protected machine/service, while regular endpoints only need the corresponding public key, thus not comprimising the keypair, if hacked.

  • 1
    While correct you should make use of NIST SP 800-63B (Digital Identity Guidelines)and SP 800-132 (Recommendation for Password-Based Key Derivation). While it might be more than you wanted to read they are meant to help you secure your api – jas- Feb 6 '18 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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