Is there any benefit to signing a random number?

E.g. a link for password reset, sent to email, often includes a base64 encoded random number to prevent someone guessing what the password reset link would be. If that number is cryptographically signed or hashed, does it improve the security in any way?

Say, 256-bits of randomness and 256-bits of signature, is that any more secure than just using 512-bits of randomness?

  • Ask yourself this: What effect can an adversary have by substituting a different number in a forged message? And, for signatures in particular, does the forgery have an impact only on the two parties trying to communicate, or does it have an impact on a third-party judge that one party is trying to convince of a forgery? Sep 12, 2019 at 16:12
  • I've migrated this question here because, although the question title is generic, the question body is about securing a system rather than questions on the cryptography used to secure it. Sep 12, 2019 at 22:32

3 Answers 3


Say, 256-bits of randomness and 256-bits of signature, is that any more secure than just using 512-bits of randomness?

It is not any more secure. The best case scenario for the signed token is that the attacker don't know anything about what would be a proper signature. That effectively makes it a 512 bit ranom number from the perspective of the attacker. Besides, a properly generated 256 bit random number is practically unguessable anyway.

You will need signatures if you want to avoid database lookups. But then you wouldn't be signing a random number, but a description of the task the token grants the user the right to perform - e.g. password reset for user 123, before the deadline X. I'm not sure I would dare to use such a scheme for something as critical as password reset, though.


If you have a database at your end where you can check that random number to ensure that it's the one you really sent, then not really.

A more important consideration in a scheme like that is that your numbers come from a strong cryptographic quality source of randomness, otherwise an attacker might guess what someone's password reset code will be! A signature does help defend against this scenario since even if an attacker can guess the code they can't sign it.

  • Can't they guess the signature too?
    – rich
    Sep 12, 2019 at 15:56
  • Not without the secret key. That's the point of a signature. :) Sep 12, 2019 at 16:11
  • For a secure system I'd do this: (1) generate a random code, (2) sign this code plus the recipient's e-mail, (3) send a code composed of the random code and the signature, (4) on receipt verify that this code plus the recipient's e-mail were signed by your secret key. Sep 12, 2019 at 16:12
  • By signing them together you "bind" these two objects together and provide proof that they are associated. Sep 12, 2019 at 16:13
  • 1
    Right, so, is it easier to guess a 512-bit number than a 256-bit number plus a 256-bit signature?
    – rich
    Sep 12, 2019 at 18:41

There are two ways to sign the token:

  1. You can sign the email envelope, but your password reset server only receives the raw token, the token is only used to prevent the email from being tampered. For example, an attacker might tamper the password reset link so they redirect to the attacker's domain instead of your real domain. The attacker can then present a fake password reset page and steals the user's plaintext password.

  2. You can sign the token itself, so that your password reset server then receives a signed token. This allows you to build a password reset system without reliance on centralised user database, which can be useful for scalability in larger distributed systems. Note that you'd want to have expiry date on the signature to prevent a long forgotten reset link requested three years ago from being used to reset the account now.

You must log in to answer this question.

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