... | ... | @@ -944,7 +944,9 @@ seems the user's password is stored on disk, encrypted with a Blowfish |
|
|
cipher in CBC mode (from `Crypt::CBC`), with a 10 bytes (80 bits) key,
|
|
|
while the HMAC is based on SHA1 (from `Digest::HMAC_SHA1`). The tokens
|
|
|
are stored in `/var/cache/userdir-ldap/web-cookies/` with one file per
|
|
|
user, named after a salted MD5 hash of the username.
|
|
|
user, named after a salted MD5 hash of the username. Tokens expire
|
|
|
after 10 minutes by the web interface, but it doesn't seem like old
|
|
|
tokens get removed unless the user is active on the site.
|
|
|
|
|
|
Although the user/password pair is not stored directly in the user's
|
|
|
browser cookies or history, the authentication token effectively acts
|
... | ... | @@ -1177,8 +1179,13 @@ label. |
|
|
|
|
|
## Monitoring and testing
|
|
|
|
|
|
<!-- describe how this service is monitored and how it can be tested -->
|
|
|
<!-- after major changes like IP address changes or upgrades -->
|
|
|
Nagios checks the `/var/lib/misc/thishost/last_update.trace` timestamp
|
|
|
and warns if a host is more than an hour out of date.
|
|
|
|
|
|
The LDAP server is monitored in the sense that Nagios checks that the
|
|
|
process is running.
|
|
|
|
|
|
The web and mail servers are checked as per normal policy.
|
|
|
|
|
|
## Logs and metrics
|
|
|
|
... | ... | @@ -1192,16 +1199,20 @@ indefinitely for locked out users. |
|
|
`chpass@torproject.org` in `/srv/db.torproject.org/mail-logs/`. This
|
|
|
includes personnally identifiable information (PII) like `Received-by`
|
|
|
headers (which may include user's IP addresses), user's email
|
|
|
addresses, SSH public keys, hashed sudo passwords, and junk mail.
|
|
|
addresses, SSH public keys, hashed sudo passwords, and junk mail. The
|
|
|
mail server should otherwise follow normal mail server logging
|
|
|
policies.
|
|
|
|
|
|
The web interface keeps authentication tokens in
|
|
|
`/var/cache/userdir-ldap/web-cookies`, which store encrypted username
|
|
|
and password information. Those get removed when a user logs out or
|
|
|
after 10 minutes of inactivity, when the user returns. It's unclear
|
|
|
what happens when a user forgets to logout and fails to return to the
|
|
|
site. Webserver logs should otherwise follow the normal TPO policy.
|
|
|
|
|
|
TODO: expand. slapd logs? web interface? specifically:
|
|
|
The OpenLDAP server itself (`slapd`) keeps no logs.
|
|
|
|
|
|
1. How long are logs kept for? Who has access to the logs? Are logs
|
|
|
archived somewhere? How long is that kept for?
|
|
|
1. How long are metrics kept for? Who has access to metrics? Are
|
|
|
metrics archived somewhere? How long is that kept for?
|
|
|
1. What personally identifiable information is captured by the
|
|
|
project? Where is it stored? How long is it stored for?
|
|
|
There are no performance metrics recorded for this service.
|
|
|
|
|
|
## Backups
|
|
|
|
... | ... | @@ -1247,11 +1258,6 @@ those years. Attempts have been made to rewrite it with a Django |
|
|
frontend ([ud](https://github.com/Debian/ud), 2013-2014 no change since 2017) or Pylons
|
|
|
([userdir-ldap-pylons](https://salsa.debian.org/dsa-team/mirror/userdir-ldap-pylons), 2011, abandoned), all have been abandoned.
|
|
|
|
|
|
TODO: next steps for LDAP:
|
|
|
|
|
|
* Are there any in-progress projects? Technical debt cleanup? Migrations? What state are they in? What's the urgency? What's the next steps?
|
|
|
* What urgent things need to be done on this project?
|
|
|
|
|
|
### Major issues with userdir-ldap
|
|
|
|
|
|
ud-ldap is old, hard to maintain, and possibly has serious security
|
... | ... | |