User passwords in logs of deployed LiveView app

Phoenix Forum Questions / Help
, , ,
1

I have a hobby project that I deploy on fly.io since recently.

When I check the logs (with flyctl logs) I can see passwords of users (only me actually currently) as part of socket messages.

For example:

Last message: %Phoenix.Socket.Message{topic: "lv:phx-F6LyLij5Vszh4gGx", event: "event", payload: %{"event" => "save", "type" => "form", "value" => "_csrf_token=OVJ*****UD&user%5Bemail%5D=testemail%40gmail.com&user%5Bpassword%5D=password1234"}, ref: "21", join_ref: "4"}

The purpose of this hobby project is to get familiar with deploying and potential pitfalls. How do I safely handle messaging the passwords? I am using phx_gen_auth in a recently generated LiveView app ([{:phoenix, "~> 1.7.7"}, {:phoenix_live_view, "~> 0.19.0"}])

2

What is your logger config set to? Generally config/prod.exs has something like:

config :logger, level: :info

And I would assume that the socket messages would only be getting logged at the console level

3

Yes, just checked.

# Do not print debug messages in production
config :logger, level: :info

A sanity check: It is not normal to be able to see passwords in production logs, I reckon? I’m using all the default settings of phx.gen and fly.io. So that’s why I was surprised to find the passwords.

4

Do You know about the redact attribute? It might help…

https://hexdocs.pm/ecto/Ecto.Schema.html

5

I know it from the code generated by phx_gen_auth.

schema "user" do
    field :email, :string
    field :password, :string, virtual: true, redact: true
    field :hashed_password, :string, redact: true
    field :confirmed_at, :naive_datetime
    ...

    timestamps()
  end
6

ok, I thought it would help, but if it is already set…

1 Like
7

Thanks :slight_smile: .

Some other thoughts.

I know passwords get hashed on the server with phx_gen_auth. And it requires the original password to make the hash. And the password needs to be sent to the server somehow; in this case over the socket connection.

So it seems like the right configs are crucial for not exposing passwords to devs. Seems like an easily corruptible model. But maybe that’s just how it is?

I’m still in the process of checking out pow and alternatives, to eventually make a choice for an auth model. So maybe I’ll find some answers along the way…