Here’s the BrowserID demo at the Mozilla All-Hands last week:

Given my prior work on email-based authentication (EmID, Lightweight Email Signatures, BeamAuth), you might think BrowserID was my brainchild. In fact, it really wasn’t. And, in a testament to the shrinking impact of academic publication venues, none of the BrowserID team had ever heard of my work on email-based authentication before I arrived at Mozila, even though Mozilla folks are quite well versed in the state of the art. But who cares: when I found out about the ongoing work and how we agreed on just about every design principle, I was incredibly excited. And when I realized the fantastic work the team had already done on defining a scaffolding and adoption path for the technology, I was super impressed.

BrowserID started with the Verified Email Protocol, designed by Mike Hanson and Dan Mills, who came up with the approach after extensive exploration of web-based identity approaches over the last two years. It’s a simple idea: users can prove to web sites that they own a particular email address. That’s how they register, and that’s how they log back in the next time they visit the site. BrowserID, the code and site, was initially bootstrapped by Lloyd Hilaiel and Mike Hanson. Shane Tomlinson and I joined the team in June. We now also have an awesome UX design team (Bryan and Andy) and the team continues to grow (yay Austin!)

So, that’s what I’m working on these days: BrowserID and other Identity+UserData efforts at Mozilla. I’m excited to be leading this technical effort. The team is amazing, and we’ve got big aggressive plans to help you control your identity and data on the Web.

On the night of September 10th, 2001, I was having drinks with an old friend (I’m having trouble remembering which friend!) in Chelsea, about 3 miles north of the World Trade Center. We stayed up late. We talked about world politics, terrorism, the Middle East. So when the alarm clock radio came on a bit before 9am (hey, I’m a software guy), with talk of a plane hitting a building, I thought I was having some messed-up dream based on the night’s conversation. By the time I turned on the TV, the second plane had hit. My mom called. “Mom, that’s a second plane, it’s not an accident.” I got a call from my sister who lived a few miles uptown, she was fine, too. I noticed a voicemail from my friend and coworker Josh. His wife, who worked in the WTC, was fine, as she was away on a trip. Then the cell phones went dead.

I threw on clothes and comfortable clothes. I watched the first tower collapse on TV. I grabbed a backpack, put on jogging shoes, and ran out of my apartment on 21st street, between 7th and 8th avenues. From my street I couldn’t see the towers, so I headed to 7th avenue. By the time I got there, all I could see was smoke. I had to ask someone on the street: “where’s the second tower?”

I started walking downtown, towards my office in TriBeCa, about a mile north of the WTC. I panicked for a moment: what if this was just the beginning and more was underway? I stepped into a convenience store, bought 3 candybars and 2 bottles of water. As I walked downtown, I passed cars stopped in the street, doors open, people standing with their radios turned on, straight out of some apocalypse movie. Then I started seeing people covered in dust. I made it to my office just south of Canal St, walked in, and logged on. I think I spent an hour clicking “respond”, writing “yes, I’m fine, more later.”

I found an unused IP address on one of our servers and set up a page to list “I’m ok” messages. Looks like the Internet Archive has a copy. I remember thinking I might be aggregating thousands of messages from around the city, though in the end it was obviously limited to my circle of friends. I guess I wanted to help, in any way I could.

Somewhere in there I chatted with co-workers, emailed our clients and partners, told them we were alright, asked how they were doing. One of our clients was on Wall Street and lost a number of friends.

In the mid afternoon, my friend Greg and I went up on the roof of our office building and talked, looking down Greenwich St towards WTC 7 surrounded by smoke of the collapsed towers. We went downstairs, heard on the radio that WTC 7 had collapsed, ran back up, and sure enough, it was gone. That night, Amanda, Greg, my sister and I crowded into my little apartment, ate frozen pizza and watched the news until we couldn’t anymore.

One of my best friends was stuck in Pennsylvania on a business trip. He wanted to be home in NYC, but couldn’t.

I gave my team the week off.

The next few days were odd.

I wasn’t able to fly out to the West Coast that Friday to see my friend Rodrigo’s new baby.

I stayed up nights listening to fighter jets flying overhead. I participated in far too many email arguments about “how to respond.” I was crazy and emotional. I made stupid, childish arguments. Within a few weeks, I would be calmer and, I think, more reasonable. I wish our leaders had also taken a moment to breathe.

People started going about their business again. There was the smell of burn in the air, but people tried not to talk about it. People were nice. Very nice. I went out a lot. I followed my friend Arjun to see indie bands on the lower east side. I didn’t want to stay in, ever, I needed to go out and be with people. I remember a faux-french band we saw, the guitarist wore an “I [heart] NYC” t-shirt he’d modified to say “J’[aime] NYC”. They didn’t mention the burning buildings. No one talked about it. Instead people went out of their way to be friendly, to reach out, to help.

That was, in some way, the saddest part of that experience. Everyone wanted to help. Doctors waited for the wounded, but none came. People lined up to give blood, but none was needed. People lined up to help downtown but there wasn’t room for everyone. So we tried to help each other, in small ways, every day.

I’ve got increased freedom, so I intend to use it. Starting today, I will not publish nor review papers destined for closed venues. Academic publications should be available for the world to read, to learn from, to build upon. If you’d like me on your program committee, if you’d like me to review a journal publication, if you’d like me to help with a paper, please understand that I will refuse if the conference/journal isn’t truly open. In the short term, this probably means I’ll only work with USENIX, and maybe IACR which appears to be moving towards true open-access.

My move isn’t exactly courageous. I have the luxury to make this decision, while many of my colleagues do not. I hope a few tenured professors make this move, though, as they have both the luxury and a good bit more influence than I do. Matt Blaze is starting down this path. Dan Wallach is helping tweak the IEEE approach. All of these efforts are incredibly important.

This is about free dissemination of knowledge. This is the point of the Internet. Academics who stand for discovery and learning should be outraged by the direction most publishers are taking today, and should at the very least encourage those publishers who are doing it well. Hesitating between ACM and USENIX? Go with USENIX. IACR holding a vote on open-access publishing? Make your voice heard.

In his speech to Harvard Med School graduates last week (stick with me here, this is relevant), Atul Gawande (author of the Checklist Manifesto), laid out, in his clearest and most convincing argument yet, how the practice of medicine needs to change:

The core structure of medicine emerged in an era when doctors could hold all the key information patients needed in their heads and manage everything required themselves. One needed only an ethic of hard work, a prescription pad, a secretary, and a hospital willing to serve as one’s workshop, loaning a bed and nurses for a patient’s convalescence, maybe an operating room with a few basic tools. We were craftsmen. We could set the fracture, spin the blood, plate the cultures, administer the antiserum. The nature of the knowledge lent itself to prizing autonomy, independence, and self-sufficiency among our highest values, and to designing medicine accordingly. But you can’t hold all the information in your head any longer, and you can’t master all the skills. No one person can work up a patient’s back pain, run the immunoassay, do the physical therapy, protocol the MRI, and direct the treatment of the unexpected cancer found growing in the spine. I don’t even know what it means to “protocol” the MRI.

Gawande tells colleagues they need to work as well-oiled teams. No heros, no cowboys. I believe, and surely I’m not the first, that the same path lies ahead for software engineers.

The open-source and free software movements caught on to this a long time ago. Sure, there are leaders (Richard Stallman, Linus Torvalds, Mitchell Baker.) But more importantly there are teams, incredibly agile teams of developers who rise to the occasion of the software itch that needs scratching. The coordination requirement on most software is usually not that of a medical team treating an emergency patient… except when it comes to releasing Firefox 4 to 100,000,000 users in 84 languages in a matter of days. You need a well-oiled open-source software machine run by a top-notch team, and that’s what Mozilla is.

There are no rock stars, or rather, everyone’s super impressive in their own way but no one is treated like a rock star. Because what matters is the team. This is incredibly refreshing for me, especially coming from academia where, though individual academics are highly collaborative by nature, there is a strong incentive to specialize, find a niche, and be the single rockstar in that niche, because that’s how you get promoted.

So I’m really enjoying Mozilla. And, we’re hiring, so if you want to work on one of the world’s most important pieces of digital infrastructure, drop me a line.

What started as a fun lunch with Sid and Alex quickly turned into passionate brainstorming with Mike, Pascal, and Lloyd on the Mozilla Labs team. I told them I wanted to deeply explore a few ideas I’ve written about and prototyped (here and here, for example) and more importantly to work on making the browser a true user agent working on behalf of the user. Mozilla folks are not only strongly aligned with that point of view, they’ve already done quite a bit to make it happen. Check out Mike Hanson’s post just a few days ago on using Web Applications for Service Discovery. And check out what the entire team just released: Open Web Apps. Not to mention the less closely related but still totally awesome work Sid and Alex are doing with Do Not Track. This is the first effort I know of that is successfully using technology to declare a preference (“please don’t track me”), which can then be leveraged by policy makers to ensure that it is respected. As a long-time student of the interplay between tech and policy, I love this hack.

My job will be to join this fantastic team and see what I can contribute. I suspect that will involve some privacy, some crypto, some data portability, and a lot of web hacking. I’ll continue to blog here at benlog.com, though when I speak here I’m speaking for myself only, not on behalf of my soon-to-be employer. And I’ll continue to hack a bit on Helios, my voting system, especially as it continues to inform how one might do advanced crypto in a web browser.

I’m super excited.

I’m taking two weeks off. I won’t be blogging or tweeting (much). I’ll be digging into a very thoughtful gift just received (what timing!): the Flour Bakery recipe book. If you live in Boston and you haven’t been to Flour, you’re simply missing out (or you don’t like baked goods, which is just too sad to think about.) This week’s goal, currant scones. Should be at least interesting, maybe delicious.

As to what I’m doing next… that’s for a blog post to be written 2 weeks from now. I’ve had some fantastic discussions with amazing people these last few weeks, and there are a few more conversations to be had before the picture is truly filled in. See you on the flip side of a few days spent with family and friends.

I want to build software for this thing. I’m really excited about the idea of a touch-screen computing platform that’s available for general use from a known brand who has successfully marketed unfamiliar devices to a wide audience.
[..]
It represents an incredible opportunity, but I can’t get excited about it because of Apple’s attempt to control who creates for it, and what they can create for it. Their policy of being the sole distributor of applications, and even worse, requiring approval on all applications, is insulting to developers.
[..]
I find it offensive on a very basic level, because I know that if such restrictions were in place when I was first learning to write software — mostly on Apple machines, no less — I would not have a career in the field.

John Lilly followed up brilliantly:

In a nutshell, what worries me about the trajectory of computing is not so much the emergence of tightly-controlled, non-tinkerable boxes, but the presumption that “normal people” don’t ever want to tinker, don’t want to be bothered with understanding how things work. I think it’s not true, really — certainly not for everyone — but I even think that this distinction between “normal people” and “tinkerers” or “techies” or “makers” is bogus at best, and really dangerously corrosive at worst.
[..]
It’s not like I was born an engineer — the instinct to fiddle with things isn’t something we’re born with. I became a tinkerer because I was exposed to surfaces that allowed — that invited — it. I figured out that I liked tweaking and building and creating because I got a bunch of chances to do that stuff, from hardware to software and everything in between. I knew I could do it because Dad modeled that behavior, but also because the stuff we had around the house was inspectable and malleable.
[..]
We all have the potential inside us to make things. But we’re not born into the world as makers — the world around us — the people in it and the artifacts in it — help us to discover what we can be.

I don’t know that I agree 100% with John: not everyone is a tinkerer. But, for sure, we need “surfaces that invite tinkering,” otherwise those who would be tinkerers might never discover it.

I was a tinkerer from an early age, but most of my tinkering in the physical world sucked, because, well, I don’t have good instincts about physics or analog things: I’m a digital kind of guy. So my egg-drop competition entries were overly complicated, my solar ovens were a perfect fit for a raw diet, my matchstick suspension bridges were unsafe at any speed, and my analog-circuit-based room-alarm systems would go off at random times in the middle of the night, or not at all, but at least would consistently end up blowing out the LED indicator (what do you mean you can’t connect the power source straight to the LED?)

I might have given up on tinkering, were it not for software… that was something else.

When my father brought home our first computer, a Thomson MO5, I was hooked. I spent hours transcribing BASIC programs from the 3 magazines I could find on the topic (this was Paris, France, not exactly Silicon Valley.) My dad took me to the office so I could talk to some Thomson engineers and debug my floppy disk drive. Later came the TO7, and eventually the Apple IIGS, my first “major” Pascal program to help my mother schedule carpooling (and my first taste of how hard it is to write a scheduling algorithm), my second “major” Pascal program to manage the Prom guest list. I wrote my final Geography report using a page-layout program on the Apple IIGS that probably cost me hours of extra time because of its bugs and the work-arounds I had to find, and got a worse grade for it because “not everyone can afford such fancy software, so we took off a couple of points” (for those of you still confused, THAT is socialism.) Not long after that I was applying to MIT and tinkering with one of the first e-commerce web sites. I love what I do, but would I have discovered this love without those first few lines of BASIC on that MO5 computer, written without anyone’s permission or knowledge?

Over time, though, I have become a little bit complacent about openness. I own an iPhone, and I’ve bought a few apps. I bought music on iTunes, and figured the DRM was not so problematic. I got a Kindle and bought some books. And then one day Apple’s DRM server went down and I couldn’t play music for a few hours. And Amazon decided to recall the book “1984″. And Apple decided to retroactively remove a bunch of apps they considered “not useful enough.” So I started thinking, maybe it’s time to get a different phone.

But I can’t. See, in the interim, I got unexpectedly locked in. I sync my calendar via MobileMe. I sync my music/TV shows via iTunes. Moving to something like a Palm Pre is going to take a significant effort. So how much worse will it be if I get an iPad, get some apps, and Apple decides to change the rules in a way that I don’t like? How locked in will I be then?

This change is happening gradually. At no point are you going to be shocked by an unfortunate Apple decision. You’ll enjoy your iPad, you’ll buy more apps, you’ll enjoy it even more. Apple will make a few decisions that inconvenience you, but you’ll deal. Until one day you’re inconvenienced enough that you might begin to look elsewhere. But you won’t be able to, because your data will be locked in. 3 years ago, we didn’t even have 3rd-party apps on the iPhone. Today, we have more than 100,000, and they’re all rushing to the iPad at warp speed. Change is happening.

One last point. A few months ago, I became a father. My wonderful little boy has an incredible appetite for life. Will he be a tinkerer? I don’t know, but if I had to bet I’d say yes. Will I be able to do for him what my father did for me? What will he tinker with, if everything in the house is a polished, professional, touch-but-don’t-tinker device? If he is to be a maker, a tinkerer, will he be able to fully explore his ideas if the rules of his digital universe are decided by the whims of Apple, Facebook, and Google?

I’m not sure. Maybe he will find a way, the way that kids do. Or maybe we, the generation that is witnessing this change, need to make sure that the rules of computing do not become a permanent, universal, inescapable sandbox.

One can have a number of arguments as to whether this is an efficient way to do research. Hint, it’s not, it’s terrible, it makes research fantastically expensive and slow. But I’m actually less concerned about that than I am about the principle: how is it okay for a naturally occurring substance that is part of me to be controlled by someone else? It’s ludicrous, and it violates a basic sense of personal freedom. Might a patent holder eventually have the right to charge me because my body is naturally producing a beneficial chemical derived from “their” gene?

So the ACLU is taking on this fight, and I commend them for it. This is a big deal. And the opposition to their action is going to be fierce, because the short-term financial interests in gene patenting are enormous. But this is the fight that matters for personal genomic freedom, efficient biomedical research, and generally finding a sane balance between necessary commercial incentives and basic freedoms. Patent a novel genome sequencing technique? Yes, by all means. Patent a gene itself so that no matter what other sequencing technique is invented, it can’t be used to sequence the “owned” gene? Insane, and wrong.

Over at CHIP (Children’s Hospital Informatics Program), we’re a bunch of folks who feverishly believe that Personally Controlled Health Records (PCHRs), records you get to share, protect, augment as you see fit, are going to be the IT platform of a new, more efficient health care system. You don’t have to believe me, you can just ask Clayton Christensen, the Harvard Business School professor who wrote the book(s) on disruptive technology. And Microsoft HealthVault and Google Health certainly seem to agree with that concept. My group’s project, Indivo, was the original PCHR that inspired the Google and Microsoft efforts (long before I arrived on the scene, so I take no credit.)

Recently, Google Health announced a deal where you can get your CVS pharmacy data into Google Health. That’s great… but can I get the data without involving Google Health if I want to? In other words, will CVS offer me a CSV (comma-separated values) file of my data so I can put it in my own spreadsheet or upload it to a competing PCHR?

I don’t know for sure, but from their web site it looks like they do not support that machine-readable data export. In other words, it’s your data, as long as you use Google Health. (Oh sure, you can export from Google Health, but what if you don’t like Google’s privacy policy?)

Adam Bosworth recently wrote about data liquidity in health records, and he’s right on. Data liquidity means that we stop with these one-off integrations, and start building common APIs and open data formats. Only then will we gain the efficiencies we seek from letting individuals truly control their personal health record.

But even if you had these building blocks, you would still have to use them in their intended way. A component can only be secure under certain well-defined circumstances, not for any use that happens to look similar.

One area of secure protocol development that seems to consistently yield poor design choices is the use of hash functions. What I’m going to say is not 100% correct, but it is on the conservative side of correct, so if you follow the rule, you (probably) can’t go wrong. You might be considered overly paranoid, but as they say, just because you’re paranoid doesn’t mean they’re not after you.

So here it is: Don’t hash secrets. Never. No, sorry, I know you think your case is special but it’s not. No. Stop it. Just don’t do it. You’re making the cryptographers cry.

What the heck am I talking about, you say? I’ll explain. But before we get lost in the details, just remember. Don’t hash secrets. Ever. Kapish?

What exactly do you mean by “Hash”?

A hash function takes any document, big or small, and creates a short fingerprint. That gigabyte movie of your newborn baby? Hash it with SHA1, and you’ve got yourself a 160 bit (~30 alphanumeric characters) fingerprint. Now, hold on, you say, 30 characters? You’ve hashed my baby to pieces and all that’s left is a measly 30 characters? No, no, don’t worry, your baby is still a unique snowflake. You can’t take those 30 characters and, from them, recover your gigabyte video. This is not uber-data-compression.

But it’s going to be darn hard for you to find any other document, big or small, that hashes to the same 30 characters. In fact, it’s so hard, even the most powerful computer in the world dedicated to this one task for hundreds of years won’t succeed at finding that doppelganger document. You’ve got lots of computers you say? You’re Google and you have hundreds of thousands of computers? Yeah, well…. tough. You still won’t succeed.

In fact, you can try something that should be easier: rather than find another document that hashes specifically to those 30 characters that represent your baby, you can go looking for any two documents that happen to hash to the same thing (collide). And you won’t find any such pair. Promised. We call that “collision resistance”. That thing about how you can’t find another document that hashes to the same value as your baby video? We call that “second pre-image resistance.”

Oh, and I forgot to mention that this magical function, SHA1, is public. Anyone can see the code. There are no secrets. Even if you see the code, you can’t find a collision. No, really, I’m not screwing with you.

I want to hash everything!

That’s usually the reaction after discovering the amazing power of hash functions. There are all sorts of nails just waiting for this magical hammer, so let’s start hashing everything in sight. De-duplicating large documents? Hash and compare! Passwords in a database? Hash and store! Anonymizing names in a database? Hash and pseudonymize!

After all, the magical power of a hash function is that you can’t “go back,” right? Given a hash, it’s impossible to get that pre-image, so hash away, my magical crypto friends!

Wrong.

Yeah, so it’s not quite that magical.

Let’s say I give you a SHA1 hash value 29b0d7c86b88565b78efffeea634cee81a209c92. From that hash alone, you can’t tell what I hashed. But if I tell you that I hashed a password, then all you need to do is try a bunch of common passwords and see which one matches. In this case, I hashed “love”, one of the most common passwords there is.

Now you start to see how this “you can’t go back” reasoning fails: if you know the domain of possible pre-images, and that domain is not too large, then you can just try them all and see which one matches. That’s a big strike against the “hash everything” approach.

Sprinkle in some Salt

It gets more interesting with the complete password use-case. Many web developers already know that they shouldn’t store user passwords in the clear in the database, just in case a break-in reveals every user’s password. So, instead of storing passwords in the clear, let’s store a SHA1 hash of the password, against which a candidate password can be easily checked: hash it and compare.

Now the web developers who have been around the block a few times know that, if you just apply SHA1 blindly, you’ve got the “small domain” problem I just mentioned. An attacker can build up a huge dictionary of hashed passwords just once, and, when he breaks into your web site, check the hashes against this pre-built dictionary.

To prevent these “dictionary attacks”, we add salt to the hashing process, so that each user’s password is hashed differently, and generic attacks don’t work: you have to rebuild the dictionary for each user you choose to attack. Sprinkling in salt is easy: just concatenate the password with a random string:

SHA1("TheAnswerIs42" || "love") = ce75a1c90ed564a231de85d93520f1e47726df64

Then, when a user types in a password, e.g. “lvoe” (a typo), the system checks:

SHA1("TheAnswerIs42" || "lvoe") = f832b210d62251c19a374a175bff760935c540d4
                               != ce75a1c90ed564a231de85d93520f1e47726df64

and sure enough, that doesn’t match, so the password is rejected.

Of course, the system has to keep the salt “TheAnswerIs42″ around to check the password, otherwise, it can’t re-perform the hash. So, if an attacker breaks in, he’ll find the salts, of course. This means that salting won’t protect a user with a weak password. But it will provide better protection for users with reasonable passwords, since, even with the salt in hand, the attacker will have to re-compute the dictionary for each salt, and thus each user.

So the moral of the story is that hashing the secret password directly is a bad idea.

And this is typically where most developers stand. They understand that hashing is good, they vaguely understand the notion of salting, and they figure that salt+hash is all they need to know. Except it’s not.

When hashing is really a signature

One interesting application of hash functions that has spread like wildfire in the last few years is in the realm of cheap signatures. Consider an application, SuperAnnoyingPoke that wants to send an authenticated message to MyFace. It could apply a full digital signature, using say RSA, so that MyFace can be sure that the message really came from SuperAnnoyingPoke. But that actually takes milliseconds on an average computer, and milliseconds are a lot. Plus, there’s all sorts of weird padding issues and size limitations that might require hybrid encryption, so it’s messy.

But hey, let’s take out our trusty cryptographic Swiss Army Knife, the hash function! Let’s salt+hash! We’ll just make sure that SuperAnnoyingPoke and MyFace share a secret string that’s a good 20 characters long or so, and when SuperAnnoyingPoke wants to send a message to MyFace, it will also send along a “Message Authentication Code” (MAC) that is computed as:

MAC = SHA1(secret_string || message)

MyFace can easily look at the message that is sent, recompute the MAC given the secret string it shares with SuperAnnoyingPoke, and compare it to the MAC sent along with the message. Heck, you can even put a timestamp in there to make sure the message can’t be re-played by an attacker at a later date. After all, since the hash function makes it hard to “go back” when you’re using a salt (the secret string), this should be a secure and cheap way to sign messages! Super!

Except this is where things really fall apart.

The security property we want here is that, if the attacker sees a message and its corresponding MAC, then it should not be able to figure out the MAC for a different message. That’s the whole point of a signature. And, unfortunately, there’s a property of SHA1 and lots of other hash functions like it that make it a fast hash function, but a terrible way to compute a MAC.

Here’s the deal: if I tell you that SHA1(foo) is X, then it turns out, in a lot of cases, to be quite easy for you to determine what SHA1(foo || bar) is. You don’t need to know what foo is. It’s just that, because SHA1 is iterative and works block by block, if you know the hash of foo, then you can extend the computation to determine the hash of foo || bar.

Oh crap.

That means that if you know SHA1(secret || message), then you can compute SHA1(secret || message || ANYTHING), which is a valid signature for message || ANYTHING. So to break this system, you just need to see one signature from SuperAnnoyingPoke, and then you can impersonate SuperAnnoyingPoke for lots of other messages.

Why? How??? But…. I thought hash functions didn’t let me “go back!” Well, note how I didn’t say the attacker would recover the secret. It’s just that, given one hash, they can compute others for related pre-images. That’s why you have to be careful about using hash functions when you’re hashing secrets. Another strike against using hash functions willy-nilly.

(If you’re keeping up, your next suggestion is “well, put the secret AFTER the message, not before”. And yeah, that’s a reasonable suggestion, but it points out how you’re now assuming some extra properties of the SHA1 hash function in your design, and that’s bad. What if you upgrade to a different hash function in 5 years, do you then have to update your protocol to match? The point is that you shouldn’t be using a hash function for this, that’s not its purpose!)

HMAC

What you should be using is HMAC: Hash-function Message Authentication Code. You don’t need to know exactly how it works, just like you don’t need to know exactly how SHA1 works. You just need to know that HMAC is specifically built for message authentication codes and the use case of SuperAnnoyingPoke/MyFace. Under the hood, what’s approximately going on is two hashes, one after the other, with the secret combined after the first hash… but don’t worry about it! That’s the whole point! HMAC is built for this feature.

HMAC has two inputs and one output: in go a message, and a secret, and out comes a message authentication code (i.e. a signature). The security of HMAC is such that, you can see as many messages and corresponding signatures as your heart desires, and you still won’t be able to determine the signature on a message you haven’t seen yet. That’s the security property you’re looking for. And HMAC is built on top of a hash function, so more specifically you should be using HMAC-SHA1.

So, again, don’t hash secrets. HMAC them.

In Conclusion

There’s plenty more to read if you’re interested in this topic, but chances are, you’re not and you just want a recommendation. “Don’t Hash Secrets” is not always entirely necessary. In the password example, you can hash a password as long as you salt it correctly. But do you really want to have to worry about that? I don’t. In fact, I use HMAC for my password databases, too. It’s overkill, but it lets me use a standard library that likely makes me safer in the long run.

So the next time you’re using a hash function on anything, ask yourself: is any of the stuff I’m hashing supposed to stay secret? If so, don’t hash. Instead, use HMAC.