
Ask HN: What's the best programming language to learn for security? - patrickgv
I&#x27;m talking about all these firms that specialise in security for companies. If I wanted to work at one of these, what programming language would I need to know?<p>I assume it would be something like C++, but I don&#x27;t know.<p>On another note, how many programming languages (and what programming languages) do you think someone would need to know to have a successful career in that field?
======
ejcx
Depends on what type of security you want to get into.

General Pentesting: Python or something higher level. Lots of library and tool
usage (i.e. scapy, nping, nmap, metasploit)

Application Security: Learn frameworks more than languages. How to work inside
of Rails, Spring, ASP, PHP stuff, etc. Common security bugs that exist in
these codebases, how to fix them, and how to recognize them. It is more
important here HOW things work not how to make really big things work. There
are tools that you need to know how to use too, like Burp or some kind of HTTP
proxy.

Exploit Development/Reversing: Goes without saying you need to know C very
well. You also need to know Assembly very well and how to navigate around the
OS. How windows exploits work from the basics like finding kernel32.dll to
bypassing ASLR and other types of exploitation techniques. Fuzzing, etc. This
probably has the highest bar of entry.

Your side note, how many programming languages do you need to be successful.
The answer is a minimum of 1 if you know everything about it. You can add a
lot of value doing things like AppSec Consulting for Java if you know a ton
about securing Java frameworks.

You can email me if you have any questions. I love talking security

~~~
tptacek
I actually don't think you need to know assembly all that well to do exploit
dev and reversing. What you need is:

(a) native-level proficiency with C and the memory hierarchy that C tries to
abstract (ie: you want to understand what goes in registers, when, and why,
and how a stack frame is laid out and why)

(b) at least limited working proficiency with compiler theory, most especially
the analysis of control flow graphs

As time goes on, knowing little working-programmer details like how LEA gets
used for multiplication is getting much less important, and understanding
compiler IRs (particularly LLVM) is getting more important. Weirdly (but
awesomely), both exploit dev and reversing is becoming more and more
theoretical (predicate translations and satisfiability, symbolic execution,
&c) and less and less systemsy, and the systemsy stuff is getting larger-
scale: like, writing whole-system emulators to reverse firmware targets.

I guess my argument would be: you don't ever need to learn how to write a
decent assembly program to get to (a) and (b), and by the time you have (a)
and (b), you'll _easily_ be able to pick up whatever assembly you need as you
go.

~~~
ejcx
That's fair. I think my point with the paragraph still stands though, that
this path has the highest bar of entry. I think the demand for this type of
worker is way lower, even in the beltway.

------
tptacek
I love a question with a simple right answer:

(Ruby OR Python) AND C.

You can skip C if you don't want to do low-level work (embedded, kernels,
writing shellcode for memory corruption exploits). Only a small fraction of
security people do this kind of work. You cannot skip (Ruby OR Python), even
if you don't ever plan to do web work (which is a dumb plan anyways).

~~~
russell_h
Second this, but want to add:

You don't necessarily need to be able to sit down and bang out quality C, but
learning some C is a great way to understand how software works at a lower
level than you'll get from Python or Ruby. On the other hand you can apply
that understanding to more quickly and correctly understand what higher level
code is doing and what risks it is taking.

If you don't already have a good theoretical background, learn some C.
Something like C++ or even Rust would work for this too, but those introduce a
lot more language concepts that you don't really need.

~~~
tptacek
I think C++ and Rust are actually a bad idea here. Learn C. Don't bother with
C++ until you've got C down.

I mean, learn Rust if you want to write Rust code. But for the objective I'm
addressing with C, you need C.

~~~
noir_lord
Agreed, in addition a lot (if not most) of the low level attack surface
(drivers, kernels, web servers) are still written in C, it's still the lingua
franca (with C++ somewhat second).

------
nanofortnight
You very much have to be flexible. Most valuable would be C and assembly
knowledge (and knowledge of the low level details of both is pretty much
required).

As for tool writing, any high level language (perferably what your employer
uses). For example, if MetaSploit is used knowledge of Perl/Ruby would be
required.

Picking up multiple imperative languages is easy, though. Fortunately most
languages in the field are imperative.

Depending on the software in question, knowledge of how virtual machines
operate can also be useful.

------
cguard
First off, obviously there isn't really a clear black/white answer to this.
Secondly even security is such a broad field that it really depends on your
focus (a similar question could be what programming languages/technologies are
the best for web development, where you'd get answers ranging from classic
LAMP stack, to Node.js, python, RoR, Angular and many others, and it depends
on whether you want to do front-end, back-end, both or whatever combination).
So firstly I'd say it's important to pin-point what you are personally
interested in; I'd say that if you want to be working on some "serious"
exploits in widely used software, you are looking at C and Assembly, and C++.
Obviously for web hacking, you'd be looking more at scripting languages, both
in terms of their usages as the underlying technologies, as well as to
automate those mundane repetitive tasks, so PHP, ASP, Perl, Python, Bash
scripting etc. is something to look into. But you should also be well versed
in sys-admin tasks, things like maintenance, event logging, filesystems and
permissions... And lastly there is networking and all the issues and things
associated with it, tcp/ip stack, routing and so much more.

The thing is, working in security isn't really dependant on the programming
languages you know, either what will matter is your specialization (if you
have any), or the overall skillset that you can offer to the company (if you
can secure a web application on a shared host, but don't do anything about
file permissions and other settings on the server, either someone else needs
to do it, or the security of the webapp is pretty useless); be aware that you
will be (or should be) learning something all the time, again depending on
your interests, and at the same time you have to stay on top of news in
research and exploits, so in a way it's really tough but also very
interesting.

------
abecedarius
The E language ([http://erights.org/](http://erights.org/)) was designed to
express smart contracts back before Bitcoin was invented -- really forward-
looking and, to me, educational. You don't in the least need to know it for a
career in the field, but it changed how I think about security.

[http://erights.org/elib/capability/ode/index.html](http://erights.org/elib/capability/ode/index.html)
is probably the best quick intro.

~~~
kentonv
FWIW, Cap'n Proto ([https://capnproto.org](https://capnproto.org)) is a cross-
language network protocol based on E's design (with direct help from E's
creator, Mark Miller). So if you're interested in E-style capability-based
security but want to use a more mainstream language, consider taking a look at
Cap'n Proto.

(Also Sandstorm ([https://sandstorm.io](https://sandstorm.io)) is a server
platform implementing this model. Disclosure: I am the lead developer of both
of these projects.)

------
ecesena
Do 2 things in parallel.

Learn C, there's plenty of open source C code strictly related to security,
from OpenSSL, to OpenSSH, to the Linux kernel.

Learn full stack web programming (SQL, a language, html+js). As for the
language, PHP could be good as there's a lot of history of (in)security, but I
definitely recommend learning a framework - I like yii (yes it is), but choose
any. Studying a framework is useful to learn how much things could go wrong,
if not done properly (SQL injection, XSS injection, ...).

------
david_shaw
There are a lot of great answers on here (Python/Ruby for general scripting,
C/C++/ASM for reverse engineering, web stack technology for web application
security, etc) -- but I wanted to focus on a slightly different approach.

I've run security teams for the last six years or so, and it's surprising to
some people how _little_ programming is often involved in penetration testing
and application security assessments. If you're looking to do network and/or
(web|mobile) application security, it's often unnecessary.

That said: learning how to do some scripting is always beneficial, and clearly
understanding how code works is very important to understanding systems,
networks, and applications. My advice, though, is that if you're trying to
work in security it's probably better to learn the fundamentals of the area(s)
of security that interest you, rather than focusing on a programming language
or framework that you think will be relevant.

There are a lot of great resources out there, but shoot me an email (address
in profile) if you'd like a little more info.

Good luck!

~~~
tptacek
Programming is a hard requirement for app pentesting.

~~~
Someone
Programming, but not software engineering. For example, it can be merely a
nuisance if the tools you write leak lots of memory, acceptable to parse XML
with a regular expression, and not a problem at all if programs run entirely
within an environment you control aren't themselves secure.

~~~
tptacek
OK, but it's not merely a nuisance if you can't understand why it's unsafe to
parse XML with a regexp, and you might not grok the issue viscerally unless
you're a good programmer.

------
contingencies
There are currently 17 threads in response to this question. None have taken
the architectural angle, one that can be well introduced with the _Rule of
Least Power_ which states _Use the least powerful language possible for a
given problem. Prefer declarative languages over procedural._ Now think for
awhile about what that is actually saying...

Could it be that the heart of a secure system has little to do with process-
oriented thought, and much to do with declarative policy?

In fact, in a well designed system, that should be the case. Unfortunately,
there are bugs in all systems, so process-oriented thinking will always have a
place. But in big picture terms - the 'heart' of a security stance - you
really do need to be thinking in this way, particularly at design time, and
generally also as an attacker.

Unfortunately, a declarative (policy-driven) architecture is essentially
useless unless you ensure the system actually follows policy... for instance,
by actually generating it largely from policy. This degree of rigor is rare in
practice, but highly desirable in theory.

If you want to ensure your skills target big picture, are applicable to
building things and not just tearing them to pieces (which in the security
world often decays in to a range of puerile one-upmanship as visible at most
prominent industry events), you could consider specializing in this area. In
that case, you would do well to learn about declarative DSLs (domain-specific
languages) and learn some of the more common ones. Then, practice generating
things (documentation, functional code, application-level proxies, protocol
test suites, policy compliance test suites) from those definitions... the
generation could be done in any language, though using something simple with
lots of libraries would be smart (possibly go, ruby, python, even perl or
php).

Just thought it was worth contributing a different perspective here.

------
chmielewski
Look into python and play around with scapy... look into Perl and play around
with Metasploit... know how to implement your own Tor hidden-service keyserver
and how to make your own site use an SSL/TLS cert... before you have completed
all four of these tasks you will have a good idea of the landscape and will
have learned a lot, possibly answering your own question.

~~~
tptacek
Metasploit is Ruby. In 10 years of consulting with a progressively larger and
larger team, I'm not sure I ever saw someone use scapy. It's not that scapy is
bad, so much as that direct targeted low-level packet manipulation is kind of
a 90s problem statement.

~~~
chmielewski
Gotcha, thanks for the clarification. So then, I suppose my recommendation of
learning Metasploit and looking into Perl/CGI/PHP/javascript site security
features are certainly separate/more than one thing. My aim was to suggest
some broad "security programming" fields/projects that are easy to get started
in or get quick results with and contain enough documentation and specialty
uses that allow them to be drilled down into specifically if that part of the
landscape interests OP. Also, doing cool things with scapy is fast and easy
and learning to write your own scapy code seemed to teach me a lot about
packet security very quickly. I was assuming that if one is an autodidact, the
things I listed will keep you busy reading/learning related subject matter and
introduce you to some cool things and familiarize yourself with what's out
there while getting visible/fast results with a tool chain rather than just
learning for learning's sake. There's a certain balance between thinking and
doing; with excess of either it's easy to lose touch with reality/scope. This
is why, when people want to "learn Linux" for example, I find out what they're
interested in and point them toward some projects/packages... rather than
pointing them to general Linux documentation which often has new users feeling
like they're reading Greek without examples, or leads to eyeglaze.

------
V-2
Related: [http://techcrunch.com/2015/05/02/and-c-plus-plus-
too/](http://techcrunch.com/2015/05/02/and-c-plus-plus-too/)

 _We fail to learn. Heartbleed. GHOST. The Android 4.3 KeyStore. Etcetera,
etcetera, etcetera._

 _C was and is magnificent, in its way. But we cannot afford its gargantuan,
gaping security blind spots any more. It’s long past time to retire and
replace it with another language._

[...]

 _So please, low-level programmers of the world, I beseech you (while, to be
clear, also respecting you immensely): for your next project, try Rust rather
than C /C++. There is no longer any good reason for today’s software to be as
insecure as it is. Those old warhorses have served us well, but today they are
cavalry in an era of tanks. Let us put them out to pasture and move on._

(Personally I'm rather neutral on the issue (I don't work with low-level
languages), I just think it's good food for thought.)

~~~
wglb
This is advice useful for architects and engineers, and would be preaching to
the pen-testing choir.

It is necessary for the member of such a security company to think of the
software that they learn is first a tool used to attack other software
(Metasploit, Burp, hand-written tools such as WWMD, quick one-off, discardable
code used during a test), and secondly to develop a deep understanding of how
the software under test works.

And, as I and others have noted previously in this forum, not all of the
dramatically-reported errors are due to the low-level nature of C. Some are
glaring implementation-language independent protocol errors.

------
walterbell
There's also a language-portable state of mind.

[http://phrack.org/issues/1/1.html](http://phrack.org/issues/1/1.html)

[https://en.m.wikipedia.org/wiki/Fravia](https://en.m.wikipedia.org/wiki/Fravia)

------
sekasi
I believe comments here that programming isn't a necessity aren't really
correct. A strong programming knowledge to the point of expertise is what you
should aspire towards in a security-related career.

Language is a hard question though, there are a lot of things to consider
around what sector you want to focus on. The holy trinity seems to be Python,
Ruby and C.

ASM is probably very overlooked in general, but also a lot harder to master.
Good luck, hope you get to a point where you can take a few steps forward.
This is going to be an enormous area of interest over the next few years (much
more so than it already is) so enjoy the challenge and the money ;)

------
based2
[http://security.stackexchange.com/questions/55723/are-
there-...](http://security.stackexchange.com/questions/55723/are-there-secure-
languages)

a specialized one: [https://developer.mozilla.org/en-
US/docs/Zest](https://developer.mozilla.org/en-US/docs/Zest)

[https://answers.yahoo.com/question/index?qid=20081013174535A...](https://answers.yahoo.com/question/index?qid=20081013174535AAjvmY1)

------
Animats
Low-level stuff. C. Assembler. Firmware. Debuggers.

------
readme
You're going to want to learn more than one, but for your first programming
language I would suggest Python.

There are already a lot of people who suggested you a laundry list of
langauges: yeah, you'll need to learn them all. However, that takes years.
Don't fool yourself by thinking it doesn't. It will come with time.

------
Mandatum
You can avoid C/C++/ASM if you're specialising in web application/mobile app
security. However it's suggested you learn them anyway, given the domai8n of
experience required for security roles.

------
dsacco
_This is going to be something of a rant, but roll with it._

This is a controversial opinion, but I don't believe someone should be a
security engineer or a security consultant until they are a provably competent
software developer.

This harkens back to the analogy of writing and editing - how can you expect
to perform competent source code review from a security perspective without
having a deep understanding of programming? Even if you do not know a specific
language you're reviewing (ideally you should, though), you can at least
generalize your understanding to look for common patterns of insecure coding.

The reason why I stress this so emphatically is because, despite the fact that
you are asking which programming languages to learn, my experience with the
security industry is that most people just don't have much real programming
experience, which is absurd.

There are many firms where they will bill out their consultants at $2000+ _per
day_ and their consultants couldn't build a simple Twitter clone if they were
handed a complete spec.

I would much rather someone who can sit down and write a compiler and who has
no security experience whatsoever than someone who knows all the payloads for
XSS and how to find them manually. One of these people understands software
engineering as a discipline and where it goes wrong, and the other is
basically learning different "routes" without truly understanding everything
under the hood. I can teach the person who writes compilers to find serious
memory corruption vulnerabilities in a week. I can't teach someone who has
never programmed to find subtle mass assignment flaws in Ruby/Rails.

This is not a straw-man dichotomy. Like 'tptacek said, it is _absolutely
necessary_ for you to have a programming background if you want to work in
AppSec. And God help you if you try to work on security in firmware or
embedded systems and don't have this background.

My personal opinion is that all security engineers should be senior software
engineers. There is a good quote by Ryan McGeehan (former Director of Security
at Facebook, then Coinbase, now Hackerone) where he explains that the most
competent security engineers start out by fully mastering a particular
discipline. After they hit that point, finding vulnerabilities becomes
extremely easy. You don't need to memorize different payloads or routes or
rote methods of testing. When you have written a lot of C you will understand
a buffer overflow in a half hour (enough to really be dangerous, anyway).

Working in security without a lot of experience programming is like trying to
ski a black diamond without having mastered all the fundamentals. _Do not do
it._ It is entirely too fashionable in the industry to hire people who don't
know what they're doing, please do not add to this.

Now that my rant is over - you should learn Python and C. Ruby and Lua are
also good; most people you'll find in the industry will be doing scripting in
Python. You should know C for its rich history and deep connection with the
information security industry, and also because most of the interesting
vulnerabilities will be found in software projects written in C.

Source: A few years of security consulting, and now working as a security
engineer in FinTech.

~~~
sarciszewski
I don't think this is controversial at all. It's completely agreeable.

------
rishikant42
It is good to learn python/c/c++/java.These programming languages will help
you.

------
aikah
what kind of security? for instance web exploits can be written in any
language even in bash scripts,. Your question is way to vague to give an
accurate and pertinent answer.

------
hoodoof
It's more about how you use it than the language itself.

------
patrickgv
Thanks so much for all the advice so far!

------
secfirstmd
Python can be very useful

------
mc_hammer
its helpful to know the clients language of choice

i would say 75% of the time: asm/c/c++/sql are req languages. python may be as
well, lots of exploits are written in python b/c its fast to write for...

if you dont got that ur gonna need or bonus to have: knowledge of exploit
methods for bash/win/php/ruby/sql and other common languages

just my take on it, cheers

