Update Password_Storage_Cheat_Sheet.md

removing minimums #601

Author: jmanico

cheatsheets/Password_Storage_Cheat_Sheet.md

@@ -98,11 +98,6 @@ Rather than a simple work factor like other algorithms, Argon2id has three diffe
 - m=37 MiB, t=1, p=1
 - m=15 MiB, t=2, p=1
 
-Consider raising these settings to the following (or more) if performance considerations do not have a negative impact your system.
-
-- m=37 MiB, t=11, p=1
-- m=15 MiB, t=26, p=1
-
 ### scrypt
 
 [scrypt](http://www.tarsnap.com/scrypt/scrypt.pdf) is a password-based key derivation function created by [Colin Percival](https://twitter.com/cperciva). While new systems should consider [Argon2id](#argon2id) for password hashing, scrypt should be configured properly when used in legacy systems.
@@ -119,7 +114,7 @@ Like [Argon2id](#argon2id), scrypt has three different parameters that can be co
 
 The [bcrypt](https://en.wikipedia.org/wiki/bcrypt) password hashing function should be the second choice for password storage if Argon2id is not available or PBKDF2 is required to achieve FIPS-140 compliance.
 
-The minimum work factor for bcrypt should be 10. Consider raising the work factor to 12 (or more) if performance considerations do not have a negative impact on your system.
+The minimum work factor for bcrypt should be 10.
 
 #### Input Limits
 
@@ -141,12 +136,6 @@ The work factor for PBKDF2 is implemented through an iteration count, which shou
 - PBKDF2-HMAC-SHA256: 310,000 iterations
 - PBKDF2-HMAC-SHA512: 120,000 iterations
 
-Consider raising these settings to the following (or more) if performance considerations do not have a negative impact your system.
-
-- PBKDF2-HMAC-SHA1: 110,000,000 iterations
-- PBKDF2-HMAC-SHA256: 48,000,000 iterations
-- PBKDF2-HMAC-SHA512: 19,000,000 iterations
-
 When PBKDF2 is used with an HMAC, and the password is longer than the hash function's block size (64 bytes for SHA-256), the password will be automatically pre-hashed. For example, the password "This is a password longer than 512 bits which is the block size of SHA-256" is converted to the hash value (in hex) fa91498c139805af73f7ba275cca071e78d78675027000c99a9925e2ec92eedd. A good implementation of PBKDF2 will perform this step before the expensive iterated hashing phase, but some implementations perform the conversion on each iteration. This can make hashing long passwords significantly more expensive than hashing short passwords. If a user can supply very long passwords, there is a potential denial of service vulnerability, such as the one published in [Django](https://www.djangoproject.com/weblog/2013/sep/15/security/) in 2013. Manual [pre-hashing](#pre-hashing-passwords) can reduce this risk but requires adding a [salt](#salting) to the pre-hash step.
 
 ## Upgrading Legacy Hashes