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:
session.tracking.mode=URLOnly|CookieOnly|CookiePreferred|CookieOverridesURL
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:
shop.AuthenticationSecurity.Mode=standard|secure_cookie_preferred|secure_cookie_only
Session Timeout
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:
session.bindToUserAgent=true
The default value is ‘false’.
Co-Authors: Thomas Bergmann, Nils Breitmann and Intershop Consulting Stuttgart
The vulnerabilities of the MD5 are not the primary reason for choosing PBKDF2. Each cryptographic hash functions must at minimum have the following properties:
* Preimage resistance
* Second-preimage resistance
* Collision resistance
The only property that is relevant to password storage is the preimage resistance. This means that given a hash h it should be computationally infeasible to find any message m such that h = hash(m). MD5 is not collision resistant. Collision resistance means that it should be very difficult to find two different messages m1 and m2 such that hash(m1) = hash(m2).
The real problem is that MD5 is very fast to implement both on hardware and in software and stolen hashes may be simply brute forced. Please note that this is not vulnerability. SHA2 is similarly fast. Besides simple brute-force there are large dictionaries and rainbow tables which present good tradeoff between memory and CPU resources necessary for cracking.
On the other hand PBKDF2 is deliberately designed to be very slow (even via configuration so that it will endure hardware improvements).
Some huge networks like stackexchange already adopted PBKDF2.