You Want Salt With That? Part One: Security vs Obscurity

A poster to one of the Joel On Software fora the other day asked what a "salt" was (in the cryptographic sense, not the chemical sense!) and why it's OK to make salts public knowledge. I thought I might talk about that a bit over the next few entries.

But before I do, let me give you all my standard caution about rolling your own cryptographic algorithms and security systems: don't.   It is very, very easy to create security systems which are almost but not quite secure. A security system which gives you a false sense of security is worse than no security system at all! This blog posting is for informational purposes only; don't think that after you've read this series, you have enough information to build a secure authentication system!

OK, so suppose you're managing a resource which belongs to someone -- a directory full of files, say.  A typical way to ensure that the resource is available only to the authorized users is to implement some authentication and authorization scheme.  You first authenticate the entity attempting to access the resource -- you figure out who they are -- and then you check to see whether that entity is authorized to delete the file, or whatever.

A standard trick for authenticating a user is to create a shared secret. If only the authentication system and the individual know the secret then the authentication system can verify the identity of the user by asking for the secret.

But before I go on, I want to talk a bit about the phrase "security through obscurity" in the context of shared secrets. We usually think of "security through obscurity" as badness. A statistician friend of mine once asked me why security systems that depend on passwords or private keys remaining secret are not examples of bad "security through obscurity".

By "security through obscurity" we mean that the system remains secure only if the implementation details of how the security system itself works are not known to attackers. Systems are seldom obscure enough of themselves to provide any real security; given enough time and effort, the details of the system can be deduced. Lack of source code, clever obfuscators, software that detects when it is being debugged, all of these things make algorithms more obscure, but none of these things will withstand a determined attacker with lots of time and resources. A login algorithm with a "back door" compiled into it is an example of security through obscurity; eventually someone will debug through the code and notice the backdoor algorithm, at which point the system is compromised.

A strong authentication system should be resistant to attack even if all of its implementation details are widely known. The time and resources required to crack the system should be provably well in excess of the value of the resource being protected.

To put it another way, the weakest point in a security system which works by keeping secrets should be the guy keeping the secret, not the implementation details of the system. Good security systems should be so hard to crack that it is easier for an attacker to break into your house and install spy cameras that watch you type than to deduce your password by attacking the system, even if all the algorithms that check the password are widely known. Good security systems let you leverage a highly secured secret into a highly secured resource.

One might think that ideally we'd want it both ways: a strong security system with unknown implementation details. There are arguments on both sides; on the one hand, security plus obscurity seems like it ought to make it especially hard on the attackers. On the other hand, the more smart, non-hostile people who look at a security system, the more likely that flaws in the system can be found and corrected. It can be a tough call.

Now that we've got that out of the way, back to our scenario. We want to design a security system that authenticates users based on a shared secret. Over the next few entries we'll look at five different ways to implement such a system, and what the pros and cons are of each.

Comments

• Anonymous
  January 28, 2005
  The comment has been removed

• Anonymous
  January 29, 2005
  Off-topic, but still related (security after all). I've created an ActiveX that downloads data from a web server, using async monikers et al. I understand that in order to support download from sites that require authentication, I need to implement IAuthenticate. Thing is, the download will most likely occur from the same site that hosted the ActiveX itself, and the containing page. I want to avoid requiring the user input the same credentials twice. Anyone know how the ActiveX can get the credentials from IE? I haven't been able to find any information about this in the MSDN, Google, etc.

• Anonymous
  January 29, 2005
  Bruce Schneier is fond of saying that "anyone can design a cryptosystem that he himself cannot break". This is always a bad idea. Even the best in the world get it wrong sometimes; there was (is?) a subtle man-in-the-middle vulnerability in IPSEC, related to XAUTH - search the IETF working group mailing list for about 2-3 years ago for details.
  
  Related to obscurity: it's interesting to note that the US Government believes in security through obscurity, in the cryptographic sense: they almost never publish the design docs to released algorithms (e.g. SHA/SHA-1), they rarely publish their own cryptanalytic findings (e.g. whatever caused the NSA to release SHA-1, or more famously, their obvious discovery of differential cryptanalysis 25ish years before the academic community), and sometimes algorithms themselves are kept secret (e.g. Skipjack, which was only released in tamper-proof chips). The US Armed Forces has been using secret stream ciphers for workhorses for years.
  
  I gotta admit, all of the above strike me as dubious strategy at best. Then again, the NSA has more crypto people than the rest of the world combined, so I guess their stuff is still peer-reviewed, albeit not in open literature.
  
  This series sounds like fun. :-)
  

• Anonymous
  January 30, 2005
  "Anyone know how the ActiveX can get the credentials from IE?"
  
  My guess? Implement IObjectWithSite::SetSite for an IUnknown back to IE. There should be some way to retrieve or listen (OnNavigate?) for the authentication info.

• Anonymous
  February 03, 2005
  Fabulous Adventures in Coding assays this week a, well, fabulous adventure, in simple cryptography. I know enough to get myself in deep trouble with this subject, but Eric has put together three short and knowledgeable posts that begin easy and...

• Anonymous
  August 17, 2005
  It still seems that 'knowing the salt tells you nothing' depends on what else you know about the salt. If you just know the salt is used in passwords on a server, that's very little help. If you know a salt is used for a particular password then a dictionary attack is more possible, you just have to try possible salt + password combinations. If you know the salt for a password and how it's combined with the password, then you can do a basic dictionary attack right?

• Anonymous
  September 06, 2007
  A recent question I got about the .NET CLR's hashing algorithm for strings is apropos of our discussion

• Anonymous
  January 11, 2008
  > "There's nothing to stop you flipping a couple of bits in the input to one of the hashes: it takes you no time at all, and it provably doesn't weaken the security..." From a cryptographic perspective, "flipping a couple of bits" in the initialization values of of an encryption scheme can indeed weaken it severely.  Many such studies have been done to prove it.  Those values may look random, but they aren't.

• Anonymous
  June 22, 2011
  The comment has been removed