There's a security issue in the token generator:
The random number generator fills all bytes in the array with random numbers between 0 and 255. The mapping between the number in each array and one character in the string possible is biased, however, as the length of possible(62) is no factor of 256. This leads to some characters being chosen more often than others, because there is a remainder(8).The solution is to check if the random number is higher or equal to 248 (62 * 4). In this case the number must be re-generated until a lower number is found. Alternatively, the string possible could be extended by two more characters, which would increase the length of possible to 64. As 64 is a factor of 256 the bias-problem would also be resolved.
In the following pull request I have added the chars - and _ to the string haystack. Theese were chosen as they are acepted by PKCE and RFC b64token types so it satisfies the needed 64 length of the haystack (which is 62 currently)
doatech
commented
2 years ago
Description
There's a security issue in the token generator: The random number generator fills all bytes in the array with random numbers between 0 and 255. The mapping between the number in each array and one character in the string possible is biased, however, as the length of possible(62) is no factor of 256. This leads to some characters being chosen more often than others, because there is a remainder(8).The solution is to check if the random number is higher or equal to 248 (62 * 4). In this case the number must be re-generated until a lower number is found. Alternatively, the string possible could be extended by two more characters, which would increase the length of possible to 64. As 64 is a factor of 256 the bias-problem would also be resolved.
In the following pull request I have added the chars
-and_to the string haystack. Theese were chosen as they are acepted by PKCE and RFC b64token types so it satisfies the needed 64 length of the haystack (which is 62 currently)Library version: