Thread by @SarahJamieLewis

Some people in this thread asked what I meant by "code that was not written to be easily audited", and asked how they can write audible code.

So join me on this fine Sunday evening as I wax lyrical about writing code that is easy to audit.

https://twitter.com/SarahJamieLewis/status/1097223122405646336

First, let me make a distinction between "secure" code and "security driven" code. While the primary purpose of most audits is to "find security bugs", the main driver of that work is determining if the code is "security driven".

Mistakes happen. All the time. Even the best engineering teams on the planet sometimes screw up.

The goal of security driven design is to minimize the impact of mistakes.

There a plenty of books about security driven design, and I'm not going to dive into methodologies. But if you don't like reading then take away this:

* Fail fast, Fail often
* Never assume good intentions
* Don't over decompose security sensitive code.

That last point applies most to my critique thread - it is impossible to audit security sensitive code split across 20 different packages, references 30 different classes and interfaces, and configured at runtime via JSON.

More so, the majority of application-level security bugs happen at the intersection of code packages e.g. calling the wrong method, referencing the wrong config file etc.

Even if the isolated code is perfect, the potential for integration misuse is high.

And because this is code, we also have to think in more dimensions. What happens when someone decides to patch the system and messes up the fragile integration configuration?

Code changes, and someone auditing code is likely considering the potential of introducing future vulnerabilities in a code base is.

Code can be secure, and also fragile.

That is a vital thing to remember.

And that brings me back to the first point "Fail fast, fail often"

To many systems try to recover from errors, I've seen some systems dedicate entire packages to making bad input safe, when the correct thing to do would be to shutdown that entire flow.

On the *never assume good intentions* front: the default return value for authentication/authorization/validation/verification should be false (sometimes it should even be panic())

Most if statements in a security sensitive function should default "return false"

One of the reasons I dislike public bug bounty stunts like this election software or across cryptocurrency space is that they focus on exploitation and not systemic soundness.

Anyone can engineer a bug bounty that demonstrates minimal exploitable flaws.

Honestly enterprise-style Java is one of the worst domains for auditing security flows because everything little thing is hidden behind an interface, in an impl folder, with injected configuration.

Not to mention the verbosity of java math.

Auditors are often time limited, and if the system is hard to understand then it is by definition hard to audit (and, thus, hard to secure).

If your auditor is spending time trying to work out ground layer things like "what cryptographic parameters are you using" things are bad.

The simplest way to make your auditor happy is to not write security sensitive code. If you have to write it, ensure it is well isolated and tested from the surrounding code.

And by well-tested I don't mean "we tested it works", I mean "here is our library of bad inputs"

To bring this back around, compare the election ZKP proof code that triggered this whole thread, with this not identical, but comparable in complexity, code from the Dalek libs:

github.com/dalek-cryptogr…

Both have a lot of complexity, and both would require skill and time to audit properly - but the latter is mostly contained, each part is documented, the proof and the verification appear are together with tests etc.

The latter is far easier to audit.

Anyway, I wish the swiss election team the best of luck in ensuring that the thousands of new, highly configurable, ZKP code, written in Java, decomposed over hundreds of files, is up to the standard of securing national elections.