Ugh and many people have made memes and such of this but its so annoying. If your policy says its to old then just have that in the message. Implying its the wrong one just pisses people off. You have a password manager and you know its the right one but you do the forgot password link and then when you put your password manager one in the truth comes out as it says you can’t use your current password. I swear non of the actual IT people from my heydey would ever do this. I feel like its the cs/mba types that bring all this bs.
that has nothing to do with this example. A valid user name was put in. If it treated all situations the same it would be an issue. If they put a wrong username in you just say invalid password still but saying expired does not give anything away. ugh. this reminds me of the wiping a drive thing. formatting to all zeroes is so slightly less than the dod 14 passes thing as to make no difference.
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:
{"error": "invalid password"}{"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:
… 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.
I get your point but again its not very realistic. password lockout makes brute force a thing of the past and manually trying to guess is even worse. you likely would have more success with just trying the list of most common passwords. and remember. 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. further the displayed message can be hidden from api calls but show to the user. it does not need to be plain text as we are talking about user usability.
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:
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.
Great, I have 8 VPN subscriptions and thousands of potential IPs, let’s go for broke here.
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.
Yeah this was just an example, I’m not trying to give a tutorial.
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.
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.
Sure, it could be no text, and I could still scrape information, so long as the responses are different between statuses.
lockouts is a common practice and itself only goes for a period. this is a solved issue. it slows down brute force attacks while limiting the inconvenience. Lets put this to bed shall we. The discussion has gotten off base. Many sites will respond with expired and direct you to the process. Why is that? Do they all have bad security practices? No. Its because @betterdev@programming.dev @corsicanguppy@lemmy.ca @notabot@piefed.social that you only get that message if you entered a correct username and password that is expired. It will not do it if you are brute forcing random crap. replying to expired passwords with wrong password is crap design.
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.
its gracious of you to let me win and just drop it. lockouts has no relation to this scenario outside of its just good practice and if your a security guy you know that. its kinda funny your arguing against them for user experience reasons.
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.
account locking is a mitigation for ddos. without it people still cannot log in because that is the nature of a ddos and with it the systems won’t put as much processing to the login request. Don’t get me wrong its not meant as mitigation of ddos as a purpose of using it but the example of how account locking is going to make user experience during a ddos is ludicrous.