Posted in TYPO3/ on February 20, 2010 by .
In TYPO3 4.3, system extension felogin comes with a rewritten password recovery functionality. With saltedpasswords it's no longer possible to send you the password you've originally chosen. And of course, sending passwords by mail is generally not a good idea.
In case of a forgotten password, felogin now asks you for your mail address or username you've initially chosen. Then it will send you an email with a link that, when being followed, allows to set a new password.
Steffen Müller has written a detailed article on this procedure: Enhanced password recovery for Frontend users in TYPO3 4.3. It's worth reading. One pitfall he mentions is using an outdated template file. So check if it's working on your website!
Posted in book/TYPO3/ on February 06, 2010 by .
You've probably noticed that there are a lot of TYPO3 books on the market. Sadly, most of these books are written in german. This is understandable as TYPO3's origin is in good old Europe and Germans were early adopters in this case.
This is about to change. Dmitry Dulepov wrote a book on TYPO3 Extension Development some time ago and now a new book has been published. Dan Osipov, a guy also well known in TYPO3 community, is covering multimedia features in TYPO3 4.3. TYPO3 4.3 Multimedia Cookbook is another book from Packt Publishing.
I've been asked by the guys at Packt Publishing to review this new book. I'm familiar with any security feature in TYPO3 4.3, but in regards to multimedia I expect the book to reveal yet unknown "recipies". I've bought Dmitry's book and so I'm curious if this book might become another must-have TYPO3 book. The book is on its way to me. So expect the review anythime soon.
Detailed information on TYPO3 4.3 Multimedia Cookbook.
Posted in TYPO3/ on February 05, 2010 by .
TYPO3 version 4.3 has brought a lot of new features. It's out since December 2009 and you've probably tried it or you're already familiar with all the new gimmicks.
I'm glad that the new system extension saltedpasswords has made it into the core. It allows to store passwords of TYPO3 user accounts as salted hash. With all these web sites that allow to "retrieve" the origin of a md5 hash, it's important that TYPO3 keeps up with the progress in security industry. With salted passwords we catch up with other content management systems like Drupal or Wordpress.
The main advantage of salted hashes is the fact that it makes pre-computed rainbow tables useless. Someone who's interested in retrieving the original password for a salted hash is basically cursed to run a brute-force attack. This is much more expensive in terms of time and computing power than looking up a hash in a pre-computed table.
What makes salted hashes so special? Every to be hashed plain-text password will concatenated with a random string (the salt). This salt is different of each user password stored in the CMS's database. Then, the hashing and concatenation will be done multiple times. By default, TYPO3 does that exactely 16384 times for each password. You now understand that dealing with salted passwords is a lot more secure than a typical md5 hash. Still, you're advised to wisely choose your password. Don't use a dictionary word; in best case it's a passphrase consisting of upper- and lowercase letters, numbers and special characters.
Now that we have such security feature, it's up to you to use it. Now I'm getting to the point of this posting.
A manual has been created and committed to the code repository. An upcoming TYPO3 version 4.3.2 will be shipped with it. The manual provides a step-by-step guide on how to install and configure this extension. In addition, it contains a developer section which will help TYPO3 extension developers to integrate saltedpasswords support in their extensions. If your favourite extension still does not support Salted user password hashes, please contact the extension developer, ask for this feature and refer to the manual.
I'm sure it won't take that much time until we find some more extensions in the TER which support saltedpasswords.
Posted in TYPO3/ on February 05, 2010 by .
Dear readers!
I've updated the TYPO3 extension T3BLOG to the latest version, have fixed some bugs (patches are in the mantis bugtracker for project t3blog) and made further modifications on it to fix my special needs.
If you still encounter any bugs, please drop me a note.
In addition, the feed url has changed. It's now http://secure.t3sec.info/feed/rsstype/2.0/rsscontent/post/pagetype/100/. However, the old url stays valid. Bonus: Now, the feed is a full text one (without any html structure).
Thanks to Dmitry Dulepov for his great work on TYPO3 extension T3BLOG. This extension has undergone a complete security review and now it's really safe to use.
Posted in TYPO3/ on January 30, 2010 by .
You certainly know that in software development, version numbers (e.g. 0.2.27) are used to identify a specific development version of a software product.
We, the TYPO3 Security Team recently had to work on an issue where the TYPO3 extension developer thought to be very smart in regards to the version number of his extension. We contacted him and reported a specific version number (like 0.2.27) to be vulnerable. After a few days, we faced a "new" version 0.2.27 of his extension cleaned up from vulnerabilities in the TYPO3 extension repository (TER).
Unfortunately, this happens quite occasionally in the TYPO3 world. It's a pity that the TYPO3 infrastructure (TER) does not prevent such overwritings of extension versions.
This is really bad development style. Let's assume you maintain a software product in which a bug occurs in version 1.3.15. You fix it, overwrite this version and now 1.3.15 is clean. A new report comes in again reporting 1.3.15 to be defective. You now face a problem. Which version contains the bug, the originally one or the modified one?
Additionally, in the TYPO3 world there's another drawback. The TYPO3 CMS has a so-called extension manager that allows to install/remove/update third party modules within the administration interface. This manager will not report a to be updated extension if you simply overwrite an already existing version.
Finally, considering security incidents, things get even worse. There are a lot of security service providers like Secunia that keep track of security advisories and so keeps you up-to-date on security vulnerabilites in products you might have deployed. Furthermore, there are "vulnerability databases" like NVD that describe and rate vulnerabilities in software products.
So in an security advisory you obviously want to clearly state that version 1.3.15 is vulnerable and version 1.3.16 is the fix for this vulnerability. You don't want to say that version 1.3.15 published until January 15, 2010 is vulnerable and any later available version of 1.3.15 is safe to use. This make things unnecessary complicated.
Do proper software development, do not overwrite version numbers! There are unlimited numbers to be used in version numbers; don't get stingy with new version numbers, you won't use them all up!