Talk:Secure by design

message: 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)
thread_title:  Invalid C Code 

message: 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)
replies: text: 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)
thread_title:  Bad Examples 

message: "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)
thread_title:  Misleading statements 

message: "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)
thread_title:  achieving concerns? 

message: No move Parsecboy (talk) 01:13, 30 April 2009 (UTC)
thread_title:  Requested move