Creating user and safely sending password

Question

Assuming I currently use a safe way to salt-challenge-response-authentication-method, passwords are stored secured and all.

I now question myself - how do users set the password? Meaning, they enter password as plain text in the textbox, and what happens next? should their client hash the password and send it to the server to be salted? isn't that prone to MITM+rainbow-table ? I was thinking about querying the server for the salt, and then the client hashes and salts the password and that's what will be stored in the DB along aside the salt.

What do you think?

Also, Is it ok\better to store the first part of the hash which is the combination of the username and password with salt? meaning that when they change username they'll need to reset their passwords aswell.

Thanks!

Answer 1

You should NEVER send passwords in the clear. As long as your communications are encrypted (TLS), your server can hash and salt the passwords when it receives them.

Answer 2

For Web Apps you best go with

1. using TLS as mandatory. This includes mechanisms like HSTS, to prevent MITMs to redirect to fake http "counterpart".
2. sending password in the clear for both login and setup
3. salting and hashing of passwords on the server. Do something along SECUREHASH(pw, salt, it), where SECUREHASH is some secure hash, and salt is some random value with about 16 bytes.

Challenge-Response for web apps is unneccessary, as your visitors download the app at each visit (via GET requests to your site for the html and js files), and therefore if the communications channel is compromised, the whole application is as well. An (active) attacker could simply grab the password before it gets hashed client-side, by changing the js accordingly.

Answer 3

Sounds a bit like you're trying to reinvent the wheel :) You're not saying if this is a web app or desktop app. In any case there are de facto ways to do these.

For credentials transport, use TLS. As the name suggests, Transport Layer Security. Use that to transfer credentials from an end-user to the server. Depending of your needs, you could get away with self-signed certificates but if you're worried about MITM then get proper certs. Do this and you don't need to implement any additional client-side encryption scheme.

To generate a safe password hash, you could use a key stretching function like PBKDF2 to add thousands of iterations and make computing a password time consuming for the attacker.

In case your db is compromised and attacker dumps all passwords, you can fight against rainbow tables by salting your passwords. Salt doesn't have to secret but it should be unique to each account to minimize the effectiveness of rainbow tables.