[TYPO3-english] TYPO3.ORG hacked

[Erik Svendsen]

Hello Andreas,

> Passwords forth and back
> As long as TYPO3 stores user data on different places, as long as
> xtimes
> personal data get stored on xdifferent places and no coordination
> takes
> place at all - TYPO3 will always be not so userfriendly and that is a
> pitty.
> There is so much coordination going on why nobody simply tries to
> figure out
> to reduce all those personal datas to one and only place.

Should BE-userdata and FE userdata be stored at one and only one place. Why. 
Do it help security. The opposite I will say. Today only admins can see BE-userdata, 
if you don't use specific extensions to give other access. So it should be 
in the future. And I also think other CMS-es use the same approach. And where 
else do TYPO3 store userdata, tt_address isn't userdata.

> Then integrate this one and only place as a "Fort Knox" into the Core
> and
> make TYPO3 more secure.

Both BE-userdata and FE-userdata is a part of sysext/core. Even felogin is 
a part of same, but if you don't need it, you don't need to install it. A 
lot of sites don't need any FE-login.

TYPO3 is by the way one of the most secure open source CMS on the market 
if you read Secunias security statistic.

And TYPO3 as CMS isn't going to be more secure with changes in handling of 
FE-userdata. The security of a CMS depends on the possibility to hack the 
system, not on plaintext or hashed password for FE-users. You enhance security 
better with real security awarness, and real security information to the 
users. I have delivered TYPO3 installations where password are plaintext, 
and there are no plans to hash/encrypt them. Are the userdata at risk. Yes, 
if someone get access to a BE user or hack the system. Are the consequences 
if someone gets these password  or/and userdata a security risk for these 
users.  Probably not, because the users are asked to not use the same password 
as on other sites. They are also given usernames that's there are low possibility 
that they use on other websites.

> If you generally look to modern CMS Systems which have been programmed
> in
> the last few months you'll see that they all focus in their basic
> edition on
> a very simple but effectfull standard set.
> All include a secure login solution for front and backend
> All store personal data not on x different places in x different ways
> All include easy accessible filemanagement
> Al include some very good basic seo features
> All are able to rewrite URLs without the hazzle like it is caused in
> TYPO3
> All come a long with a standard set of ready to use extensions/modules
> like
> - news/blog
> - simple ecommerce
> - login solution
> - some even with a gallery
> - online editor
> Having something similar in TYPO3 would reduce lots of stress in how
> to setup a secure and working solution for front and backend. And it
> would start with a secure running system. Simple try to make TYPO3 not
> only more secure but also more userfriendly.
> 

A standard TYPO3 installation is pretty secure, it's not going to be more 
secure if you put a standard set of extension in it or make it more userfriendly. 
More userfriendlyness will make it easier to get at working solution but 
doesn't necessary make it more secure (sometimes it even do the opposite). 
More standard extensions will probably make the system more unsecure. Most 
of the vulnerabilities i TYPO3 are in extensions (bad coding). Usability 
is a goal in itself.

I will say TYPO3 has good basic SEO features, rewrite URL's are not very 
difficult (also on other CMS-es you have to use .htaccess) and enable rewriting. 
TYPO3 has also working filemanagment, online editor (or do you mean inline 
frontend editor, which very few CMS has really good soultions for). Login 
solution is a part of core/sysext.

News/blog, ecommere, gallery should never be a standard part of an enterprise 
CMS/CMF. For instance, I don't need News to make a news website i TYPO3, 
neither need I any gallery. This is also the strong part of TYPO3, the possibilities 
to do nearly whatever you want without the use of extensions/modules at all 
(except for the core/sysext part), or using exactly the extensions which 
is needed. TYPO3 has never tried to give the 

Remember also, TYPO3 has a 10 years history from the first codelines. Ther 
aren't many other CMS where your 4 - 5 year old website with relatively ease 
has been upgraded to newest version.

TYPO3 isn't trying to give the expression of an easy to install and configure 
system. It's a complex and advanced system, which I never will recommend 
to anyone who wants to make their own homepage fast and easy.

> A human factor where somebody with admin access "kidnapps" passwords
> will exist in any System but even here I guess encrypting password or
> using md5 would make it a bit more difficult even for this admin user
> to get and use the passwords in cleartext.

As said in many posts, md5 hashed password aren't really secure. Other encrypting 
solutions are a bit/much better. But the real good solution is. Have procedures 
which reduse the risk for anyone to get hold of an admin account (restrict 
the number of admin users, delete accounts that not are in use). Upgrade/patch 
systems. Use SSL for backend login. Try to make the possibility for hacking 
the system as little as possible. Use WAF/mod_security. Because password 
isn't necessary the data with largest consequences. Email, username and other 
information can make a bigger security threat than that someone knows one 
of your password. Password are possible to change (you shouldn't use the 
same everywhere), other data isn't so easy.

> 
> Thinks like just happened are mostly depending on a human factor which
> can't be excluded at all but we should be able to make it much more
> difficult for those people to get our data in plain text.
> 
> Andi

You are correct, security is depending on the human factor. Therefore are 
the most important part of security work to do something with the human factor, 
mostly make people aware of the risks and educate them. And have good procedures 
in handling BE useraccounts.

WBR,
Erik Svendsen
www.linnearad.no