about
blog
tutorials
Password policy for user accounts
Posted in others/ on March 18, 2010 by .
My situation
You might have heard that I've lost my beloved smartphone. Due to this, I assume the person that found it might have got hold of several user accounts of mine.
In the last days I've revoked several SSH keys, changed credentials of server accounts and changed passwords of several accounts on websites.
If you ever come into this situation, you should start with your e-mail accounts. They usually contain your most private information, confirmations of account creations and perhaps passwords of user accounts. Then move on to e-commerce websites and change passwords there. Finally, change passwords of any other user account.
Of course, you should not have one password for all of your accounts. Before you ask, no I haven't had a one and only password for all of my accounts.
A draft of an ideal password policy
By changing my credentials, I stumbled over websites that have not any user interface to change passwords (contact support), websites that hide the user interface in the FAQ section, websites that allow only alpha-numeric passwords and nearly perfect websites in regards to password policy.
If you're building websites with user accounts, following suggestions will help you to make password policy user friendly.
- If the account requires an e-mail address, do not allow the user to change the address via an user interface! Such change should always require the user to contact the support. The support should verify the identity of the user requesting this change and might wait mandatory three days before applying the change. The support should send a notification mail to the old e-mail account that informs about the planned change of e-mail address. This period allows the account holder to interfere in case of credential compromise when the change request was initiated by the bad guy.
- Do not hide the user interface for changing the password. It should be part of a account/settings webpage reachable via one click!
- The interface of the password change should consist of one field for the old password and two fields for the new one (one for confirmation preventing spelling errors).
- Allow alphanumeric AND special characters for the password!
- Put a description text to the password fields that tells the user what kind of characters are allowed.
- Divide possible characters in four classes: numeric characters, lowercase alphabet characters, uppercase characters and special characters. Require at least three classes to be chosen from for the password and a minimum length of the password string.
- Put a graphical representation of the password strength next to the password field. This should calculate the mathematical entropy of the password string. Red, orange and green are nice colors to represent the strength.
- Inform the user via mail about the change of his password along with the IP address of the host that initiated the change!
- Do not send passwords via mail!
I've found out that Amazon and Ebay are nearly perfect in regards to password policy. It's up to you to take my suggestions and improve your website!
I'm awaiting your comments; any important point missing?
No preannouncements for TYPO3 security advisories
Posted in advisory/TYPO3/ on March 04, 2010 by .
Every once in a while the TYPO3 Security Team is being asked to generally use preannouncements. Such preannouncements, to be published days before the actual TYPO3 Security bulletin, seem to be a nice way to be prepared for a necessary update of the TYPO3 Core, the base platform.
We discussed this suggestions but came to the conclusion that we better stick to the current procedure. Following is a list of points you need to understand.
- Preannouncements for third-party TYPO3 extensions seem to be not necessary. Most time, you won't be affected by extension issues as you aren't using any of the mentioned extensions.
- We believe and know that upgrading (w/o testing) alone of the TYPO3 Core won't take longer than 5 minutes per server.
- We are not aware of any other Open Source project that has preannouncements in general use.
- Preannouncements will become useless again, if we need to late-postpone or pre-release a new TYPO3 Core version. Valid reasons would be regressions or exploits in the wild.
- Your TYPO3 installation might not be vulnerable because of not using an extension in question (recent openid vulnerability etc..) or the exploitability risk is very low (e.g. XSS in the backend with another vulnerability as mandatory prerequisite).
Last but not least, preannouncements would be another task to be done by the TYPO3 Security Team. The creation/review/publication of the bulletin takes hours (not taking any work on the issue itself into account). We're mostly interested in reducing our work load; after all, most of us do this work for free. However, preannouncements would mean the contrary and the overhead does not compensate the to be expected benefits.
Nonethless, for critical security issues we will of course proceed with preannouncements which has been done several times in the past.
TYPO3 as good as its competitors in web application security
Posted in TYPO3/ on March 01, 2010 by .
IBM has recently released its X-Force 2009 Trend and Risk Report. This report summarizes reported web application vulnerabilities in 2009. TYPO3's overall "performance" is as good as its Open Source competitors like Drupal, and Joomla!. The number of vulnerabities in the CMS cores are more or less equally; when taking third-party addons/extensions/modules into account choosing TYPO3 seems to be slightly better than Drupal or Joomla!. However, this might also be caused by different total numbers of available third party plugins.
|
Product |
Base Platform |
Plug-ins |
Total |
|---|---|---|---|
|
Drupal |
0.2% |
2.5% |
2.7% |
|
Joomla! |
0.2% |
2.5% |
2.6% |
|
TYPO3 |
0.3% |
1.2% |
1.5% |
The report additionally considers vulnerabilities w/ and w/o patches. In regards to this, TYPO3 numbers seem to be odd. I'm not aware what IBM considers as unpatched. For TYPO3 core there weren't and aren't vulnerabilities disclosed for the base platform without providing patches. Either IBM is taking versions into account that aren't officially supported any longer or wrongly considers a non-issue issue I covered in a previous blog post.
|
Platform |
Base Platform |
Plug-ins |
|---|---|---|
|
Drupal |
18% |
13% |
|
Joomla! |
8% |
80% |
|
TYPO3 |
5% |
51% |
We see a relatively high percentage of unpatched vulnerabilities in plug-ins (Joomla! and TYPO3 specifically). At least for TYPO3, this can be explained. TYPO3 is on the market for years now. Plug-ins are an essential part of a TYPO3 installation to bring missing functionalities. Therefore we have really old and no longer maintained plug-ins in the TYPO3 extension repository. Besides, security awareness wasn't that good in the good old days.
There's a high change that extensions with unpatched vulnerabilities are no longer in use or even aren't working anymore. Also, if the maintainer decides to stop support for an extension, TYPO3 security team won't provide patches. Providing patches in such cases would mean that the TYPO3 Security Team is responsable for these extensions forever and ever. Nonetheless, we encourage the TYPO3 community to contact the TYPO3 Security Team to take over maintainership of unpatched vulnerable extensions. Then a fixed version of the extension might again appear in the TYPO3 extension repository.
Still, I'm curious why Drupal has a significantly lower number of unpatched vulnerabilities in their plugins. Enlighten me!
Providing third-party plugins is always a tradeoff between security and user-friendlyness. You want to keep burdens low to provide additional functionalities and so help spreading the product. Then, overall quality of third-party plug-ins is definitely not as good as the base platform. So choose your plug-ins wisely and make a basic check by having a first or second glance on the code.
What I believe is more important, all mentioned CMS vendors above have professionally working teams that take care of security in the base product and third-party plug-ins. Every software product contains bugs. If you need to choose one CMS over other ones, check out the vendor's security awareness. If there's one CMS product without any disclosed vulnerabilities, it's either brand-new, not widely spread or doesn't care of security issues. If in doubt, better avoid such product.
In regards to security, Drupal, Joomla! and TYPO3 seem to be equal. In the end, functionality matters. You won't make a security mistake by choosing one over the others.
I'd like to take this posting as a change to say thanks to the TYPO3 Association. The Association cares about the security in their baby at least as much as the TYPO3 Security team does. They are giving us - the TYPO3 Security Team - a decent budget to cope with security issues. Thanks again. By being a TYPO3 Association Member you help to have a secure CMS. If you ever asked yourself, where your fees are spent on - not only on development but also partly on the TYPO3 Security Team. And it's definitely worth it.
One additional figure from the TYPO3 Security Team:
In 2009 we have handled 317 reports in total; starting with suggestions on how to improve security, over support requests on hacked servers and of course vulnerability reports in third-party plug-ins and TYPO3 core. That's an impressive number considering the small number of security team members.
Disclaimer:
X-Force statistical data are used as are. I personally do not warrent their correctness. IBM and X-Force are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.
Frontend login password recovery
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!
TYPO3 4.3 Multimedia Cookbook - a new book in english
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.
