Deprecate all algorithms (except HMAC SHA-256?), add real KDF

[lahwran]

https://cryptobook.nakov.com/mac-and-key-derivation/hmac-and-key-derivation
https://cryptobook.nakov.com/mac-and-key-derivation/modern-key-derivation-functions

• All algorithms in passwordmaker except HMAC-sha256 are extremely broken and should not be used. they should be hidden under a "show more" and should have a very scary warning, so that any users still using them will realize how concerning it is and change their main passwords, which they only use with a newer algorithm, so that their main passwords can't be reversed from their generated passwords. Importantly, for anything secure, if you used a main password with an old algorithm, that main password should be considered compromised.
• HMAC-sha256 is concerningly fast, but is sturdy enough that strong main passwords will not be easily reversed from it. Optimized hash brute forcing equipment may still be able to be used to extract a main password from a hashed one, if the main password is weak. It's already implemented, though, so simply putting it at the top as the only sane option given the current implementation would be a good start.
• bcrypt would be acceptable but is not slow on all types of brute forcing equipment.
• scrypt is strong and cannot be practically brute forced in the current era of computer size, even if the main password is somewhat weak and the attacker has significant compute.

Implementing bcrypt or scrypt would require finding a sidechannel-free javascript library which is also fast enough to use, and would not be trivial. However, the first two items are UI changes, so should simply be done and published, to inform any users of the old algorithms of their vulnerability.

[miquelfire]

I'm not going to close this as I want a conversion about this, but here are some things that would have to happen before someone would find your master password.

1. The attacker would have to grab a generated password. If they don't have that, there's nothing to worry about. Most hackers will just stop there though, as for as they know, the password might be stored in a password manager of some kind, and the user is actually using a tool like this and not using a normal password manager.
2. Once they have the password, they would not only need to figure out the algorithm in use, but also all the other parameters. First, they would need to know the character set, also if the prefix and suffix are used (This might tip off the hacker that this tool is used to generate a user's password, as I'm not aware of any other password generate that has this as an option). Second, they would need to know if the user used the username and modifier fields, then they can try and find the master password.
3. They might actually need multiple passwords to even know if they got it right in the first place

Also, if bcrypt and scrypt were used, the libraries would have to output a plain hex value. Furthermore, the program would have to generate a static salt to use, so every time you enter your stuff, it will generate the same value. Out of the box, bcrypt and scrypt generate a random salt every time you use the function, so the generate password would change on each use. They would be more useful for password managers that store your passwords.

[ericjung]

It's almost as if @lahwran has not used PasswordMaker. To @miquelfire's point, there are many variables involved that are not part of classic collision and brute force attacks which make this a much more difficult problem for an attacker. Having said that, it would be nice to update PasswordMaker with some newer hashing algorithms. But I don't think we have any maintainers, do we?

[heavensrevenge]

@lahwran The algorithms in Passwordmaker do not use the hash of the password you type in directly, the hash is converted using the options you choose in a profile to alter the output password to conform with site password requirements and your own personal requirements. So hash tables or rainbow tables cannot work for Passwordmaker generated passwords. Which is why this situation you mentioned in your post is a misconception.

[heavensrevenge]

@ericjung Adding new algorithms will cause implementations of PasswordMaker to not be compatible with each other. Settings and exporting/importing would have to add conditional logic based on selected algorithms. I did add support for Blake2s,Blake2b and SHA-512 in my personal branch before but never shared it because of the incompatibility reason.