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.
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.
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.
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.