1
$\begingroup$

I just came across this question, but it does not really answer my main concern that I have regarding password tokens.

To authenticate a client who is not logged in; I generate two random tokens and then use one as the DB selector, the other one as the validator, to authenticate an unknown client for a given operation, like resetting a password, etc.

My question is not regarding the generation of the hashes, that's all done. The thing is that I've been told to attach the base64 representation of the hashes to the reset password or whatever URL. Because it uses less space / is more efficient than HEX. That of course is true, but isn't that more dangerous for brute-force attacks, if you use a base64 string, which is shorter?

Improve this question
$\endgroup$
0

3 Answers 3

Reset to default
1
$\begingroup$

I think I see the confusion. Making the string shorter isn't like having a shorter password.

Shortening a password does make a brute-force attack faster, because the number of possible passwords gets smaller, so you have to try fewer passwords to brute-force it.

But encoding a fixed-size hash value in a different base (16 or 64) does not change the number of possible combinations needed to brute force it, so does not make brute forcing easier or faster, assuming the attacker has seen at least one example of the hash, so can guess what base it's encoded in.

Base64 is 2/3 the length of base16 (it encodes 6 bits per character instead of 4).

So let's say you are trying to brute-force a variety of different hashes. Let's calculate how many possible combinations you'll need to try, at worst.

A single, 24-bit integer: (16777216 possible values) ^ (1 integer) = 16777216 attempts. Well, duh, obvs.

A 4-character, base-64 string: (64 possible values) ^ (4 characters) = 16777216 attempts.

A 6-character, base-16 string: (16 possible values) ^ (6 characters) = 16777216 attempts.

A 24-character, binary string: (2 possible values) ^ (24 characters) = 16777216 attempts.

Notice how those numbers are all exactly the same. We have to try exactly the same number of different possibilities to find the correct one in each case, because they are all 24-bit values, just encoded in different ways.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Cheers now I fully understand it! $\endgroup$
    – DevelJoe
    Commented Sep 2, 2022 at 0:56
2
$\begingroup$

A longer URL will make request times a miniscule amount longer. Not enough to hinder brute-force attacks, and you should have rate limiting anyway which would make any differences negligible. Further, reset tokens shouldn't be usable more than a few times. Once would be ideal, but some email providers (gmail) follow URLs in emails with their scanner bots as an anti-spam measure.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Cheers for the clear answer! @aschoerk thanks for your answer too; selected this one as its responds more concretely to my concern. $\endgroup$
    – DevelJoe
    Commented Sep 1, 2022 at 17:37
1
$\begingroup$

Concerning the length: Be aware that Base64-Encoded Strings may contain +,/ or =. Therefore it is not direct usable in URLs. The necessary url-encoding can add to the length. A Hex-String can be added without additional url-encoding.

Concerning the danger, I don't understand the question since both encodings are easily detectable and reversible.

Improve this answer
$\endgroup$
6
  • 1
    $\begingroup$ If you use stuff like SODIUM_BASE64_VARIANT_URLSAFE within this; you avoid URL-related problems. My concern is: Does the shorter length of base64 strings not make brute-force attacks easier than the longer hex strings? $\endgroup$
    – DevelJoe
    Commented Sep 1, 2022 at 15:11
  • $\begingroup$ Just imagine you have a password reset URL like http://example.org?token1=selector&token2=validator. My concern is that it's potentially easier to brute-force selector and validator if they're base64 encoded, vs if they're hex-encoded. No? $\endgroup$
    – DevelJoe
    Commented Sep 1, 2022 at 15:18
  • 2
    $\begingroup$ The transported information is not different. So the mean necessary number of attacks to be successful will be the same. Transporting x% less bytes may make the transport-time a bit faster. So the shorter URL might support the brute-force attacks. But is that really an issue? If you want to keep the URL long to hinder brute-force-attacks, you can use other means as well. $\endgroup$
    – aschoerk
    Commented Sep 1, 2022 at 15:18
  • $\begingroup$ "So the mean necessary number of attacks to be successful will be the same." vs "So the shorter URL might support the brute-force attacks." => ??? $\endgroup$
    – DevelJoe
    Commented Sep 1, 2022 at 15:23
  • 3
    $\begingroup$ @DevelJoe they mean that the amount of attacks is the same since the decoded bytes are the same always, but it takes less time to transfer the data because of the shorter URL, so each individual attack may take less time (sane rate limiting should remove the difference though) $\endgroup$
    – Junelilly
    Commented Sep 2, 2022 at 1:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.