Developer Code of Conduct

[ConvertFromOldNGs]

by Stephen >> Wed, 28 Sep 2005 5:04:13 GMT

Hi,
I am wanting to find out what people are doing to satisfy the likes of bosses or auditors that your development team is not doing anything untoward.

Its pretty simple for a developer to write something to access confidential information, such as credit card numbers, passwords etc.. that are stored in the database. Despite ones best intentions to have these things encrypted within the database, so outside users could never find them out, there is always an unencrpyt method to get the information out for when you need to use it in your application. So developers can always get at this sort of information. Always. It would be pretty simply as a developer to add in any amount of devious little bits of code.

Even within your live applications, staff can change a customers password, (or change the email address to their own, reset the password and email it to themselves - or whatever method your app uses) then access the website or whatever as someone else. Sure you have audit trails, but that only tells you what someone has already done.

So how are people stopping this from a legal point of view.
Technically I'm not worried - I just want our sweet betudies covered incase someone asks what we have in place to stop it!
Every development house on the planet must face this issue, so is there any standard code of conduct, or best practice, or ISO-5601 type thing, that people can get developers to sign before starting a project?

I hope you understand what I'm trying to get at, and would appreciate anyones comments on how they approach this.

Thanks
Stephen Persson

[ConvertFromOldNGs]

by cnwjhp1 >> Wed, 28 Sep 2005 6:14:23 GMT

I realise you are looking for legal things, not technical things to address this problem, but I believe some technical things are worthwhile also.

In a similar situation years ago involving password encryption in an eftpos-type system, I implemented what in Jade would be a source-encrypted peer schema. All surrounding code appeared to be doing something else (something complicated and boring!), due to the naming of attributes and methods. And only supervisors with some seniority were allowed to reset passwords.

Sure, a determined hacker-developer could figure it out, but at least the code wasn't flaunted in everyone's face. It's kind of like locking your house - it doesn't stop a determined burglar, but it does make intruders less likely. And not doing it is like not locking your house because you figure they could break a window and get in anyway.

Surely any client who would be impressed that developers promise in writing not to do bad things would be impressed by technical steps taken to discourage it, wouldn't they?

Cheers,
John P

[ConvertFromOldNGs]

by Scott >> Wed, 28 Sep 2005 20:59:18 GMT

Password encryption only ever needs to be a one way algorithm with a few appropriately authorised users who can reset a password back to a known value again should the users forget their passwords.

Credit card details - if you absolutely must store these after the transaction has successfully completed, encryption with a multi-part key where no one person knows the entire key required to unencrypt them is an option. Should the need ever arise to decrypt the card details, this is likely to be an abnormal situation and you could choose to have your external auditors present with the sealed envelope with the remaining security key details required to do the decryption. As for the end users having to rekey their details for each transaction, should they complain you can simply advise them you do not automatically restore their card details for security reasons and they're unlikely to complain.

[ConvertFromOldNGs]

by Stephen >> Wed, 28 Sep 2005 22:45:20 GMT

Thank you both for your comments.

We do have steps and measures in place to do the types of things both replies stated.

In the case of credit card details, we do store them in our database to make recurring monthly payments for subscriptions if the customer requests this. In this case the payment is automatically made on the last day of their subscription, by an automated job processor. So no system user can possibly get at the credit card number, and it is encrypted within the database. However any developer working on the code for that job, can see the code for unencrypting the number before it is put it into the COM component that makes the payment.....

In the case of encrypted schemas - granted this keeps most developers out of the code that will do anything too sensitive, but someone still has to have access to that sensitive code if it needs to be changed.

So while I agree that you can impress clients and auditors with steps taken to technically stop things happen, and we can put in as many security measures and steps as we can dream up, in the end there is always someone, and needs to always be someone, that can access the information. If there isn't, then it could never be fixed or modified if the need arose.

And one could equally argue the value of making someone sign a piece of paper, if they are going to do it, a piece of paper isn't going to stop them. I guess I just don't believe that when it really comes down to it, an argument like "Yeah sure people can access that information, but we do our best to stop it..." can really hold any weight, nor is it much comfort to someone whos system could be breached.

One interesting document I found is a code of conduct that was developed by the IEEE-CS/ACM joint task force on Software Engineering Ethics and Professional Practices (SEEPP) which includes the following :

2.05. Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law.
3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized.
4.04. Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices.

Full link: http://www.computer.org/portal/site/iee ... eneric.xsl&

I think I'll run with that one, but would still be keen to hear others thoughts or opinions.
Thanks
Stephen

[ConvertFromOldNGs]

by cnwjhp1 >> Thu, 29 Sep 2005 4:24:41 GMT

Correct, and the system I was porting in 1980 used a one-way hash. With knowledge of the algorithm, however, and especially as it used a 4-digit pin, I only had to run 'foreach i in 1 to 9999' through the algorithm to find a pin I could use for that account. I did that for my own card, and came up with 4 synonyms for my pin - different pins that generate the same hash. I decided I liked one of them better, so continued using it! But that was what made me decide to hide the source. With the algorithm plus the hash value, a stolen card can be used. Even with the longer passwords in use now perhaps making such a brute-force technique unfeasible, I would imaging that if you had access to the algorithm you could find ways of shortcutting it.

[ConvertFromOldNGs]

by rob >> Wed, 28 Sep 2005 21:29:03 GMT

Despite ones best intentions to have these things encrypted within the database, so outside users could never find them out, there is always an unencrpyt method to get the information out for when you need to use it in your application.

A note on storing passwords - the standard industry approach is to encrypt passwords using a one-way (or hash) algorithm, so there is no unencrypt method. Authentication relies upon hashing the entered password, and comparing with the stored hash value. Passwords are therefore unrecoverable, so a process is required to allow users or supervisors to reset a forgotten password (often a series of 'secret' questions such as date of birth, mother's maiden name, favorite flavour of ice cream). Hash and two-way encryption algorithms are fundamentally different (note the latter relies on a key, which must be kept secret). There are a multitude of hash implementations available as dlls etc, and there are also plenty of Jade native implementations of varying complexity/security; a common metric used to compare hash algorithms is "collision rate", which provides a measure of how often different passwords will result in the same hash value. Check out the web ... there's more coverage of these subjects than there are cheap loan ads.

Back to your main question ... I don't believe there is a way to guarantee 100% protection against a determined developer - the code-hiding technique described by John P can also be used to hide trojan code from independent code review. So I suppose clients must trust our professionalism and honesty ..... I suspect one day this will become a huge issue when a developer somewhere becomes very rich, while bankrupting a national treasury somewhere. Now there's a thought ...

Cheers,
Rob