Drupal EID insecurity discussion : what is important here

Here you can read the following comment from the drupal community/maker

Get the facts about Drupal & eID


Drupal.org did not make an eID module. It was made by a third party developer, and the code is hosted on Drupal.org.
From a technical, internal Drupal point of view, the code is probably secure (no obvious runtime bugs, no SQL injections etc) so the code was admitted to drupal.org.
But from a design point of view the code is of course totally wrong and in violation of Belgian privacy law.

Amedee Van gasse
amedee@vangasse.eu http://amedee.be

This is totally wrong and it is just because it is totally wrong that such mistakes were made, not only in the drupal module but also in the EID middleware (first and second version).

It is important that you check your code for insecurities and bugs and that processes of your different modules an sich are secure. But when that is done and you have secure code and secure modules who interact in a secure way the work only begins. You have at that time the building blocks of your infrastructure or module.

Than you ask. What is the importance of the data or the transaction that I want to use this code for and which are the implications for my modules and my applications. The more important the data is, the more judicial and new other security mechanisms and monitoring and update mechanisms have to be put into place.

If one had followed this route, than the biggest work would have only started after the 'secure' drupal code was finished. The second phase is to secure the important identity data that it was going to use. This is maybe not only done in this module in Drupal environments but it should be clear that this module should only be used if the securisation of the transactions, storage and monitoring is in place. This should in fact - if the data is so important that it could lead to judicial and financial problems if it were to be compromised - be independently certified and audited on a regular basis.

Because in Belgian law there is the general principle that you didn't work as a good homemaker (traditional family expression) by not taking care from the beginning to limit the risks for the others you are responsable for. (the obligation of caution and professionalism). Can you sue Drupal or the makers of the Drupal module ? Maybe, maybe not...

I know this all seems very odd for some in the open source community but if the open source community is to survive in the business environment than certification, control and automated update mechanisms are the only way to keep the trust.

If I were drupal I would develop a complete secure framework or drop out of the financial/identitycard business alltogether. And give no permission to include any modules that aren't certified and updated this way which is what killed Joomla security. Once you lose the trust it is very difficult and costly to win it back again if you ever do.

To conclude I don't care about the code an sich, I follow the data. And securing the data is the centerpiece of security. Securing the code to protect the data is only the very first step of many and this is a continuous process.

And I understand the frustration of the developers who for the moment don't really know where to go for advise, secure code, testing, norms and all the other stuff that such a serious project like EID should have had from the beginning. There are some initiatives but lets all agree that even with all their enthusiasm, such a big project needs more professionalism and guidance. Not only for Drupal developers.

And hereby I close this debate about open source because I don't care how open or closed a code is when we talk about security and privacy. Frankly my dear, I don't give a damn.

Comments

  • I just meant that it is perfectly possible to write bugfree code that is totally insecure. Isn't it a bit silly that we, both Dutch speakers, converse in a foreign language?

    Once you're inside Drupal I think that we can suppose that we're secure, but of course I totally agree with you that it is utterly useless to secure an identity token that was provided by an insecure middleware. Garbage in, garbage out. It's as simple as that.

    I also agree that on a broader perspective Drupal should set a policy that refuses authentication modules that provide insecure identity tokens.

    And that is also my last contribution to this discussion.

The comments are closed.