Worst Practices in Developing Secure Software, Part II
Click Here for Part I
As I’ve said before, The “Best Practices Mantra” annoys me.
A major component of success involves avoiding making any major mistakes. Instead of focusing exclusively on implementing “Best Practices,” I suggest avoiding “Worst Practices.” You can do almost everything perfectly, but if you do one thing horribly wrong you can negate everything. A soldier greatly increases his chances in a firefight by doing things right, but one serious mistake and his odds of surviving plummet. Fatal flaws and mistakes are often exactly that – FATAL!
Assuming that only “important” software needs to be secure.
“Hey Ted, wasn’t this also in Part I?”
Yes, but it’s worth repeating!
All programs and services need to be secure. Even a simple game or utility could be compromised, contain a Trojan or otherwise harbor malicious code, and lead to your entire network being compromised. This includes prototype and test code as well.
Not planning for failure
Complex systems can and do fail. Both partial and complete failures need to be planned for. Software should always fail to a secure mode, and when in failure mode, deny access by default. If the entire system fails, any secure data should be unavailable!
When failure occurs, no data should be disclosed that wouldn’t normally be available, and as little information as possible should be disclosed.
For example, if a login fails, it is far preferable to report that the login failed than to specify “invalid password” or “no such account.” If a login fails, it should reveal no information other than failure (if even that).
I worked on one system where the results of a successful and unsuccessful login were visually the same – the user didn’t even know their login failed until they tried to do something.
In contrast, I recently was authorized by a client to login to their Blogger account to add Google Ads and make a few other changes to their blog. They gave me an incorrect account name and password, and when I tried to login I got a message that said “non-existent account.” I now knew the account name was wrong, and I tried a couple of “obvious” account names such as the company name, etc. My second guess was correct and I got a different error message, “incorrect password.” The password was easy to guess too – it was my client’s dog’s name!
I was authorized to access his account, but even if I hadn’t been, I could have “guessed my way in.” If Blogger didn’t differentiate between incorrect passwords and non-existent accounts, it would be more secure and I probably would have given up quickly and waited for my client to give me the correct login information.
Should a significant failure occur to a critical system, e.g. a defacement of the organizations web server or a inability of a server used for ecommerce to authorize credit card purchases, there *should* be a security policy in place that specifies contingency plans. For example, should the server be taken off line? Should it report an “unavailable – try again” message? Should it be left live and fixed as quickly as possible?
Counting on “Security through Obscurity”
Click here to read more
As I’ve said before, The “Best Practices Mantra” annoys me.
A major component of success involves avoiding making any major mistakes. Instead of focusing exclusively on implementing “Best Practices,” I suggest avoiding “Worst Practices.” You can do almost everything perfectly, but if you do one thing horribly wrong you can negate everything. A soldier greatly increases his chances in a firefight by doing things right, but one serious mistake and his odds of surviving plummet. Fatal flaws and mistakes are often exactly that – FATAL!
Assuming that only “important” software needs to be secure.
“Hey Ted, wasn’t this also in Part I?”
Yes, but it’s worth repeating!
All programs and services need to be secure. Even a simple game or utility could be compromised, contain a Trojan or otherwise harbor malicious code, and lead to your entire network being compromised. This includes prototype and test code as well.
Not planning for failure
Complex systems can and do fail. Both partial and complete failures need to be planned for. Software should always fail to a secure mode, and when in failure mode, deny access by default. If the entire system fails, any secure data should be unavailable!
When failure occurs, no data should be disclosed that wouldn’t normally be available, and as little information as possible should be disclosed.
For example, if a login fails, it is far preferable to report that the login failed than to specify “invalid password” or “no such account.” If a login fails, it should reveal no information other than failure (if even that).
I worked on one system where the results of a successful and unsuccessful login were visually the same – the user didn’t even know their login failed until they tried to do something.
In contrast, I recently was authorized by a client to login to their Blogger account to add Google Ads and make a few other changes to their blog. They gave me an incorrect account name and password, and when I tried to login I got a message that said “non-existent account.” I now knew the account name was wrong, and I tried a couple of “obvious” account names such as the company name, etc. My second guess was correct and I got a different error message, “incorrect password.” The password was easy to guess too – it was my client’s dog’s name!
I was authorized to access his account, but even if I hadn’t been, I could have “guessed my way in.” If Blogger didn’t differentiate between incorrect passwords and non-existent accounts, it would be more secure and I probably would have given up quickly and waited for my client to give me the correct login information.
Should a significant failure occur to a critical system, e.g. a defacement of the organizations web server or a inability of a server used for ecommerce to authorize credit card purchases, there *should* be a security policy in place that specifies contingency plans. For example, should the server be taken off line? Should it report an “unavailable – try again” message? Should it be left live and fixed as quickly as possible?
Counting on “Security through Obscurity”
Click here to read more
posted by Ted Demopoulos at 9:48 PM
Comments on "Worst Practices in Developing Secure Software, Part II"
post a comment