Skip to content

Security

EntryStore provides the following security measures for storing and transferring credentials:

  • Passwords are stored as PBKDF2-hashes with per-user salts.
  • All random numbers involved in cryptographic operations are generated using the cryptographically strong SecureRandom class.
  • The tokens for cookie-authentication are based on cryptographically strong random numbers and do not have any connection to username or password.

Other security-related information:

  • EntryStore can be accessed using HTTPS by using an SSL-enabled Web server and/or reverse proxy.
  • It is recommended to redirect HTTP requests to HTTPS.
  • It is recommended to use SSL/TLS only with Perfect Forward Secrecy (PFS). Recommended cyper suites can be found at https://wiki.mozilla.org/Security/Server_Side_TLS.

Informing users of changed passwords

Whenever the password of a user changes, either through password reset or manually setting the password, the user is informed by email. The following settings can be used to change the subject and body of the email message:

entrystore.auth.password-change.email.subject=Your password has been changed
entrystore.auth.password-change.email.template=<path-to-template>

See also the KB entry on Signups for more information on how the templating mechanism works.

HTTP Server response header

EntryStore stamps a Server header on every HTTP response so operators and integrators can identify the running service. By default the value is EntryStore/<version> (e.g. EntryStore/6.0), which is convenient for debugging and support but discloses the exact running version to clients — useful for fingerprinting and version-targeted reconnaissance. Two settings let operators trade off identification against fingerprinting:

  • entrystore.http.header.server — explicit override. Whatever string is configured here is sent verbatim, replacing both the product name and the version. Use this for fully custom branding (e.g. entrystore.http.header.server=Acme API).
  • entrystore.http.header.server.version-precision — controls how much of the auto-computed default's version is exposed. Ignored when the explicit override above is set.

The precision values:

Value Resulting header (example for version 6.0.3-SNAPSHOT)
full (default) Server: EntryStore/6.0.3-SNAPSHOT
minor Server: EntryStore/6.0
major Server: EntryStore/6
none Server: EntryStore

For public-facing deployments concerned about fingerprinting, prefer setting entrystore.http.header.server.version-precision=major (or none) over editing the explicit override every release — that way the header stays stable across upgrades without per-release maintenance.

The header is applied at the Jetty protocol level, so it covers every response — including requests rejected by Spring Security (401, 403), CSRF rejections, maintenance-mode responses (503), and protocol-level errors that bypass servlet filters.