Security - Number Of Characters For Login Hash

Let's say I want to provide each user a unique URL to login into a system. The URL might look like this: http://example.com/login/a1b2c3d5e6

For example the string a1b2c3d5e6 uses lower case English alphabet with numbers from 0 to 9 and contains 10 characters, so the string of this length has 36^10 variations.

How many characters should I use to get a nice short hash string but at the sa开发者_如何学Cme time to be sure it is practically impossible to bruteforce? Should I use uppercase letters?

---

I see what you're doing here, but I wouldn't bother with hashes and such, where you have the risk of collisions (microscopic chances, granted).

I would recommend doing the following:

1. Take the user's ID from the database (which will obviously be unique)
2. base_convert it to base 36. (See: http://php.net/manual/en/function.base-convert.php)
3. Use the resultant string as your URL

The result will be a very small string that is guaranteed to be unique and collision-proof.

From what I understand, URL shortening services like TinyURL and others use this mechanism to generate their URLs. I actually learned that on this site, but can't find the link to that other thread anymore. Many thanks to the original author smarter than myself who brought this to my attention!

I hope that's helpful.

---

If your login url is:

http://example.com/login/a1b2c3d5e6

then I wouldn't worry about the last part of it but about the first part - http. If your users are visiting your url over insecure http then no matter how hard to guess you make it, it will be always easy to eavesdrop. Use https for any kind of authenticated connections.

Also you didn't explain what are you going to have at this url. I hope that you are going to use it as an additional precaution together with other forms of authentication and not instead of other forms of authentication.

That having been said, I think that if your idea is for your normal user/password login form to work only if the correct token is available in the url then it can only make the security of the system stronger, never weaker. This is a kind of security measure that works like an additional layer of the onion - even a weak layer will only make the onion stronger even if not much stronger. Just don't use it instead of some other form of authentication. And don't be too helpful with a failed login message, eg. your application should never say that the url is incorrect until it is correct and then say that the password is bad etc. You should only have one general error message for any reason of failed authentication.

Now about the length of the token, 10 characters seems reasonable. Just make sure that it is truly random or that it's a cryptographically strong hash of a unique value like username and some secret value. You can use HMAC for that if you want a ready to use solution. If you use HMAC-SHA1 then you'll get 20 bytes for each token. It's 40 hexadecimal digits from which you can use just the first 10 or 20 or whatever you want, or you can encode it as some form of Base64 or Base32 or something else.

Keep in mind that this token will have to be changeable and you will have to have a mechanism to remind it to someone who forgets it.

If you consider all of this then I see no harm of using it as an additional mechanism of authentication.