3

I see a lot of people say to hash for the token on email verification when dealing with member registration.

I am wondering, if the email token is only to activate the account and nothing else, would the email token still need to be hashed ? Or do I need to hash the email token?

My thought: Since it has no correlation on the account information, it has no direct affect/access to the account. even the user tries to change the email token, it will only possibly affect the database active column from 0 to 1 (inactive to active).

Andrew
  • 151
  • 4
  • 1
    Can you provide a more precise source than "a lot of people" (a link to some well-established reference for instance would be the best). – WhiteWinterWolf Sep 05 '15 at 08:34
  • @WhiteWinterWolf sorry I dont have a well-established reference, but I found a related article http://security.stackexchange.com/questions/40310/generating-an-unguesable-token-for-confirmation-e-mails. Maybe its not a lot of people, but I just want to indicate people is using hash...do you think it is necessary to hash the email token? – Andrew Sep 05 '15 at 08:50

2 Answers2

2

The discussion you are linking actually says that you should not hash your token, you must only ensure that it is long and random enough, quoting Tom Leek:

Don't compromise, use a good PRNG. Don't try to make something yourself by throwing in hash function and the like; only sorrow lies at the end of this path.

However, as per your specific concern, using a poor predictable token could allow an attacker to enable accounts, as you said, but more importantly it will be allow him to do so without having access to the associated email address, thus bypassing the role of the email verification system.

For instance an attacker can create an account on your website using a fake email address. This account could then be used in social engineering attacks (the attacker could act as if he was an employee from some large company, another member colleague, etc.).

WhiteWinterWolf
  • 19,292
  • 4
  • 61
  • 110
  • so its better to hash the email token after all ? or how can I prevent such attack ? I am using this bin2hex(openssl_random_pseudo_bytes(10)) for my email token, is it safe? btw, thanks for your time! – Andrew Sep 05 '15 at 10:05
  • @Andrew: No, hashing will not increase security. You use the right functions, they are the one recommended by Tom Leek in the linked post, however in his message he recommends to use 16 bytes to be on the safe side instead of the 10 you currently use. Such change should be easy to implement and with such a long token (32 chars) there is no way an attacker could just guess a valid token. For supplementary security regarding the token, you can also check your token validity period (unused tokens should not accumulate other the years ;) ), but this will heavily depend on the application used. – WhiteWinterWolf Sep 05 '15 at 10:45
  • thanks for your response! Now I have a better understanding on how I should build with the structure. Sometimes I think I spend too much time on this and maybe in reality it isn't that much of a big of deal.... – Andrew Sep 05 '15 at 11:31
1

Generate a cryptographically secure random string (e.g. 128 bits) and use this for the token.

On the server side, you can hash this using SHA-256 and store it. That way, if anyone performs a successful SQL injection attack or the like, they will not be able to use any of the tokens retrieved. Again, the token supplied to the user via email is the unhashed version.

SilverlightFox
  • 34,178
  • 6
  • 73
  • 190