If you spend any time writing code to talk to a database from an object-oriented language, you will come across the notion of an object-relational impedance mismatch. This is the idea that there are fundamental differences between the data models of relational databases and object-oriented programming languages that make it difficult to map between the two. This idea has spawned a large number of object-relational mapping (ORM) tools that attempt to bridge the divide. In this post, I’ll argue that while there are many practical differences between SQL and typical OO languages, there is no fundamental disagreement between the two – so long as we adopt an appropriate logical view of objects.
Category: General
Re-evaluating Searle’s arguments against machine consciousness
Like many students of artificial intelligence, I have long viewed John Searle’s Chinese Room argument with slight annoyance. It seems so obviously wrong headed and yet it persists. So I was pleasantly surprised to find myself re-evaluating my interpretation of the argument after watching some old videos of Searle. This is not to say that I suddenly believe it is a good argument, but I now think I understand a little better why Searle makes it.
Continue reading “Re-evaluating Searle’s arguments against machine consciousness”
API Security in Action now in early access
As some of you may already know, I have been working on a book on API security for Manning in my spare time: API Security in Action. The book has now reach a point where the publisher are happy for it to go into early-access release (MEAP as they call it), so you can now pre-order and download the first 3 chapters on their website. Use discount code fccmadden to get 37% off when ordering.
The book covers the basics of securing remotely accessible APIs (REST) taking a ground-up approach, and then moves on in the later chapters to look at the specifics of securing microservice APIs in Kubernetes and even APIs for the Internet of Things (IoT). It covers lots of things you’d expect, like JSON Web Tokens and OAuth 2, and some things you perhaps wouldn’t like Waterken-style capability URLs and Macaroons. I’ve also taken an opinionated approach, which will come as no surprise to anybody who knows me. JWT is covered because its an important technology, but that doesn’t mean it gets a free pass. I’ve tried to separate the good parts from the bad, and warn you away from the real foot-guns.
The principle I’ve followed so far is that good practical advice (the “in Action” part) requires having a good understanding of how things actually work and what security properties each component provides. So rather than just throwing together a JWT library and an API gateway and showing a few deployment patterns, you’ll learn some of the deeper principles involved first. I start off with some basic secure development techniques and common attacks against REST APIs. We then look at the basic security controls of authentication, rate-limiting, access control, and audit logging. You’ll build primitive (but secure) versions of all these mechanisms from scratch before moving on to look at more fully-featured alternatives as the book progresses.
I hope you take a look. If you do, please leave feedback (good or bad) in the forum or email me personally. It’s been a much harder process writing it than I originally expected, trying to balance the desire to teach everything with a need to keep it simple enough to engage readers. Hopefully I’ve struck the right balance, but let me know either way. And of course, if you spot anything outright wrong then let me know about that too so I can fix it.
Why you really can parse HTML (and anything else) with regular expressions
There is a common story that has played out many times in the history of computer science. A software engineer learns regular expressions for the first time, feels like a god, and then immediately over-applies them to situations they are not great at, like parsing HTML. What then usually happens is that a more experienced developer patiently explains why HTML cannot be parsed with regular expressions, because HTML is (at least) a context-free language, and you should use a proper HTML parser instead. In this post, I’ll explain why the advice is right, but the reasoning is wrong.
Note: in this post, I am talking about regular expressions as defined in theory, not the heavily extended regexes of Perl etc.
Continue reading “Why you really can parse HTML (and anything else) with regular expressions”
Simplifying JOSE
Hot on the heels of my dives into authenticated encryption and key-driven cryptographic agility, I thought I’d lay out a sketch of what I think a simpler core JOSE/JWT spec might look like. We’ll take in misuse-resistant crypto and Macaroons along the way. And cats. But first, a brief diversion into JSON.
Public key authenticated encryption and why you want it (Part III)
In Part I, we saw that authenticated encryption is usually the security goal you want in both the symmetric and public key settings. In Part II, we then looked at some ways of achieving public key authenticated encryption (PKAE), and discovered that it is not straightforward to build from separate signing and encryption methods, but it is relatively simple for Diffie-Hellman. In this final part, we will look at how existing standards approach the problem and how they could be improved.
Continue reading “Public key authenticated encryption and why you want it (Part III)”
A small tweak to checked exceptions
Almost everyone hates Java’s checked exceptions. Even those that still use them will admit that they lead to a lot of boilerplate. Everyone has code along the following lines: Continue reading “A small tweak to checked exceptions”
Moving away from UUIDs
If you need an unguessable random string (for a session cookie or access token, for example), it can be tempting to reach for a random UUID, which looks like this:
88cf3e49-e28e-4c0e-b95f-6a68a785a89d
This is a 128-bit value formatted as 36 hexadecimal digits separated by hyphens. In Java and most other programming languages, these are very simple to generate:
import java.util.UUID; String id = UUID.randomUUID().toString();
Under the hood this uses a cryptographically secure pseudorandom number generator (CSPRNG), so the IDs generated are pretty unique. However, there are some downsides to using random UUIDs that make them less useful than they first appear. In this note I will describe them and what I suggest using instead.
Comments turned off
I’m seeing a large spike in attempted comment spam, so I’ve turned off all commenting for now.
So how *do* you validate (NIST) ECDH public keys?
Updated 20th July 2017 to clarify notation for the point of infinity. A previous version used the symbol 0 (zero) rather than O, which may have been confusing.
Updated 28th May 2020: in step 4 of the full validation check, n is the order of the prime sub-group defined by the generator point G, not the order of the curve itself. This is critical for security if you are performing this check because small-order points will satisfy the order of the curve (which is h * n), but not the order of G.
In the wake of the recent critical security vulnerabilities in some JOSE/JWT libraries around ECDH public key validation, a number of implementations scrambled to implement specific validation of public keys to eliminate these attacks. But how do we know whether these checks are sufficient? Is there any guidance on what checks should be performed? The answer is yes, but it can be a bit hard tracking down exactly what validation needs to be done in which cases. For modern elliptic curve schemes like X25519 and Ed25519, there is some debate over whether validation should be performed at all in the basic primitive implementations, as the curve eliminates some of the issues while high-level protocols can be designed to eliminate others. However, for the NIST standard curves used in JOSE, the question is more clear cut: it is absolutely critical that public keys are correctly validated, as evidenced by the linked security alert.
Continue reading “So how *do* you validate (NIST) ECDH public keys?”
Neil Madden 