Is it possible to crack a password with a dynamic salt that is not stored anywhere?

Question

Android

Suppose on the client, along with a password, ask the user to enter a word (at least 6 characters, it will be a salt that only the user knows, it does not appear anywhere else) and then do everything according to this scheme:
hash(password+hash(word)) and send this hash to the server.
Upon arrival of the data to the server, do this: hash(incoming hash + salt from the database for this user) and compare it with what is in the database.

Answer 1

than the password will differ simply from the password with this salt on the client? a password with this salt becomes just a password again. cracked in the same way as a simple password.

Answer 2

Your option with salt is no different from simple authorization with a password.
If the user has a password of 10 characters and a salt of two, then cracking will not be conceptually different from cracking a password of 12 characters. It will simply add another factor of 11 to find the position of breaking a string of 12 characters into "password + salt"

Answer 3

Possibly: a hash is caught (hash(password+hash(word))) via MiTM and anyone further authorized under this hash.
UDP: password+hash(word) = password2, which is also guessed.
A little more reliable, like this:
1. At the client's greeting, the server generates a random salt and responds with it: RSALT
2. The client hashes the password with this salt, adding its random RANDOM parameter and its random SALT salt to get the password key: HKEY=hash(pass+SALT ), then sends 2 parameters to the server:
HASH=hash(RSALT+RANDOM+HKEY), RANDOM
(SALT - also saved on the client for subsequent authorizations!)
3. The server saves (when setting/changing the password): HKEY
4. Checking when authorization: HASH===hash(RSALT+RANDOM+HKEY)
Thus, the salt is stored by the client, and the server always generates a unique request.

Answer 4

Of course, it is possible to hack, the option is not much different from the option just a password, everything also breaks down by brute force.
and certainly it is much less secure than the password + normal salt option.
ps you understand that 99% of users have: password == word and for the most part, these are words from the top 1000 popular passwords, well, the maximum date of birth is their own or relatives.
this is, firstly, and secondly, the browser will not save these two words in the password storage, as a result, your users will constantly have problems logging into the site.
thirdly, it is very difficult to remember both the password and the word and not confuse them in places, this further aggravates p2.
in total, a huge crap is created for users only because you were too lazy to add one field to the database. and there isn't much security.

Answer 5

The salt is needed to protect the password hash database from group brute force using rainbow tables , in case it gets stolen. It doesn't protect you from anything else. For the target case, the salt should not be secret, but should be random.
Here you are talking about salt in the database, that's ok.
Here you are talking about computing a password hash on the client, calling hash(word) a salt. This is an incorrect use of the term. The salt must be random.
Depends on the conditions of the hack. For example, if an attacker sees a hash going from the client to the server, he can use it without the need to hack something.