Talk:Secure by design
From Wikipedia, the free encyclopedia
[edit] Bad Examples
These examples do illustrate insecure practices, indeed. But are their flaws actually caused by the software design?
I consider the following example to make the point clearer: Microsoft Windows determines the type of a file by its filename (e. g. malicious.pdf.exe is treated as an executable). An email client which has a dubios document of type "application/pdf" is allowed to save it under a filename allowing it to be executed. To make things worse, Windows does not display the filename extension of known file types to the user (the file being displayed as malicious.pdf, together with an icon chosen by the creator of the file).
Hiding the most important information from the user is never a good idea. Letting the untrusted file choose its own executable status and its icon is wrong. That is a design issue.
To emphasize my point: Security by design is not a programming issue. If you already have started coding C source, it is too late for this security pattern.
--217.226.97.81 (talk) 11:30, 14 March 2008 (UTC)
Can somebody write a secure version of the example ? —Preceding unsigned comment added by Drowsy (talk • contribs)
Sure.
#include <stdio.h>
int main(void)
{
char buffer[100] = {0};
puts("What is your name?");
if (scanf("%99s", buffer) == 1)
printf("Hello, %s!\n", buffer);
return 0;
}
I won't add it to the article proper for at least three reasons: There's more than one way to do it; it would break up the flow of the text without adding anything useful to the discussion; and the entire article pretty much needs a total rewrite, if not outright deletion, anyway. The current article is very much a collection of security trivia dumped in with some industry buzzwords. I don't think there's anything encyclopedic to say about "security by design" (which is where this article probably should be, anyhoo). --Quuxplusone 00:54, 14 December 2006 (UTC)
[edit] Misleading statements
"It is not mandatory, but proper security usually means that everyone is allowed to know and understand the design, because it is secure. If people are prevented from looking at the design, then it is usually flawed (and they know it, so you can't have a look at it). However, that does not mean that an open approach is always secure. It's secure until someone outsmarts the designers. The real advantage is, however, that when not keeping a design secret, issues can be discovered faster and hence can be fixed faster. (See Linus's law.)"
Most of this is speculative and misses the real details of security arguments. E.g.: 1) Preventing people from seeing a design does not mean it is flawed. Secrecy may also be for a number of other reasons including IP protection, stealing a march on competitors as part of business strategy, or indeed hiding security flaws that would destroy consumer confidence. 2) Just because someone has not yet outsmarted the designers does not mean software is secure, it means no-one has bothered to highlight the vulnerabilities yet. 3) Discovery of issues does not lead to fixing them faster. That relies on resources to support a product.
There are many, many other issues to do with security and this article probably doesn't help with clarification of those issues, which in itself is a key part of propogating security by understanding. —Preceding unsigned comment added by 82.35.40.133 (talk) 16:55, 29 January 2008 (UTC)
