An overview of core security features in TYPO3 4.3

Cookie Security

If you are running a TYPO3 installation that makes use of SSL, the following feature will enhance your website’s security. You probably know that the HTTP protocol is stateless and therefore sessions try to solve that problem. TYPO3 uses cookies to exchange session identifiers between server and client.

For example, currently when you are running TYPO3 backend with SSL (HTTPS) enabled and call the backend, the server will issue a cookie with the session ID.  This cookie will be transferred over a secured/encrypted channel that prevents an eavesdropper from reading the session ID from the cookie.  If you call the backend again using standard (insecure) HTTP, your client will transfer the same cookie with the session ID exposed in plain-text for everyone who is sniffing your traffic.
Now, with feature #7461 (‘transfer cookies via SSL only, whenever possible’) implemented, you can decide if TYPO3 should transfer created cookies only over a secured/encrypted channel or if cookies, initially issued by the server over a secured/encrypted channel should again only be transferred over a secured/encrypted channel.
This is done by setting a specific cookie declaration that current browsers understand and therefore will apply to your client-server traffic.

To use that new feature, please adjust a new parameter $TYPO3_CONF_VARS[‘SYS’][‘cookieSecure’] (through localconf.php file):

• integer “0” – current behaviour, transfer of cookies over any channel (default)
• integer “1” – server creates and transfers cookies only when accessed over a secured/encrypted channel; client is asked to send the cookie only over secured/encrypted channel (this setting enforces SSL)
• integer “2” – server will always create and transfer the cookie no matter which channel is used; if accessed over a secured/encrypted channel, the cookie will only be exchanged in an encrypted way.

Even if your TYPO3 backend is accessible over SSL only, you won’t be safe from cookies with session IDs transferred in an insecure manner and exposed SIDs as plain-text. So, whenever using SSL with TYPO3, please make sure to be familiar with that new feature and its options.  There’s now the possibility to access frontend or backend session cookies via HTTP only.  With that enabled, it’s no longer possible to access these cookies via JavaScript and for example retrieve session IDs from them. Current browsers support such declaration and will prevent the JS access to the cookies.
In the past it had been possible for a malicious person to find and exploit a Cross-Site Scripting vulnerability, to get hold of session IDs via JavaScript and to try to authenticate to a TYPO3 installation using these session identifiers.

It is expected that some TER-listed extension might stop working. Therefore, this feature is currently disabled by default. Nonetheless, it will be activated by default at a later point in time. Therefore, you might want to test your installation already today:

To enable and use this new security feature, put

$TYPO3_CONF_VARS[‘SYS’][‘cookieHttpOnly’] = true;

into your localconf.php file.

Salted passwords

Passwords in TYPO3 are stored using a regular MD5 hash. With knowledge of that hash value, an attacker may be able to recalculate the original password by using rainbow hash tables. The Salted Passwords extension adds a random value – the salt – to the stored hash which drastically reduces the chance of rainbow attacks. This feature can be used by installing the system extension ‘saltedpasswords’. Furthermore, a secure channel must be available to transfer the password data. The HTTPS protocol is one option and if that is not available the RSAAuth extension can be used instead.

Asymmetric Encryption for authentication

RSA is a method of asymmetric encryption – something you might already know if you are using GnuPG or PGP. A key pair (public and private key) is created and then, a message can be encrypted using the public key. Only the owner of the private key is later able to decrypt the message.

In case of TYPO3, TYPO3 itself will create a key pair for each login attempt. The public key is given to the client (your browser) which will use it to encrypt you password. So sniffing your traffic will not reveal the password and you are able to login to your TYPO3 installation in an unencrypted wireless LAN without having second thoughts on a possible compromise later. TYPO3 will then decrypt the message with the private key so that the plain-text password is again available on TYPO3 side.

Having plain-text passwords available on TYPO3 side (not only hashed ones like currently) will enable the possibility to apply arbitrary complex transformations on (original) plain-text passwords before being stored into the database. You might even consider to encrypt your passwords in the database. RSA authentication replaced the currently used superchallenge authentication method. However, if you are already using SSL to secure authentications for frontend or backend (normal login method), there’s no need to use RSA. The RSA authentication service can be used in the frontend and backend by enabling the system extension rsaauth.

Open ID

OpenID is a method of using a single login at a trusted provider to automatically allow you trusted access to other websites. You do not need to create accounts or new logins at the other websites, you merely need to tell the other websites what your OpenID is. The first time you do this at a website you are giving permission to your trusted provider to give some of your profile information to the new website. Behind the scenes the trusted provider confirms to the other website that you are who you say you are, because you have already logged in with them today from this browser session.

For example, you have a Yahoo account. You have at some time in the past logged into Yahoo and enabled OpenID with them, and they gave you an OpenID identifier/url. You want to post a comment on BlogSpot or some other website. On that website, you tell them your OpenID identifier/url. If you were already logged into Yahoo today you will be asked by a simple Yahoo page to confirm that you wish to share your identity with BlogSpot, and then you will be granted access. If you are not currently logged into Yahoo, you will be asked to do so. This all occurs without having to manually create a separate new BlogSpot account.

Using OpenID is generally free. All you need to do is register with one or multiple OpenID providers that you trust. Open ID can be used in a typo3 powered website through the new system extension OpenID.