Would this RESTful login system be secure?

Question

So I have been thinking about a way to make a secure restful API for application logins.

This is what my teacher and I have come up with:

1. The Client (swift program) initializes the connection with the server.
2. The Server returns a "shared secret" (ex. +40) and a hash of a random string of letters and numbers.
3. The Client then hashes the Username and Password (separate) and sends it back with the hash of: hash + "the shared secret".
4. After the Server sends data (step 2) the server hashes [hash + "shared secret"] and then updates it in the db
5. The Server then receives the hashed value from the Client and checks the db to see if it matches
6. The db will also have a timestamp that if not updated frequently enough there will be a function that runs through the db and drops the items that are no longer used.
7. For every request after the login the bearer token is sent.

The bearer token will follow this formula:
Request verification token = hash [ (original hash) + (shared secret) * (# of requests) ]

Is this sufficient to secure against Man in the Middle attacks and client spoofing, or basically anything that could let the attacker impersonate a user?

Answer 1

No, you're actively harming usability with no gain to security.

This sounds like a bad case of Security Theater*!

I say this because what you're currently doing is only just as secure as sending over the username and password over HTTPS anyways! All you add is a couple of extra setup communications. The vulnerabilities of this implementation as well as the vulnerabilities of HTTPS sending of password and username are exactly the same.

Let's break down the example:

Setting up and using the secret

1. Establish secure connection
2. Send payload to be stored
3. Confirm payload, and if confirmed log in

Setting up and using a password

1. Establish secure connection
2. Send payload to be stored
3. Confirm payload, and if confirmed log in

These steps are exactly the same, and provide no extra security. If a full takeover(MITM/system level) happens, the same thing that would happen with a username and password will happen to your system. The attacker will still see all data as it is transferred and accessed between your system and the server. This is why full takeovers are so dangerous. There's basically nothing you can do to protect the user. The user is using a system of communication that is no longer theirs, but the attackers and that attacker can see, and use everything in the communication.

Really all you're doing is generating a secret(commonly called a password) to be stored, and some meta data(commonly called a username) to identify it. If the meta data and secret match an entry, you retrieve that information. The only advantage you're gaining is that the user gets an extra long password. But to what end? Bcrypt has a maximum character length, so you're limiting the number of characters the individual password can have. You now also have that shared secret to worry over getting the same every time or your user or they can never log in.

Passwords and usernames over HTTPS have been used so much so often because after a certain point(the HTTPS connection) there is nothing you can do to increase security. If someone gets access to all communications, or to memory space all of your techniques have just been defeated since they just have to recreate your steps and you may never even know until they carry out their attack.

*: As of last week this phrase is now macroed on my keyboard...
*: Security theater is the act of putting practices into place that do nothing to improve security, and may actually harm it!