166

You can know whether some software does only what it announces in the same way that you can know whether the food they serve you at restaurants is poisoned or not. In plain words, you cannot, but Society has come up with various schemes to cope with the issue: You can listen to friends and critics to know if the food at a given restaurant has good ...


141

The way I see it, not storing passwords in Git (or other version control) is a convention. I suppose one could decide not to enforce it with various results, but here's why this is generally frowned upon: Git makes it painful to remove passwords from source code history, which might give people a false idea that the password was already removed in the ...


116

It depends on what is meant by "secure source code analysis." One can do anything one pleases. The issue, I presume, is when someone else has asked for something called "secure source code analysis," and one wonders why one is not qualified for it. In many cases, such analysis must be done by a Subject Matter Expert (SME). In the final product, a SME ...


92

First, the non-security reason: Password Change Workflow Passwords change independently of a software application code. If a DBA changes a database password, does it make sense for developers to have to update the code, get a new build and release to production, and try to time it all? Passwords are a runtime configuration artifact, not development ...


84

A malicious hosting provider can do a lot more than simply steal your code. They can modify it to introduce backdoors, they can steal your clients' data, and ruin your whole business. Trust must exist between you and the host. About the source code. If the attacker is trying to gain access to your source code, they will gain access to your source code, ...


84

In any sanely managed company, a developer usually gets full access to the sourcecode of any project they work on. The reason is that the benefits of releasing parts of the code on a strict need-to-know basis isn't worth the bureaucratic hassle and the huge work impairment it creates for the developers. Developers can't work without seeing the whole ...


66

The important thing is maintenance. Regardless of whether you reused existing code or wrote your own, you will achieve decent security only if there is someone, somewhere, who understands the code and is able to keep it afloat with regards to, say, evolution of compilers and platforms. Having code without bugs is best, but in practice you must rely on the ...


62

First off, I want to say that just because a company is big doesn't mean their security will be any better. That said, I'll mention that having done security work in a large number of Fortune 500 companies, including lots of name-brands most people are familiar with, I'll say that currently 60-70% of them don't do as much as you'd think they should do. Some ...


49

There are a number of different techniques, depending on the skill level of the malware author: Embedded metadata - compiled programs can contain details about their authors. This is most commonly seen in legitimate programs, and shows in the details screen if you look in Windows properties. Attackers who are out for fame might well put identifying details ...


47

When the private key is nothing more than a test fixture used to test some process requiring a private key and where the private key is not actually used to secure any system. In some cases it can be appropriate to commit an encrypted key. For example if the repository is public/open source but a Continuous Integration system requires access to that file - ...


43

This is taken from one of my questions on Stack Overflow: Which $_SERVER variables are safe? Server controlled These variables are set by the server environment and depend entirely on the server configuration. 'GATEWAY_INTERFACE' 'SERVER_ADDR' 'SERVER_SOFTWARE' 'DOCUMENT_ROOT' 'SERVER_ADMIN' 'SERVER_SIGNATURE' Partly server controlled These variables ...


41

Javascript code executes on the client browser, so the client browser sees the code, and every user can obtain it. At best you can obfuscate the code so as to (try to) hide its meaning and behaviour. Obfuscation will not deter motivated attackers (it will just makes them a bit angrier), so it would be quite unwise to use it as foundation for your security ...


38

Well, this calls for three comments: You cannot protect secrets with code obfuscation. Not really. Code obfuscation somehow works against unmotivated attackers, but it is not strong. If there is commercial value in breaking through it, then it will happen. If you don't trust your hosting service then look for another hosting service. If the secrecy of your ...


38

Even more so. Security code is tricky. Cryptography code is downright hard, even if you are a trained cryptographer - and impossible to get right, if you are not. If there are so many critical bugs in so many big important software packages and companies - what makes you think* you would be able to do a better job? * Unless of course this is your ...


38

In general mixing code and secret configuration (passwords, keys etc) in the same respository is a bad idea because generally a lot more people need (or at least would benefit from) access to the code than need access to any given secret. Also the common workflow with VCS systems is to create lots of copies. That doesn't mean you can't put secret ...


29

No, it isn’t worth it. Nobody wants to steal your code. A thousand million SaaS products have been launched by individuals and companies using third-party hosting of some description or another, and roughly none of them have found themselves to be competing against themselves after having the code for their products stolen by their hosts. So, should you ...


29

Disclaimer: I work for a very big company that does a good job in this area, but my answer is my own personal opinion and is not indicative of my employer's position or policies. First of all, how to protect code from being leaked: Network Security: This is the obvious one -- if Chinese hackers get credentials into your internal systems, they'll go for ...


28

You can use source code as password. However I'd strongly recommend against using source code as a passphrase. The reason for this is entropy. Passwords / passwphrases need to provide lots of entropy (100 bits+) and programming languages usually pose severe constraints on the formulation of instruction thus resulting in less entropy per character than even ...


27

I think you need to be a good programmer to be successful, so I'd recommend becoming one. There may be lots of things that your toolkit / scanner misses. I honestly don't recommend relying completely on tools scan your code for you, as exploits change constantly, and someone may have coded in a way where the scanner can't detect the vulnerabilities. The ...


26

There is no defined blueprint on what is the best language to learn. Therefor I would like to mention two good alternatives that I (and many otheres) think is a good languages to learn in computer security. LUA Explanation of Lua from wikipedia: Lua is a lightweight multi-paradigm programming language designed as a scripting language with "extensible ...


26

There's nothing wrong with deploying from a git repo, in fact it's a pretty common practice and as you say a lot less prone to errors than copying files over ftp or rsync. Given the information you've provided I'd note the following points: Don't just pull in the latest master. Production should be deployed from a release tag. Use git flow or similar to ...


26

Matthew's answer was excellent. There are a few other ways as well. Not a whole lot of malware authors are all that bright. For example, you can open a lot of executables in notepad and look for string data. I've seen countless authors who simply put their email address/server name, username, and passwords inside the programs in a string, and it literally ...


24

I think the operative word in the question here is "afraid." The aversion is based on fear, not fact. The reality is, the threat model isn't particularly realistic. Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's ...


24

It's always important to keep in mind that suggestions do have to be tailored to fit your use-case. Security safeguards taken by, say, the NSA to protect all the zero-days they keep around for a rainy day should be much more stringent than security safeguards taken to protect up-votes on a cat-picture-posting site. On one extreme, I can think of an example ...


23

You can't, at least not with 100% accuracy. Speaking as a programmer, it's very easy to code in whatever I want, and it's not necessarily just what's advertised. Not all unexpected activity, however, is malicious. I'm assuming you're worried more about malicious activity. Even that is not 100% possible to detect all the time, but there's hope. You can ...


23

Short answer: you can't. You can't never protect a password that you are distributing. You might hide it between some strings and use other operations to "cover" the password but, in the end you will have to put it all together to make your function to operate. And here is where the cracker is going to take it. There is no easy way to solve this problem ...


22

There are automated and manual approaches. For automated, you could start with lgtm - a free static code analyser for open source projects and then move to more complex SAST solutions. For manual - you could build a threat model of your app and run it through OWASP ASVS checklist starting from it's most critical parts. If there is file deletion in your ...


21

Like most password generation algorithms, this one relies on security through obscurity. As long as nobody suspects that you use this method, nobody will use a cracking tool which tries random valid source code snippets and the rule of strength = possible_characters ^ number_of_characters will stay valid. But as soon as someone suspects that you might be ...


20

Compilation is a mostly one-way operation, and it is not deterministic, at least not in a robust way. You could recompile the source code and see if it yields the same binary. However, the exact binary can vary depending on a lot of parameters, including the compilation options and the exact version of the used compiler. Moreover, some compilers embed some "...


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