0

Question

I was just brainstorming about the hashing, stretching, salting part of the user password in the authentication process and I want it to be as secure as possible (no matter how paranoid that is).

I came up with something that I described in the diagram shown below. I was wondering if this is a good way to go or that is has some disadvantages or potential risks using this process.

Diagram

I think the combination of salting and stretching locally based on a pin-code that is never stored but just known by the user makes it harder to guess the salt and also to reproduce the exact process without the user since the local used salt and amount of stretching will be unknown to the server.

Secondly assuming that the connection is compromised because of an MiTM attack. The process of how the leaked hash of the password is created is still unknown because the salt and iterations (based on the pincode) are unknown. The local process (in the browser) can be reversed engineered obviously but assuming the browser and computer aren't infected, just by intercepting the communication, it's not possible to reproduce it (read: very hard to guess).

Simplified example

- User opens browser and goes to login page
- User types password / pincode / username, nothing gets send yet
- Javascript in browser uses pincode to generate a salt
- Generated salt is used to hash the password locally
- Only username and hashed (+salted+stretched) password is send to server over compromised TLS SSL
- Server rehashes the browser created hash with a server-wide/global salt to +restretch
- Server rehashes previous hash with a user-specific salt so the same salt isn't used for all stored password hashes
- Final hash is used for storage / comparing in authentication process
- User is send to a Two-Factor authentication step
Bob Ortiz
  • 6,665
  • 11
  • 50
  • 96
  • 2
    What problem are you trying to solve? What attack(s) is this intended to protect against? – Anders Jun 23 '16 at 12:14
  • Also could you write this as some kind of simple pseudo code as well? I find it hard to follow all the boxes. – Anders Jun 23 '16 at 12:18
  • 1
    @Anders both done. – Bob Ortiz Jun 23 '16 at 12:26
  • This might help in passive MitM, not against active MitM. But why aren't you using some sort of standardized mechanism to prevent passive MitM attacks? How will the server validate the hash when the user tries to authenticate without transferring the pincode? I think you should also explain the authentication process. – Silver Jun 23 '16 at 12:37
  • @Silver, can you suggest an answer wherein you describe why it does help in a passive but not in an active MitM attack? The server will validate the hash because the exact same local/server-side process is used when creating the password the very first time. The auth. process is nothing more than validating the username/hash like described above and after that sending the user to a TFA page. Also, what standardized mechanism do you suggest? – Bob Ortiz Jun 23 '16 at 12:41
  • Active MitM, I inject my JavaScript code to obtain both password and pin.
  • If the server validates the hash, then actually the hash becomes the password (an attacker can send the hash if it can capture it via passive attacks).
  • – Silver Jun 23 '16 at 12:44
  • @Silver, in case of a javascript injection there is nothing you can protect against. So lets exclude that. But "the hash becomes the password" is interesting. This is partly true but the hash that is locally created and the hash that is server-side stored are different. So you can only send the local hash as the server expects it before rehashing it. Right? – Bob Ortiz Jun 23 '16 at 12:47
  • See also: the "Is this scheme secure" anti-pattern canonical answer. – Jacco Jun 23 '16 at 12:52
  • Indeed, see my answer which I will update based on your comments to provide an overview. – Silver Jun 23 '16 at 12:54
  • Also, JavaScript crypto is generally not seen as desirable. – Jacco Jun 23 '16 at 12:54