1

I want to use username and password instead of public key cryptography for a decentralized peer-to-peer application, but since the passwords are stored on users' computers, there is a possibility of being stolen. How do I store the passwords securely?

And how do I give permission safely? How can I prevent someone else from gaining permission unfairly?

New contributor
coderdd is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
3
  • Why do you not want to use public-key cryptography? – MechMK1 2 days ago
  • You should never store a password in plain text nor using a reversible encryption, but only store a non inversible hash of it. Bcrypt is a possible tool for that use. – Serge Ballesta 2 days ago
  • @SergeBallesta That doesn't work. You can't solve this with hashes. – MechMK1 2 days ago
1

Storing Password on User devices is always unsecured. But You can use that way. It is not standard or actually it is fully useless method to achieve security.

If you store password on user device.

  1. If user lose phone, Account needs to be created.
  2. How Do you achieve forgetting password?
  3. Simply when user create account, where do you going to store account details?
  4. Actually if you don't need centralized server mean, you don't need user name and password as well.

Best way to achieve this is using centralized server for authentication. It is flexible scalable and Secured.

New contributor
web_guy is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
1

Depending on your goal, you may want to use different architectures:

1. Use a centralized server for authentication

This would be similar to how some videogames act. A centralized server would handle authentication and authorization, but actual data transfer would happen directly between clients for performance reasons.

This approach works well, since authentication can be treated like any other client/server scenario. Passwords can be stored securely in one centralized database, while the server doesn't need to worry about actual traffic between clients.

The downside of this is if your centralized server is unavailable (maintenance, Denial-of-Service attack, obsolescence of service, etc.), then the entire application becomes unusable.

2. Use public-key cryptography

You stated in your question that you do not wish to use PKI. Unfortunately, PKI excels at precisely this kind of scenario. A client can generate a new key pair, which is akin to a new "identity". The client can then publish their public key, allowing others to verify their identity. Whether or not the corresponding private key corresponds to a real-life identity is not an easy problem to solve, but one you don't necessarily need to solve. If a virtual identity (akin to a username/password combination) is enough, then PKI solves this problem well.

Advantages of this system would be that it is very resilient, requiring basically no maintenance, since there is no centralized server involved. Two users, who have each other's public keys, can authenticate each other until the end of days.

Disadvantages is that if you have multiple devices, migration becomes less simple than just "entering your credentials" on the other device. You either need to copy your private key to the other device, or you generate a new private key there and have the keys sign each others public key. In a sense, Key A says "I guarantee that Key B is also me. Yours truly, Key A" and vice versa Key B says "I guarantee that Key A is also me. Yours truly, Key B".

This system works well, but requires your users to be a bit more involved. Depending on who your target audience is, it could be a reasonable assumption to make that your users will understand how PKI works. Otherwise, telling them to copy a file will be something most users can do.

3. Zero-Knowledge Proofs

Basically, you want to prove to someone that you know something, with them knowing anything what that thing is. This seems like an impossible task, but it is doable. Wikipedia provides a set of abstract examples, but for the sake of completeness, I will include one here:

Imagine you have two differently-colored balls, and a color-blind friend. To your friend, the balls seem identical. You want to prove to him that they are differently-colored, without revealing which ball is which color.

Your friend shows you the balls, then places them behind his back and randomly decides to switch them or not. He then asks you whether or not he switched the balls. If the balls are indeed differently-colored, then you can see the difference and say whether or not they were switched.

The first time this is done, your friend believes that there is a 50% chance that you could have just guessed it correctly, so he repeats the task. You succeed again, and now there is a 25% chance it was just another lucky guess. With each repetition, his confidence doubles. After 80 repetitions, your friend is more than 99.9999999999999999999999 % confident that you weren't just guessing, which "proves" to him that you indeed are able to differentiate the balls, even if you did not disclose how, or which ball is which color.

To be less abstract, the Secure Remote Password Protocol implements a Zero-Knowledge Proof, which allows a server to verify whether or not a client knows a password without storing the password. The following image demonstrates the workflow:

SRP Workflow, credit to thinbus-srp

Image credit to thinbus-srp

I'll be honest with you, I've never worked with SRP before, but it seems to be something worth looking into.

Why can't I just store hashes?

A password is a so-called "shared secret". Authentication with a "shared secret" works by sending the server my secret, and the server checks whether or not this shared secret matches what the server previously stored. However, in your case, you don't want the involved parties to know the secret - after all, then they could just impersonate you. You're tasked with solving the problem of whether or not someone knows something, without knowing what it is. Let me show you why this doesn't work:

  1. If you just send plaintext passwords, then every client needs to store every plaintext password of every user they encounter - and are thus able to impersonate every user they encounter. Not good!
  2. Just hash them, right? Imagine you "register" with me, telling me the hash of your password is 04C11DB7.... How can you authenticate to me then? You could send me your password in plain text, which means I can steal it. You could also send me that hash again, but then I could just in turn send your hash to other people. By just hashing everything, you made the hash the new password.
  3. Just add more hashes, right? No, it doesn't work. No matter how many layers you apply, I can always just take what you send me and send that to other people.

Your Answer

coderdd is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.