Encryption

Hashing

  • It is the process of transforming information (like a password) into an apparently random string of characters using a mathematical function called a hash function . In game development, hashing is mainly used to protect passwords. Instead of storing the player's actual password, a "hashed" version is stored.

  • Characteristics:

    • A hash cannot be “decrypted” to obtain the original password; instead, you must compare the hash of the current value with the stored hash to see if they match.

    • The same input data always generates the same hash.

  • Hashing is the most common method to securely store passwords since the passwords themselves do not need to be recovered, only verified.

  • If the database is compromised, attackers will not have the real passwords, only the hashes.

  • Hashing + Salting is not an encryption method .

    • Although hashing shares some superficial similarities with encryption, it works fundamentally differently and serves a distinct purpose.

    • Reasons:

      • Hashing is one-way, while encryption is two-way; i.e., it is possible to recover data with encryption, but not with hashing. Hashing is irreversible.

Salting

  • It is an additional feature to increase hashing security. A salt is a random set of characters added to the password before hashing to make attacks more difficult, especially 'rainbow table attacks', where hackers use precomputed hash tables to discover passwords.

  • If two people choose the same password, the generated hash would be identical. With a salt, even if the passwords are the same, the hashes will be different because the salt adds a unique value to the password before hashing.

  • Always use salting . As mentioned, the salt is a random value added to the password before processing by the hash. This helps ensure that even if two people use the same password, their hashes will be different.

  • Usage:

    • The salt should be unique  for each password and stored along  with the hash.

    • When a user attempts to log in and provides their password, the system must verify if the entered password matches the stored hash. For this, the system must apply the same salt to the hashing process to generate the hash of the provided password and compare it with the stored hash.

  • Process:

    • Hash the (password + generated salt).

    • Password:

      • password123

    • Salt:

      • abcxyz123

    • Password + Salt:

      • password123abcxyz123

    • Hash of (Password + Salt):

      • 9c56b457ae63cd789f71cd0213b7c4d7f36d5fef7b9b6fe49bc49d24c6be5b7f

  • Superficial explanation of Hashing and Salting in Godot {1:03:41} .

    • ~This is done to "scramble" the password and make it more secure

Pepper (Optional)

  • In some systems, besides the salt, a pepper (an additional secret value) is used with the hash. This adds an extra layer of security, although using a pepper is less common than using a salt.

  • For example, one peppering strategy is hashing the passwords as usual (using a password hashing algorithm) and then using an HMAC (e.g., HMAC-SHA256, HMAC-SHA512, depending on the desired output length) on the original password hash before storing it in the database, with the pepper acting as the HMAC key.

  • The pepper is shared among stored passwords , rather than being unique  like a salt.

  • Unlike a password salt, the pepper should not be stored in the database .

  • Peppers are secrets and should be stored in "secrets vaults" or HSMs (Hardware Security Modules). See the Secrets Management Cheat Sheet  for more information on securely storing secrets.

  • Like any other cryptographic key, a pepper rotation strategy should be considered.

Work Factors

  • The work factor is the number of iterations of the hashing algorithm performed for each password (usually 2^work  iterations). The work factor is typically stored in the hash output. It makes calculating the hash more computationally expensive, which reduces the speed and/or increases the cost for an attacker attempting to crack the password hash.

  • When choosing a work factor, balance security and performance. Higher work factors make hashes harder to crack but will slow down verifying login attempts. If the work factor is too high, application performance may degrade, which could allow an attacker to perform a denial-of-service attack by exhausting the server's CPU with many login attempts.

  • There is no golden rule for the ideal work factor — it depends on the server performance and the number of users. Determining the optimal work factor requires experimentation on the specific server(s) used. As a general rule, calculating a hash should take less than one second.

  • Algorithms like MD5 and SHA-1 were designed to be fast, and you can adjust how slow they are by changing the work factor.

  • Upgrading the Work Factor :

    • A key advantage of a work factor is that it can be increased over time as hardware becomes faster and cheaper.

    • The most common approach is to wait until the user next authenticates, then re-hash their password with the new work factor. Different hashes will have different work factors and may never be upgraded if the user doesn't log back in. Depending on the application, it may be appropriate to remove older password hashes and require users to reset their passwords to avoid storing older, less secure hashes.

Security

  • The Hash and Salt do not need to be kept secret . They are just random values used to make the hashing process unique and more secure. The purpose of the salt is to ensure two identical passwords do not result in the same hash, but storing it publicly along with the hash is fine. Security lies in the fact that the password itself is not stored recoverably (because it is hashed) and the hashing process is irreversible.

    • The main reason is that a hash function (like SHA-256, bcrypt, etc.) is designed to be irreversible. Once the data (password + salt) is transformed into a hash, there is no viable mathematical method to reverse it and retrieve the original data (the password).

  • Even if someone has access to the hash and salt, they cannot simply reverse the process to discover the password. The hash is a "fingerprint" of the input data but does not contain enough information to reconstruct it.

  • Hash functions are designed to be hard to invert. This is achieved through various techniques, such as using one-way functions and a large output space.

  • However , although hashing is irreversible and theoretically cannot be reversed back to the original password, techniques exist to try to find the password associated with a hash if the attacker has the hash and salt.

    • Brute Force Attacks :

      • Even if the hash is hard to reverse directly, the attacker can try all possible password combinations until one produces the same hash. This is called brute force. If the hash and salt are publicly available, an attacker can compute hashes for all combinations until the corresponding password is found.

Algorithms

  • You do not need to hide which password hashing algorithm is used by an application.

In Odin

  • "'@Yawning' is working on argon2id , and scrypt  and bcrypt  aren't available either, so following recommendations , you're left with PBKDF2 using a SHA256 HMAC and a work factor of at least 600k.

Argon2

  • Argon2 was the winner of the 2015 Password Hashing Competition.

  • Of the three Argon2 versions, use Argon2id since it provides a balanced approach to resisting both side-channel and GPU-based attacks.

  • Tips .

Scrypt

  • While Argon2id is the best choice for password hashing, scrypt should be used when Argon2id is not available.

  • Tips .

Bcrypt

  • Should only  be used for password storage in legacy systems where Argon2 and scrypt are unavailable.

  • The work factor should be as large as verification server performance allows, with a minimum of 10.

  • Tips .

PBKDF2

  • Requires selecting an internal hashing algorithm such as HMAC or other hashing algorithms. HMAC-SHA-256 is widely supported and recommended by NIST.

  • "PBKDF2 isn't memory hard unfortunately, but it's widely used (unfortunately), and the only FIPS-certified option (unfortunately)."

  • "The main reason I implemented it is that 'it's easy to implement and widely used'."

  • "It's sound given strong passwords or a large work factor."

  • "FIPS 140-certification is one reason to use it, otherwise you'd use something better."

  • Tips .

SHA-256

  • "SHA256 is 'fine', just not my first choice."

HMAC

  • HMAC (Hash-based Message Authentication Code) is a cryptographic authentication function based on a hash function (like SHA-256 or SHA-3) and a secret key.

Blake2

  • Speed: Up to twice as fast as SHA-256 in software.

  • Security: Resistant to known attacks, such as collisions and pre-images.

  • Customization: Supports features like keyed hashes (for HMAC) and variable-length hashes.

  • Versions:

    • BLAKE2b: Optimized for 64-bit systems.

    • BLAKE2s: Designed for 8-32 bit devices.

MD5

  • Generates 128-bit hashes.

  • Obsolete for secure applications due to collision vulnerabilities.

  • Methods exist to alter a file and produce the same hash, breaking the algorithm's security.

SHA-1

  • Generates 160-bit hashes.

  • Also considered insecure.

  • Why to use 'slow hashing functions' .

  • The video shows reapplying hashing many times to simulate Bcrypt, making hashing slower and more secure.

  • (2024-11-08) Godot only supports MD5, SHA1, and SHA256; all are fast, which is bad.

Security Tests / Requirements / Etc

NIST

  • NIST (National Institute of Standards and Technology) is the U.S. federal standards and technology institute under the Department of Commerce.

  • NIST develops and publishes technical standards and guidelines in areas including:

    • Cryptography

    • Cybersecurity

    • Metrology (science of measurement)

    • Information technology

  • NIST standards are widely used by government agencies and the private sector as a reference for security and interoperability.

  • Examples of NIST cryptographic standards :

    • AES (FIPS 197)

    • SHA-2 / SHA-3

    • PBKDF2 (RFC 8018)

    • FIPS 140-2/3

FIPS 140

  • Certification requirements like FIPS 140 are defined by NIST.

  • FIPS 140 (Federal Information Processing Standard Publication 140) is a U.S. government standard that defines security requirements for cryptographic modules (hardware and software).

  • FIPS 140-2/3 certification ensures that the cryptographic module has been tested by accredited labs and meets specific security criteria.

  • Security Levels :

    • FIPS 140 defines four security levels (1 to 4), with Level 1 being basic and Level 4 most stringent, covering physical and logical protection against attacks.

  • PBKDF2 :

    • PBKDF2 can be part of a cryptographic module seeking FIPS 140 certification.

    • This does not mean PBKDF2 itself is "certified," but a specific implementation within a module is evaluated and approved.

    • PBKDF2 complies with NIST standards, which are required for FIPS.

    • It is considered an approved key derivation method for data protection, provided parameters (iterations, key size) meet NIST guidelines.