I was a big fan of Troy until relatively recently. He's turned to bullying and ridiculing people publically who don't agree with his positions on security. I blocked him on Twitter after I realized that I wasn't the only person who noticed, and that I had made at least a couple tweets that could make me a target.
That being said, what I really want to see someone do is make an Active Directory plugin for Pwned Passwords. Corporate networks are both most at risk and most often where you find bad passwords.
Troy doesn't really have that many positions on security matters other than "as an operator of a website, you must offer HTTPs". Is this the topic you're referring to?
One for sure, but he's also pretty adamant against password reuse of any kind on any site no matter how trivial and in favor of cloud-based password managers, which, while very much the current mainstream opinions today, I disagree with fairly heavily. I'm willing to bet many of these approaches will be seen in a different light in a few years, just like we no longer favor regular password rotation in recommendations today.
There's significant problems with all of those views, and while arguing about each one would be a larger discussion, Troy's behavior towards people who don't agree with him is concerning.
Well yes, his views on password reuse are obvious, and that password managers are the best option for most people are clear, but I haven't seen any tweets shaming people for these things. So I assume the bullying behaviour you're referring to is regarding HTTPS.
If that's the case, then you should probably be more clear. He ridicules people for not using HTTPS is a much weaker claim than that he ridicules people for not agreeing with his security principles.
First and foremost: Password managers create a huge single point of failure. Every password manager has had security vulnerabilities, and of course, if it's cloud-based, it's far easier to gain access to it. You think password reuse is bad, try a password manager, where all of your passwords are only exactly as secure as your master, your only real password. And this leads you to treat all your accounts similarly, when in fact, many of them are more important than others.
So password managers are a bad solution, and they're a bad solution to a problem that otherwise takes over the password reuse issue: Security exhaustion. When confronted with extreme complication, frustrated users will fall back to something poor to keep themselves sane. (See the common "season + year" password format that constantly defeated password rotation as being a good idea. It met complexity requirements and rotated, but was a terrible password.)
There are passwords that should always be unique, your email, your web hosting, your bank, etc. But rather than waste effort ensuring every account known to mankind has a unique password, you should consider how many of your accounts matter. Your HN account probably doesn't matter. If you don't store your credit card details with a site, your random retailer account probably doesn't matter. (Go ahead, log into my Target account, see what you can do with it that harms me. You'll learn I once bought a Taylor Swift album, and everything else was already contained in public records.)
You are far better off reducing the impact of an account breach affecting your security and privacy than trying to ensure your account on any given website is ironclad. And for most people, I'd recommend a scrap of paper in their wallet with some key passwords over a password manager.
Also, a bonus fun fact: I changed my email address about three years ago, and have yet to receive an HIBP breach notification for it. So while I'm regularly getting breach notifications for loss of passwords from time to time, none of them are tied to my current email address for the past few years. Which is to say, if you do have a handful of reused passwords, and you rotate them every couple of years on whatever accounts you're currently interacting with, even your low security accounts are very unlikely to be breached because the data that gets passed around tends to be fairly old.
I'm not trying to say I'm the definitive expert on online security by any means, but treating the currently accepted practices as the be-all-end-all is bad, and bullying people for disagreeing with them is even worse.
His website is now one giant advertisement for 1password, so, yes, he does have a strong, biased (because ttey pay him), opinion on at least one security topic.
Credit where credit is due, I don't think Troy advertises things he didn't think was right first. As much as I'm criticizing Troy, I do believe he legitimately believes in password managers... I just think he's wrong.
There's a big difference between believing in using password managers, and using your position to promote a very specific one (and one that is proprietary, lol). The former is admirable, the latter is malicious.
I don’t understand. If you’ve rightfully decided not to offer sms as a 2 factor option because of its poor opsec (number porting, sim cloning, etc.) why then offer it as a recovery option. Your 2-Factor is only a secure as the weakest recovery option.
The client attempting to bypass password complexity checks on registration is not part of most threat models. I.e. they're not an attacker, it's more of a user aid.
More serious reason is imo js requirement, as I'm not aware of native support of password hashing in HTML forms. Also, different ways of hash keying/salting would make it either complicated or inflexible..
That would mean that you trust the client completely to log somebody in. What's preventing somebody from bypassing the clientside bcrypt check?
As long as the password is sent over a secure channels (TLS) and doesn't leak somewhere on the server (e.g. logs), sending it plaintext from the client is not where most password breaches come from. But stuff like https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... would provide a solution for that.
29 comments
[ 5.1 ms ] story [ 72.2 ms ] threadI guess that most website should do the same and progressively warn users that their password is weak and is listed in a popular password list.
Of course it's bothering users, but frankly it should be done.
That being said, what I really want to see someone do is make an Active Directory plugin for Pwned Passwords. Corporate networks are both most at risk and most often where you find bad passwords.
There's significant problems with all of those views, and while arguing about each one would be a larger discussion, Troy's behavior towards people who don't agree with him is concerning.
If that's the case, then you should probably be more clear. He ridicules people for not using HTTPS is a much weaker claim than that he ridicules people for not agreeing with his security principles.
First and foremost: Password managers create a huge single point of failure. Every password manager has had security vulnerabilities, and of course, if it's cloud-based, it's far easier to gain access to it. You think password reuse is bad, try a password manager, where all of your passwords are only exactly as secure as your master, your only real password. And this leads you to treat all your accounts similarly, when in fact, many of them are more important than others.
So password managers are a bad solution, and they're a bad solution to a problem that otherwise takes over the password reuse issue: Security exhaustion. When confronted with extreme complication, frustrated users will fall back to something poor to keep themselves sane. (See the common "season + year" password format that constantly defeated password rotation as being a good idea. It met complexity requirements and rotated, but was a terrible password.)
There are passwords that should always be unique, your email, your web hosting, your bank, etc. But rather than waste effort ensuring every account known to mankind has a unique password, you should consider how many of your accounts matter. Your HN account probably doesn't matter. If you don't store your credit card details with a site, your random retailer account probably doesn't matter. (Go ahead, log into my Target account, see what you can do with it that harms me. You'll learn I once bought a Taylor Swift album, and everything else was already contained in public records.)
You are far better off reducing the impact of an account breach affecting your security and privacy than trying to ensure your account on any given website is ironclad. And for most people, I'd recommend a scrap of paper in their wallet with some key passwords over a password manager.
Also, a bonus fun fact: I changed my email address about three years ago, and have yet to receive an HIBP breach notification for it. So while I'm regularly getting breach notifications for loss of passwords from time to time, none of them are tied to my current email address for the past few years. Which is to say, if you do have a handful of reused passwords, and you rotate them every couple of years on whatever accounts you're currently interacting with, even your low security accounts are very unlikely to be breached because the data that gets passed around tends to be fairly old.
I'm not trying to say I'm the definitive expert on online security by any means, but treating the currently accepted practices as the be-all-end-all is bad, and bullying people for disagreeing with them is even worse.
It seems so weird to me that the passwords are not hashed leaving the client, and it’s considered good practice.
if you just pass the hash back to the server, you can't verify that the password was secure.
More serious reason is imo js requirement, as I'm not aware of native support of password hashing in HTML forms. Also, different ways of hash keying/salting would make it either complicated or inflexible..
As long as the password is sent over a secure channels (TLS) and doesn't leak somewhere on the server (e.g. logs), sending it plaintext from the client is not where most password breaches come from. But stuff like https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... would provide a solution for that.