Psono Documentation

# V3 Session Management

Session management verification requirements

# ASVS Verification Requirement

ID Detailed Verification Requirement Level 1 Level 2 Level 3 Since
3.1 Verify that there is no custom session manager, or that the custom session manager is resistant against all common session management attacks. x x x 1.0
3.2 Verify that sessions are invalidated when the user logs out. x x x 1.0
3.3 Verify that sessions timeout after a specified period of inactivity. x x x 1.0
3.4 Verify that sessions timeout after an administratively-configurable maximum time period regardless of activity (an absolute timeout). x x 1.0
3.5 Verify that all pages that require authentication have easy and visible access to logout functionality. x x x 1.0
3.6 Verify that the session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies. x x x 1.0
3.7 Verify that all successful authentication and re-authentication generates a new session and session id. x x x 1.0
3.10 Verify that only session ids generated by the application framework are recognized as active by the application. x x 1.0
3.11 Verify that session ids are sufficiently long, random and unique across the correct active session base. x x x 1.0
3.12 Verify that session ids stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes x x x 3.0
3.16 Verify that the application limits the number of active concurrent sessions. x x x 3.0
3.17 Verify that an active session list is displayed in the account profile or similar of each user. The user should be able to terminate any active session. x x x 3.0
3.18 Verify the user is prompted with the option to terminate all other active sessions after a successful change password process. x x x 3.0

# V3.1

Due to the client side encryption which is tightly tied to the session and the activation of the session it was impossible to fall back to a standard session manager.

According to owasp.org/index.php/Session_Management_Cheat_Sheet (opens new window) the following requirements should be tested:

  • Session ID length at least 128 bits:

    Sessions keys are generated by os.urandom(64) which returns 64 random bytes (512 bits)

  • Session ID entropy high enough:

    According to https://docs.python.org/2/library/os.html (opens new window) os.urandom is suitable for cryptographic use

  • Session ID Content meaningless:

    The ID is only a reference to a database entry and does not contain any information

  • Session Management Implementation:

    The session management is implemented as HTTP Authorization Header. The session ID is never part of any URL to prevent any leakage in browser histories or other side channels. Advanced token properties are defined, including the expiration date and time.

  • Used vs. Accepted Session ID Exchange Mechanisms:

    Only Header authorization is accepted.

  • Transport Layer Security:

    Requires configuration of a proper reverse proxy. Psono.pw implements most of the possible features, including:

    • HTTPS
    • HSTS
    • CSP
    • XSS

  • Secure Cookie Attribute:

    No Cookies are used, therefore this does not apply.

  • HttpOnly Cookie Attribute:

    No Cookies are used, therefore this does not apply.

  • SameSite Cookie Attribute:

    No Cookies are used, therefore this does not apply.

  • Domain and Path Attributes:

    No Cookies are used, therefore this does not apply.

  • Expire and Max-Age Attributes:

    All sessions expire at least after 30 days.

  • Session ID Generation and Verification: Permissive and Strict Session Management:

    Psono is using a strict session management, enforcing cryptographically secure random number with os.urandom (see above)

  • Manage Session ID as Any Other User Input

    Session IDs are always validated as a first step. Invalid session IDs lead directly to Permission Denied, preventing any further handling.

  • Renew the Session ID After Any Privilege Level Change

    The session id changes (from none to something) during the login process. Afterwards no privilege level change occurs.

  • Considerations When Using Multiple Cookies:

    No Cookies are used, therefore this does not apply.

  • Session Expiration:

    Sessions currently expire after 30 days (for trusted devices) and 24 hours for untrusted devices. Idle timeouts are currently not implemented. Sessions can be invalidated by the client, but are automatically invalidated on the server after expiring.

  • Automatic Session Expiration:

    Idle timeouts / absolute timeouts / renewal timeouts are not implemented

  • Manual Session Expiration:

    A logout button is on every page and will invalidate the session on the server and the client.

  • Web Content Caching:

    Requires configuration of a proper reverse proxy. Psono.pw has the following implemented for everyhing behind /server endpoint:

      add_header Last-Modified $date_gmt;
  add_header Pragma "no-cache";
  add_header Cache-Control "private, max-age=0, no-cache, no-store";
  if_modified_since off;
  expires off;
  etag off;

  • Initial Login Timeout:

    A session is only generated once the user logs in, and not before, so this is not applicable.

  • Force Session Logout On Web Browser Window Close Events:

    Not implemented.

  • Session ID Guessing and Brute Force Detection

    There are two countermeasures preventing this. First the extreme size of the session ID with 512 bits (1.340781e+154 possibilities) and rate limiting (default for anonymous users 1440 per day) making it highly unlikely. The rate limiting will automatically detect such an attempt and block the user.

  • Detecting Session ID Anomalies:

    No session ID anomaly detection is implemented, due to the extreme low threat. (see above)

  • Binding the Session ID to Other User Properties

    Psono binds session IDs to the fingerprint of the browser.

  • Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs

    Part of the audit logging in the Enterprise edition.

  • Simultaneous Session Logons:

    Simultaneous sessions are explicitly allowed, but Psono allows the user to kick other sessions at any time.

  • Session Management WAF Protections:

    This requirement is specific to each implementation and out of the scope of psono, yet psono.pw and Psono SaaS are using Cloudflare for adequate protection.

# V3.2

The /logout endpoint invalidates the corresponding session.

# V3.3

Inactivity currently does not lead to session timeouts by default, yet can be activated with the AUTO_PROLONGATION_TOKEN_TIME_VALID flag.

# V3.4

All sessions timeout after at least 30 days (for trusted devices) or 24 hours (for untrusted devices)

# V3.5

All pages have an easy accessible logout button

# V3.6

No url discloses the session id. Error messages do not disclose any information. (This does not apply to DEBUG mode) URL rewriting of session cookies is not applicable as no session cookies are used.

# V3.7

All successful authentication and re-authentication generate a new session.

# V3.10

All sessions are managed in the database. Any session id that is not in the database is declined.

# V3.11

Session IDs are 512 bits long. The session ID generation happens on the server. The function generating it is os.urandom. According to https://docs.python.org/2/library/os.html (opens new window) os.urandom is suitable for cryptographic use

# V3.12

Not applicable as no cookies are used.

# V3.16

The software allows to configure the ALLOW_MULTIPLE_SESSIONS flag to prevent multiple sessions. In addition users can manage and potentially disable other sessions.

# V3.17

An active session list is displayed in the account profile section so users can easily disable sessions on other devices.

# V3.18

A popup is shown to the user once he has changed his password where he can logout all other devices.

← V4 Access Control →