Let's say I'm using several crypto functions from a 3rd party lib and those crypto functions should never fail because my code, and not a user, is sending all the arguments (buffers, sizes, etc..) so if the function fails it's due to some "internal error". Let's say I have an rsa function and a hash function, my question is:

If those functions fail, should my code return internal_error error code for both failures? Or should it return rsa_internal_error and hash_internal_error respectively?

Returning just internal_error reveals that an internal error and no more so it's harder to debug if my code can return internal_error from several places in one function.

On the other hand, returning a specific error code for each type of failure makes it easier to debug, but also reveals more information to the user.

Which practice is better?

Does returning specific internal error codes can help attackers in their penetrations attempts?

EDIT: This is an embedded systems so we are cheap on logs. Since this error should not occur (it's not dependent on input or something) we usually don't log those errors.

  • Just return an ID which can be looked up in the logs by an admin. Jun 6, 2018 at 14:32
  • @SilverlightFox of course the error names are mapped to unique IDs, I'm asking if returning specific errors codes regarding internal errors can help attackers in their penetration attempts.
    – Gil-Mor
    Jun 6, 2018 at 14:39
  • I mean an ID for that specific occurance of the error. That way you do not have the debug problem as your server-side logs will contain full debugging information without revealing anything to the end-user. Jun 6, 2018 at 14:42
  • In this day and age where we can produce compute on the size of credit card, I find it hard to be "cheap on logs". Jun 6, 2018 at 15:17
  • 4
    @ShaneAndrie Not relevant.. Every system has its own requirements.
    – Gil-Mor
    Jun 6, 2018 at 15:21

3 Answers 3


Which practice is better?

It depends on your needs. There is no "secure" or "not secure", only "secure enough for my needs". Which is better depends on your particular risk/benefit tradeoff willingness. As such, this is rarely an answerable question in a security context.

Does returning specific internal error codes can help attackers in their penetrations attempts?

Probably not. You certainly shouldn't be returning stack traces or the like, but a vague error description is probably unlikely to help a would-be attacker. However, a vague error description is probably also unlikely to be very helpful during debugging. As a result I'm going to ask the obvious question:

Don't you have logging on in your system?

For instance, in my API calls if there is an error in production I simply return (a JSON document) that says "Internal Error" along with a 500 status code. This works out well for our front-end developers. When they see that they just stop and come bug me because they know the problem isn't on their end. For my part, I then just go look in my server logs which tell me exactly what happened. There is nothing that can potentially leak to outsiders, and I have all the debugging information I need to fix whatever the problem is.

In short, it sounds like what you need is some detailed logging that is only accessible internally.

  • Thanks, I edited my question. I'm talking about an embedded system and we can't log everything :)
    – Gil-Mor
    Jun 6, 2018 at 14:53
  • @Gil-Mor Do you have a way to flag the system between development and production? If so you can return whatever you want in development. Just make sure that they only leave the building in production mode. Jun 6, 2018 at 18:04
  • @Gil-Mor Actually, that last comment is pretty much the same thing that Peter said in a comment on his answer. Jun 6, 2018 at 18:04

You could obscure the errors using hash/hmac. One option would to have secret key K hardcoded in app (or in a file if you are pedantic, or the app is widely distributed). On error generate random token T, then display error as HMAC(K, T + error_code);

When debugging, just use a simple utility to try all possible errors and see which one generated the HMAC. This obscures the error enough for user not to find out which error it was, but still allows not too difficult debugging.

PS: Also using non-sequential error codes may help.

  • Thanks, nice idea, the question is - is it worth it?
    – Gil-Mor
    Jun 6, 2018 at 15:05
  • @Gil-Mor Really depends on the app and your threat model. Conor explained that better than me. I just wanted to contribute this middle of the road approach that does not require logs. I would say for most apps, it is not worth it. Instead make some switch to enable/disable the error codes so you can enable them when debugging only. PS: also show a note "debugging enabled" in a visible place, so it does not remain turned on by accident. Jun 6, 2018 at 15:07

Yes, Yes, return meaningful errors

Security is hard enough. Make the developer or user experience easier. In this case, the tradeoff is minimal.

Does returning specific internal error codes can help attackers in their penetrations attempts?

Yes, but (hopefully) not to a meaningful extent.

How can the verbose error message hurt you?

Actually none of your mitigations prevents some timing attacks. Here is a simple timing attack. Let's say you are comparing a password string to a password string like this:

$password = "bobcat"

The way the computer checks this is:

for char1 in $password: for char2 in "bobcat": if char1 != char2: break

Now, if i send the password "p", and it fails slower than if I send the password "a", I'll know the first character is "p".

Now I just need to loop through the rest of the alphabet until I get the rest of the characters.

If your errors are timing attack resilient, don't worry about the verbosity.

  • We have protection against timing attacks :) Thanks for the answer
    – Gil-Mor
    Jun 10, 2018 at 13:51

You must log in to answer this question.

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