Improve grammar on how-to-store-passwords post

content/posts/how-to-store-passwords.md

@@ -34,7 +34,7 @@ Imagine a smoothie maker. You put fruit in, it mixes it up, and you get a smooth
 
 An interesting characteristic of passwords is that that two slightly similar inputs can give completely different answers.
 
-There are many different hashing algorithms, although the most common are the SHA family, specifically SHA265 and SHA512. SHA1 and MD5 are whilst better than nothing, considered insecure. Base64 is not a hash!
+There are many hashing algorithms, although the most common are the SHA family, specifically SHA265 and SHA512. SHA1 and MD5 are whilst better than nothing, considered insecure. Base64 is not a hash!
 
 When storing a users' password, rather than storing the password, you store the hash. To authenticate, just look for rows where the username is the provided username, and the password is the hash of the provided password.
 
@@ -58,7 +58,7 @@ The salt doesn't need to be protected in itself, as it's not private information
 
 ### Peppering
 
-[Peppering](https://en.wikipedia.org/wiki/Pepper_(cryptography)) is a technique similar to salting, in that it further strengthens hashes, however it's done in a different way. Rather than using a different salt per user and storing it with the user, peppering uses a single shared key, which must remain private. The objective of peppering is to ensure that even if the database is compromised, there's still missing data which would be needed to perform brute forcing: the pepper.
+[Peppering](https://en.wikipedia.org/wiki/Pepper_(cryptography)) is a technique similar to salting, in that it further strengthens hashes, however it's done slightly differently. Rather than using a different salt per user and storing it with the user, peppering uses a single shared key, which must remain private. The objective of peppering is to ensure that even if the database is compromised, there's still missing data which would be needed to perform brute forcing: the pepper.
 
 #### Why not?
 
@@ -74,15 +74,15 @@ The point of key derivation is to implement everything I've said above. It takes
 
 ### Why not?
 
-Key derivation is designed to be slow - Not critically slow, but slow enough. This can add a considerable overhead to any bulk tasks involving passwords. With that said, this is a good thing, and shouldn't be changed or avoided. If you're creating a lot of users during tests, you may get quite a performance improvement by weakening your hashing during tests. I've seen improvements of nearly 30% using just this.
+Key derivation is designed to be slow; Not critically slow, but slow enough. This can add a considerable overhead to any bulk tasks involving passwords. With that said, this is a good thing, and shouldn't be changed or avoided. If you're creating a lot of users during tests, you may get quite a performance improvement by weakening your hashing during tests. I've seen improvements of nearly 30% using just this.
 
 ## Comparison timing
 
-Once a user has logged in, you've hashed their password using only the best practices, you've pulled what their password should be from the database, it's time to compare them. They're both strings, so `==` should work, right? Well yes, but actually no. Comparing strings is incredibly well optimised, for good reason! Lots of fundamental parts of programming depend on strings being compared as quickly as possible. However when it comes to security, this isn't necessarily what we want.
+Once a user has logged in, you've hashed their password using only the best practices, you've pulled what their password should be from the database, it's time to compare them. They're both strings, so `==` should work, right? Well yes, but actually no. Comparing strings is incredibly well optimized, for good reason! Lots of fundamental parts of programming depend on strings being compared as quickly as possible. However, when it comes to security, this isn't necessarily what we want.
 
-Many methods of string comparison have a number of cases to short circuit, and run faster than a regular character-by-character comparison. Even then when running a character-by-character comparison, it's good practice to abort as soon as you've got one character which doesn't match. When comparing hashes, these short circuits are counter-productive. By accurately measuring how long the system takes to check your password, you can gain insight about what the true hashes value is, and therefore begin to crack it. This is known as a [timing attack](https://en.wikipedia.org/wiki/Timing_attack).
+Many methods of string comparison have a number of cases to short circuit, and run faster than a regular character-by-character comparison. Even then when running a character-by-character comparison, it is good practice to abort as soon as you've got one character which doesn't match. When comparing hashes, these short circuits are counter-productive. By accurately measuring how long the system takes to check your password, you can gain insight about what the true hashes value is, and therefore begin to crack it. This is known as a [timing attack](https://en.wikipedia.org/wiki/Timing_attack).
 
-Any time you're comparing values in a secure context, you should a constant-time algorithm. The time required for these is always relative to the length of the values, and doesn't short circuit. For example, like the following Python:
+Any time you're comparing values in a secure context, you should a constant-time algorithm. The time required is relative to the length of the values, and doesn't short circuit. For example, like the following Python:
 
 ```python
 def constant_time_compare(val1, val2):