Tag Info

Hot answers tagged

39

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 ...


26

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 ...


17

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 ...


13

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 ...


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 ...


12

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 ...


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

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 ...


10

I think the easiest, simplest take on this is a software engineering one. The argument usually follows: open source software is more secure because you can see the source! Do you have the software engineering knowledge to understand the kernel top down? Sure, you can look at such a driver, but do you have a complete knowledge of what is going on to really ...


9

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 ...


9

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 ...


8

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 ...


8

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 ...


8

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

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 ...


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 ...


7

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 ...


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 ...


5

The developer of the application can check, if they wish, simply by downloading and installing the application themselves and confirming that what they get matches what they uploaded. Random users of the markets cannot check for themselves that applications they download have not been modified by the app market. But we can probably count on developers to ...


5

Most open source vendors (i.e. businesses and people that sell open source software in some capacity) make money through support contracts. The obvious examples are Red Hat, Novell, IBM, etc. So even if a support contract is required, open source is still very much fair game.


5

In general, the consensuses within the security community is that disclosing security practices (aka, transparency) leads to improved security. Transparency has many benefits: It gives you motivation to do security right. Sometimes doing the right thing for security is annoying or costly, and having no one to account to makes it tempting to not do it the ...


5

Let me first state that I do not know any case where only the precompiled executable file of a FOSS project contains malicious code. So if you are looking for concrete examples, this answer probably isn't for you. The biggest advantage of compiling the code yourself is the ability to read through said code and determine what the code actually does. This is ...


5

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 ...


4

I like @this.josh's answer where he says Open Source is not automatically better or more secure. It's the development process and the QA that matters most, the rest is a matter of personal preference. Here are a few thoughts that come to mind when I consider using IE that was created with a proprietary development process One year after IE6 browser was ...


4

As to the security of open source systems I prefer to consider analogous physical world examples such as a door lock over the many eyes argument as many eyes have missed vulnerabilities for years (e.g. bind). The details of all front door locks are well known and understood but that knowledge does little to lessen its security. The security of that lock ...


4

As far as I can tell, this is a bogus bug report. I think the Drupal team is 100% in the right to dismiss and contest this "bug report". None of the alleged "vulnerabilities" seem like vulnerabilities to me. Just claiming that something is a vulnerabilities doesn't necessarily make it so. The reporter alleges a number of problems: Allegation: if the ...


4

If you want to do log analysis in general you can use Splunk or something alike and just introduce all logs. You just have to create a query for your different files (I suggest putting them in one index). After that you can just create a timegraph and and piecharts to see when, where and how much people have tried to log in. It's not opensource though. Only ...


4

Primarily, three philosophies are followed in the industry regarding security vulnerabilities: Full Disclosure No disclosure Responsible Disclosure In full disclosure the security researcher who discover vulnerabilities openly announce the details of the vulnerability and in most cases a PoC of the exploit is also provided with the disclosure ...


3

A similar question was asked in Open Source and how it works for secure projects? As this is really an integration/deployment issue, you might consider using a lookup function for sensitive data. By using keywords to identify your data and keeping separate tables in development, staging and production, you can still run tests against this part of the code, ...



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