Salt, Nonces and IVs.. What’s the difference?

When it comes to scrambling data in order to keep passwords and users safe, there are a few different paths to take. What do they all really do?All these algorithms have different approaches used to prevent pre-computation attacks such as Rainbow Tables.

Salts, nonces, and IVs are all one-time values used in cryptography that don’t necessarily need to be secret, but still lead to additional security. It is generally assumed that these values are visible to attackers, even if it is sometimes possible to hide them.

Salt

Generally, salt is used in password-based systems and is concatenated to the front of a password before processing. So in other words, if there were no salt, an attacker could build a dictionary of common passwords and just look up the original password by authenticator.

The use of salt means that the attacker would have to produce a totally separate dictionary for every possible salt value. If the salt is big enough, it essentially makes dictionary attacks a bit more infeasible.

Pepper

A pepper performs a comparable role to a salt, but while a salt is not secret (merely unique) and can be stored alongside the hashed output, a pepper is secret and must not be stored with the output. It also is usually only one character appended at the end of the password. The hash and salt are usually stored in a database, but a pepper must be stored separately (e.g. in a configuration file) to prevent it from being obtained by the attacker in case of a database breach. Or simply discarded after use. Typically you want to implement both salt and pepper to your hash.

A Nonce (“ number used once”) are bits of data often input to cryptographic protocols and algorithms, including many message authentication codes and some encryption modes. Such values should only be used a single time with any particular cryptographic key. In fact, reuse generally isn’t prohibited, but the odds of reuse need to be exceptionally low.

Sequential nonces have a few advantages over random nonces:

• You can easily guarantee that nonces are not repeated. Note, though, that if the possible nonce space is large, this is not really a concern.
• Many protocols already send a unique sequence number for each packet, so one can save space in transmitted messages.
• The sequential ordering of nonces can be used to prevent replay attacks, but only if you actually check to ensure that the nonce is always incrementing. That is, if each message has a nonce attached to it, you can tell whether the message came in the right order, by looking at the nonce and making sure its value is always incrementing.

However, randomness in a nonce helps prevent against classes of attacks that amortize work across multiple keys in the same system. Generally you want to have both a random portion and a sequential portion.

Step 1: The client initiates a SCRAM authentication session

Step 2: The server issues a challenge

Step 3: The client responds with a proof

Initialization vector

IV’s or starting variables is a fixed size input.

IV and nonce are often used interchangeably. Essentially though, an IV is a nonce with an additional requirement: it must be selected in a non-predictable way. This would eliminate all sequential nonces, an IV must be random.

BCRYPT

We can’t forget however about the awesome gift Ruby on Rails provided us with for cybersecurity. bcrypt() is a sophisticated and secure hash algorithm designed by The OpenBSD project for hashing passwords. The bcrypt Ruby gem provides a simple wrapper for safely handling passwords. Typically a password goes through the bcrypt algorithm and then is “salted” for another layer of security.

Basically to summarize, salts and IVs should be random, and nonces are usually sequential, potentially with a random salt as a component, if there is room. With sequential nonces, you need to ensure that you never repeat a single {key, nonce} pairing. Unless you have the magic of bcrypt, it’s good to look into applying multiple algorithms to protect data.