2

So my question or hypothesis is that: most people use only a few passwords for all online services, getting one of these passwords means you could access that person's sites easily which don't have any other login security (e.g. 2-factor). A website that takes passwords and emails can store those passwords maliciously, or a hacked site can do so...

Two options come to mind:

  1. Hash the password client-side. Yes, "then the hash becomes the password", but if each site uses a slightly different hashing algorithm, then the same plaintext password will result in a different hash, and knowing the hash from one site does not help an attacker get into another site.

  2. Could we implement a zero-knowledge algorithm for passwords?

schroeder
  • 123,438
  • 55
  • 284
  • 319
benbyford
  • 211
  • 2
  • 7
  • Doing something on passwords the client must be repeatable between all clients (otherwise, you won't be able to login with the same password from different clients). It means the process is predictable. So a malicious server could ask the client to do what the targeted server will require (ie: malicious server asks client to hash password like the targeted server would require), making this useless. This would have to be network/browser implemented, not server's decision. – Xenos Apr 06 '17 at 08:11
  • 1
    then the hash becomes the password – schroeder Apr 06 '17 at 08:27
  • 1
    Who is "we"? The public? Website designers? Security pros? – schroeder Apr 06 '17 at 08:28
  • hash is the password indeed, but is that better is the question? better than knowing their free text password? – benbyford Apr 06 '17 at 08:39
  • **We** developers of services – benbyford Apr 06 '17 at 08:39
  • Or can we do something else which is zero knowledge instead of passwords to grant access to a service? – benbyford Apr 06 '17 at 08:42
  • This question has been flagged as "too broad". I think the core question is good, so I have taken a stab at removing the fluff and bringing out the core question. If you don't like what I've done, you can revert it [here](https://security.stackexchange.com/posts/155806/revisions). – Mike Ounsworth Apr 06 '17 at 14:36

3 Answers3

1

This is not a definitive answer, just some thoughts.

1. Client-side hashing.

I see what you're going for: protecting the plain-text password. An idea like this relies on every site using a different hashing scheme (otherwise you can make lists of which sites use the same hashing scheme and know that their hashes / passwords will be interchangeable).

So I guess this would help a little, but certainly doesn't solve the problem, and relies on devs changing their hashing schemes from the default (which is dangerous for other reasons if they don't really understand how password hashing works).

2. Zero-knowledge proof based on password

I am not an expert in Zero-knowledge proofs, but my understanding is that they are a subset of Public Key Algorithms. Symmetric-key algorithms (like AES encryption) can easily be combined with passwords ... public key, not so much. My intuition is that if you flesh out this idea fully, you're basically going to re-invent client-authenticated SSL, so just use that?

Misc comments

IMO passwords as a whole are a sinking ship; they are a broken system. This is because we are at the point in history where hacker's ability to brute-force passwords is starting to surpass the human brain's ability to remember complex passwords.

Rather than trying to patch a sinking ship, I suggest that we (as an industry) move as quickly as we can to adopt non-password-based auth systems. Things like 2FA or ssh keys do not have the same fundamental problems as passwords, and are the kinds of solutions we should be embracing.

P.S. At time of writing, the question has 3 close votes as "too broad". I've done a dangerous thing here where I edited the OP's question to be less broad, then posted an answer to the newly-worded question. I hope this is acceptable.

Community
  • 1
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Any client-side solution falls apart if the attacker modifies your page (be it a man in the middle, arbitrary code execution or XSS) instead of just plain old leaking the database. – John Dvorak Apr 06 '17 at 15:34
  • @JanDvorak Define "falls apart", you mean worse that the original of sending the plaintext password to the server? – Mike Ounsworth Apr 06 '17 at 15:36
  • Well, it's not "worse than" the original, merely "as bad as no defense at all" – John Dvorak Apr 06 '17 at 15:37
  • Great anwser thanks. "IMO passwords as a whole are a sinking ship" couldnt agree more. – benbyford Apr 06 '17 at 15:49
  • Passwords are not a sinking ship. Provided you use them *as they should be* that means correct passphrases for local authentication and random passwords generated by a password manager for remote authentication, they are still an acceptable alternative to a federated authentication system because of privacy concern, and PKI systems because of simplicity. – Serge Ballesta Apr 06 '17 at 16:14
1

This is, admittedly, just a "personal opinion" type answer to a broad question, but...

The answer you're really looking for is a centralized, trusted, authentication system for online services, with frictionless setup and federated authentication. Basically, you (we) need something like Facebook for authentication, but where the organization wasn't willing/able to track individual usage across multiple sites, and the people were in control of their personal information (ie: a unique token code is given to each site for each user, personal data is only released on an opt-in basis, etc.). Then sites wouldn't need to store passwords at all, and the problem just goes away (most everyone can keep access to one system reasonably secure, especially if that system had good access security, TFA, etc.).

That system, unfortunately, does not currently exist, and might be impossible to build (and even if it could be built, might be impossible to keep solvent as a business entity)... but that's the "real" answer, imho.

Nick
  • 199
  • 4
  • fair, and a good solution. hopefully its not the only one, and Maths can come to the rescure as it did with RSA encription. But you're right a single sign on central solution would be a great user experience – benbyford Apr 06 '17 at 17:33
0

The answer you are looking for is in your question: do not let users use the same password as on other websites, or enforce two factors authentication (2FA).

How to prevent user from reusing passwords? On the client side, next to the password field, place a button to generate a long random password. Place a lower bound (16 for example) on the size of the password so that most passwords will not fit: this will give the incentive to use the generated passwords. You can also advise your users to let their browser remember the password.

However, you can expect a drop in the number of your users, as some might be repelled by these constraints. But there are psychological ways to make them do this extra step, such as making them fill an easy form to create their account, then on another page you ask for their password stating it's the last step. Most will not want their time spent on creating an account going to waste at the last step.

A. Hersean
  • 10,046
  • 3
  • 28
  • 42
  • great anwser! and I totally agree. I was just wondering if its worth making something new or different than this strategy, as you rightly pointed out, its not ideal for users – benbyford Apr 06 '17 at 12:30