Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Login session.
Nothing was collected or created yet.
Login session
View on Wikipediafrom Wikipedia
In computing, a login session is the period of activity between a user logging in and logging out of a (multi-user) system.
On Unix and Unix-like operating systems, a login session takes one of two main forms:
- When a textual user interface is used, a login session is represented as a kernel session — a collection of process groups with the logout action managed by a session leader.
- Where an X display manager is employed, a login session is considered to be the lifetime of a designated user process that the display manager invokes.
On Windows NT-based systems, login sessions are maintained by the kernel and control of them is overseen by the Local Security Authority Subsystem Service (LSA). winlogon responds to the secure attention key, it requests the LSA to create login sessions on login, and terminates all of the processes belonging to a login session on logout.
See also
[edit]Further reading
[edit]- Microsoft. "How Interactive Logon Works". Windows Server 2003 Technical Library. Archived from the original on 2006-05-07. Retrieved 2006-05-24.
 | This operating-system-related article is a stub. You can help Wikipedia by adding missing information. |
Login session
View on Grokipediafrom Grokipedia
A login session, also known as a logon session, is a computing session that begins when a user successfully authenticates to a system—typically via credentials such as a username and password—and ends when the user logs off, the session times out due to inactivity, or the system terminates it for security reasons.[1] In operating systems like Unix-like systems, a login session encompasses the period from login until logout, often bound to a specific seat (physical or virtual) such as a terminal or SSH connection, and is managed by services like systemd to track user activity and resource usage.[2]
Login sessions are fundamental to multi-user environments, enabling secure resource allocation, process isolation, and auditing of user actions across operating systems including Windows and Linux. In Windows, the Local Security Authority (LSA) maintains logon sessions to associate user identities with tokens that control access to system resources, ensuring that privileges persist only during the active session.[1] Similarly, in Unix systems, login sessions integrate with Pluggable Authentication Modules (PAM) to handle authentication, session opening, and closing, logging events in files like
/var/log/wtmp for historical tracking.[3] Effective management of these sessions prevents unauthorized access, with features like idle timeouts and session limits configured via system policies to mitigate risks such as session hijacking.[4]
In web applications, login sessions extend this concept to stateless protocols like HTTP by using server-side mechanisms—such as session IDs stored in cookies or tokens—to maintain user state across multiple requests, allowing persistent authentication without re-entering credentials.[5] This form of session management is critical for security, as vulnerabilities like session fixation or fixation attacks can expose user data if not addressed through practices like secure cookie attributes (e.g., HttpOnly and Secure flags) and short expiration times.[5] Overall, robust login session handling underpins user privacy, compliance with standards like GDPR, and defense against common threats in both local and networked computing environments.[6]
Definition and Fundamentals
Definition
A login session in computing refers to the duration of authenticated user activity in a multi-user system, commencing upon successful authentication (login) and concluding upon de-authentication (logout), during which the user gains authorized access to system resources and services.[1] This temporal state enables secure, controlled interaction with the system, encompassing all processes and activities performed under the user's credentials within that period.[7] The concept of the login session originated in the 1960s with early time-sharing systems designed for multi-user mainframe environments, such as the Compatible Time-Sharing System (CTSS) developed at MIT in 1961–1963, which introduced mechanisms for users to remotely connect via terminals and authenticate for shared computing resources.[8] It evolved through systems like Multics, initiated in 1965 as a collaborative project by MIT, Bell Labs, and General Electric, to manage concurrent access in large-scale, networked setups during the 1960s and 1970s.[9] Although personal computing shifted focus in later decades, login sessions remain fundamental in server-based and networked environments for enforcing security and resource allocation.[10] A login session differs from a user account, which represents a static, persistent identity comprising credentials, permissions, and profile data stored in the system, independent of active use.[7] It also contrasts with a process, defined as an individual instance of a running program or task that operates within the broader session context but lacks the overarching authenticated scope.[11] Thus, the login session emphasizes the dynamic, time-bound authenticated state that binds multiple processes to a single user interaction. The session lifecycle typically includes initiation via authentication, ongoing maintenance, and eventual termination, as explored in subsequent sections.Key Characteristics
A login session is fundamentally stateful, maintaining a persistent record of user context—including authentication status, permissions, and preferences—across successive interactions without requiring re-authentication for each action.[5] This statefulness enables seamless continuity in user activities, such as retaining access rights to files or applications initiated early in the session.[12] Login sessions possess temporal boundaries, typically enforced through maximum duration limits, inactivity timeouts, or deliberate logout actions to mitigate security risks from prolonged exposure.[12] A core attribute is the session ID, a unique identifier generated upon initiation to track and validate the session's legitimacy throughout its lifespan.[1] Additionally, sessions operate within a specific scope, distinguishing between local access (e.g., direct console interaction) and remote access (e.g., via network protocols), which influences resource availability and security controls.[13] Systems generally support multiplicity, allowing multiple concurrent login sessions for a single user or across numerous users simultaneously, with built-in isolation mechanisms to ensure that activities in one session do not affect others.[1] In Unix-like environments, this isolation is achieved through session structures comprising process groups, preventing signal propagation or resource contention between unrelated sessions.[11] Similarly, in Windows, logon sessions use unique identifiers to segregate access to window stations and other objects, safeguarding against interference.[1] Login sessions associate with specific system resources to facilitate user operations, including environment variables that encapsulate session details like the user's home directory and shell configuration, which persist for the session's duration.[14] The session also links to the user's initial working directory, typically set to their home folder upon login, and access tokens or equivalent credentials that define permissible actions on files, processes, and network resources.[15] These associations ensure that resource utilization aligns with the authenticated user's profile without global spillover.[16]Session Lifecycle
Initiation
The initiation of a login session begins with the authentication process, where a user provides credentials to verify their identity. Common credentials include usernames paired with passwords, biometrics such as fingerprints or facial recognition, or digital certificates.[17][5] The system then verifies these credentials against a stored database, such as /etc/shadow in Unix-like systems for hashed passwords or a directory service like LDAP for enterprise environments.[18][17] This verification typically involves hashing the provided password with a salt and comparing it to the stored hash, ensuring secure handling without exposing plaintext secrets.[18] Upon successful authentication, the system creates a new session by generating a unique session identifier, often a random string or token with at least 64 bits of entropy produced via a cryptographically secure pseudorandom number generator to prevent guessing attacks.[5] This identifier is associated with a security context that includes the user's privileges, such as user ID (UID) and group memberships, along with environment setup like the home directory and default shell from configuration files like /etc/passwd.[18] In network authentication protocols like Kerberos, this may involve issuing a ticket-granting ticket encrypted with a session key for subsequent service access.[19] The session ID's randomness is crucial for security, as it binds the session to the authenticated user without revealing sensitive information.[5] Login sessions can be initiated through various types, including interactive logins where users directly input credentials at a local console or terminal; non-interactive logins, such as those triggered by scripts, batch jobs, or automated processes without user intervention; and remote logins via protocols like SSH for command-line access or RDP for graphical desktops.[20][21] If authentication fails due to invalid credentials, the login attempt is rejected, preventing session creation, and the system logs the event for audit purposes, including details like timestamp, username attempted, and source IP to detect patterns of abuse.[17][5] Verifiers implement rate-limiting, such as capping failed attempts at 100 per account to mitigate brute-force attacks, after which further attempts may trigger temporary lockouts.[17]Maintenance
Once a login session is active, its maintenance involves preserving the user's state to ensure continuity of access and functionality. This preservation typically tracks user-specific data, such as preferences, authentication tokens, or application states like a shopping cart in web applications or command history in terminal sessions. Such state is maintained through mechanisms like in-memory storage for transient data, file-based persistence for durability across restarts, or database records for scalable, shared environments. For instance, in web contexts, session objects bind user data to a unique session identifier, allowing seamless retrieval across requests.[22][23] Inactivity detection is a core aspect of session maintenance to balance security and usability, employing timers to monitor idle periods without user interaction. Systems often implement idle timeouts, ranging from 2-5 minutes for sensitive applications to 15-30 minutes for general use, triggering warnings or automatic session suspension to prevent unauthorized access from unattended devices. Renewal mechanisms, such as token refresh on periodic activity, extend session validity without requiring re-authentication; for example, short-lived access tokens can be refreshed using longer-lived refresh tokens if activity is detected. These server-side enforcements ensure that sessions do not persist indefinitely, reducing exposure to risks like session hijacking.[24][25] Concurrency handling addresses scenarios where users may attempt multiple simultaneous sessions, such as from different devices, to prevent conflicts and enforce access limits. Mechanisms include organization-defined caps on concurrent sessions per account, often limited to 1-2 for administrative or high-security contexts, achieved by invalidating prior sessions upon new logins or blocking additional ones. Synchronization techniques, like checking active session counts via APIs before granting access, ensure data consistency and avoid race conditions; for example, refresh token registries can track and revoke excess sessions to maintain a single active device limit. This approach mitigates risks such as account sharing while allowing legitimate multi-device use under controlled policies.[26][27][28] Monitoring active sessions involves logging key events and metrics to detect anomalies and support auditing, without delving into platform-specific implementations. General practices include recording activity timestamps for login events, session usage, and resource consumption, such as CPU or memory tied to session processes, to build timelines of user behavior. Tools facilitate this by correlating session identifiers with logs, enabling detection of unusual patterns like rapid session creations or IP changes; for instance, hashed session IDs are logged alongside timestamps to trace lifecycle events while preserving privacy. This ongoing surveillance ensures proactive maintenance and compliance with security standards.[29][30][31]Termination
Login sessions can be terminated explicitly by the user through an action such as selecting a logout button in a web interface or issuing a logout command in a terminal, which invalidates the session identifier and clears associated state information on the server side.[12][32] This process ensures that the session token is immediately rendered unusable, preventing further access without re-authentication. In systems following NIST guidelines, explicit logout triggers the erasure or invalidation of session secrets both on the server and, where applicable, on the client endpoint.[12] Implicit termination occurs automatically due to predefined conditions, including inactivity timeouts where the session expires after a period of no user activity—typically ranging from 15 minutes in high-security environments like banking to up to an hour in less sensitive applications—or overall session lifetimes that cap the total duration post-authentication.[32] System events such as shutdowns or idle thresholds can also end sessions, while forced revocation may be initiated by administrators for security reasons, such as detecting fraud or responding to account compromise, thereby immediately disconnecting all active sessions for the affected user.[12][33] Upon termination, cleanup processes reclaim system resources, including memory and file handles allocated to the session, and invalidate any stored data to prevent lingering access.[12] Servers typically log the termination event, recording the end time and reason for audit and compliance purposes, while session history may be retained as required by regulations like those in the CJIS Security Policy.[34] Post-termination, users must re-authenticate to establish a new session, and no prior session data remains accessible, ensuring that authenticated resources are protected from unauthorized reuse.[12][32]Sessions in Operating Systems
Unix-like Systems
In Unix-like systems, the login process begins with the getty daemon, which manages terminal lines and presents a login prompt to users on physical consoles or virtual terminals. Upon entering a username, getty invokes the /bin/login program, which prompts for a password and verifies credentials using Pluggable Authentication Modules (PAM), a flexible framework that allows authentication via various backends such as /etc/passwd, LDAP, or Kerberos. If authentication succeeds, login updates the system's utmp/wtmp logs, sets the effective user ID (UID) and group ID (GID) for the new process, and executes the user's default shell, typically /bin/bash or /bin/sh, thereby initiating the interactive session.[35] A login session in these systems is structured as a session—a collection of one or more process groups sharing a common controlling terminal, with the login shell serving as the session leader. The controlling terminal, which may be a physical device (e.g., /dev/tty1) or a pseudo-terminal (e.g., /dev/pts/0 for SSH connections), handles input/output multiplexing, job control, and signal propagation for all processes within the session. Process groups within the session are identified by a process group ID (PGID), and only the foreground process group receives input from the terminal, ensuring orderly interaction in multi-process environments like shells running background jobs. This structure, defined in POSIX standards, enables robust isolation and management of interactive environments.[36] Active sessions can be monitored using several standard commands. The who utility lists currently logged-in users, displaying details such as username, terminal device, login time, and idle duration, drawing from the utmp file for real-time information. The w command builds on this by showing additional activity metrics, including the user's host of origin, CPU load, and currently running processes via integration with ps. In modern distributions employing systemd, the loginctl tool offers enhanced introspection, allowing users to list sessions with commands like loginctl list-sessions, which reveals session IDs, associated users, seats (e.g., graphical or console), and states (active, closing, or online), facilitating administrative oversight of multi-user environments. To support multi-user operations, Unix-like systems enforce isolation through unique user identifiers (UIDs), numeric values assigned to each account that govern process ownership, file permissions, and resource access, preventing unauthorized interference between users. During session termination—triggered by commands like exit or logout—the shell broadcasts a SIGHUP signal to all processes in the session's process groups, prompting child processes to terminate gracefully and release resources, which helps maintain system stability and security in shared environments. This signal handling is a core POSIX mechanism, ensuring cleanup without requiring manual intervention.Microsoft Windows
In Microsoft Windows, login sessions are managed through distinct logon types that categorize how users or processes authenticate and access system resources. The primary logon types include interactive logons (type 2), which occur via console or hardware remote control for direct user interaction requiring passwords, smart cards, or other credentials; remote interactive logons (type 10), used for Remote Desktop Protocol (RDP) connections; network logons (type 3), used for accessing remote resources like file shares over the network with credentials such as passwords, NT hashes, or Kerberos tickets; batch logons (type 4), employed by scheduled tasks executing on behalf of users without direct intervention; and service logons (type 5), associated with system services running under specific accounts. Each logon session is uniquely identified by a Locally Unique Identifier (LUID), a 64-bit value assigned to the session for tracking purposes within the local system.[37][1] Authentication for these sessions is handled primarily by the Winlogon executable (Winlogon.exe), which initiates the logon process by collecting user credentials through secure attention sequences, and the Local Security Authority Subsystem Service (LSASS), which validates those credentials against local or domain policies. For domain-joined systems, LSASS integrates with Active Directory to facilitate Kerberos-based authentication, enabling seamless logons across networked environments. This process ensures that access tokens, which include the LUID and Security Identifier (SID) for the user, are generated to enforce security contexts for the session.[38][1] Administrators can query active login sessions using built-in commands such asquser or query user, which display details like session IDs, usernames, states (e.g., active or disconnected), and idle times on Remote Desktop Session Host servers. For more detailed enumeration, the Sysinternals LogonSessions tool provides comprehensive output, including the LUID, associated processes, and SIDs for each session, aiding in security auditing and troubleshooting.[39][40]
Windows supports multi-session handling through Remote Desktop Services (RDS), allowing multiple concurrent user sessions on a single host, particularly in server editions where licensing permits beyond the default two administrative sessions. Sessions are isolated using unique session IDs, with Session 0 reserved for system services and non-interactive processes, Session 1 for the physical console session (in Windows Vista and later), and higher IDs assigned to remote connections, ensuring resource separation and preventing interference between users. Upon termination, sessions trigger cleanup of associated resources, such as tokens and handles, to maintain system integrity.[41][42]
Sessions in Web Applications
HTTP Session Management
HTTP is a stateless protocol, meaning each request from a client to a server must be treated independently without inherent knowledge of prior interactions.[43] This lack of built-in statefulness poses a challenge for web applications requiring persistent user sessions after login, necessitating explicit mechanisms to track and associate subsequent requests with the authenticated user via unique session identifiers generated and managed by the server.[5] Following successful authentication—such as through form-based login or protocols like OAuth—the server establishes a session by creating a unique session ID, which it associates with the user's details on the server side and transmits to the client for inclusion in future requests.[5] The client then embeds this identifier in each subsequent HTTP request, allowing the server to retrieve and validate the corresponding session data, thereby maintaining continuity across the stateless exchanges.[5] Session expiration policies are critical for balancing security and usability, typically employing either absolute timeouts, which enforce a fixed end time regardless of activity (e.g., 8 hours from creation), or sliding expirations, which reset the timeout period upon each user interaction to extend the session dynamically.[5] Applications must also address concurrent sessions, such as those from multiple browsers or devices for the same user, by implementing policies like allowing only one active session per user (terminating prior ones upon new logins) or permitting multiples with restrictions to mitigate risks like session hijacking.[5] In popular frameworks, HTTP session management is abstracted for ease of implementation; for instance, PHP's session handling begins with a call to initialize the session context, enabling automatic ID tracking, while Java Servlets provide the HttpSession interface for servers to create and manipulate per-user sessions programmatically.[44][45]Session Storage Mechanisms
Session storage mechanisms in web applications primarily involve methods to persist and transmit session identifiers and associated data between client and server, ensuring continuity across stateless HTTP requests. Cookies represent the most common approach, where the server sets a session ID in an HTTP response header, which the browser stores and returns in subsequent requests. The HttpOnly flag on cookies restricts access to these values from client-side scripts, mitigating risks such as cross-site scripting (XSS) attacks that could otherwise steal session data.[46] Without the HttpOnly flag, session cookies are vulnerable to theft via XSS, as malicious scripts can read and exfiltrate the cookie value.[47] The Secure flag further ensures that cookies are only transmitted over encrypted HTTPS connections, preventing interception in transit.[46] Server-side storage complements cookie-based identifiers by maintaining the actual session data on the server, such as user preferences or authentication details, keyed by the session ID. This approach allows for secure handling of sensitive information without exposing it to the client. In-memory storage, like session files in application servers, provides fast access but may lack persistence across restarts, while databases offer durability; Redis, an in-memory key-value store, is widely used for its sub-millisecond latency and scalability in handling high-volume sessions across distributed systems.[48] As a cookie-less alternative, URL rewriting embeds the session ID directly into URLs (e.g., appending;jsessionid=ABC123), enabling session tracking when cookies are disabled, though it requires careful encoding to avoid exposure in logs or shared links.[49]
Token-based alternatives, such as JSON Web Tokens (JWTs), enable stateless sessions by encoding all necessary claims within a self-contained, digitally signed token that the client stores and presents to the server. Defined in RFC 7519, JWTs consist of a header, payload, and signature, using algorithms like HMAC SHA-256 for integrity protection without requiring server-side lookups.[50] The payload includes standard claims like expiration time (exp), which specifies a Unix timestamp after which the token becomes invalid, supporting automatic session termination. This stateless design enhances scalability in microservices environments, as any server can verify the token independently.
Hybrid approaches combine client-side storage with server validation to balance performance and security, particularly in distributed systems. For instance, localStorage can hold non-sensitive session data or tokens on the client, reducing server load, while the server validates each access to prevent tampering; this method leverages the 5-10 MB capacity of localStorage for persistence across sessions but requires encryption and XSS protections to avoid exposure. Such strategies emphasize scalability by minimizing centralized session stores, allowing horizontal scaling without session affinity concerns.[51]