Chapter 14. Security

Table of Contents

14.1. User Authentication
14.1.1. Login Passwords
14.1.2. PIN Codes
14.1.3. Authentication Tokens
14.1.4. One-time Authentication Tokens
14.1.5. User Dialog
14.2. Access over Internet
14.3. Web Sessions
14.3.1. Web Session Timeout
14.3.2. Web Session Cookies
14.4. SSL Passwords
14.5. Secured JMX Connection
14.6. Encrypted Secrets
14.7. Document Signature
14.8. User Client
14.9. Server Commands
14.10. Web Services
14.11. Log Files
14.12. Network Card Reader
14.13. Internal Services
14.14. External Services
14.14.1. Google Cloud Print Service
14.15. Vouchers

This chapter discusses how SavaPage secures sensitive user and application data, and how it communicates with external Information Providers.

14.1. User Authentication

This section discusses how user credentials are protected.

14.1.1. Login Passwords

This section is about the passwords and PIN codes entered in the Web App Login Dialog.

Tip

Users can use the HTTPS protocol for connecting to the Web App, so data is encrypted to and from the server.

14.1.1.1. User Domain Passwords

SavaPage does not store or cache user domain login passwords. These passwords are always checked real-time at the source.

14.1.1.2. Internal User Passwords

Passwords of Internal Users are stored as SHA1 hash in the database.

14.1.1.3. Internal Admin Password

The SHA1 hashed password of the internal administrator admin is stored in a text file located at /opt/savapage/server/admin.properties. Access to this file is restricted to the savapage user.

SavaPage installs with admin as initial password for user admin.

Tip

If you forgot the internal admin password, you can reset it by editing the admin.password property in the /opt/savapage/server/admin.properties text file. Ignore the existing HASH value. SavaPage will hash your password upon first use.

14.1.2. PIN Codes

User PIN codes are stored in the database as encrypted secret.

14.1.3. Authentication Tokens

When Authentication Persistence is enabled for Browser Local Storage, authentication tokens are stored in the Local Storage of the browser. See Section 4.10.3, “User Authentication”.

Separate authentication tokens are held for the User, Admin, POS and Job Tickets Web App context and the same token is used for different sessions (on different devices) of a single user. A explicit logout in the Web App destroys the token. Authentication tokens are managed in memory on the SavaPage server. So, when the server restarts all local tokens are implicitly invalidated.

14.1.4. One-time Authentication Tokens

A Trusted Third Party (TTP) can acquire a one-time token for Web App user authentication by calling an XML-RPC method. The expiration time of the token should be as short as possible to minimize the risk that an accidentally exposed token can be misused. See Section C.2.1.1, “onetime-auth.createToken” for details.

14.1.5. User Dialog

When authentication fails a neutral "Authentication failed" message is communicated to the user to prevent Account Enumeration and Guessable User Account.