That is a valid concern. However, once a password is published (especially in docs or tutorials) it is insecure whether they are random values or not - simply because they are public and clearly linked to the product you're running.

That's why I chose to make it explicit, and thus more likely to be caught in review if done.

I'd suggest using something like:

  export SYSTEM_SECRET=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
  echo "SYSTEM_SECRET is $SYSTEM_SECRET"

Good idea! How could that look like on windows (the guide should work on all OS and I'm no windows pro)?

Rough equivalent in PowerShell would be:

  @(48..57 + 65..90 + 97..122) | Get-Random -Count 32 | ForEach-Object -Begin {$secret = ''} -Process {$secret += [char] $PSItem} -End {$env:SYSTEM_SECRET = $secret; Write-Host "SYSTEM_SECRET is $secret"}

My Powershell-fu isn't quite up there. What's the first part of that block? Is that concatenating arrays of ranges of char codes?

Yes, it just creates an array of the decimal values for ASCII A-Za-z0-9. By default Get-Random just returns a random unsigned int, but if you pass in an array of objects it will select a random object from the array.

Note that Get-Random is not cryptographically secure, it's just seeded by the time stamp of the start of the session.

Linux noob here: what's the fold for? How is that secret different from doing something like

tr -dc A-Za-z0-9_ < /dev/urandom | head -c 32

?

The difference is that fold will add a trailing newline. Another option is to add an '; echo' at the end of the operation.

And yes the "cat" is not necessary.

One solution could be the app/service could have some dummy passwords built in which you can use for tutorials but it will refuse to use them if supplied.

Good point, Hydra does this to for things like missing TLS encryption but not yet for secrets (it only rejects secrets that are too short). I've tracked this here: https://github.com/ory/hydra/issues/573

It seems like the simplest thing, then, would be to use a secret that is too short in your documentation and make note of both the fact that it's too short and what the requirements are for a good secret.

Of course, this runs the risk that a user will simply "salt" the sample you provide up to the necessary length, which makes the length of their secret effectively the difference between the minimum length and the sample length.

I solved this for my objects in two ways.

1) admin accounts are generated on startup with random passwords. These are printed on the console on the first startup only.

2) in a configuration format I use, there is a special keyword for using a random string as a value which is different each time the config is parsed.

I think any secure value should be either generated for you or random on each startup unless specified otherwise. It would greatly improve the security of some projects out there.