#20495: add login failure events to django.security logger
--------------------------------------+------------------------------------
Reporter: ptone | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by claytondaley):
I'd like to at least +1 that extensive logging of authentication (etc.
etc. etc.) is a requirement in some industries (e.g. healthcare). I
suspect the "why" is a combination of SIEM's real time features and breach
notification regulations. For example, the severity of the breach (number
of impacted records) affects your regulatory obligations so it behooves
you to know *exactly* what was touched even if you didn't stop it.
Of course, if you're selling into the healthcare space and your customers
demand it, **how** is far more important than **why**. For example, the
following is what one healthcare client requires:
> The Product or Service will provide user activity Audit Log information.
>
> Audit Log entries must be generated for the following general
classifications of events: login/logout (success and failure); failed
attempts to access system resources (files, directories, databases,
services, etc.); system configuration changes; security profile changes
(permission changes, security group membership); changes to user
privileges; actions that require administrative authority (running
privileged commands, running commands as another user, starting or
stopping services, etc.); and remote control sessions (session
established, login, logout, end session, etc.).
>
> Each Audit Log entry must include the following information about the
logged event: date and time of event; type of event; event description;
user associated with event; and network identifiers (IP address, MAC
Address, etc.) or logical identifiers (system name, port, etc.).
The description is somewhat ambiguous between OS and software-level
logging because it's intended to cover both. Many of these (auth, roles,
permissions and related administrative actions) have to be captured from
Django components.
===
The lesson I draw from #23155 is that logging can't (in fact shouldn't)
depend on signals. Signals should be lightweight. It should be enough to
say "user _n_ failed to log on". If the receiver needs to know about
user _n_, they should load whatever additional data they need (hopefully
from cache). That's what a signal is.
Logging should (and generally does) aspire to the opposite. We don't say
"that's too trivial... don't log it". We say "log it, but classify it as
DEBUG". I think we should have the same mindset for sensitive data. The
comment above is correct that logging usernames/passwords to plain text
would be inappropriate. What we really need is a "DEBUG flag" for
content.
I even have a thought about how this might be done... an improved logger
that "white lists" data elements. Send everything and let the consumer
decide. Debate the defaults. We agree that username shouldn't be
included so it's left out of the defaults, but **not hard-coded into
Django**.
--
Ticket URL: <https://code.djangoproject.com/ticket/20495#comment:20>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.0c6a948bbc3093535a22fd8ba29719c9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
