Currently the posts are filtered by: TYPO3
Reset this filter to see all posts.
Posted in TYPO3/ on April 30, 2009 by .
Today, TYPO3 made a huge step forward in regards to security. Dmitry Dulepov has sent a patch (#11016) to the TYPO3 Core mailinglist that implements RSA authentication for TYPO3 Backend and Frontend.
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.
The next step and also planned to be shipped with TYPO3 4.3 are salted hashed passwords for FE and BE user accounts. An already existing extension (t3sec_saltedpw) will therefore be integrated in TYPO3 Core.
RSA authentication will replace the currently used superchallenge authentication method. However, if you are already using SSL to secure authentications for FE or BE ("normal login method"), there's no need to use RSA.
Give TYPO3 4.3 a try; test and review the upcoming alpha3 release! You won't regret it.
Thanks to Dmitry for his efforts. "Inspiring people to share" at its best!
Posted in TYPO3/ on April 22, 2009 by .
TYPO3 allows to create export files. They are useful as poor man's backups or if you want to move your TYPO3 instance to another server. TYPO3 allows to configure which data to include in such an export. Usually they are written to or below fileadmin directory.
What's wrong about it?
These files might contain credentials (username and passwords of FE and BE users) and are written below DocumentRoot (publicely available). Think of having DirectoryIndex enabled or an easy to guess filename (backup.t3d)!
Using apache as web server it is easy to restrict access to such files. Simply put following lines in the vhost configuration:
<FilesMatch "\.t3d$">
Order allow,deny
Deny from all
</FilesMatch>
Further requests to such files will result in a 403 Forbidden status message.
Posted in TYPO3/ on April 21, 2009 by .
The TYPO3 install tool is a great help when initially installing TYPO3, configuring TYPO3 or debugging it.
As it should run during the install process, it's a complete isolated module. It is restricted by a password only.
When TYPO3 is running smoothly, there's no need to let the tool enabled. Enabling it is done with creation of one single file called
typo3conf/ENABLE_INSTALL_TOOL
Obviously the first task is to change the initial password (joh316) to something different and more complex. Just assign the md5-hash of the new password to
$TYPO3_CONF_VARS['BE']['installToolPassword']
and put the line in file
typo3conf/localconf.php
If you regulary need to access the tool, set up an additional barrier like a htaccess protection for directory
typo3/install
So what's the problem of the install tool?
It allows to modify files with the rights of the web server user account. If someone unauthorized gains access to the tool, he has the same possibilities like somebody with a local user account on the web server.
In the past there were several reports where Blackhats used the TYPO3 Install Tool to setup a webshell on the server. You obviously want to avoid that.
If your website administrators need to use the TYPO3 Install Tool and therefore are able to create the ENABLE_INSTALL_TOOL file by themselfes (using ftp access or whatever), you might want to consider running an hourly cronjob to remove these files again.
Call following command every hour as root:
find / -name ENABLE_INSTALL_TOOL -type f -mmin +60 -exec rm -f {} \;
This removes such files if they are older than 60 minutes.