SecureRandom documentation does not cover a common use case

[gzankevich]

As I understand it, if you're trying to generate a token for something which you plan to store in the database then you need to hash the result of nextBytes. It would be handy if the docs mentioned this in:

http://symfony.com/doc/master/book/security.html#generating-a-secure-random-number

[javiereguiluz]

I don't understand this issue. The behavior of nextBytes() depends on the configuration of your system:

1. If OpenSSL is supported, the returned bytes are generated with openssl_random_pseudo_bytes() PHP function.

2. If OpenSSL is not supported, Symfony generates the bytes itself and returns them after applying the sha512 hash algorithm.

In the second case, there is no need for the hash. In the first case, the returned value is a string (although it can contain only digits and be interpreted as a number). So, do you really think we need to add a note about hashing this value?

[stof]

@javiereguiluz nextBytes returns a binary string. This may contain \0, so you should indeed hash it/convert it if you want to store it in a DB as they generally don't like NUL bytes.
And if you plan to use the token in a URL, you should restrict the string to URL-safe chars. Using it in form submissions does not play well either with binary strings (which is why CSRF tokens are converting the random bytes for instance)

[javiereguiluz]

Now I understand the problem. I'm trying to fix it in #5472. Thanks for the explanation.