This question is about the server running on the client’s machine (as a desktop app in some shape or form). There is no secret to be kept if both the server serving http and the browser reading it are on the same machine, controller by the same user.

I agree with you and I will go even far by saying to never never put secrets in a release, always retrieve them from the environment the release will run, because as you say the final release can always be inspected in order to extract them.

I am writing a guide in hardening Phoenix, and I am covering this security concern in more detail:

The project I am working on to test all the hardening is still a work in progress, but the runtime.exs file at this moment looks like:

import Config

# Use here the hostname for the server itself, that is not necessarily the one
# you type in the browser.
# Behind a proxy or in a docker container the host is for example `localhost`
# and port `4000`, but when the server is facing directly the Internet will be
# like `example.com` and port `443`.
server_hostname = System.fetch_env!("PHOENIX360_SERVER_HOSTNAME")
server_http_port = System.fetch_env!("PHOENIX360_SERVER_HTTP_PORT")

# Use here the same host and port you type in the browser. So, in development it
# can be `localhost` and port `4000`, but in production, behind a proxy, on a
# docker container or directly facing the Internet, it will be like
# `example.com` and port `443`.
public_domain = System.fetch_env!("PHOENIX360_PUBLIC_DOMAIN")
public_domain_http_port = System.fetch_env!("PHOENIX360_PUBLIC_DOMAIN_HTTP_PORT")
public_domain_https_port = System.fetch_env!("PHOENIX360_PUBLIC_DOMAIN_HTTPS_PORT")

# Phoenix by default compiles secrets and salt values into the release, and this
# becomes a security concern, because this values can be leaked during the CI/CD
# pipeline. Also, anyone getting their hands in the release binary can reverse
# engineer it to extract this sensitive values, therefore you may put a release
# into production without knowing that is already compromised or it can be
# compromised after you deploy it.
config :phoenix360, Phoenix360Web.Endpoint,
  secret_key_base: System.fetch_env!("PHOENIX360_SECRET_KEY_BASE"),
  render_errors: [view: Phoenix360Web.ErrorView, accepts: ~w(html json), layout: false],
  pubsub_server: Phoenix360.PubSub,
  live_view: [signing_salt: System.fetch_env!("PHOENIX360_LIVE_VIEW_SIGNING_SALT")],
  cache_static_manifest: "priv/static/cache_manifest.json",
  check_origin: [
    "//" <> public_domain <> ":" <> public_domain_https_port,
    "//www." <> public_domain <> ":" <> public_domain_https_port,
  ],
  server: true,
  # url: [host: public_domain, port: public_domain_http_port],
  http: [
    port: server_http_port,
    transport_options: [socket_opts: [:inet6]],
  ]

# ## SSL Support
#
# To get SSL working, you will need to add the `https` key
# to the previous section and set your `:url` port to 443:
#
config :phoenix360, Phoenix360Web.Endpoint,
  url: [host: public_domain, port: public_domain_https_port],
  https: [
    port: public_domain_https_port,
    cipher_suite: :strong,
    # keyfile: System.fetch_env!("PHOENIX360_SSL_KEY_PATH"),
    # certfile: System.fetch_env!("PHOENIX360_SSL_CERT_PATH"),
    transport_options: [socket_opts: [:inet6]],
    # dispatch: [
    #   {
    #     "[www.]" <> public_domain,
    #     [
    #       # {:path_match, :handler, :initial_state}
    #       {:_, Phoenix.Endpoint.Cowboy2Handler, {Phoenix360Web.Endpoint, []}},
    #     ]
    #   }
    # ],
  ]

# The `cipher_suite` is set to `:strong` to support only the
# latest and more secure SSL ciphers. This means old browsers
# and clients may not be supported. You can set it to
# `:compatible` for wider support.
#
# `:keyfile` and `:certfile` expect an absolute path to the key
# and cert in disk or a relative path inside priv, for example
# "priv/ssl/server.key". For all supported SSL configuration
# options, see https://hexdocs.pm/plug/Plug.SSL.html#configure/1

config :phoenix360, Phoenix360Web.Endpoint,
  # To be retrieved at runtime by `Phoenix360Web.Endpoint.RuntimeSession.options/0`.
  session_options:
    [
      store: :cookie,
      key: "_phoenix360_key",
      signing_salt: System.fetch_env!("PHOENIX360_SESSION_SIGNING_SALT"),
      encryption_salt: System.fetch_env!("PHOENIX360_SESSION_ENCRYPTION_SALT"),
    ]

config :phoenix360, Phoenix360Web.Endpoint,
  letsencrypt: [
    # Note that native client is very immature. If you want a more stable
    # behaviour, you can provide `:certbot` instead. Note that in this case
    # certbot needs to be installed on the host machine.
    client: System.get_env("LETSENCRYPT_ACME_CLIENT", "native") |> String.to_existing_atom(),

    domains: [public_domain, "www." <> public_domain],

    emails: System.fetch_env!("LETSENCRYPT_ACME_EMAILS") |> String.split(","),

    db_folder: Application.app_dir(:phoenix360, System.get_env("LETSENCRYPT_STORAGE_DIR", "priv/letsencrypt")),

    directory_url:
      case config_env() do
        env when env in [:dev, :test] ->
          {:internal, port: System.get_env("LETSENCRYPT_ACME_HTTP_PORT", "4002") |> String.to_integer()}

        # If running the `:prod` release in staging set the `ACME_SERVER_URL` env
        # variable to: https://acme-v02.api.letsencrypt.org/directory
        :prod ->
          System.get_env("LETSENCRYPT_ACME_SERVER_URL", "https://acme-v02.api.letsencrypt.org/directory")
      end
  ]

if config_env() == :prod do
  log_level =
    (System.get_env("PHOENIX360_PROD_LOG_LEVEL") || "info")
    |> String.downcase() |> String.to_atom()

  # Configures Elixir's Logger
  config :logger, :console,
    level: log_level,
    format: "$time $metadata[$level] $message\n",
    metadata: [:request_id]
end

This is far from being the final solution, but as you can see at the top the secrets are fetched from the environment, and once Elixir runs this file each time it starts then we don’t have the production secrets in the binary for the release.

when you build a release an env.sh file is created, thus you can try to set and export the SECRET_KEY_BASE var their with:

# file: _build/prod/rel/phoenix360/releases/0.1.0/env.sh

export SECRET_KEY_BASE=$(strings /dev/urandom | grep -o '[[:alpha:]]' | head -n 64 | tr -d '\n'; echo)

And you need to see how you can do the same in the env.bat file for Windows environments.

To bear in mind that having a new SECRET_KEY_BASE in each release means that any connected user will need to re-authenticate, because and any previous cookies, csrf_tokens will be invalid.

You want to run the command out of band and supply the results on startup of your application. If secret key base would be meant to change each time the app boots phoenix would do that internally instead of asking you to provide a secret.

The secret key base changing would mean all data signed with that secret becomes invalid. That is cookies, Phoenix.Token‘s and probably csrf tokens if not more.