Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log all Login Attempts #67

Closed
7 tasks done
nelsonic opened this issue May 8, 2020 · 8 comments
Closed
7 tasks done

Log all Login Attempts #67

nelsonic opened this issue May 8, 2020 · 8 comments
Assignees
Labels
discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality help wanted If you can help make progress with this issue, please comment! priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished T1d Time Estimate 1 Day technical A technical issue that requires understanding of the code, infrastructure or dependencies

Comments

@nelsonic
Copy link
Member

nelsonic commented May 8, 2020

At present (pre-alpha!) we aren't logging anything. We need to log everything in the Auth app to help mitigate malicious activity.

The fields we want to log are:

  • email - encrypted email address of the person the login attempt was made for. This allows us to keep track of how many attempts were made for a given account in a set time frame.
  • person_id - if the email exists in our people table log the person_id otherwise just the email so that we can later analyse the failed attempts. (e.g: typos)
  • ip_address - so we can rate limit by person_id and ip_address and so that we can inform people when their account has been accessed from an unrecognised IP.
    see: https://github.com/dwyl/hits/blob/cd9a8e15c6e598281b7bc6b037963dab6ac515f8/lib/hits_web/controllers/hit_controller.ex#L32-L33
  • user_agent_id - same as in Hits, we will have a user_agents schema where we store the full User Agent string then we reference it in the log rather than duplicating it.

This will eventually be replaced by "Client Hints" for better privacy (according to Google) 🙄
see: https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome )

This is related to our general quest to do Logging effectively in Phoenix Apps: dwyl/learn-devops#60
I think it makes sense to do the API logging table first and re-use it for this. dwyl/app#274 💭

@nelsonic nelsonic added enhancement New feature or enhancement of existing functionality help wanted If you can help make progress with this issue, please comment! discuss Share your constructive thoughts on how to make progress with this issue technical A technical issue that requires understanding of the code, infrastructure or dependencies labels May 8, 2020
@nelsonic nelsonic added the priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished label May 13, 2020
@SimonLab
Copy link
Member

I was thinking of creating a plug that we can add to the endpoints we want to listen to.
The plug can extract the information from the headers and from the assigns value (we need to make sure that it is run after the assign values are set by other plug).

However I think we also want to save the information of the responses (at least the status codes).
I'm not sure yet if this is doable with a plug so I'm going to try some code and which information and where on the request/response life cycle we can access them with elixir.

@SimonLab SimonLab self-assigned this May 14, 2020
SimonLab added a commit that referenced this issue May 14, 2020
@nelsonic
Copy link
Member Author

@SimonLab if you are looking into this issue,
please consider the more general logging issue first: dwyl/app#274
and read the source of https://github.com/timberio/timber-elixir to see how they are doing it.
Ref: dwyl/learn-devops#60

@SimonLab
Copy link
Member

Logging a response status might not be possible in every case to do directly inside a Phoenix application.
There is the register_before_send function:
image

However if the application fail before (e.g. error in a controller) the function might not be called
see: https://elixirforum.com/t/how-to-log-the-raw-http-response-built-by-phoenix-right-before-it-is-sent-to-the-client/19192/7

@nelsonic
Copy link
Member Author

@SimonLab if the request is failing in the controller we should be able to trace it in our logs.
Using register_before_send could be an option as part of our logging. 👍

@SimonLab
Copy link
Member

I've been reading the following articles:

This mostly deal with Logger and how to configure and use it in your Elixir application.
The articles explain what are the different type of log levels (debug, info, warn, error) and how to select one. By default the Logger is using debug, however the configuration of each environment set the level (ie do not display debug on prod, only info, warn and error).

Logging can consume cpu and memory and can delay your application, for example when a complex datastructure is passed to Logger which requires to be analyse first. For that Logger provides some options:

  • sync_threshold: define limit of message in queue where the log is not anymore asynchronous and become syncrhonous
  • discard_threshold: discard messages above the define threshold (ie max number of log message in the queue)

You can configure the level of log at runtime with Logger.configure function, for example `Logger.configure(level: :debug)

Logger is able to used different backend. A backend is where the log is written, the default one is console.
My first thought to log all the login attempt was to create a customise backend which will writte the log automatically in Postgres. However for a first attempt this feel over engineer at the moment.
So I'm currently creating the tables login_logs and user_agents as describe on the first comment and will call the ecto query in the controller which manage the logins.

SimonLab added a commit that referenced this issue May 19, 2020
SimonLab added a commit that referenced this issue May 20, 2020
SimonLab added a commit that referenced this issue May 20, 2020
SimonLab added a commit that referenced this issue May 20, 2020
SimonLab added a commit that referenced this issue May 21, 2020
SimonLab added a commit that referenced this issue May 22, 2020
@nelsonic
Copy link
Member Author

Working on this today as it's required by #122

@nelsonic
Copy link
Member Author

Logging now enabled. Updated code, schemas and tests included in #123

@nelsonic
Copy link
Member Author

Example of logs including both success and failure:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality help wanted If you can help make progress with this issue, please comment! priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished T1d Time Estimate 1 Day technical A technical issue that requires understanding of the code, infrastructure or dependencies
Projects
None yet
Development

No branches or pull requests

2 participants