Tag Info

Hot answers tagged

40

Using obscure applications is, as my phrasing suggests, a form of security through obscurity. Such reasoning is false, and only leads to a false sense of security. Obscurity is not security. Don't select your security-critical software based on how popular it is or isn't; select it based on the amount of analysis that has gone into the software, how quick ...


34

This is called "security through obscurity", which is generally considered to be a bad security model for most (if not all) purposes. There are two main terms focusing upon this concept: Kerckhoff's principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Claude Shannon reformulated this ...


27

The notion that open source software is inherently more secure than closed source software -- or the opposite notion -- is nonsense. And when people say something like that it is often just FUD and does not meaningfully advance the discussion. To reason about this you must limit the discussion to a specific project. A piece of software which scratches a ...


23

It's not that simple. With the huge number of platforms on which the program could have been built, it can be extremely difficult to replicate the original build environment. Because of this, you could be using a different compiler, with different settings, using different versions of libraries. These slight variations in the environment can definitely ...


22

I have recently heard that most of the PHP code is confidential, because if attackers know your database structure or the hash function used to encrypt the passwords, there is higher chances of a breach. That's only when designers don't use the correct hash function or protect the webapp from SQL injection. But these things can be easily detected, there ...


19

Maintained software is more secure than software which is not. Maintenance effort being, of course, relative to the complexity of said software and the number (and skill) of people who are looking at it. The theory behind opensource systems being more secure is that there are "many eyes" which look at the source code. But this depends quite a lot on the ...


15

If you compile the code yourself, then you may obtain the same binary. Or not. Basically, your chances are good if the compiler uses deterministic optimization algorithms (that's the usual case) and you use the exact same compiler version with the same command-line options (that's usually much harder to ensure). Deterministic re-compilation is easier with ...


14

The theory is: Closed-source software is mostly non-trojaned because the vendor of such software is legally responsible for the software contents, and easily tracked down, should a hidden malicious code be revealed to be part of it (e.g. through reverse engineering). Open-source software is mostly non-trojaned because it is very difficult to ...


13

@Polynomial makes very good points regarding "security through obscurity" and you definitely shouldn't secure yourself based on "obscurity" because it has proven not to work. However, I don't believe that the answer to your question is that simple - I think your question is more of a "risk reduction" question but could be wrong. Quite often in the security ...


13

No, because knowledge of the method is not enough to break it. You would also need to acquire information (e.g. Decryption keys), which simply cannot be obtained by an attacker. The attacker can't figure out the source IP, or look at the data. Each Tor node only "knows" the source and destination of a block of data that it is handling. It can't open it to ...


12

Open source software is less confidential than closed source software, but that is not relevant when considering backdoors, as opposed to vulnerabilities in general which are almost always accidental. In this answer, I will only address backdoors, and not the wider issues of vulnerabilities in general (only an insignificant fraction of vulnerabilities are ...


12

It depends. If all reasonably functional alternatives are fundamentally prone to programming errors, like it is the case with browsers, it is probably a good idea to use a not-so-popular one. In particular, if your threat model does not include sophisticated adversaries that wait, observe and develop attacks specifically for your setup, using the ...


12

I have recently heard that most of the PHP code is confidential This appears to be incorrect. At the very lease, most PHP is unobfuscated and readable to anyone it's distributed to. because if attackers know your database structure or the hash function used to encrypt the passwords, there is higher chances of a breach. Also incorrect. Neither the ...


11

I think the premises that most use to differentiate between closed and open source are pretty well defined. Many of those are listed here, both have their advocates. Unsurprisingly the proponents for Closed Source are those that sell it. The proponents for Open Source have also made it a nice and tidy business (beyond a few who have taken it on as a ...


11

I'll take a crack at explaining this without technical jargon. Lets say you want to send a nasty letter to someone, but you'd rather not deliver the letter in person for fear that they might get angry with you. You can ask a courier to take the letter from your house, and deliver it to the recipient, right? That works, but has the problem that the courier ...


10

You will likely not find too many people or groups who will vouch for OSS product's security because it could put them at risk of being legally liable. While reputation is a part of a measure, it is hard to quantify and people like hard numbers. Here are some factors you could consider. Has it been independently reviewed? Ok here's your numbers. Coverity ...


10

With Open-Source software anyone can see and analyse the code, so this model actually has a lot going for it. Many eyes etc... The problem comes when you have a massive codebase, and not enough qualified, experienced eyes - things may slip through the net. However with closed-source code, you are essentially putting your trust in the developers - how do ...


10

If you can recompile the source code and have your own binary, then maybe you won't be able to get the exact same binary as the one that is distributed; but why would it matter ? At that point, you have your own binary, which necessarily matches the source code (assuming your compiler is not itself malicious): you can just ditch the binary package, and use ...


10

Yes it is possible. But it is very hard, as the whole compilation process hasn't been designed for that goal. It is often called "deterministic builds", "reproducible builds", "idempotent builds" and is a challenge. Bitcoin, Tor, and Debian, are attempting to use deterministic builds, and the technical process is described here. Admittedly the process is ...


9

Open source software is not necessarily better or more secure. Where open source has an advantage is the potential for independant security minded individuals to examine the source code and hopefully the conceptual model for a given software project. This advantage is contingent on: review by qualified individuals feedback from the reviewer to the ...


9

The basic principle of SOX (I can't speak to the Japanese version, but I'd put my bet that it carries over) is that the officers of the company must attest that they are aware of the company's action and are responsible for those actions. This is usually done by having a consultant come in and document what the company is doing. The focus of SOX is on ...


8

The key here is that with closed source code, the onus is on protecting that code - attackers may try to steal the code, reverse engineer it, or just attack it. The internal processes should be designed to identify vulnerabilities and fix them, but the numbers are quite skewed: Attackers: many Defenders: few With open source code, there is a slightly ...


8

There is already a standard method of reporting vulnerabilities to vendors. CERT is great about contacting vendors and mitigating the issue. I think that your ideas can be helpful and there is a lot of overlap with your ideas and OWASP. You should look for a local OWASP chapter in your area. If one doesn't exist, MAKE ONE!, and use it as a platform ...


7

Theoretically, to ascertain what a chip does, you break it apart and reverse-engineer it. In practice, this will be nigh impossible to do. Actually, even for software, for which you have the actual source code, you cannot guarantee that the code really always does what you believe it does (otherwise we would be able to produce bug-free code). This is not a ...


7

Source-available (SA) differs from true open-source (OS) that there is no right to fork. That means when a security flaw in a SA software gets known and the developers refuse to fix it (which doesn't have to be out of bad intentions - it could just be lack of resources), users do not have the option to fork the project and continue the project under a new ...


6

The following anecdote does not have a general value: In 1999, I took the source code for PGP (not GnuPG, still in its infancy), version 5.5, and compiled it on my machine (which was an Alpha running NetBSD, i.e. a rather "normal" Unix system). PGP's source code had been available for quite some years, and it was often touted as necessarily secure since it ...


6

Please remember the following important rule: Don't hardcode cryptographic keys or secrets in the code! This rule is not specific to open source. It is a good rule of thumb for all source code. Maybe you are wondering: where should you store secret keys, passwords, etc.? The answer: Store them in a separate configuration file, not in the source code. ...


6

Generating the private key deterministically from a password is known and works; however, it has the following drawback: anybody can then try to brute-force your password, since the public key is public. It suffices to re-run the key generation algorithm from any potential password and see if the result matches the public key. We rarely want passwords to be ...


6

Most of the time, it's only just barely safer, and sometimes it's less safe. Under what conditions can I simply download the exe(cutable?) Signed packages from major distributions are built on the Distribution's build servers. In that regard, it's almost certainly best to use the packaging system. Are there times when I should I compile the binary ...



Only top voted, non community-wiki answers of a minimum length are eligible