[support] Subject: Re: Site Hacked

[Roger]

> Pl go to drupal support and give your details and report them about
> hacking better change admin password
No point in doing that. It's a whole of Drupal design thing, including 
engine and modules. It is  not a small problem.
The inherent problems, for us, with Drupal 7 are:

- The engine is part of the site and can be played with/altered while 
live. Convenient but potentially damaging.

- There is no way to not have admin on a live site. In fact there should 
be no admin at all on a live site or as a minimum, a disabling switch. 
Without admin access a live site is less vulnerable. It can be hidden 
but not disabled.
Live should be just display of data with limited data input and change 
thereof. This requires another mindset for Drupal as a whole.

- For us, some components, that we needed, like say Work bench, 
taxonomy, and several others need admin permissions for the user to 
enter/change data. This opens a pandora's box of risk.
Alternatively we write work around code or find and install yet another 
set of "work around" modules to overcome the problem. This in turn 
introduces potential threats, risks, more maintenance, etc. To date we 
have several work around modules.
Creating modules or rewriting is not an option for me. I do not like 
PHP, it's boring, cumbersome and repetitive.

- Configurations are stored in the database, there is no way to dev or 
test without entirely separate installs which require copies of the live 
database updated into the dev/test areas. We can't work on updated data 
without potentially wrecking d/t changes and vice versa.
  Ideally configurations could be separate from data. Dev/test could 
instead  be a subset of live data with just the config and display 
changes worked upon.
We don't have the expertise to go through every table to find which is 
linked to which.

- There is no clean, obvious way to move a small change from dev/test to 
live site without overwriting the database or part thereof which means 
that latest data may be changed or some field content no longer relates 
to changes. Unless yet another set of protocols is introduced with more 
complication.

- Introducing changes as above, for us, have wrecked parts of the live 
system because it seems, virtually every table is referred to by every 
other table in some way.

- When Admin, on a static IP, is locked out there is no way, apart from 
waiting many hours, for the ip lockout to be dropped. Unless there are 2 
or 3 admins and one or those resets the lockout, not easy!

- We routinely use extremely convoluted very long passwords, changed 
regularly. The password is the only hidden part of a log in.
User names are displayed to all and sundry. For us, hiding actual user 
names and displaying preferred user names unrelated to login would be 
more secure.
Barriers to hacking Drupal core are the password and the 5 tries and 
you're out. Hidden user name and display of preferred, but different 
name could add another level of security.

Roger