I feel like the argument being made is unclear, and the conclusion does not follow.
The argument, as I understand it, is this: 1) Users are well-trained to use HTTPS to send passwords 2) Passwords are vulnerable to snooping by staff at websites, through various means 3) Through the third-party doctrine, users cannot expect privacy of their passwords (and I'm being specific about the passwords themselves) The conclusion, however, appears to be one of two choices: 1) Users should ignore advice to use separate passwords. The risks of 1, 2 and 3 mean that using a shared password across services is preferable to an unstated risk of using different passwords; or 2) Server operators should use the technology being developed by OP's employer Incidentally, the page at https://cbcrypt.org is somewhat more coherent about this issue, and, although uncredited in the original post, is clearly a source for much of the original argument. Ned's been part of this community for some time, and I genuinely believe he is trying to help improve the state of the art, rather than astroturfing for his employer. However, even the page at https://cbcrypt.org has some issues. First, I'll take issue with the notion that users are well-trained to use HTTPS. People suck at crypto. The user interface indicators of HTTPS are too subtle, and users often fail at using them. (http://www.troyhunt.com/2011/07/padlock-icon-must-die.html) Next, the article at https://cbcrypto.org actually agrees with using multiple secrets for a site, but, instead, uses a separate asymmetric key for each site (and each user, and more factors). ("CBCrypt deterministically generates a public/private keypair unique to each specific user, on a specific server, using a specific password. Any variation of any of these factors results in an entirely different and unrelated keypair.") Finally, the article at https://cbcrypt.org appears to be advocating client-based crypto in an environment where client machines cannot be trusted. This is why JavaScript Crypto is generally dismissed by experts (not that CBCrypt is necessarily JavaScript Crypto) -- there's no way to verify that the client is running code that doesn't leak passwords. Take the PHP example given in the article -- why couldn't I replace the CBCrypto component on a client system with one that does all the same things, but also sends the passwords to a collection botnet? Obviously, CBCrypto implementors will take precautions against this, but, so far, no one has cracked this issue, and there's no evidence presented that CBCrypto has a novel approach to this issue that solves a heretofore-unsolved problem. (I'm not saying that solving the problem is impossible, just that it's hard enough that it requires a dedicated effort, and CBCrypto does not give any attention to this issue in the article, so there's no reason to suspect they have a new solution.) In the perfect world mentioned above, would you reuse passwords? Practitioners of good OpSec would not. This is one of the main reasons for sudo -- if you have an administrator leave, you don't have to change everybody's password. Similarly, most of us would advocate using different passwords for banking vs reddit. So, really, I don't think the argument that "is should be OK to reuse passwords" actually holds up. My last point is about the threat model. In a shared-secret environment, if I'm able to guess the shared secret, and that secret is used across multiple properties, then I've exposed multiple properties. It doesn't matter how the shared secret is exposed -- it could be guessed without compromising any data or code. The key threat today is that unsecured (or inadequately secured) passwords are being captured at one site and reused in another. (http://www.troyhunt.com/2012/07/what-do-sony-and-yahoo-have-in-common.html) >From what I'm reading, CBCrypt agrees with this position -- the authors do not advocate reusing shared secrets. Instead, they want a computed proof, rather than presenting a secret. However you do it, you have to respond to the current issue, and reusing passwords does not do that. I'm certain the industry will invent a better mousetrap some day. For now, though, my advice to users remains 1) Use different, randomly-generated passwords on different sites (and use a password manager so you don't have to tax your memory to do so), and 2) Use multifactor authentication, especially time- or host-varying tokens, everywhere you can. I feel like the original OP subject is hyperbole, intended to draw a response (and, to some degree, I do not feel good about responding, but enough others have that I think the cat's out of the bag). I don't think Ned really advocates telling users to actually reuse passwords on sites; instead, OP wants to tell server operators to upgrade their technology. It would be good for Ned to acknowledge this. If Ned actually thinks that people should go back to reusing passwords across sites without other technology changes (as implied by the subject of the message, and by the lack of any nearby qualification), then I think it's irresponsible and unethical. On Sat, Sep 19, 2015 at 4:40 PM, Edward Ned Harvey (lopser) < lop...@nedharvey.com> wrote: > > From: Tracy Reed [mailto:tr...@ultraviolet.org] > > > > I'm not sure I understand you here. But my initial reaction is to > caution you > > against confusing the public by pushing this. They are much better off > using > > separate passwords and a password manager. > > Everybody knows they shouldn't login to anything over HTTP. Even the most > non-technical people I know have been trained to use HTTPS. > > You don't know your Verizon tech guy any better than you know the > employees working at Dropbox, Google, Yahoo, or whatever. > > > > We should also assume (because it is true) that it is much easier for > bad guys > > to access the passwords in the database than in memory post-decryption or > > in > > the decryption software itself etc. > > Whatever site you're operating, there is a form that users HTTPS POST > their password to. That form has the actual plaintext password available, > and calls bcrypt or whatever. > > In wordpress, I just did this: > grep -lir bcrypt wordpress > > And found this: > wordpress/wp-includes/class-phpass.php > > Which is a PHP file, that I could trivially edit, which has access to > passwords submitted to my site over HTTPS. > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
