Tag Info

Hot answers tagged

46

Actually most languages are "secure" with regards of 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++), ...


44

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


42

I would say a great way to learn is for her to break the applications she has already written. Assuming she is writing web applications, point her towards the OWASP Top 10. Have her see if she can find any of those flaws in her own code. There is no better way to learn about security concepts than actually seeing it happen on your own code. Once a flaw has ...


23

Languages are useful for doing things. What type of things it's suitable for completely depends on the type of language, the frameworks available for it, what OSes have interpreters / compilers for it, etc. Let's look at the ones you've mentioned: Perl Scripting language General purpose Available on most *nix OSes since the '90s. Great for quick hacks ...


16

If you consider the bug as reading out of bounds of the current structure, than this would probably have been prevented in other languages, because one does not have unbound access to memory and would need to implement these things differently. But I'd rather would classify this bug as missing validation of user input, e.g. it believes that the size sent in ...


16

Actually none of these languages would have prevented the bug, but they would have lessened the consequences. OpenSSL's code is doing something which, from the abstract machine point of view, is nonsensical: it reads more bytes from a buffer than there actually are in a buffer. With C, the read still "works" and returns whatever bytes lingered after the ...


14

I'm going to take the position that may get me flambéed... The problem I see, is that secure programming is taught as an add on. Best practices should be taught from the beginning (including security). The lie people are taught is that practice makes prefect. The truth is practice makes permanent. So if you are doing it wrong, you have to unlearn what ...


12

While I agree in principle with Everett, there is another point of view. The point of a lesson is to learn a concept, which can then be further built on. This lessens the slope of the learning curve. Teaching too much too fast is overwhelming; when faced with an onslaught of information, most brains "leak". It's great to say "Secure coding practices should ...


12

For studying malware, you will be doing a lot of reverse engineering to understand what it does as well as a lot of analyzing systems for weaknesses to try to predict which ways malware development might go. A Computer Science degree will be critical and you will want to focus on decompiling and low level development (assembly and C/C++). Understanding ...


11

Half of cryptography is about the raw algorithms, like SHA-256 or AES. The other half is about assembling these algorithms into complete protocols like, for instance, SSL/TLS; designing a secure protocol is not easier than building a secure algorithm. When a developer meddles with an algorithm, then, by definition, he is in the process of creating his own ...


11

My take-aways would be: Never roll your own cryptography if you can avoid it. (Sometimes you'll have to for tailor-made solutions / embedded platforms.) If you have to roll your own, always build on known working protocols. Don't rely on hiding your implementation. Obfuscation is a valid layer of defense in depth, but should only be used to add to existing ...


11

Most software is written in languages that the developer knows how to use, and for security-related software, that's not a bad thing -- provided that the developer actually knows his language of choice, down to the fine details, and I may argue that this is not the case with C and C++ (a vast majority of developers who believe they know C or C++ are actually ...


10

Here is a great answer I found on a stack overflow question of similar context by @tqbf: (I copied this answer here, because I believe it gives valid reasons for which they may be prefered, so it might be useful to future readers) You probably want Ruby, because it's the native language for Metasploit, which is the de facto standard open source ...


9

Choice of programming language for cryptography depends on a lot of parameters, including (but not limited to) the following: If the goal is to support research (e.g. to try variations) then the language should be one that is most mastered by whomever will do the research. For instance, people who want to "investigate crypto" and feel most comfortable with ...


8

Much like other aspects of a real education (perhaps this should be more on Parenting.SE...), I think it comes back to critical thinking. My daughter is also taking some college CS courses, and I'm helping her work through them. However, I do not spoonfeed her the information, she needs to work for it. In many cases, I explain something very wrong to ...


8

Generally speaking, to be a good pentester you have to master some of the skills that are required to be a good programmer. Solid development experience about possible programming mistakes is very helpful, because a lot of pentesting is about finding corner cases that the programmer did not think of -- i.e., bugs. This goes both way: a good developer should ...


8

Being able to process strings of arbitrary length without leaking information on their length seems to be very hard (i.e. I don't see how to do it) because of caches. A very long string, by definition, will take a lot of room, and thus reading the string will incur interaction with the caches. Accessing the string from RAM will trigger cache misses, and also ...


7

Not the best answer, but I'd say developers need to learn enough to make good decisions with respect to the risk to their project. I have seen that any project needs someone who knows enough about the entire system to be able to: Diagnose and fix cases where parts won't connect - increases with the number of diverse systems you try to connect together. ...


7

Last night I finished an online course that is offered by Stanford University's Center for Professional Development. Video lectures were by Dan Boneh, a prominent cryptographer and professor at Stanford. He said something that stood out to me that I wanted to share with you, which was: Don't try to implement your own cryptographic protocols (as you've ...


7

Actually putting a class member on public or private has nothing to do with security. This answer on stackoverflow covers it quite well: What are public, private and protected in object oriented programming? Also note that there are languages like Python where there is just a convention to start private methods with an underscore. However every programmer ...


7

Degree-wise, I'd recommend Computer Science with a strong grounding in code development - the average software engineering classes, with extra effort in lower level languages that touch the system more intimately (C,C++, assembly) and compiler theory. As an add on - ways of breaking through higher level web based technologies is also becoming a trend - so ...


7

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there already is a standalone TLS package, crypto/tls in Go that does not depend on any outside library. Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the ...


7

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


6

Libraries, Time to write Code, cross-platform compatibility are key here. I found that using Python I was able to come up with Proof-of-concept exploits in a very short amount of time with minimum lines of code. This is possible because of the extensive standard library and additional libraries that you can download as well. I believe that is python's ...


6

You can write insecure software in any language. C and C++ might make it easy to make a critical mistake, especially to inexperienced programmers... but ... even as the most experienced and careful programmer you would have no control over a security problem that resides within the complexity of a high level language. With C and C++ you got a lot of ...


6

Unfortunately, the bug would not have been prevented, because OpenSSL uses its own memory allocator, rather than the one provided by the system. The buffer from which the infamous heartbeat data is read is allocated by a function called freelist_extract in ssl/s3_both.c. This function, by default, manages OpenSSL's own list of used/unused memory, and does ...


5

To really understand IT security (and, more generally, computers), you will have to know how things go inside, so, sooner or later, you will have to learn assembly for one or two architectures (preferably more than two). The low-level exploit codes (e.g. for buffer overflows) don't make sense unless you know assembly. Then move on to C, which is very ...


5

I think that ultimately it comes down to trying to figure out at what point the security education doesn't obfuscate the point of the lesson. Lesson assignments are usually simplified problems designed to expose a particular problem and show how to solve that particular problem. I think the more ideal way to approach it is to start out with having her do ...


5

If developers shouldn't use cryptography libraries, then perhaps they shouldn't be available to developers. Given that they are, I simply must assume, as a developer, that I should be able to use them. .NET has many built-in cryptographic algorithms, both in fully "managed" code and as wrappers to the CryptoServiceProviders in the MFCs. Java has a few of ...


5

I have zero knowledge in these fields, but the mentioned programming languages all enable rapid programming, i.e. one could try out a much larger number of different ideas in a given time frame than with the more runtime-efficient but inefficient for programming (and debugging) programming languages like C etc. That might be a point.



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