2

I am tasked to change our users current login method to a more secure one (at the moment all password are stored in clear text in the database...).

The problem is, all passwords must be on the customer's local network (as they should be able to work even without internet connection), but we should still be able to recover them and tell them to users in case they forget.

I tried to push for the standard "hashing and salting + password reset if required" solution, but it was deemed too complex.

I was thinking about using asymmetric encryption, so we can deploy a public key to customers and encrypt all passwords with it (checking the encrypted password at login time, as you normally do with hashes), and keep the private key so we can eventually decrypt the password if required.

Is this actually secure (provided we keep the private key for ourselves) or should we resort to another method?

2 Answers 2

3

First: no password storage.

Storing passwords is wrong. Clear-text or encrypted, symmetric or asymmetric encryption, it does not matter. If the password can be reverted, it will be reverted.

You must store the password on a secure hashed form. Use bcrypt with a sane amount of rounds. Too much rounds (100,000) will use too much resources, too few (100) will make a dictionary attack or bruteforce easier.

Salting and hashing plus password reset is not a complex solution. Is simpler than to deploy a public key to the client and properly protect the private key.

And don't recover passwords. Generate new ones. It's not hard. Just make sure only the owner of the forgotten password can reset the password. Sending a link to the user's email, or a confirmation code to their phones. And don't modify the password until the user clicks the link or access the password reset service with the correct username and reset code.

7
  • 1
    I'm perfectly aware of how to make a secure login process, but this time I'm not the one writing the requirements. I tried to push for the usual hashing method for about a month, and they still won't listen. I'm actually looking for the lesser of evils here.
    – BgrWorker
    Sep 14, 2017 at 13:12
  • 4
    If they don't listen, write a report with all caveats on their implementation, the risks, the possible outcomes, your proposed solution, and send to them all. When the password database leaks, they will not be able to say that you were responsible. Storing passwords is a great evil, few things are better than that.
    – ThoriumBR
    Sep 14, 2017 at 13:17
  • 1
    Unfortunately I need to agree with @BgrWorker here; if someone asks a question "I know X is not ideal, but I need to do it because {reasons}, what's the best way?", our job is to answer the question they asked, not to ignore the question they asked and suggest they do X anyway. By all means, put a big flashy disclaimer, but do answer the question. Sep 14, 2017 at 13:17
  • 1
    If OP cannot push for a simple hash + salt because it's complex, how can he implement secure public key password encryption and private key storage? Less complex than salt and hash is clear text storage...
    – ThoriumBR
    Sep 14, 2017 at 13:20
  • 1
    @ThoriumBR Maybe I wasn't clear, it was deemed too complex for users (which in fact are used to call us if they forget their password, and apparently can't be bothered to change them or set them again), not for me to implement.
    – BgrWorker
    Sep 14, 2017 at 13:25
0

If you are willing (and able) to store your own private key securely, and be responsible for resetting user passwords anyway, then I'd suggest you just provide a mechanism where you can issue a signed, privileged "reset password" instruction for a user.

You said part of the use case was they have to be able to reset while offline. This would be akin to license mechanisms, where customer would contact you, verify who they are, you would use your private key to issue a token/license/reset-string they could enter into the software which would enable a one-time password reset for specific user.

No password storage, works locally.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .