For additional information please refer to Overview – Administration and Configuration and its subsequent documents.
User Credentials & Passwords
By default Intershop used to have a cryptographic one-way hash function (MD5) to encrypt the users password. As MD5 is known to vulnerabilities now PBKDF2 (Password-Based Key Derivation Function 2) is used instead. Users passwords are migrated on the fly when users log in again.
Session Management via Cookies
To reduce the risk of spreading session IDs with an URL, it is advised to use browser cookies, CookieOnly, for session handling and session management. For Intershop Commerce Management (ICM) the session handling can be configured under $IS_HOME/ share/system/config/cluster/webadapter.properties:
Since Intershop 7.4 CI, this has changed and the tracking mode is now set to CookieOnly per default and any other option is obsolete.
Web Adapter Session Handling
Web based applications use session IDs (SIDs) to overcome the limitations of the HTTP. As a stateless protocol, HTTP needs a session ID to assign certain activities to a specific user. Each user entering a site for the first time starts a new session and gets a unique session ID. From that point, this SID will be used in all subsequent requests. Depending on the lifetime value specified for a session, the IDs remain valid for a few minutes, hours, or even days.
The session also stores the information whether a user is logged on or not. In order to prevent that session IDs from users currently logged on are abused by unauthorized clients, Intershop 7 provides a complementary security mechanism based on authentication tokens. When a user logs on, a random authentication token is generated which is stored at the session. In addition, the authentication code is sent back to the client using a secure cookie. With each new request within the same session, the client passes the authentication token which is then compared with the token stored at the session.
Session Cookie Settings
You can define how the session tracking cookies are set in the client. To this end, the webadapter.properties file includes the two settings:
session.SIDCookie[.<site>] = <Set-Cookie>
session.PGIDCookie[.<site>] = <Set-Cookie>
where session.SIDCookie defines the SID cookie generation, and session.PGIDCookie defines the PGID cookie generation. The default values are:
#session.SIDCookie = Set-Cookie: sid=%v; Path=/; Version=1
#session.PGIDCookie = Set-Cookie: pgid=%v; Path=/; Version=1
The placeholder %v is to be used “as is” as the actual SID or PGID cookie value. Another placeholder, %s, expands to the request’s site name (or an empty string), which is useful in the PGID name definition.
For detailed information about the <Set-Cookie> syntax, refer to RFC 2109 (http://www.ietf.org/rfc/rfc2109.txt).
Separate Authentication State
Since Enfinity Suite 6.1, the authentication state is separated from the session ID. An attacker knowing an SID is not allowed to perform critical operations, such as ordering and account management. This is implemented with a secure cookie AuthenticationStateToken: It is stored at the client with a successful login and it must be presented to the server for all subsequent critical operations. This cookie has the “Secure” attribute set and thus is transmitted only via ‘secure connections’, typically HTTPS. It will never be transferred in unencrypted form. See RFC 2109 for details. This feature can be controlled at $IS_HOME/share/system/config/cluster/appserver.properties:
To reduce the risk of misuse, reduce the period of time an SID remains valid. This can only be done by setting a hard limit for the lifetime of SIDs, and therefore implicitly for the lifetime of application server sessions. If the Intershop system receives an HTTP request containing an SID that reached the end of its lifetime, a new SID is created and assigned to the client. The hard limit for the SID lifetime can be configured at $IS_HOME/share/system/config/cluster/webadapter.properties:
session.ttl=<time in seconds>
Besides this “hard” SID timeout, there is also a “soft” timeout for the lifetime of an application server session. The related session timeout counter restarts with each request. If the application server does not receive a request for this session within the session timeout interval, the session state at the application server is discarded. The SID itself remains valid. The next application server request with this SID would create a new session at the application server. Configure the session timeout at $IS_HOME/share/system/config/cluster/appserver.properties:
intershop.session.TimeOut=<time in minutes>
Bind SID to User Agent
Intershop can be configured to bind SIDs to a particular user agent. This is done by including the contents of the HTTP header field “User-Agent” into the MD5 hash of the generated SID. SIDs in URLs are then only valid when they are sent from a client computer whose web browser and operating system version match that of the web client that started the session. This behavior can be configured at $IS_HOME/share/system/config/cluster/webadapter.properties:
The default value is ‘false’.
Co-Authors: Thomas Bergmann, Nils Breitmann and Intershop Consulting Stuttgart