3

I have a function that returns random unguessable keys with the following characters: a-z A-Z 0-9.

I have set the key length to 10 and I am using that for my form tokens to prevent CRSF and I will be using the same function also to generate email confirmation keys.

My question is if that will be secure enough to use?

The form tokens will be tied to a user session, and the email confirmation keys will be stored up to 24 hours before destroyed. Other than that I will not keep a log of them.

I have noticed there are a lot of sites that use extremely long confirmation keys with a length of about 30-40 characters. In my eyes that looks way overkill.

7
  • 10 chars (60 bits) is a bit on the low side, but there is no reason to use more than 20 (120 bits). Apr 22, 2014 at 21:12
  • If the email confirmation link does not contain the email address or userid, it'd be possible to generate an account with an email you don't own with about a billion requests by first requesting a token a billion times and then guessing a token a billion times, after which you probably guessed correctly once. (A kind of birthday/multi target attack) Apr 22, 2014 at 21:15
  • So, increasing the token and confirmation key lengths to 20. And including the user id (over email, to keep the link as short as possible) to end up with a confirmation link like: "domain.com/5363/Q9LNcCkCPIGz7McnErmB" [domain]/[id]/[key]. That would be secure, right? Apr 22, 2014 at 21:30
  • If you have 120+ bit tokens you don't need to include the id anymore. Just make sure you generate them from a secure and well seeded PRNG, not crap like rand, mt_rand etc. Apr 22, 2014 at 21:31
  • I'm using a combination of openssl_random_pseudo_bytes, bin2hex and hexdec. But why wouldn't I need to include the id anymore? Are the amount of possibilities too much for someone to even try finding them? Apr 22, 2014 at 21:34

2 Answers 2

1

If you add limited validity period (like 20minutes) for these keys (csrf, email confirmation) then I would say it is sufficient.

Also this is assuming you do not keep any history of the keys.

1
  • CSRF tokens will be tied to user sessions and refresh on every request. Email confirmation key will be stored for 24 hours before destroyed. Apr 22, 2014 at 18:08
1

"Secure enough to use" -- secure enough to use for what? Are you a bank? Healthcare website?

The "secure enough" question needs context and and understanding of your appetite for risk. If you sell $2 widgets and you're a daredevil then 10 charters is fine. If you're running something more sensitive and a 10-character token is going to keep you up at night, then it's not enough.

The other thing I don't get is why 20 (or 40 (or 80)) is too much. I'm not a fan of making security designs based on aesthetics. Bytes are pretty much free, who not go for it? If you're operating at the size where 10 vs 20 is going to create scaling issues for you then it would be worth the examination.

Keep in mind that technology advances. Guessing a 10-character value might be slow today, but feasible 3 years from now. Go big and hedge against computing getting faster and cheaper (which it always has).

You must log in to answer this question.

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