86

While Kyle Fennell's answer is very good, I would like to offer a reason as to why it is recommended for internal applications to be designed securely. A large number of attacks involve internal actors There are many different versions of this factoid. "50% of all successful attacks begin internally", "Two thirds of all data breaches involve internal ...


80

I'm currently writing my own little password manager That's your first mistake. Something this complex has many subtle pitfalls that even experts sometimes fall into, without plenty of experience in this area you don't have a chance making something even close to secure. stores the key in an SHA256 hash Uh oh... This doesn't necessarily indicate you're ...


77

From a developer's perspective, the first two points you have are not very relevant. Stored and Reflected XSS have the same mitigation: properly escape things you output according to their context. Layers of defense will likely only be viewed as an excuse for poorly implementing this mitigation: "The WAF will catch it for me." Instead, focus on these code ...


70

Yes that is a good idea to overwrite then delete/release the value. Do not assume that all you have to do is "overwrite the data" or let it fall out of scope for the GC to handle, because each language interacts with the hardware differently. When securing a variable you might need to think about: encryption (in case of memory dumps or page caching) ...


69

Unfortunately, you are the ones responsible of seeing if your threat model is justified or not. Therefore, we cannot simply give a definite "yes" whether we see using the platform as a security threat or not. However, there are two points that I'd like to expand on: You seem to be extremely worried about the source code containing vulnerabilities and that ...


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


56

Actually most languages are "secure" with regard to buffer overflows. What it takes for a language to be "secure" in that respect is the conjunction of: strict types, systematic array bound checks, and automatic memory management (a "garbage collector"). See this answer for details. A few old languages are not "secure" in that sense, notably C (and C++), ...


55

The Ada language is designed to prevent common programming errors as much as possible and is used in critical systems where a system bug might have catastrophic consequences. A few examples where Ada goes beyond the typical built-in security provided by other modern languages: Integer range type allows specifying an allowed range for an integer. Any value ...


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


34

Storing a value that isn't used again? Seems like something that would be optimized out, regardless of any benefit it might provide. Also, you may not actually overwrite the data in memory depending upon how the language itself works. For example, in a language using a garbage collector, it wouldn't be removed immediately (and this is assuming you didn't ...


25

Yes, internal applications should be secured with due diligence and yes OWASP can be a good guide for securing your application. Also look over Microsoft's Security Development Lifecycle (SDL), It is a security assurance process that is focused on software development. Why? Defense in depth. An attacker could breach the network defenses. Put more layers of ...


23

@Simon has already provided a fantastic answer, but I'd like to add in response to this point: there is no possible real warranty that staff from Gitlab cannot investigate the source and find security holes or some sensitive configuration Configuration does not belong in the repository. Configuration should be combined with code at deployment, not ...


19

What are some concepts you think are indispensable to get across to them? Difference between Reflected and stored -- I don't really care. Layers of defense -- Yes. Many developers do not understand "defense in depth". Assume that every other mitigation has failed and your code is the last thing that is standing between the attacker and the vulnerable ...


19

First let me disclose that I work for 1Password, a password manager, and although it may seem self-serving, I have to add my voice to those telling you that writing a secure password manager is harder than it may first appear. On the other hand, it is good that you are trying and asking about it in public. This is a good way to learn that it is harder than ...


18

You need a threat model You should not even begin to think about overwriting security variables until you have a threat model describing what sorts of hacks you are trying to prevent. Security always comes at a cost. In this case, the cost is the development cost of teaching developers to maintain all of this extra code to secure the data. This cost ...


15

Most programming languages higher level than C are much more secure when it comes to programming errors like Heartbleed's. Examples that primarily compile to machine code include D, Rust and Ada. It's not interesting to talk about just memory safety, in my opinion. Here is a list of additional programming language features that (I think) make it much harder ...


15

Interesting question! I'd like to answer it more from probability standpoint, than from Best Current Practices standpoint. While Thomas and others provide great answers, I do not think they touch on the core question - which is "is unique (or less used) code more resilient in practice than popular code". Note that I've deliberately not used "more secure ...


14

If we want to look for rational reasons not to use scrypt right now, we can find mostly these three: It is unclear whether a "memory-hard" function is what is needed, with the parameter configurations supported by scrypt. Scrypt was initially designed to support local encryption, particularly whole-system encryption. This means that the password must be ...


14

Yes, it is good practice security-wise to overwrite data that is particularly sensitive when the data is no longer necessary, i.e. as part of an object destructor (either an explicit destructor provided by the language or an action that the program takes before deallocating the object). It is even good practice to overwrite data that isn't in itself ...


13

What happens here is that the foo() function uses a so-called old-style declaration, i.e. as things were done in C before the first normalization (aka "ANSI C" from 1989). In pre-ANSI C, a function bar() which takes two arguments of types int and char * would be defined that way: void bar() int i; char *p; { /* do some stuff */ } and it would ...


12

The simple answer is: don't roll your own security. There are two parts to this. Algorithm and implementation. As for the algorithm, creating your own encryption algorithm is horrendous. Even if you are versed in the field of cryptography, you still aren't in a position to create a new algorithm. Unless you have a team of experts in the field working on ...


11

You're right that a cookie is a bad idea, but the approach itself is misguided. The problem with these kinds of hard limits is that they make it easy for an attacker to create a DoS condition for the legitimate user, simply by putting in 10 incorrect email addresses. Even if you time-delay the attempts, the attacker can simply send a request every time the ...


10

In many programming languages, initialization of local variables is forced, or the engine will flatly refuse to read uninitialized data. Even in languages where you can read uninitialized variables and thus get a copy of what remained in RAM at that emplacement, you cannot count on it to be "random"; it will have a tendency to contain always the same value, ...


10

This is a vulnerability. If users have JavaScript disabled, their passwords will not be changed to dots, and thus they are vulnerable to shoulder surfing. As user @Question Overflow points out in their comment to your question, clicking outside the field would also display the password. Which means a co-worker could see the user's password by taking their ...


9

You covered most of the basics. To extend a bit on your points (some of these will seem obvious to most readers here, but may not necessarily be obvious to all developers): XSS can happen via GET and POST. XSS is also an issue in admin backends. DOM based XSS exists. Browser defenses exist, but should not be relied upon. The same goes for WAFs and server ...


8

You cannot. If the application has to know the password, there is no way to store it safely, unless you ask a user at run time for a master password. Because if the app can get it, an attacker could do the same either directly if it is stored in clear text or with reverse engeneering if it has been obfuscated. The real question to ask is why an application ...


8

The problem is that the server cannot store a hash of the fingerprint, because the fingerprint can come with slight variations that would give a completely different hash. And if your fingerprint is compromised (either by taking it on a object you have touched or directly from the server) you can hardly change it - ok you can use up to ten fingers. But a ...


8

Which practice is better? It depends on your needs. There is no "secure" or "not secure", only "secure enough for my needs". Which is better depends on your particular risk/benefit tradeoff willingness. As such, this is rarely an answerable question in a security context. Does returning specific internal error codes can help attackers in their ...


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