In other words: a maintenance nightmare, filled with security gotchas, difficult to scale, and hard to write.
So is the alternative the author describes (except for scaling). HMACs for temporary credentials are clever and simple, if you're already versed in crypto primitives. But to anyone else, they're magic security sauce: "But why can't I just use MD5? Wait, no, that's broken somehow - what about SHA? What do I include in the HMAC? Do I have to use a new key every time?"
The solution trades implementation complexity for arcane knowledge. The author is so confident that his solution is superior because he already has that arcane knowledge.
That said, a well-implemented HMAC-based password reset flow is probably more bulletproof than a well-implemented DB-based flow. So if you're implementing AWS, go for HMAC. If you're implementing a blog, go with whatever you feel like. Just implement it well.
I don't really consider HMACs to be particularly arcane knowledge. They're easy to generate in any language and straightforward to work with.
While I consider myself to be a pretty good developer, I'm definitely not well-versed in crypto and math isn't my strongest skill. Despite that, I've had no problem using crypto for several of the obvious use cases (ex. password resets).
You shouldn't implement HMAC yourself, of course. I repeat: you should not do this.
However, if you read Wikipedia on HMAC, you'll find that HMAC is in fact probably one of the easier crypto primitives to understand and implement (as a TOY project). As long as you do the padding thing exactly as specified.
That's a common misconception. While designing your own cipher or implementing AES is a terrible idea, it's fairly easy to produce broken systems with strong primitives like AES or HMAC, and the brokenness would not have anything to do with the implementation of those primitives.
Are you arguing in favor of developer laziness? An average programmer should be able to understand the use cases for HMAC within a couple hours or so, given nothing but the Wikipedia page and an IDE or REPL, and knowing about MACs might prevent him from cooking up all manner of broken security protocols in the future.
Well, I'm certainly not in favor of name-calling like that. HMACs don't provide any greater provable security guarantees than a database row in this scenario, so it comes down to implementation. HMACs are harder if you're not familiar with them, but almost everyone is familiar with a database. On the other hand, HMACs make the security of the overall system easier to verify, assuming HMACs are used correctly - but it's harder for newcomers to use them correctly.
I'm saying that in this scenario, it doesn't make much of a difference which system is used. So the author shouldn't be quite so forceful in telling people to use a crypto primitive outside of their comfort zone for minimal benefit. I'd rather use a system written by someone confident in their DB solution, rather than someone who learned their HMAC solution in a couple of hours on Wikipedia.
How confident should the average developer be that they are able to create a secure crypto implementation in a couple of hours, based on some possibly-dubious advice they read in Wikipedia? I would argue that they shouldn't be very confident in this.
The first thing you learn about crypto is that it's harder than it looks and best left to experts. Knowing when it's actually okay is difficult. At the very least, I'd expect that they ask for a review from someone who does know what they're doing, and how many developers who don't work at a big Internet company have a spare security expert handy?
Nobody is suggesting the developer should roll their own crypto. Pretty much every language out there have mature packages for HMAC's. What you need to know are a few basic things about how to use them to verify the integrity of a message.
This is a valid and very real concern and one of the reasons that a lot of companies want to hire CS graduates as developers. They have an idea of what this is, and any reasonable CS grad would know where to look for this, if they aren't already well versed in the crypto world.
So is the alternative the author describes (except for scaling). HMACs for temporary credentials are clever and simple, if you're already versed in crypto primitives. But to anyone else, they're magic security sauce: "But why can't I just use MD5? Wait, no, that's broken somehow - what about SHA? What do I include in the HMAC? Do I have to use a new key every time?"
The solution trades implementation complexity for arcane knowledge. The author is so confident that his solution is superior because he already has that arcane knowledge.
That said, a well-implemented HMAC-based password reset flow is probably more bulletproof than a well-implemented DB-based flow. So if you're implementing AWS, go for HMAC. If you're implementing a blog, go with whatever you feel like. Just implement it well.