-1

I am creating a web app on a LAMP stack where I have users with their own logins and passwords. Typical users of the application have limits on operations. For example they cannot approve an order over $5000. If there is an order over $5000, they have to get a manager to come to their desk and enter in his/her username and password to approve the order.

I can easily create a form for the manager to enter his/her credentials into an HTML password input, but here is the problem. When the manager enters their credentials into the browser, the password field is hidden from the user. But when the form is submitted, the password is transmitted in clear text. In theory, a user could get the password by using F12 or by looking at the POST.

I wanted to hash the passwords before submitting the form, but the problem is that PHP stores the passwords using BCRYPT, and javascript can only digest with SHA.

So basically my question is. How can I ensure that the manager password is hidden from the user and they cannot get it?

karozans
  • 53
  • 7
  • 4
    This a problem with the physical process. The manager should be using their own device for approvals. Basic IT policy in most organisations is that users never share devices. – ADyson Dec 18 '22 at 10:24
  • 1
    A good web stack should include hooks for MFA, which mitigates some of the risk associated with passwords alone, so you might want to research that avenue... – Trentium Dec 18 '22 at 11:07
  • ADyson. I agree. Unfortunately, I am between a rock and a hard place. The customer I am making the app for has managers walking the floor in buildings with up to 1000 people. And they want the manager to be able to walk up to the users computer, and enter their credentials in order to approve an order over $5000. – karozans Dec 18 '22 at 19:27
  • 1
    They could walk up to the computer with a mobile device in their hand, get a notification on an app and approve it that way. Or you have to go with one of the other solutions involving MFA and/or one-time tokens. Just because a customer wants something doesn't make it a good idea or an essential thing. Part of our job as programmers and solution designers sometimes is to explain to the customer why something they're asking for is actually a really bad idea, and then to propose a better one to the same job. – ADyson Dec 18 '22 at 19:29
  • 1
    I agree. I have told the customer about the security risk, but they want it done regardless. So I am trying to mitigate any problems and trying to finish it at the same time. I didn't think about being able to use a phone. That would be a good solution. Thanks. I'll check out the MFA too. – karozans Dec 18 '22 at 20:45
  • 1
    @karozans in a lot of solutions, a cell phone acts as the MFA device in conjunction with an app, such as Google Authenticator. Take a look at the following Q&A, as I believe it will assist you in your endeavor... https://stackoverflow.com/questions/5087005 – Trentium Dec 19 '22 at 00:18

1 Answers1

2

javascript can only digest with SHA

I'm sure you could find implementations of bcrypt in client-side Javascript…

That won't really solve your problem though. If the password is hashed client-side, then the server cannot hash it further and needs to accept the hash as is to compare it directly to the stored hash. Which in essence means, the hash becomes the password, so the user could send the same hash again to the server and pass the test.

Further, bcrypt should be using random salts, so in order to recreate the same hash, the server would need to send the used salt to the client so it can create the correct hash. This is all madness.

Instead, you probably want some sort of challenge protocol. The idea being that the value the client sends to the server is different every time, so even if the attacker sees the value, they cannot reuse it. For this purpose the server would make up some random value, send that to the client, the client calculates some answer given the password and the random value, and sends only that to the server. A rough overview of different algorithm can be found at MDN and elsewhere.

This still won't solve the issue of the attacker installing some keyboard logger, or simply overriding some Javascript handler to log the entered password to the console before answering the challenge. In the end, if you don't trust the attacker and the attacker has full control over the system the password is entered into, there's nothing much you can do.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • Ah yes. I see the issue now. Thanks for the info. Unfortunately the customer wants this ability. I might try to implement the challenge like you said and see if that works. – karozans Dec 18 '22 at 19:35