Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techcommunity.microsoft.com

Post reply on HN
Print view View original

61–70 of 160 posts

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

#61

Post by RandomInteger4 »

gpm wrote: post #33
RandomInteger4 wrote: post #28

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...

Sounds like a great way to create a huge security flaw for your users and their passwords, or a nifty method by which your attackers can DoS your site.

KISS.

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

#62

Post by mr_toad »

mikekchar wrote: post #56
methodover wrote: post #13

This is a good article. However, in regards to credential stuffing: > Some guidance says to ban all passwords on this list. Try that and see how successful your users are at choosing passwords at all. We're doing that. We don't let you choose any password that's been discovered in a prior breach. Did Microsoft implement the same thing and discover a high rate of users bouncing off the registration page?

Just idly wondering... I wonder how many AJAX style sites do password checking server side and send the password to the server in plain text...

Hashing the password on the client doesn’t really gain you anything. The hash becomes the password (effectively), and you end up having to hash the hash on the server side to maintain security anyway.

https://security.stackexchange.com/questions/8596/https-secu...

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

#63

Post by lopmotr »

dillutedfixer wrote: post #20

In my opinion, Microsoft's implementation of MFA on Office 365 (at least our instance) is broken. SMS MFA is inadequate and should not be used, the SS7 network is apparently trivially hackable in some circles and text messages can be rerouted. So they want us to use MS Authenticator, great. However the 365 login screen always has the "Sign in another way" option in which I can just bypass the Authenticator app and us…

These gaps would be obvious if services displayed all their authentication options completely in some graphical or table form. I personally would like a logic circuit diagram showing eg:

(password AND SMS) OR (password AND app) OR SMS --> Get in!

Then it would be obvious that the password is sort of redundant and it's really less secure than 1FA. It would also be clear what you have to lose to be locked out yourself. Only having 2 factors is not great because that's twice as many ways to get locked out. You really need 3 or more but it's never clear if that's reducing security to 1FA level or not because they don't clearly show you what the account recovery options are.

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

#64

Post by skybrian »

Someone1234 wrote: post #17

The number one reason I don't turn on MFA has nothing to do with the effort in entering the MFA code/pressing a confirm button. The lifecycle of MFA is the problem. The backup/recovery options are just terrible. You either print out a sheet of "one time codes" (which I need to not lose forever), my phone simply needs to never break, or I need to configure an insecure recovery account (creating a whole chicken/egg pro…

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.

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

#65

Post by lopmotr »

djakjxnanjak wrote: post #26
dillutedfixer wrote: post #20

In my opinion, Microsoft's implementation of MFA on Office 365 (at least our instance) is broken. SMS MFA is inadequate and should not be used, the SS7 network is apparently trivially hackable in some circles and text messages can be rerouted. So they want us to use MS Authenticator, great. However the 365 login screen always has the "Sign in another way" option in which I can just bypass the Authenticator app and us…

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're still trusting the phone company not to assign your number to somebody else, and that's what they're not good at.

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

#66

Post by jarfil »

mquander wrote: post #32
Someone1234 wrote: post #17

The number one reason I don't turn on MFA has nothing to do with the effort in entering the MFA code/pressing a confirm button. The lifecycle of MFA is the problem. The backup/recovery options are just terrible. You either print out a sheet of "one time codes" (which I need to not lose forever), my phone simply needs to never break, or I need to configure an insecure recovery account (creating a whole chicken/egg pro…

I was blown away when I discovered that there was no way for me to export my Google Authenticator TOTP secrets from my locked Android phone, since unlocking it wipes the disk. I guess I will not make the mistake of not immediately unlocking an Android phone again.

You can save the TOTP secret on your own when setting the Authenticator. Usually you have a choice between a QR code and a text, just save the text to your separate "account recovery" database in your password manager, then set the phone with the QR. I do that with any service not offering recovery codes for their 2FA (shame on you).

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

#68

Post by dillutedfixer »

quartz wrote: post #60
elliekelly wrote: post #50

Earlier quoted context omitted.

Can you explain this a bit further? We just switched to Office 365 and I ran into this today but I had assumed user error. So even though I have an authentication key set up there’s always the possibility that a password reset can be authenticated via my phone number?

Pretty sure you can remove sms from the 2fac process by going to: My Account > Security & Privacy > Additional Security Verification > Update Your Phone Numbers Used for Account Security And then setting the preferred method to "use verification code from app". Once you finish setting up the authenticator app you can delete your phone number from the 2fac list. At the end of that process you should be left with only…

When I uncheck Authentication phone I get a red error message: "Configure at least one phone so that if you lose the app you are not locked out of the account."

If You are able to remove it, I’m wondering if there is some sort of policy or limitation our VAR is adding to our instance.

edit - added quotes to the error message

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

#69

Post by jarfil »

spydum wrote: post #40
gpm wrote: post #33

Earlier quoted context omitted.

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...

I’m pretty sure that would be unmanageable, but love to see it tried.. Are you thinking of each character acting more like a number in a combination lock and needing to be provided to the app sequentially to be checked? I dont get how you distinguish between password managers and bots or API dictionary attacks on the same interface?

Isn't that essentially how the "I'm not a bot" captcha works though? And it seems to work pretty well.

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

#70

Post by nerdponx »

skybrian wrote: post #64
Someone1234 wrote: post #17

The number one reason I don't turn on MFA has nothing to do with the effort in entering the MFA code/pressing a confirm button. The lifecycle of MFA is the problem. The backup/recovery options are just terrible. You either print out a sheet of "one time codes" (which I need to not lose forever), my phone simply needs to never break, or I need to configure an insecure recovery account (creating a whole chicken/egg pro…

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?
Post reply on HN