> 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 fur

> 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.