[Improvement] Encrypt user_id on account verification instead of actual user_id

[sidopufn]

When an email is sent to verify a new user's account, the clickback string contains the actual user_id of the user. It would probably be a better practice to use a random or hash value for that clickback instead of the actual user_id.

[OmarElgabry]

+1 encrypted value not hash value

[panique]

This will generate an extremely long and "ugly" link like this:

/register/verify/d9a32f8b6215ff64957c3e5c58491afb6be76124a51d7424847bfbc66b8d30c3%AD%B4%971%C4%1F%C0%84%93%F3%E6%1C%82%B4%8D%D1E%AB%DF%B7%F9%AE_%AA%29k%D8%23%3C4Mk/88983430bb0286f95a8fb3703b929f9b09a1272d

which is for unknown reasons not clickable in thunderbird, and also fails to become properly de-encrypted, even when used with urldecode() ..

Does somebody know how to do this properly ? Please do not use these links, I think for the initial verification link it's totally okay to use the real user_id. What's the potential value for an attacker, does somebody know this ? thanks! :)

[geozak]

You could hash them like git commit id hashes. Just take the first 7 or so characters and to prevent collisions when generating the value check if the shorted hash is already used by another user and if it is then make it one character longer until there is no conflict. Although with most decent hashing algorithms there should not be any similarities in the hash value of numbers close to each other and unless your user base is millions large that should be even less a problem.

[geozak]

Although I am not sure of the necessity of this is either as the user_id is just a pointer to internal information.
I haven't seen anything in the huge repo that would suggest having a user_id would provide any link into the system and even if there is an attacker could simply make guesses a few thousand time and find a user_id.

There is the possibility of them using it as part an injection attack and dropping that user but that is not a problem with the user_id, its a problem with blocking the attack.

[sidopufn]

The problem with exposing the user_id is that user_id might be used as an identifier outside the platform - like an account number.

[OmarElgabry]

This is because you are sanitizing the URL before passing arguments to action method. And at the same time, you can't omit the sanitizing part .

The solution is to use an algorithm that hashes the user_id like the way YouTube hashes the video Ids, GitHub commits & comment, ...etc(not highly secured as Encryption::encrypt() but It will almost do the job)