This question already has an answer here:
- How to securely hash passwords? 12 answers
I understand the basic idea of password salts.
- You generate a 'random' string of data
- prepend this data to a user password
- store password and salt (salt maybe even in 'clear' form)
Like in the following scenario: You have a client side mobile application and a server application with a database. The user registers with a username and password using the mobile app. The password gets a prepended salt and is stored hashed on the server side. The salt has to be stored on the server side too, because you wouldn't trust the mobile client at all. And the salt should somehow be connected to the right user account. So let's assume, it is stored in the same user table right beside the password.
How could using a salt in this case prevent any attack (e.g. dictionary attack)? If the attacker already has access to the database server it would be easy to get the salt. If the attacker uses the interface of the server application in a proper way the salt would also be applied to his 'attack attempts for login'. Maybe I'm missing some important point how this kind of attack is usally carried-out. Or would this system only be secure if salting and hashing would be executed directly on the client?