Completely unrelated, how bad 1-10 would you rate it if a system were to, say, use the hashed password as an API key?
I wouldn't do it myself, but in theory, assuming you don't allow for authenticating somehow using the raw hash, it should not be any directly security risk. If I was to "fix" such a system, I'd double hash it, but it might be impossible due to integrations with other systems, where all systems needs to be updated, etc ...
Maybe creating "transition code" where the thing is double hashed, and both double hash and single hash is considered a "match", then log all single hashes, and slowly weed out single hashes over time. However, if this is your largest security issues, you're in a good place compared to some of the places I've been ... ;)
However, of course the correct way to create API keys is to create them dynamically, having them being completely unrelated of users and passwords, allowing admins to revoke them with time. That train has probably "left the station" for your current system ... :/
Edit - It depends upon how the password was hashed. I kind of assumed BlowFish and individual per record based salts. If this is not the case, the hash is almost as good as having raw access to password, due to rainbow dictionary brute force attacks ...
The dev responsible keeps saying "in a future release", but more pressing issues keep on surfacing, so my guess is it won't be done until this potential risk gets abused
I thought about your problem. The simple solution would just be to create lonbg lasting JWT tokens, assuming that's what you're using for plain auth. As in, creating JWT token lasting for 3 months or something. It doesn't provide eviction, but I suspect it'll be better than simply sending the hash ...
And, it wouldn't need to touch database, and the token will be valid if the user account changes pwd, etc, etc, etc. Not perfect, but way better ...
This would allow the token to "impersonate" a user account, removing all "special logic" required for API tokens ...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wouldn't do it myself, but in theory, assuming you don't allow for authenticating somehow using the raw hash, it should not be any directly security risk. If I was to "fix" such a system, I'd double hash it, but it might be impossible due to integrations with other systems, where all systems needs to be updated, etc ...
Maybe creating "transition code" where the thing is double hashed, and both double hash and single hash is considered a "match", then log all single hashes, and slowly weed out single hashes over time. However, if this is your largest security issues, you're in a good place compared to some of the places I've been ... ;)
However, of course the correct way to create API keys is to create them dynamically, having them being completely unrelated of users and passwords, allowing admins to revoke them with time. That train has probably "left the station" for your current system ... :/
Edit - It depends upon how the password was hashed. I kind of assumed BlowFish and individual per record based salts. If this is not the case, the hash is almost as good as having raw access to password, due to rainbow dictionary brute force attacks ...
Thank you for the elaborate response
The dev responsible keeps saying "in a future release", but more pressing issues keep on surfacing, so my guess is it won't be done until this potential risk gets abused
I thought about your problem. The simple solution would just be to create lonbg lasting JWT tokens, assuming that's what you're using for plain auth. As in, creating JWT token lasting for 3 months or something. It doesn't provide eviction, but I suspect it'll be better than simply sending the hash ...
And, it wouldn't need to touch database, and the token will be valid if the user account changes pwd, etc, etc, etc. Not perfect, but way better ...
This would allow the token to "impersonate" a user account, removing all "special logic" required for API tokens ...