The important part
The fact that you are generating salts on your own is a red flag. The best way to do this, especially if you have little experience with security, is to use an established library for password hashing.
A well-designed library will generate and use salts automatically for you, and it will store the salt and the hash in the same string, that you put in one column in your database.
So, use a slow algorithm designed for password hashing, and use an established library, and you won't have to think about how to generate the salt.
The answer
Still, I should answer your question. Does it matter if the salt has high entropy? There are two properties that we may want the salt to have here, that randomness helps with:
- Unique, in your database, between password changes and preferably globally, so that an attacker can only crack one password at a time.
- Unknown to the attacker, even before any (before a breach), so that an attacker targeting a specific account can not start any preparatory work before the database is leaked.
Using a counter as salt is a decent solution, but not perfect. The salt is at least locally unique, but it's not globally unique or even unique over multiple installations of the same software. It's not unknown to the attacker, but that really isn't such a big issue. Once the hash is leaked, the salt will be leaked too.
But still, using a library that gives you a random salt will be better. Don't mess around with homebrew solutions for something as important as this!
