Secure by design, in Software, means that the design is made to be secure. Usually this involves being fully fault tolerant. If, for instance, a user (computing) has to type his/her name, and that name is then used elsewhere in the computer program, care must be taken that when a user does not type a name, the program does not break.

Generally, designs that work well do not Security through obscurity. It is not mandatory, but good security usually means that everyone can know and understand the design, because it is secure . If people are prevented of 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 found faster and hence can be fixed faster. See Linus s law .

Also, it is very important that everything works with the least amount of privileges possible. A web server that runs as the administrative user (root or admin) can have the ability to remove files and users that do not belong to itself. Thus, a flaw in that program can put the entire system at risk. On the other hand, a webserver that runs inside a jail (computer security) and only has the privileges for required network and filesystem functions, can not allow compromising the entire system it runs on, unless the security around it (the jail in this example) is also flawed.

To summarise, secure by design means that it cannot (or should not be able to) be abused. That is, it doesn t allow its users to do things that are not normally possible. Everything that can be done, will be done. So to minimise impact, everything has to be taken into account. Nothing should be given the chance to do things that it should not do. What the future brings must be taken into account before [it happens].

A perfect authentication system for logins does not allow anyone to log in at all, because the user could be a threat to the system. However, some designs can never be perfect. Passwords, biometrics, and such are never perfect.

== Practical hints ==

Many things, especially input, should be distrusted. A program could even distrust itself (see fault tolerant). Nothing guarantees that a given input is something expected.

One of the most famous examples is the program that asks the user for his/her name, and prints Hello, . Suppose the name is stored in a buffer of 1024 bytes (characters), and the input stops when a newline character is detected, the user could overflow the buffer only with 1024 spaces, because strings always end with a terminating null character. Thus, if the user is not allowed to enter a name longer than 1023 characters, the user can t overflow the buffer.

Then, when the input is printed, the user could have typed format string directives. This is a problem with code like this:

printf(buffer);

The printf function takes a format string and optionally variables to be inserted into the formatted string. So for instance, and integer x can be printed with:

printf( x is: %i , x);

When the value of x is 7, this prints:

x is: 7

However, when a user types in %i as his/her name, no extra argument is given, causing undefined behaviour. Instead, a function call like this:

printf( %s , buffer);

will not allow the user to do this. See Format string attack.

A common mistake in online Scripting programming language is to not validate parameters given to it. For example, consider a script that fetches an article by taking a filename, which is then read by the script and parsed. Such a script might use the following hypothetical URL to retrieve an article about dog food:

http://www.example.net/cgi-bin/article.shname=dogfood.html

If the script has no input checking, instead trusting that the filename is always valid, an could forge an URL to retrieve configuration files from the webserver:

http://www.example.net/cgi-bin/article.shname=../../../../../etc/passwd

Depending on the script, this may expose the Unix security#Passwords file, which on Unix-like systems contains (among others) User_identifier_(Unix), their Username, home directory paths and Operating_system_shell.

IPC

When creating message passing routines, a lot of thought needs to be put in its design. In server/client models, the program at the other side may not be your client. And the client s server may not be your server. Or maybe it is, but there s something undetectable in between, a man-in-the-middle attack. Also, when a program needs to keep checking for a file and read it when found, someone could ve quickly put a file in place thats not from where it should be.

However, good IPC models can increase security. For instance, as one subsystem is compromised, other subsystems could disconnect from it and warn the administrator, without having everything compromised at once. But this, like many things, always has its ups and downs.

== See also ==

*Secure by default *Security through obscurity *Security *Encryption *Authentication *Authorisation *Buffer overflow

== External links ==