After using many APIs, I noticed that most of them offer 2 keys: API Key and Secret Key. The secret key is used to sign the request body with HASHAGE algorithm, the most used is HMAC SHA256. This technique is used by financial platforms like BINANCE, coinbase...

But according to my research, the secretKey is stored in the database of the API providers server. Isn't it a security problem ? If the database is compromised, the hacker can access the secretKey.

Why don't the API providers use RSA to generate the signature. Instead of generating a HASH with SHA256, we can use a private RSA key. This way the providers keep only the corresponding public key. The private key (here our secretKEY) is never stored in the database and the security is better. Why don't the API providers do this? Excuse me if my question is trivial, but I am a junior engineer and I want to understand better.

1 Answer 1


It is possible to do this, but public key algorithms are typically substantially slower than most MAC algorithms, which tend to be based around hash functions. RSA specifically also results in signatures that tend to be around the size of N, which is also much larger than a typical HMAC function (3072 bits versus 256 bits for 128-bit security).

For comparison, on my three-year-old laptop with OpenSSL 3.0, I can do 28,416 3072-bit RSA verifications per second, 9954 Ed25519 verifications per second, and 85,395 16KiB HMAC-SHA-256 operations per second. This actually understates the performance of HMAC-SHA-256, since most signed requests are actually much smaller, and on newer machines SHA-256 is extremely fast since it's accelerated in hardware.

For making a small number of requests, this isn't a problem, but when your server is processing large numbers of requests, this can matter quite a bit, since you want the bulk of the expense of the operation to be performing the user operation and not authenticating it.

It is also substantially easier to encode and decode an HMAC value than a signature. Typically, one just uses something like base64 encoding. Digital signatures typically use large integers, which must be written in some endianness (which one matters), can use multiple integers (how to encode them and separate them matters), and often require validation (padding for RSA, point verification for ECDSA). In addition, private key operations that are online can be subject to timing attacks, which most hash functions are impervious to. Because HMAC is substantially simpler, it is much more likely that people will use a secure and correct implementation on both the client and server side, which is a huge selling point, considering that overwhelmingly security problems stem from implementation or protocol errors and not algorithms which have been suddenly broken. (People do still use insecure algorithms, but usually there is plenty of advance notice that the algorithm is weak and alternatives should be considered.)

In many cases, the risk of compromise can be minimized by limiting the lifetime of the token. For example, requiring people to constantly rotate the credentials means that if the database is compromised once, the credentials will soon be useless. This can easily be achieved with automated means in software, so the burden of doing so is often minimal.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .