How secure is a signature based on hashing data with a salt?

Question

Hashing

Let's say a site client has a login that is stored in cookies. The server needs to check with each request whether the user is authorized, and without resorting to the database (for this case, it will also not use caching in RAM, we will not use redis and the like).
In short, you need to do a quick authorization check without using the database. It is very convenient, easy and fast to do this:
1. The user enters the site (indicates the login and password on the authorization page)
2. If the login and password are correct, the server takes the login, for example Test, concatenates it with some kind of complex random string, e.g. ZIvvWQOaGvjzjKSD, gets hash:

sha256('Test' + 'ZIvvWQOaGvjzjKSD') = 'b67c9b06ab56cd32ae41b12ad427a96aa04560f097ed8c0bdbccb74015d9ec69'


3. The server returns new client cookies: Login Test and the signature obtained in the second step b67c9b06ab5... the line is in the cookie. It is clear that the secret string is the same for all users. How secure is such an algorithm?

PS I would like to use such a thing not only for a quick authorization check, but also for other purposes. Does it make sense to use this algorithm as a signature, or is it better to use regular algorithms?

Answer 1

I would not check authorization only on data from the client. Basically. The very method of generating an authorization token is quite good, but IMHO you should add some secret to it, known only to the server, i.e. store salt or part of it in the database next to the information about the client account. If suddenly the static salt somehow leaks, get anonymous authorization under any account on the server, including non-existent ones, with the presence of the dynamic part of such a problem should not appear. And saving one request to the database for input authorization is illogical for me, especially if the project is not a highload (and optimizations are allowed there, including storing the login-salt match somewhere in the memory of a neighboring microservice).

Answer 2

How secure is this algorithm?

This algorithm is not secure.
Firstly, you are confused in terminology. First you call it "hashing data with a salt", then the salt becomes "some kind of complex random string", then it's a "hash with a key", and in the end it turns out that the string is secret. The salt is a means of uniqueizing hashes and protecting against hash guessing using rainbow tables, its value is not secret, but it must be unique for each protected object.
Secondly, if the "complex random string" is shared by all users and is used as you described, it simply becomes part of the hashable password without salt. An authenticated user who receives a hash for their password can pick up a "complex random string".