Hacker News Reader

Comment by upofadown | Hacker News Reader

>Microsoft declined to comment specifically on Bill’s research, but said customers can block the overwhelming majority of account takeover efforts by enabling multi-factor authentication.

Or, of course, by not reusing passwords everywhere. ISPs can help by turning on some sort of brute force protection on SMTP and IMAP. They can also help by checking for completely obvious passwords (yes, by brute force cracking with a short list). Which brings us to this:

>But you also know they are accessing their email exclusively through an email client. What do you do? You can’t flag their account for a password reset, because there’s no mechanism in the email client to affect a password change.”

If only there was some way to communicate with a email customer...

View on HN

This is a common problem, if your only method of communicating with your customer is compromised (email), then you have no action except account disablement and require contact support some how, or accept the abuse.

Or, intercept non-encrypted http request, and inject popup messages via javascript... like ISPs have been doing already

how many websites do you visit without https?

Most computers will make at least one HTTP request to determine if there’s a captive portal, right?

I think only the ISP or the free wifi internet cafe gets the chance to capture that request though?

> Or, of course, by not reusing passwords everywhere.

At one of my jobs, we ran into this soon after launch. Attackers would loop through giant lists of leaked username / passwords using a different ips for every attempt. Blocking passwords at signup that existed in haveibeenpwned's database worked fairly well (and then later adding a required second factor).

> Attackers would loop through giant lists of leaked username / passwords using a different ips for every attempt

Mny password attempts for 1 username, isn't it easier to slow down attempts to authenticate the username after x tries, regardless of the IP? Just the fact that multiple IPs are being used for 1 username in a loop is enough of a red flag.

> Blocking passwords at signup that existed in haveibeenpwned's database worked fairly well

That's half a billion passwords to disallow?

> Mny password attempts for 1 username

Credential stuffing isn’t password bruteforcing. You don’t try half a billion passwords for one username. Instead, you try countless previously leaked username/password combinations from many ostensibly benign residential IPs. Each user account may only see one attempt. The goal isn’t to break into a specific account, but rather, to compromise as many as possible.

just pick which size list you want to disallow: https://github.com/danielmiessler/SecLists/tree/master/Passw...

If you refuse to out-source this capability for whatever reason, it's also ideal as a micro-service. It has no dependencies on your other components, all it does is take one parameter (the password or more likely an ordinary hash of it) and respond yes it's pwned or no it isn't.

> Mny password attempts for 1 username, isn't it easier to slow down attempts to authenticate the username after x tries, regardless of the IP? Just the fact that multiple IPs are being used for 1 username in a loop is enough of a red flag.

Nope, one attempt per username - they were using a giant list of hundreds of thousands of leaked credentials.

> That's half a billion passwords to disallow?

Yup.

Using IPs to block attempts is no longer feasible since the IPv4 shortage. Mobile carriers in Europe and even landline cable providers use NAT for IPv4, so thousands of legitimate users will appear to use the same IPv4.

> If only there was some way to communicate with a email customer...

I'm not really sure what the issue here is. When the ISP knows their customer's accounts are compromised it doesn't matter what type of client they use to check their messages they absolutely can "flag the account for a password reset" by simply resetting the password or temporarily disabling those accounts.

This forces the customer to call into the ISP the next time they try to check their email, verify their identity to the ISP, and then set a new password.

The customer might be angry about having to take the time, but in most cases telling them "Your account was hacked and they were accessing your email messages" is enough to change their attitude from annoyed to grateful.

You don't even have to wait for them to be compromised. I worked for an ISP that updated their system to require more complex passwords. They put out notices to get as many people as possible to reset their passwords then disabled every remaining email account in batches until everyone had called in to reset their password under the new requirements.

> The customer might be angry about having to take the time, but in most cases telling them "Your account was hacked and they were accessing your email messages" is enough to change their attitude from annoyed to grateful.

I guess you’ve never done tech support over the phone.

I've done abuse handling, so I've had to give all kinds of bad news to people after cutting them off from the internet. Some percentage of people are always going to be unreasonable, but the vast majority are glad they found out and we stepped in, even when it means they now have to take their PC into a shop, leave it offline until their nephew comes over, or pay their contractor to come in and get the infected machines off their network.

It helps that these days most people have the cell network for a backup and they can still get their social media fix

I did satellite television, so it's possible the clientele was different.

Microsoft’s 2FA implementation does not help because it allows attackers to guess the password first and the second factor next. They just don’t get it.

Sure. So, let's say you guess my password. Now you get prompted for the second factor, which you don't have.

In fact I have Security Keys, so, now you're trying to break AES, which you can't do.

But let's suppose you're attacking the average person whose second factor is a TOTP authenticator. Unsurprisingly Microsoft only give you a finite rate of tries at TOTP codes. And of course the correct code keeps changing meanwhile, so you can guess forever and never have better than about 1 in a 100 000 chance to guess a valid code each time. How many guesses do you think you get before your client is considered vexatious and can't try any more?

If the second factor were enough security why even have the password?

And how do you know the attacker is one client? He can just be 1000000 clients each only trying once. And if you block them you also block the user.

> If the second factor were enough security why even have the password?

Having two factors is better. But obviously neither of them should be a conventional password because passwords are crap.

You can have WebAuthn set to do usernameless authentication, with the two factors both being local. So when you visit a site with this behaviour and it wants authentication, you maybe touch your fingerprint sensor on your phone, that's one factor, having the phone is the other factor, that's two factors, the phone hands over credentials including a large identifier that's equivalent to a user ID for the site, plus its assurance that you are present (based on the fingerprint) and a signature proving it is still the same phone used to sign up for this method. No typing your email address, no passwords, much better security.

> He can just be 1000000 clients each only trying once. And if you block them you also block the user.

Yes, if you rate limit attackers you also rate limit the real user.

But as an attacker, what value am I getting from that? Maybe it's a chargeable service I can sell? It certainly doesn't help me steal gift cards.

$1000 per hour to annoy a friend by preventing them from logging into their email? Not many buyers at that price. $100 per hour? $10 per hour? $1 per hour? Remember that to fuel this you are throwing away a botnet so that you can hammer on the login until you get blocked, and botnets aren't that cheap to buy.

> You can have

Yes you can have proper security. But this is about the Microsoft solution where you don’t, where you can first guess the password and then guess the 2fa code. Which is not very smart, considering it’s not that much harder to check both at the same time and fail when either is wrong.

> it’s not that much harder to check both at the same time and fail when either is wrong.

You can't do that. Try to imagine what this looks like:

You're at the Microsoft login screen. Microsoft needs you to present both a password and...

* WebAuthn sign-in credentials, for which it must send data to your client

* a TOTP code, from the authenticator you may or may not have

* the SMS code, which you er... wait, what SMS code, how can Microsoft send it to you if you didn't say who you are?

* the email code, which again er... Microsoft can't send this until it knows who you are

* any other technology Microsoft adds later which may require any of the above or something else.

They can switch to display the right one when you enter your email address, they already do this. And of course indeed it doesn’t work with methods like sms and emailing codes, both of which are not secure anyway.

> They can switch to display the right one when you enter your email address, they already do this

So the effect here is this gives bad guys a free targeting feature. Just type in any email addresses and Microsoft will tell you which 2FA is enabled if any.

> And of course indeed it doesn’t work with methods like sms and emailing codes

So, it doesn't help at all for the good case, and it breaks the bad case worse, what was the goal again?

Sorry, but if you think emailing codes is the good case you’re beyond help.

WebAuthn is the good case, which is the case you didn't break since it doesn't care about any of this. And you made the bad cases worse. So good news I guess, "At least Microsoft aren't as bad at this as tinus_hn".

Ah, so you just don’t get it. That’s fine. Other people will improve things along the way.

Agreed. Second factor where you tell the attacker they got the password right before asking for the next factor isn't really 2 factor.

Either that, or you force the user to do a password reset if ever they provide the password but cannot provide the 2nd factor in the same login attempt. I think that would upset a lot of users though.

Shouldn't repeated failed 2FA login attempts trigger a notification to the user? Or password OK, 2FA failed login attempts at a different location that the user normally is at?

I mean if there's repeated login attempts where the password is correct but the 2FA is not that's a pretty good indication that the password may be compromised. I'd like to be notified of that.

You can't guess the 2FA code. It changes faster than you could ever attempt to test all combinations.

It doesn’t matter that the code changes, each guess has a 1/1000000 chance of being the right code. Yes you can’t guarantee you’ll find the code in 1000000 tries, but you still only need to do half of that to have 50% chance of a match.

If someone attempts 500,000 failed 2FA attempts on an account, I think its safe to lock that account/take extra steps.

But you could try ~100 password variations and then attack the 2FA.

Up until recently SMS 2FA could be broken for $10 because one VOIP provider allowed number registration on any number.

If you can filter 10,000 accounts down to 100 with known passwords, now you just have to bypass 2FA on 100 accounts.

How can you register a number if its already registered?

A common service offered (I think required to be offered, actually) by telephone service providers is "number porting" - where you switch providers but keep the same number, because people don't like changing phone numbers more than they have to.

It used to be this didn't have any real backend checks, so you could effectively steal someone's number, at least temporarily.

> Up until recently SMS 2FA could be broken for $10 because one VOIP provider allowed number registration on any number.

Surely not?

> "I used a prepaid card to buy their $16 per month plan and then after that was done it let me steal numbers just by filling out LOA info with fake info," Lucky225 added, referring to a Letter of Authorization, a document saying that the signer has authority to switch telephone numbers.

From 2021:

https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-1...

EDIT: yea it's not 'registering' the number but rather rerouting a copy of all messages to another number.

> yes, by brute force cracking with a short list)

Possible without if they're only checking during password reset or account creation.

sending email to a address controlled by a hacker isn't super effective.

My email was hacked and the attacker used that to reset my Delta password to clear out my points to use on the marketplace where you could exchange them for gift cards.

What's interesting is that they logged into my webmail to create rules to forward all mail from Delta to trash so that I wouldn't see any of the notifications.

If your only method of contacting your customer is via email and the email is demonstrably controlled by a hacker then you have a hacker for a customer.

If email isn't your only method of contacting your customer... then sending an email to an address controlled by a hacker isn't your only option.

> If your only method of contacting your customer is via email and the email is demonstrably controlled by a hacker then you have a hacker for a customer.

That's obviously false. The context of this very discussion is that more than one person is able to log into an account for many email accounts.

A previous comment mentioned the hackers setting up rules to automatically delete messages that would inform the user they were hacked.

Sure but the hacker can trash the email.

Thanks for agreeing.

It seems like they tend to not change the account password. If anything, changing the password could be counterproductive because they seem to want access to look for stuff more than exclusive control. the longer they have access more likely they are to find something valuable.

In terms of notifying them, I think an email would be appropriate, although straight up saying that the customer's account has been compromised might not be the best idea because the hacker could update their software to look for that. It might be better to send an email about some billing issue, and when the customer calls then explain to them that their account has been comprimised.

Whatever wording they chose, if any major email provider they went down this route hackers would learn to identify these emails soon enough and automatically delete them from compromised accounts

If the server software were smart, it could consider certain emails undeletable for 7 days.

I often wonder why Gmail 'Suspicious login' emails aren't like this.

They could. The success of that approach would vary though. The email provider could look for that too and resend the email. They could also disallow rules that block emails from them in this case.

The user could also get the email on their device if the hacker doesn't delete it quickly, which is a possibility given the low and slow nature of this scheme.

Reply on news.ycombinator.com