The History of Random.org (2009)

Visiting a webpage and copy-pasting a string off of it is not a very good practice for security because you're adding on a lot of parties to trust with that secret!

Effectively you want to minimize ANY place that your secret exist in plaintext, and trusting a webpage with this is just not a good idea.

I imagine owning random.org, and not being very mean but a little clever. I know how many people come here for a quick clip; more importantly I know you come here. I rotate the same blob. I know all the pieces to brute force your infrastructure. Maybe you’ll use the wrong setting and something will be public that shouldn’t be. Hello.

It all comes down to chain of trust. When it comes down to a root password, or any secret that's business-critical you want to minimize ANY sort of risk and that's just the right way to do business.

When I point my scraper at random.org I can see it talks to "ocsp.digicert.com", "ajax.googleapis.com", "ssl.google-analytics.com", and obv. "random.org" (wow that's actually pretty good =P)... those are now three separate entities that now need trust because they all have the opportunity to see what was rendered on that page in plaintext, they have the opportunity to see what you selected, etc.

Then add to that, any browser plugin, the browser itself, etc etc. Then the "in plaintext over screenshare" issue - and you've got a lot of points where something, or someone could MiTM a plaintext password if they wanted/needed.

Generating a random password/secret by visiting a public site on the internet is stupid/silly with regards to actual security, and opens yourself to attack vectors _for no real reason_. There are a TON of VERY QUICK/EASY ways to generate a very secure string for secret management that don't involve trusting a ton of third parties =|

In a "security culture conscious" SF tech company there should be no place for laziness/lack of care like that. IMO - dumb compromises like that are how you get caught with your pants down leaking a ton of PII.

There’s a strong assertion that it’s a bad idea, but no actual reasons given. The link doesn’t address it. So I asked the question.

So far the answers have been downvotes and evasive questions, so I’m leaning toward the idea I stepped into some kind of ideological thing. That’s fine, I don’t really care so I withdraw the question.

So the problem become to determine the offset of the stream you looked at, which is an integer that probably fits in 64 bits.

You could do the same with audio noise by looking for peaks above a certain value and using a similar time function.

I don’t know if that is really how it is done, so I might be misremembering.

One way to do that is to “compress” all your input entropy into a single state, and then use that as the key for a stream cipher, like AESCTR or Salsa20.

You can also "seed" subsequent round of the has with the output from the previous round. That helps protect against certain kinds of failures. It's not really necessary, but it's not hard to do either so you might as well do it.