wrong password message instead of expired.
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.
28 replies
From a security perspective the message should always just say "wrong password", rather than giving a hint as to what's wrong. Anything extra leaks information that an attacker will use to attempt to infiltrate that account. That's why mistyping your username will also give that message.
Obviously, from a usability point of view, it's not great, but you're using a password manager, so you know your username and password are correct, so you can assume you need to reset the password if it's not working.
there is a lot of its better security that is pretty weak sauce. changing passwords often even if strong and if you lock out on password attempts. usability should not be second. Sure if it made a major increase in actual security as seen in the wild but that is just not the case. I would argue that not be specific causes user confusion which results in support situations that make it easier for social engineering to work.
Simply saying "failed login", though, isn't weak sauce; it's actually fundamental and it's effective.
that would at least be an improvement over expired password. at least that is not specifying its something its not. the weak sauce is not in not giving good feedback. that is just bad. the weak sauce is justifying it as a security measure. you can point to methodology that involves it and sure someone will do what they can to categorize and filter but ultimately how useful it was to gain access is what I question. in most cases I have seen its been bad passwords, leaked passwords, or social engineering.
Actually there have been multiple breeches that were made possible by identifying people's usernames due to overly descriptive error messages. Knowing the password is expired gives social engineers even more information to work with. You are correct that there is a balance between making the system secure, and making it usable. This is usually addressed by making the password reset process easily identifiable, and straighforward to use.
Passkeys are the next protocol that is supposed to save us from the hassle of remembering username and password, or dealing with expired passwords, and whilst they do have their own problems, they're a definite step away from the frustrations you've described.
putting the username in the message is unnecessary rather than the username used but if they entered the username, which for this type of situation is mandatory, it does not a security issue. im not sure what error messages you are talking about where they get a username in an action that did not require the username but I could see that being bad. not in this situation. Passkeys are something I don't use not having a smartphone or being willing to buy an item for it. I am fine with an authenticator given I can just use software I want but honestly I don't see them as all that useful. if people use a manager and good passwords then I doubt more breaches are from some sort of cracking (given again there should be some sort of lockout) rather than social engineering problems logging in. I know im being a bit flippant. I realize using a hash of a password with time sorta hides it more but it kinda cracks me up they seem fine not having as many requirements as the passwords when the secret is created.
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.
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.