I'm still a bit worried...

Me: Browsing the security of a website.

Tell the website developer that they are using the SHA-1 hashing algorithm for encrypting the credentials of it's registered users.

Them: Yeah, so what?

Me: You shouldn't be using an algorithm which was exploited years ago in the age of 2016.

Them: Don't worry, nothing will happen.

Me: *facepalm*

encrypting strings with the key being the string itself is considered hashing?

The importance of not using static salt / IVs.

I've been working on a project that encrypts files using a user-provided password as key. This is done on the local machine which presents some challenges which aren't present on a hosted environment. I can't generate random salt / IVs and store them securely in my database. There's no secure way to store them - they would always end up on the client machine in plain text.

A naive approach would be to use static data as salt and IV. This is horrendously harmful to your security for the reason of rainbow tables.

If your encryption system is deterministic in the sense that encrypting / hashing the same string results in the same output each time, you can just compile a massive data set of input -> output and search it in no time flat, making it trivial to reverse engineer whatever password the user input so long as it's in the table.

For this reason, the IVs and salt are paramount. Because even if you generate and store the IVs and salt on the user's computer in plaintext, it doesn't reveal your key, but *does* make sure that your hashing / encryption isn't able to be looked up in a table