Talk:Secure by design

Invalid C Code

The code displayed is stats "Because the gets function in the C standard library ...". This is no longer true. gets() is no longer in the C standard library. The latest standard (ISO/IEC 9899:2011, finalized back in dec. 2011) has totally removed gets() from the standard library - making that example no longer valid standard C code. In fact, there is no even mention of this change. 68.232.126.69 (talk) 22:44, 30 March 2013 (UTC)

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)

Good point, let's scratch the current example as it demonstrates a common coding error. Instead, an example where input has to pass a secured layer would be better and it doesn't necessarily have to be shown in code. For instance, in web applications it's good practice to have an abstraction layer around the database that makes sure what goes in is safe, preventing SQL injection attacks. 83.80.26.21 (talk) 00:07, 16 August 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)

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)

achieving concerns?

"Security architectural design decisions are based on well-known security strategies, tactics, and patterns defined as reusable techniques for achieving specific quality concerns" - would addressing concerns not be better than achieving concerns here? — Preceding unsigned comment added by 195.238.24.42 (talk) 16:48, 22 June 2022 (UTC)

Requested move

The following is a closed discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was No move Parsecboy (talk) 01:13, 30 April 2009 (UTC)

• Oppose. "Secure by design" gets twice as many google hits as "security by design". On the other hand "secure by obscurity" gets almost no google hits (255) vs. "security by obscurity" (65,300). This is a case where common usage has not chosen to make them the same. I guess people just like the fact that it rhymes. 199.125.109.124 (talk) 12:36, 24 April 2009 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.