4 ms·

> false sense of security You don’t think a random generator that looks like it outputs log₂(26²⁰) ≈ 94 bits of entropy, but is limited by the weak PRNG state

> false sense of security You don’t think a random generator that looks like it outputs log₂(26²⁰) ≈ 94 bits of entropy, but is limited by the weak PRNG state space to 36 bits, and further limited by poor seeding to about 20 bits, creates a false sense of security? (Source: https://github.com/gteissier/erl-matter https://github.com/gteissier/erl-matter) It would be entirely possible to generate a cookie that gives true security. It would also be possible to generate no cookie at all and force the administrator to become aware of the issue if they want to enable clustering. It would also be possible to limit the exposure to localhost only by default. But Erlang does none of these things. It generates a weak cookie that looks like a strong cookie, leaves it in a hidden file that the administrator may never even become aware of, and exposes a daemon that relies on it for security to the internet by default. This is not how you build a secure system. This is not even how you build a system to get the administrator to realize that it needs to be secured. This goes against every security best practice that’s been written and some that are so obvious they shouldn’t need to be written. This is irresponsible and inexcusable in today’s environment, and hardly even excusable in the environment that Erlang was originally written for. This needs to be treated as the serious vulnerability that it is, and needs to be fixed.

Ndymium 5y ago
> You don’t think a random generator that looks like it outputs log₂(26²⁰) ≈ 94 bits of entropy, but is limited by the weak PRNG state space to 36 bits, and further limited by poor seeding to about 20 bits, creates a false sense of security? I don't think so, as the Erlang documentation states that 1) the distribution protocol is in plaintext, 2) the cookie is not secure in the cryptographic sense, but in the sense that it will prevent accidents, and 3) the cookie handshake is not cryptographically secure. It is not possible to generate a cookie that provides any true security as the distribution protocol is plaintext and the cookie handshake is not secure. Claiming to get any security benefit from a "stronger" cookie would only give a false idea to the user. Erlang does not start distribution by default. This is done by the user of Erlang, or the application that runs on Erlang. It is up to them to make sure that their environment is secure and that they understand how Erlang distribution works. Namely, to not open ports in the firewall willy nilly and only allow communication to them from an isolated network or over TLS. Frankly I don't know what you would expect Erlang to do here, maybe to add even bigger warnings to the documentation? The problem here is application developers not understanding how to configure their application to be secure by default. They are the ones opening the distribution wide to the Internet and not advising their users on how to do it safely, not Erlang.

Ndymium 5y ago

> You don’t think a random generator that looks like it outputs log₂(26²⁰) ≈ 94 bits of entropy, but is limited by the weak PRNG state space to 36 bits, and further limited by poor seeding to about 20 bits, creates a false sense of security? I don't think so, as the Erlang documentation states that 1) the distribution protocol is in plaintext, 2) the cookie is not secure in the cryptographic sense, but in the sense that it will prevent accidents, and 3) the cookie handshake is not cryptographically secure. It is not possible to generate a cookie that provides any true security as the distribution protocol is plaintext and the cookie handshake is not secure. Claiming to get any security benefit from a "stronger" cookie would only give a false idea to the user. Erlang does not start distribution by default. This is done by the user of Erlang, or the application that runs on Erlang. It is up to them to make sure that their environment is secure and that they understand how Erlang distribution works. Namely, to not open ports in the firewall willy nilly and only allow communication to them from an isolated network or over TLS. Frankly I don't know what you would expect Erlang to do here, maybe to add even bigger warnings to the documentation? The problem here is application developers not understanding how to configure their application to be secure by default. They are the ones opening the distribution wide to the Internet and not advising their users on how to do it safely, not Erlang.