Live data from Hacker News

When it comes to composition and length, passwords mostly don't matter

techcommunity.microsoft.com

71–80 of 160 posts

Re: When it comes to composition and length, passwords mostly don't matter

#71

Earlier quoted context omitted.

> No SMS text option. ... ridicolous Agreed. My Twitter account was recently hacked thanks to T-Mobile's incompetence. [0] [0]: https://medium.com/@simon/mobile-twitter-hacked-please-help-...

I'm confused... because the whole reason your twitter was able to be hacked was because the SMS option allowed it to be hacked.. They stole your SIM. SMS option was now in their control. SMS is not a secure 2FA option. sure its better than not having 2FA but only a little better.

Everything you said agrees with what simonebrunozzi said. SMS is a bad 2FA option.

Re: When it comes to composition and length, passwords mostly don't matter

#72
post #14

> Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA. An important thing to remember here is that MFA works with a password. Otherwise, that 99% goes down dramatically because I can just steal your phone/Yubikey/whatever. This article isn't suggesting that we get rid of passwords. It's suggesting that the energy we spend making sure that passwords are good would be bett…

> Otherwise, that 99% goes down dramatically because I can just steal your phone/Yubikey/whatever. If this were true your car would probably get stolen a lot more often. You're less secure from targeted attacks from people who know you IRL but that's a lot rarer than the attacks you'll actually encounter.

It's less about "how do I steal this partícular guy's phone", and more about "how do I use this random stolen phone to access any accounts it was used with".

Re: When it comes to composition and length, passwords mostly don't matter

#73
post #58
post #18

Earlier quoted context omitted.

Furthermore many sites make it difficult to use a password manager because it's hard to block automated password guessers and not interfere with password managers trying to enter passwords.

My old bank used to "encrypt" your password as you typed it into the input field, on keydown it would take the character you typed and — and I'm not making this up — ROT13 it . This had the effect of making it impossible to paste anything into the input field since the script would capture your ctrl+v and replace it with the letter "i". The icing on the cake is that when I called to complain about it, the support age…

>since the script would capture your ctrl+v and replace it with the letter "i".

not an issue on firefox because you can toggle the dom.event.clipboardevents.enabled to false, and sites won't be able to hijack your pastes.

Re: When it comes to composition and length, passwords mostly don't matter

#74
post #18

> Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA. I'd be much more interested what that percentage is when you only consider people who use password managers. (Which is not to imply that MFA isn't good.)

Furthermore many sites make it difficult to use a password manager because it's hard to block automated password guessers and not interfere with password managers trying to enter passwords.

[deleted]

Re: When it comes to composition and length, passwords mostly don't matter

#75
post #33

Earlier quoted context omitted.

The web developers that think like this are bad at web development, and likely security. Why would anyone trying to brute force your authentication portal care about using your UI?

This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots. You'd probably mostly catch password managers and people copy-pasting passwords though. If you had per-user fingerprints also people typing on a new device...

>This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.

at that point you might as well outsource that sort of fingerprinting/behavior analysis to some service like recaptcha.

Re: When it comes to composition and length, passwords mostly don't matter

#76
post #65

Earlier quoted context omitted.

Does anyone know if there’s a way to prevent your SMS from being rerouted, or get a special protected number? The ability to do this would not mitigate Microsoft’s responsibilities here, but at least it would allow some people to help themselves.

If you had that protection, what would you do if your phone was lost/stolen and you wanted the number transferred to a new SIM card? You lose your number forever if it was impossible to transfer. If there's some way to transfer it, like showing your passport in person in the phone company's office, a hacker can pretend to be you and do that too if your account is valuable enough to be worth the risk. Ultimately, you'…

I guess I’d like the ability to delegate the responsibility of updating the ownership of my phone number to an entity of my choosing. The phone company would only be able to update with this entity’s go-ahead. Services could specialize in this kind of work so identity verification would be a core competency, and I could pay more for better protection.

Re: When it comes to composition and length, passwords mostly don't matter

#77

Earlier quoted context omitted.

The point of the article is that many common attacks work just as well against completely random, unique passwords as they do against weak/reused ones. If you get phished, it doesn't matter if your password is strong. If your machine has a keylogger on it, it doesn't matter if your password is strong. Etc. Lots of attacks boil down to the attacker convincing you to unknowingly divulge your password, and if that passw…

> unknowingly divulge your password What's to keep you from unknowingly divulging your MFA token's current generated code? You're right that being phished/keylogged pwns a password-only account no matter how strong the password, but MFA isn't immune to phishing/keylogging/clipboard stealing either. Yes, the generated code will only give them access for 30 seconds (or whatever the algorithm's time window), but that's…

My main gripe with MFA, is that once you have 20+ services each one with a different token, it becomes tedious to sift through them to find the right one. I'd much rather have some MFA app capable of detecting where you're logging in, and a "click to authorize" option.

That wouldn't completely stop someone from being able to steal the token, but it would thwart most simple keyloggers.

Re: When it comes to composition and length, passwords mostly don't matter

#78

Note this is from the perspective of a security decision maker, like an IT administrator. Policy-wise, users can't be forced or trusted to create excellent passwords on their own. But as an individual, your passwords do matter. It makes a world of a difference to use a password manager and long, completely random passwords - such passwords are immune to all sorts of cracking attempts, and using them can often make MF…

The point of the article is that many common attacks work just as well against completely random, unique passwords as they do against weak/reused ones. If you get phished, it doesn't matter if your password is strong. If your machine has a keylogger on it, it doesn't matter if your password is strong. Etc. Lots of attacks boil down to the attacker convincing you to unknowingly divulge your password, and if that passw…

I don't agree that the conclusion from that is that it makes no difference whether your password is weak or strong. It does make a difference, just not for attacks that don't depend on password's length.

I.e. make your passwords strong either way. It will be only worse if you won't.

Re: When it comes to composition and length, passwords mostly don't matter

#79

Earlier quoted context omitted.

This is why you need two options. It could be a yubikey and your phone, or a yubikey and backup codes kept in a safe, or two yubikeys, one of which might belong to a trusted relative. Or if you're really worried about getting locked out, maybe three options.

And keeping a truly reliable backup is hard. Do you print out recovery codes, laminate the paper, and put them in a fire resistant home safe, or a safe deposit box?

> And keeping a truly reliable backup is hard. Do you print out recovery codes, laminate the paper, and put them in a fire resistant home safe, or a safe deposit box?

This had me thinking about off-site backups and eventually my mind got to steganography (as the trust placed in the off-site custodian is a lot). It's a shame backup codes don't match phone numbers in terms of digit count, that would make keeping a book of them more easy to obscure, or even leaving a couple in your synced contacts as unassuming names.

Re: When it comes to composition and length, passwords mostly don't matter

#80

Earlier quoted context omitted.

> No SMS text option. ... ridicolous Agreed. My Twitter account was recently hacked thanks to T-Mobile's incompetence. [0] [0]: https://medium.com/@simon/mobile-twitter-hacked-please-help-...

I'm confused... because the whole reason your twitter was able to be hacked was because the SMS option allowed it to be hacked.. They stole your SIM. SMS option was now in their control. SMS is not a secure 2FA option. sure its better than not having 2FA but only a little better.

> sure its better than not having 2FA but only a little better.

I'm becoming convinced this is a pervasive fallacy (perhaps not for all users in all cases, but for many). Having SMS as your 2FA potentially makes your phone, phone line, and everything linked to it an attack target. So you might lose a heck of a lot more than you would if they were all unlinked. It depends kind of on what your current security practices are, but I think for many it can well be indirectly risking more damage than it's preventing.

Post reply on HN