Are you deliberately trying to troll me?

Look man, you either completely misunderstood (my bet) or purposefully misrepresented what notabot said, and all I did was come here in good faith and try and explain it to you. You have, for 3 days now, completely missed it, and pointed out that back-end enumeration mitigation isn't the specific feature you're complaining about.

I never once said that it was.

The only concept I've been trying to communicate to you, through my own frustration, is this:

On a simple login endpoint, if there's bits of information that differentiates one scenario from another, then you have provided a vulnerable surface that can be abused to extract information.

It doesn't matter how likely it is.

It doesn't matter how hard it is.

It doesn't matter if we're talking about an embedded device, an api endpoint, or a database server.

It doesn't matter if that information is a response code, a failure message, or a response time.

If youre responses are differentiable based on enumerating the possible inputs, that leaks data.

I'm aware that has nothing to do with showing you a pretty little message. I just wanted to be a source of information for you.

I have been patiently explaining the core of the above concept through simplified examples, and attempting to engage in a meaningful discussion where (hopefully) you walk away knowing something new.

I never set out to lay out the grand design of a perfectly impregnable digital fortress, nor by contrast explain the nuances of every single technique in the hacker's arsonal. I never suggested you were wrong that websites can securely tell you your password's expired. I was explaining the idea behind notabot's comments which you clearly didn't understand.

That's not to say I agree fully with notabot, but they came here, and they tried to tell you about a concept they knew a bit about. That's kind. Correct or not, they tried doing something nice for you.

You mischaracterized what they were trying to say, so I tried to step in and fill in a few conceptual blanks for you. Next time I'll just keep my mouth shut. I'm sorry I intruded into your safe space where you just wanted to feel vindicated in how you felt due to a bad user experience.

Have a nice life.

P.S. DDOS doesn't mean what you think it does. Its broader than that. DOS = Denial of service. That can take many forms. One form would be overwhelming the infrastructure and causing the service to stop responding. That's what you're thinking of. Another form would be making it where all the users can't log in. Same effect, the service isn't being provided anymore. Nobody can log in. D = distributed, meaning you can't just IP block the jerk who's keeping your users locked out. And locked out doesn't necessarily mean what you seem to think it does either. One form of lockout means "contact the admin so they can unlock your user", another means I just keep failing to sign in as you, hundereds of times, and the service never lets the real you in, correct password or not. I hope you at least learned a few new words today.

Oh well, survivorship bias I guess

I love you

This may be the most upvoted post I've ever seen on lemmy

I'm not.

I'm just pointing out that they open you up to DDOS attacks (and before you point this out, yes there are mitigations for those too)

Anyway, I concede that if you're only returning "expired" responses when the user enters the correct, but expired password, you mitigate a lot of the surface I was referencing.

I was mostly trying to use simplified examples to demonstrate principle, and when you kept poking holes in them, I became frustrated, because I was never trying to holistically describe or prescribe protection against literally every attack vector, I just wanted to explain the specific reasoning why someone would make this choice.

For the record, I'm not a security guy, I don't implement login endpoints, I'm just a nerd that finds this topic fascinating, and I love infodumping when I get the chance. I'm sorry for how it came across.

I can see you're determined to be "right" here and aren't interested in the reason systems are implemented that way. So I'll drop it here and let you "win".

I'm tempted to inform you about DDOS attacks and how allowing all your users to get locked out due to a determined and persistent threat is probably a worse user experience than not having a "Your password is expired, please change it" message, but no, you're totally right, and somehow I just couldn't see your brilliant solution to all the problems I mentioned and was determined to naysay you. My bad.

We could just concede every time to the user experience guys, and hey, we probably should, life's a lot more fun when you ignore security best practices.

further the displayed message can be hidden from api calls but show to the user.

The UI has to get the information from the backend somehow in order to distinguish wrong from expired.

The back-end responding differently based on status reveals information.

You say unlikely. I say it depends on how valuable you are as a target.

Edit:

password lockout makes brute force a thing of the past

OK so I just hammer your login endpoint for each user I've found until all your users are logged out.

Then I continue doing this every day until you stop using password lockouts.

ban my IP

Great, I have 8 VPN subscriptions and thousands of potential IPs, let's go for broke here.

manually trying to guess is even worse.

When targeting a single user, sure, but at scale the tables turn. One of your users uses a weak password, or a re-used password.

you likely would have more success with just trying the list of most common passwords.

Yeah this was just an example, I'm not trying to give a tutorial.

You got the supposed user name list from the 404/403 which is not related to being clear about the error for the user I am talking about.

Sorry if this didnt land, but I had hoped my payload thing demonstrated the whole "if the different statuses are distinguishable from one another, you're leaking information" thing.

further the displayed message can be hidden from api calls but show to the user.

Cool but the UI has to know which message to display. No matter how you spin it. You can return 418 "I'm a teapot" responses for expired passwords, and 403 for wrong passwords, and 404 for no user found, but the principle is the same. You are leaking information about the users by responding differently.

it does not need to be plain text as we are talking about user usability.

Sure, it could be no text, and I could still scrape information, so long as the responses are different between statuses.

Ok, great, working from your example and my example combined, in order to continue the illustration:

I'm still the same hacker. I've got the list of valid usernames, and I'm trying to figure out where to put my effort for cracking passwords in.

When I hammered the login endpoint I noticed something interesting:

• most responses were 404 Not Found (no user by that name)
• some responses were 403 Unauthorized (invalid login)
  • But the payload of the responses varied across the 403 responses:
    • most had {"error": "invalid password"}
    • but a few had {"error": "password expired"}

This is fantastic! The server's login endpoint gave me all the information I needed to filter this huge list of real usernames into something more reasonable to work with! Additionally, if a user's password is expired, there's a higher likelihood its an abandoned account (won't notice when I log in as them), or someone who doesn't take security all that seriously (ideal social engineering victim), so essentially I have a list of this service's most vulnerable users.

So let's say I take this list and focus all my energy on breaking in as them. Lots of options for that:

• I could try brute-forcing their password
  • pros:
    • will eventually work (unless the user changes their password to something I've already tried during my attempt)
    • cons:
      • loud, noticeable
      • takes forever
      • costly
• I could try finding them (lots of people use the same username across services, so I find them on Lemmy, learn their dog's name, country, married status, industry, perhaps even real name, by digging hard enough, then I target my password attempts to probable combinations)
  • pros:
    • learn about people
    • make a few friends along the way
    • higher likelihood of success
  • cons:
    • learn about people
    • make a few friends along the way
• I could try searching for this username in leaked database tables

... Actually, look, I hope you get it at this point, I don't have to write a book. You don't need an exhaustive list of all the ways people find and crack passwords. You just needed to know how responding with "expired" vs a binary "invalid"/"valid" response weakens security, and if I haven't demonstrated that to you at this point, I'm wasting both of our time.

Responding with additional information makes hackers' jobs easier.

That's what we're all trying to say.

People are just people. Everyone thinks they're the good guy. Hate hurts you more than them.

Your message to me reads like someone who is upset, so right up front I'm going to say that I understand where you're coming from and it's not wrong to feel the way you do about this.

However, the other reply-er is right about the security problems with what you're asking, and I'm going to try to illustrate why.

If that's not something you're interested in, you don't have to read this. I'm not calling you out or anything, I'm just trying to fill you in.

Let's imagine I'm a hacker, right?

And I want to get into a particular service, but I don't have any credentials. How to solve this problem?

Let's just try figuring out the usernames in-use first.

I make a web request to the sign in service. I get a "404 Not Found" response (or, in this case, a "no user exists with that username" message on screen)

Awesome, I'll just write a quick script that hammers the sign-on endpoint with every conceivable username I can enumerate. Most get 404s, a few get "403 Unauthorized" (or an "invalid password" message). Those represent real usernames. Great!

Now I just gotta find one person from this list with a predictable password, or enough of an identifiable username to target with a social engineering attack. Bonus points if they have elevated access.

It's true that 2FA, IP based bans of bad actors, passkeys, strong password requirements, password expiration, and more can make this job a little harder, but there's workarounds for all these problems.

That's what they're saying. Not that the server returns your username, just that by providing different responses to to failed login attempts, you make usernames extractable based on your response behavior.

I hope this helps you understand the reasons for the frustrating user experience. Its because they're trying to protect your data (username) from hackers.

Lol somebody skipped naptime today

Why do you think the dev (who very well may be unpaid, this is an open-source driver) owes you a solution?

Would you milk a cow for an entire community for free? Would you charge money? How much? If someone didn't like the milk, would you ask why?