Software serial hashing salting

An attacker cannot attack a hash when he doesn't know the algorithm, but note Kerckhoffs's principle , that the attacker will usually have access to the source code especially if it's free or open source software , and that given a few password-hash pairs from the target system, it is not difficult to reverse engineer the algorithm.

It does take longer to compute wacky hash functions, but only by a small constant factor. It's better to use an iterated algorithm that's designed to be extremely hard to parallelize these are discussed below.

And, properly salting the hash solves the rainbow table problem. But if your reason for doing so is to make the hash computation slower, read the section below about key stretching first. Compare these minor benefits to the risks of accidentally implementing a completely insecure hash function and the interoperability problems wacky hashes create. It's clearly best to use a standard and well-tested algorithm.

Because hash functions map arbitrary amounts of data to fixed-length strings, there must be some inputs that hash into the same string. Cryptographic hash functions are designed to make these collisions incredibly difficult to find. From time to time, cryptographers find "attacks" on hash functions that make finding collisions easier. A recent example is the MD5 hash function, for which collisions have actually been found.

Collision attacks are a sign that it may be more likely for a string other than the user's password to have the same hash. However, finding collisions in even a weak hash function like MD5 requires a lot of dedicated computing power, so it is very unlikely that these collisions will happen "by accident" in practice.

A password hashed using MD5 and salt is, for all practical purposes, just as secure as if it were hashed with SHA and salt. This section describes exactly how passwords should be hashed.

The first subsection covers the basics—everything that is absolutely necessary. The following subsections explain how the basics can be augmented to make the hashes even harder to crack. Warning: Do not just read this section. We've seen how malicious hackers can crack plain hashes very quickly using lookup tables and rainbow tables. We've learned that randomizing the hashing using salt is the solution to the problem.

But how do we generate the salt, and how do we apply it to the password? As the name suggests, CSPRNGs are designed to be cryptographically secure, meaning they provide a high level of randomness and are completely unpredictable. The salt needs to be unique per-user per-password. Every time a user creates an account or changes their password, the password should be hashed using a new random salt.

Never reuse a salt. The salt also needs to be long, so that there are many possible salts. As a rule of thumb, make your salt is at least as long as the hash function's output. The salt should be stored in the user account table alongside the hash. If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?

Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server.

To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not. The problem is that the client-side hash logically becomes the user's password.

All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.

This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:. If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password. Some web browsers don't support JavaScript, and some users disable JavaScript in their browser.

So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.

You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password.

Since you're hashing and salting with a good salt on the server too, it's OK to use the username or email concatenated with a site-specific string e. Salt ensures that attackers can't use specialized attacks like lookup tables and rainbow tables to crack large collections of hashes quickly, but it doesn't prevent them from running dictionary or brute-force attacks on each hash individually. High-end graphics cards GPUs and custom hardware can compute billions of hashes per second, so these attacks are still very effective.

To make these attacks less effective, we can use a technique known as key stretching. The idea is to make the hash function very slow, so that even with a fast GPU or custom hardware, dictionary and brute-force attacks are too slow to be worthwhile. The goal is to make the hash function slow enough to impede attacks, but still fast enough to not cause a noticeable delay for the user.

Key stretching is implemented using a special type of CPU-intensive hash function. Don't try to invent your own—simply iteratively hashing the hash of the password isn't enough as it can be parallelized in hardware and executed as fast as a normal hash. These algorithms take a security factor or iteration count as an argument. This value determines how slow the hash function will be. For desktop software or smartphone apps, the best way to choose this parameter is to run a short benchmark on the device to find the value that makes the hash take about half a second.

This way, your program can be as secure as possible without affecting the user experience. If you use a key stretching hash in a web application, be aware that you will need extra computational resources to process large volumes of authentication requests, and that key stretching may make it easier to run a Denial of Service DoS attack on your website.

I still recommend using key stretching, but with a lower iteration count. You should calculate the iteration count based on your computational resources and the expected maximum authentication request rate. Always design your system so that the iteration count can be increased or decreased in the future. If you are worried about the computational burden, but still want to use key stretching in a web application, consider running the key stretching algorithm in the user's browser with JavaScript.

The iteration count should be set low enough that the system is usable with slower clients like mobile devices, and the system should fall back to server-side computation if the user's browser doesn't support JavaScript.

Client-side key stretching does not remove the need for server-side hashing. You must hash the hash generated by the client the same way you would hash a normal password. As long as an attacker can use a hash to check whether a password guess is right or wrong, they can run a dictionary or brute-force attack on the hash. The next step is to add a secret key to the hash so that only someone who knows the key can use the hash to validate a password. This can be accomplished two ways.

Either the hash can be encrypted using a cipher like AES, or the secret key can be included in the hash using a keyed hash algorithm like HMAC. This is not as easy as it sounds. The key has to be kept secret from an attacker even in the event of a breach. If an attacker gains full access to the system, they'll be able to steal the key no matter where it is stored.

The key must be stored in an external system, such as a physically separate server dedicated to password validation, or a special hardware device attached to the server such as the YubiHSM. I highly recommend this approach for any large scale more than , users service. I consider it necessary for any service hosting more than 1,, user accounts. If you can't afford multiple dedicated servers or special hardware devices, you can still get some of the benefits of keyed hashes on a standard web server.

Most databases are breached using SQL Injection Attacks , which, in most cases, don't give attackers access to the local filesystem disable local filesystem access in your SQL server if it has this feature. If you generate a random key and store it in a file that isn't accessible from the web, and include it into the salted hashes, then the hashes won't be vulnerable if your database is breached using a simple SQL injection attack. Don't hard-code a key into the source code, generate it randomly when the application is installed.

This isn't as secure as using a separate system to do the password hashing, because if there are SQL injection vulnerabilities in a web application, there are probably other types, such as Local File Inclusion, that an attacker could use to read the secret key file. But, it's better than nothing. Please note that keyed hashes do not remove the need for salt.

Clever attackers will eventually find ways to compromise the keys, so it is important that hashes are still protected by salt and key stretching.

Password hashing protects passwords in the event of a security breach. It does not make the application as a whole more secure. Much more must be done to prevent the password hashes and other user data from being stolen in the first place. Even experienced developers must be educated in security in order to write secure applications. Unless you understand all the vulnerabilities on the list, do not attempt to write a web application that deals with sensitive data.

It is the employer's responsibility to ensure all developers are adequately trained in secure application development. Having a third party "penetration test" your application is a good idea. Even the best programmers make mistakes, so it always makes sense to have a security expert review the code for potential vulnerabilities. Find a trustworthy organization or hire staff to review your code on a regular basis. The security review process should begin early in an application's life and continue throughout its development.

It is also important to monitor your website to detect a breach if one does occur. I recommend hiring at least one person whose full time job is detecting and responding to security breaches.

If a breach goes undetected, the attacker can make your website infect visitors with malware, so it is extremely important that breaches are detected and responded to promptly.

Even though there are no cryptographic attacks on MD5 or SHA1 that make their hashes easier to crack, they are old and are widely considered somewhat incorrectly to be inadequate for password storage. So I don't recommend using them. It is my personal opinion that all password reset mechanisms in widespread use today are insecure. If you have high security requirements, such as an encryption service would, do not let the user reset their password. Save my name, email, and website in this browser for the next time I comment.

Skip to content Press Enter. Random to generate a salt, it has been correctly pointed out that there are stronger algorithms for hashing that are recommended. Cryptography; using System. ToBase64String byteResult. GetBytes bytes ; return Convert.

GetBytes password , Encoding. Nick Proud Nick is a Software engineer specializing in systems automation using. C cryptography Hash hashing passwords salt security.

About Nick Proud Nick is a Software engineer specializing in systems automation using. Previous Post String and string in C. Leave a Reply Cancel reply Your email address will not be published. You Might Also Like Windows Forms Continue Reading.

String and string in C. Continue Reading. People have actually died over private key compromises throughout history. Today, thanks to computer technology and the internet we can now practice public key cryptography. With public key cryptography, one public key is used to encrypt and the other private key is used to decrypt.

It would still take a supercomputer thousands of years to decrypt bit encryption. First and foremost, everyone needs to… shake hands?! RSA — RSA stands for Rivest-Shamir-Adlemen, after its creators, it is a public key encryption algorithm asymmetric that has been around since and is still widely used today. It uses the factorization of prime numbers to encipher plaintext.

Each step uses a different algorithm. PGP has been criticized for poor usability, a lack of ubiquity and for the length of its keys. As we discussed earlier, encryption is a two-way function. You encrypt information with the intention of decrypting it later. So, correspondence with someone online, protecting your cloud data or transmitting financial data are all examples of times when encryption is appropriate.

Hashing is the practice of using an algorithm to map data of any size to a fixed length. Whereas encryption is a two-way function, hashing is a one-way function. Hashing is one-way. In other words, it serves as a check-sum. Every hash value is unique. If two different files produce the same unique hash value this is called a collision and it makes the algorithm essentially useless. But Google went there. Following this, the whole thing is encrypted so it can be downloaded.

When a customer downloads the software, their browser is going to decrypt the file, then inspect the two unique hash values. The browser will then run the same hash function, using the same algorithm, and hash both the file and the signature again. If the browser produces the same hash value then it knows that both the signature and the file are authentic—they have not been altered.

Just remember, no two files can create the same hash value, so any alteration — even the tiniest tweak — will produce a different value. That includes passwords created during registration or as the result of a password reset. If the user eventually cycles over the same password, we don't want to give away that the password has already been used.

Cryptographically strong or strong cryptography define a cryptographic system that is highly resistant to cryptanalysis , which are efforts to decipher the secret patterns of a system. Showing that a cryptographic scheme is resistant to attacks is a complex process that requires a lot of time, extensive testing, reviews, and community engagement. Due to this complexity, security experts recommend that you don't roll your own cryptography. To create such cryptographically-strong random data, we may use a cryptographically secure pseudorandom number generator CSPRNG to gather unpredictable input from sources that we cannot observe, such as the Random Generator API of our operating system.

Even better, we could use a battle-tested, cryptographic library for that. Most of these libraries include facilities for working with random numbers. As an advice, never roll your own random number generators.

As storage permits, use a byte or byte salt with the actual size dependent on the protection function. A longer salt effectively increases the computational complexity of attacking passwords which in turn increases the candidate set exponentially. A longer salt also increases the space required to store hash tables while decreasing the possibility that such a table exists in the wild. The security of this scheme does not depend on hiding, splitting, or otherwise obscuring the salt.

Simply put, do not mess with the salt. The salt doesn't need to be encrypted, for example. Salts are in place to prevent someone from cracking passwords at large and can be stored in cleartext in the database. However, do not make the salts readily accessible to the public.

For that reason, usernames are bad candidates to use as salts. It does not matter if they are visible and unencrypted, what matters is that they are in place. Based on these guidelines, f1nd1ngn3m0 is not being generated from an unpredictable source.

In fact, the salt is a way of writing findingnemo , a popular animated movie, which could be part of a dictionary-brute-force strategy. Our second salt, f1nd1ngd0ry suffers from the same weaknesses. I chose it based on it being the sequence to the "Finding Nemo" movie, "Finding Dory".

Our human imagination to create randomness can only go so far so it's better to delegate that task to the machine. As we can see, hashing and salting are very complex processes and the security of our systems greatly relies on their successful implementation. It's best to leave the creation, maintenance, and operation of such methods and systems to security experts. A misstep in your home-made security strategy may lead to extensive damage to your business, users, and reputation.

It's best to leave their implementation to security experts. A misstep in a home-made security strategy may lead to damage to a business, its users, and reputation. You'd want to rely on algorithms such as bcrypt that hash and salt the password for you using strong cryptography. Additionally, you may use a security framework, such as Spring Security for the Java Ecosystem for example. These frameworks offer you abstractions that make the development of your applications safer but also integrate with reliable identity providers , such as Auth0, that make Identity and Access Management much easier.