Tag Info

Hot answers tagged

43

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++), ...


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


42

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


19

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


15

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


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


12

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


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


10

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


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

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


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


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

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

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

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

All current (meaning still updated) programming languages are designed to have as few inherent security flaws as possible, but at the end of the day it's (almost always) the programmer who is responsible for security flaws, not the language he's using. EDIT: As @DCKing pointed out, not all languages are equal, and I'm not saying it's a good idea to pick one ...


6

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


6

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


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

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

There are limited, specific situations where field visibility has an impact. I am talking about Java applets. An unsigned Java applet can only do limited system interactions (no access to local files, no connection to external servers except the one which served the applet code, and so on). These restrictions are enforced through a complex framework of ...


5

Malware analysis is one of the IT fields in which you don't need a previous job for show your experience. You can investigate about current malware and show your research to the world using the appropriate mean. It is like penetration test for example. If you are able to find vulnerabilities on recognized sites and get your CVE number, when applying for a ...


5

As a fundamental, try programming -- in particular low-level stuff like assembly and C, because everything with computer is much clearer when you understand what goes on under the cover. Not that you would actually use a lot of assembly or C afterwards; it is for its enlightening value.


5

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



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