That's easy to do. You just check that the username exists. If someone enters a wrong username/password pair, you can still check that the username exists, but how do you know that the user intended to log in with that username? You would also have to check every other username to see if the password matches, and that can't be done with a simple search because you need to compute a different hash for each user you check. Then if the username exists and the password also happens to match someone else's password, then what do you report? Should you even report it? Because doing so reveals that someone had that specific password, and if the list of usernames is publicly available (which they often are, or could become public through a leak of some sort), then you can brute force over a small set of usernames to match them up.
I was having a chat about this with a UX guy. His argument for using a similar flow was that the username/email will have to be validated at the point of registration anyway so you might as well make it easier for the user when the email is wrong. I couldn't really refute this logic.
If you throttle both login and registration, then surely the risk is minimised while keeping the user happy?
You see the registration problem in so many places. If the username is an email, the proper way to validate it without revealing if an account exists is to accept any email address and if it already exists say that in the registration email you would send anyway. With the appropriate throttling if needed.
Compared to login or password reset, you rarely see the email validate before register flow, especially for mobile apps etc. That makes it pretty hard to make the case that this needs to be actioned from a security perspective when even the big companies are not following it either.
i think these days the best practice for mobile apps re retention (other than sso or passkey) is to just ask for an email, then from the validate link continue with register
reason being that more steps to register means more ways people are likely to drop out of the flow, and this is basically about as short as it can be
when the user has validated their email, then they’re more invested so they are more likely to complete
that also fits nicely with what we’re talking about with good security
Just to clarify, would you mean to have the email/validate stage as part of the flow to access the app, or let them continue with just the email with a limited functionality?
either… some apps have just started to do single factor login with just email, profile options can be optional, if there are required fields or terms of service to agree to then that can come after email validation
I pretty much always recommend throttling. It's a very low severity issue generally, but of course it depends on the product. There might be some products where it is a very big deal
"who's" is "who is"[1] or "who has"[2], and it can be wrestled into a possessive if you make "who" all or part of a name[3], but it's the wrong sort of possessive for this context. If you really want the possessive form, it ought to be phrased "which person's", which is mostly what "whose" means.
(An actual linguist would speak more about the genitive and how it works in English, but I'm not as capable.)
[1]: e.g. "Who's there?"
[2]: e.g. "Who's let the cat out again?"
[3]: e.g. "This is you-know-who's box of tricks."
(linguistics) The practice of prescribing idealistic norms, as opposed to describing realistic forms, of linguistic usage.
E.g.
Most linguists in this age believe that prescriptivism is outmoded and should no longer be used
Most linguists in this age believe that descriptivism is a more accurate model of language than prescriptivism
Most linguists in this age believe that "correcting" language unnecessarily is actively harmful, as it stifles the evolution of a living growing thing, which prescriptivism fails to accurately model
Most linguists in this age agree the more important factor is CONTEXT, that you should use the correct language style for the context, whereas prescriptivism falls flat as it ignores context. Contextual Language is the idea that you use a different style of language talking to your boss then you do to your friend, then you do to your best friend, than you do to a stranger
There's this thing in linguistics, casual language requires backchanneling - to respond back with either short utterances that show you understand, or to show confusion and then ask for clarity
The reason formal language is formalised, as in the shit used in essays, is that there is no easy way to say "what did you mean?" - the feedback loop is far too slow for that process and by the point the author(s) get to respond they likely forget what they meant as well
This makes so much sense, my most painful experience in understanding department is from forums where feedback is at best hours long, and infinitely long at worst if the person never ever replies
They actually are the reverse of irked, cause like an archaeologist finding a new artefact, they find the cool thing of evidence of the shift of language.
What's your opinion of the word "neologologist" and are you proposing that these "most linguists" are in fact described by it? And what do you think their opinion of it would be? ;p
Well, that was an entirely unnecessary and lengthy correction to a mistake that was A) a typo I didn't notice from using swipe on my phone keyboard, not a misunderstanding on grammar, and B) not an error that rendered my comment confusing or indecipherable requiring your clarification. But thank you for your (air quotes) help. I really hope that you're a bot, not a person this annoying or one who writes that way.
I'm about 50/50 on grammar errors. They bother me either way, but sometimes I feel the need to correct them and try to explain why.
Today I seem to have worded it in a way that's rubbed people the wrong way. It has gone better. You win some, you lose some.
And yes I know I sound like an LLM. I used to not be able to communicate my ideas at all (flashback to not being able to string a 500 word essay together at school) but then I got a job working technical support and I had to figure out a way of getting my ideas and explanations across. And this is now how I communicate, for better or worse.
Unfortunately, LLMs learned how to communicate in a not dissimilar way. And so we sound alike.
I am annoyed by (but respect) APIs that take it a level further and don't even give you a 403 to say you're unauthorised, they just give you a 404 because anything else would acknowledge that the resource you requested actually existed
I don't respect them because most instances a 403 is more than adequate for your security. The only time I agree with having a 404 over a 403 would be file-specific pathing, but realistically the entire file directory should be a 403 instead of a 404, And then if the user is authorized to access the resource(but it isn't there), then it gives a 404.
Yea, it doesn't matter too much in most instances, but there are times when it might, especially if the URL itself has some meaning embedded in it. For example if part of the path is a SHA sum of some content, which is fairly common, it might be bad to allow someone to determine if that resource exists
Whether you respond as a 404 or a 403 would be dependent on whether or not the user who is logged in has the authorization to read the previous directory.
A site administrator, for example, would have the authority to read the previous directory, which means that the site administrator would know whether or not the resource existed or not(as the previous directory would list it) so in which case a 404 would be proper. However, a user who doesn't have authority to read the previous directory should not have the ability to know whether or not it exists. so a 404 would not be proper here because the proper one would be a 403 because it's inherited from the previous directory.
edit: changed traverse to read, as traversal doesn't mean you can see what else is there.
I'm not sure. I was actually asking. And I'm not even sure enough to tell if this is a joke reply you're making or not. Lol.
I just assume the process is to start a general session. Rather than accessing the request to the resource directly.
So, I guess it would be abstracted a bit though. The user COULD be successful at starting the session. Get a success response to redirect to the resource they are trying to reach AFTER the session starts. Then once they are logged in their privileges are checked on that resource. Either returning an unauthorized response or the actual content.
So, I'd guess this is (at minimum) a two step process. Though from a user perspective they just login and get the resource.
If the login fails it's just a single response. I'd guess for security just a 200 response but with no session token or response.
Honestly, I'm just typing this for my brain to try to remember the small amount of work I did with Redfish and RESTful stuff awhile back.
But, you are right. There isn't a reason to give the user html error codes that can tell them anything more than they should know. Without a user session or without user privileges it's just telling users more than they should. Redirecting to a 404 page with the same generic response is probably best practice. As long as it's consistent.
Not gonna lie back when websites had password hints that you could do. I used to put something like that where it wouldn't be the full password, but it would be either a part of the password or I would label it as same as computer password or something like that.
I remember there was a joke about this back in the day were someone put a joke error message saying: "that password belongs to ninja123, please enter your password"
I have had that experience, then I realised I used oauth on that site. CTRL+refreshed the page and it did the auto login. No idea how I got a log in prompt that one time; probably clicked login before the page finished loading
The site had disabled password login for users who had changed to oauth
yeah real question how would the website even know. Whole point is to match the 2 things together. Is hunter2 my password, well that depends who are you, we've got plenty of users that have that hunter2 password
The website could know whether the username actually exists on the system. But revealing that information is a security weakness because someone could at least learn who has an account at that site (especially if usernames are email addresses, as they often are).
Right but not only is it a security weakness, but it's also not helpful to the user. Point is the username probably exists in the system.
Say I went to a website to register TheFogan, but TheFogan already exists, so I created TheFogan2.
3 years later I go back to the website, try and log in with username: "TheFogan" password: "Hunter2", and it tells me "your username is right but your password is wrong". But in reality I have the right password for my account, but the site would just think I have the wrong password for the guy who beat me to my account.
So yeah agreed the primary reason for it is security, IE a fully user focused, while having bad security practices would be, a "if the username exists in the system, report "Username and password don't match", if the username doesn't exist report "There is no user by this name in the system". My point is the site only can know if they have a user by that username, not whether that is MY username.
Generally speaking, unless you're using OAuth for an authentication, you would check your username and your password at the same time. It's just you wouldn't respond if either existed or not. You would just say invalid username and password combination.
What gets really complicated is the hybrid SSO integrations where they use a username and then if the account has SSO enabled it then redirects you to the sign-in page, Otherwise, it brings you to a password field.
Realistically what these sites should do to prevent that vulnerability would be to make it so you have to click a dedicated sign in with single sign on button. But not everyone does that type of flow.
Granted, this also doesn't include sites that convert your user account into a user ID. And then for your password's table, only give a user ID. Those would require two queries or a join, regardless, because it's two separate data places. One to get the user Id and one to get the passwords
Had manager that wanted us to return error codes on a field of an API response along with an HTTP 200 because "errors bad". It needed a few of us to make him understand how that worked against common design patterns and you still had to handle error codes since you didn't know if the error would be coming from the app, web server, api gateway, local network (no internet), etc.
The UPS tracking API has a similar issue, when it doesn't find a tracking number it returns 200 and an API response with the not found error inside. The documentation even states that the API does return 404 in that case. A github issue about that mismatch is open for over a year already: https://github.com/UPS-API/api-documentation/issues/166
In cass it's not clear from other comments, if the site tells you either one's wrong but not both, you can then brute force and try out a bunch of usernames and passwords to effectively farm for both: those that say "wrong username" means that the password is valid, while those that say "wrong password" means you got the username that's in the system.
Once you've collected them, the rest is just trying out every password for every user.
So... while this seems weird for a person, it is very much intentional.
Edit after several comments: I don't know why it's hard for people to look at the OP, take it for what it is, and argue for the sake of the argument, rather than claiming that something's impossible because of common or correct technical practices.
whew
thankfully they redacted the phone nunber
Stuff like this is why you need to understand the reasons why, and not just the actions to do something.
Being able to determine if a username is valid without a valid password is a security flaw
Even something as simple as taking longer to validate the password when the username is a valid one can also lead to user enumeration
I keep hearing that, yet the websites will gladly tell you that the username is taken when trying to register
I'd assume the spam protection for signing up is a lot tighter than the one for logging in
There are also a lot of websites where you first just enter a username and only when that is valid they ask for a password
Many of those will progress to password even if the user doesn't exist
And this fucks with password managers as they usually expect both fields on the same page.
Which ones? Both Keeper and KeepassXC will work just fine with it and the latter is FOSS.
That's easy to do. You just check that the username exists. If someone enters a wrong username/password pair, you can still check that the username exists, but how do you know that the user intended to log in with that username? You would also have to check every other username to see if the password matches, and that can't be done with a simple search because you need to compute a different hash for each user you check. Then if the username exists and the password also happens to match someone else's password, then what do you report? Should you even report it? Because doing so reveals that someone had that specific password, and if the list of usernames is publicly available (which they often are, or could become public through a leak of some sort), then you can brute force over a small set of usernames to match them up.
I was having a chat about this with a UX guy. His argument for using a similar flow was that the username/email will have to be validated at the point of registration anyway so you might as well make it easier for the user when the email is wrong. I couldn't really refute this logic.
If you throttle both login and registration, then surely the risk is minimised while keeping the user happy?
You see the registration problem in so many places. If the username is an email, the proper way to validate it without revealing if an account exists is to accept any email address and if it already exists say that in the registration email you would send anyway. With the appropriate throttling if needed.
Compared to login or password reset, you rarely see the email validate before register flow, especially for mobile apps etc. That makes it pretty hard to make the case that this needs to be actioned from a security perspective when even the big companies are not following it either.
i think these days the best practice for mobile apps re retention (other than sso or passkey) is to just ask for an email, then from the validate link continue with register
reason being that more steps to register means more ways people are likely to drop out of the flow, and this is basically about as short as it can be
when the user has validated their email, then they’re more invested so they are more likely to complete
that also fits nicely with what we’re talking about with good security
Just to clarify, would you mean to have the email/validate stage as part of the flow to access the app, or let them continue with just the email with a limited functionality?
either… some apps have just started to do single factor login with just email, profile options can be optional, if there are required fields or terms of service to agree to then that can come after email validation
I pretty much always recommend throttling. It's a very low severity issue generally, but of course it depends on the product. There might be some products where it is a very big deal
It's called security.
"Wrong username. Correct password."
"Uh.... who's password?"
I don’t know who is password, or why is password, or when is password, but I do know where is password, and it’s out there!
But... how is password? Secure enough?
Error: password already in use by CobainKiller94
*whose
"who's" is "who is"[1] or "who has"[2], and it can be wrestled into a possessive if you make "who" all or part of a name[3], but it's the wrong sort of possessive for this context. If you really want the possessive form, it ought to be phrased "which person's", which is mostly what "whose" means.
(An actual linguist would speak more about the genitive and how it works in English, but I'm not as capable.)
[1]: e.g. "Who's there?" [2]: e.g. "Who's let the cat out again?" [3]: e.g. "This is you-know-who's box of tricks."
Noun
prescriptivism
(linguistics) The practice of prescribing idealistic norms, as opposed to describing realistic forms, of linguistic usage.
E.g.
I envy these linguists' ability to either not be irked by grammar errors at all or to be able to deal with their irritation when errors arise.
I also envy their ability to understand what was meant, because sometimes there are enough errors to make meaning completely impossible to discern
There's this thing in linguistics, casual language requires backchanneling - to respond back with either short utterances that show you understand, or to show confusion and then ask for clarity
The reason formal language is formalised, as in the shit used in essays, is that there is no easy way to say "what did you mean?" - the feedback loop is far too slow for that process and by the point the author(s) get to respond they likely forget what they meant as well
This makes so much sense, my most painful experience in understanding department is from forums where feedback is at best hours long, and infinitely long at worst if the person never ever replies
They actually are the reverse of irked, cause like an archaeologist finding a new artefact, they find the cool thing of evidence of the shift of language.
Not errors, evidence of change
What's your opinion of the word "neologologist" and are you proposing that these "most linguists" are in fact described by it? And what do you think their opinion of it would be? ;p
I would say that most aren't, but some definitely are
It's a study of both the past and the present, many study both, many study just one, some flip-flop between
Well, that was an entirely unnecessary and lengthy correction to a mistake that was A) a typo I didn't notice from using swipe on my phone keyboard, not a misunderstanding on grammar, and B) not an error that rendered my comment confusing or indecipherable requiring your clarification. But thank you for your (air quotes) help. I really hope that you're a bot, not a person this annoying or one who writes that way.
I'm about 50/50 on grammar errors. They bother me either way, but sometimes I feel the need to correct them and try to explain why.
Today I seem to have worded it in a way that's rubbed people the wrong way. It has gone better. You win some, you lose some.
And yes I know I sound like an LLM. I used to not be able to communicate my ideas at all (flashback to not being able to string a 500 word essay together at school) but then I got a job working technical support and I had to figure out a way of getting my ideas and explanations across. And this is now how I communicate, for better or worse.
Unfortunately, LLMs learned how to communicate in a not dissimilar way. And so we sound alike.
I like the way you write, FWIW.
Probably the overuse of superfluous grammar that's throwing people off tbh. You should research the idea of Contextual Language to fix that
When one provides correction for someone is much better to do that than to reply "*whose"
You don't need to read it if you don't want to
Just good security, nothing to see here.
Any further "helpful" information in that error message would be a security issue.
I am annoyed by (but respect) APIs that take it a level further and don't even give you a 403 to say you're unauthorised, they just give you a 404 because anything else would acknowledge that the resource you requested actually existed
I don't respect them because most instances a 403 is more than adequate for your security. The only time I agree with having a 404 over a 403 would be file-specific pathing, but realistically the entire file directory should be a 403 instead of a 404, And then if the user is authorized to access the resource(but it isn't there), then it gives a 404.
Yea, it doesn't matter too much in most instances, but there are times when it might, especially if the URL itself has some meaning embedded in it. For example if part of the path is a SHA sum of some content, which is fairly common, it might be bad to allow someone to determine if that resource exists
But if there is no resource, how can the system know whether they are authorized? 403 it is.
Whether you respond as a 404 or a 403 would be dependent on whether or not the user who is logged in has the authorization to read the previous directory.
A site administrator, for example, would have the authority to read the previous directory, which means that the site administrator would know whether or not the resource existed or not(as the previous directory would list it) so in which case a 404 would be proper. However, a user who doesn't have authority to read the previous directory should not have the ability to know whether or not it exists. so a 404 would not be proper here because the proper one would be a 403 because it's inherited from the previous directory.
edit: changed traverse to read, as traversal doesn't mean you can see what else is there.
Wouldn't unauthorized only be meant for AFTER a login is successful?
Like, the user should have to have an active session first. Maybe you're just talking about that case though.
Maybe I meant unauthenticated. What is this, mandatory cybersecurity education!?
I'm not sure. I was actually asking. And I'm not even sure enough to tell if this is a joke reply you're making or not. Lol.
I just assume the process is to start a general session. Rather than accessing the request to the resource directly.
So, I guess it would be abstracted a bit though. The user COULD be successful at starting the session. Get a success response to redirect to the resource they are trying to reach AFTER the session starts. Then once they are logged in their privileges are checked on that resource. Either returning an unauthorized response or the actual content.
So, I'd guess this is (at minimum) a two step process. Though from a user perspective they just login and get the resource.
If the login fails it's just a single response. I'd guess for security just a 200 response but with no session token or response.
Honestly, I'm just typing this for my brain to try to remember the small amount of work I did with Redfish and RESTful stuff awhile back.
But, you are right. There isn't a reason to give the user html error codes that can tell them anything more than they should know. Without a user session or without user privileges it's just telling users more than they should. Redirecting to a 404 page with the same generic response is probably best practice. As long as it's consistent.
unauthorized (403) is still valid for unlogged in as you can permit anonymous access to certain resources.
unauthenticated (401) is for when you should be redirecting the user to the login page
Thanks. I think I might have been misreading these in my head. Dyslexia is a dickhead. The number codes really helped.
While true most of these websites expose valid usernames in other places
Yeah, the error message could be more helpful:
3rd hint: their passwords are...
I thought that the implication already was that these accounts have the initially tried password
It could've been a random list of accounts with similar passwords
Not gonna lie back when websites had password hints that you could do. I used to put something like that where it wouldn't be the full password, but it would be either a part of the password or I would label it as same as computer password or something like that.
God, I was so insecure when I was young.
AI slop is great, isn't it?
It's hilarious how all OP did with this post is show everyone how dumb they are.
Seriously, how do you NOT understand the security risk of that?
I remember there was a joke about this back in the day were someone put a joke error message saying: "that password belongs to ninja123, please enter your password"
It'd be funny to have a social website that does that just to see what happens.
It's very tempting to use that (maybe with several random usernames to select from) as the insufficiently strong password error message
It's probably just a little too user hostile though
try all passowrds. Fail
Maybe I don't have an account...
create new account. email already in use. Fail.
Okay, guess I'll reset the password through email.
password can't be one already used. Fail
WHAT?!
I too only type my password correctly when I go to reset it.
I have had that experience, then I realised I used oauth on that site. CTRL+refreshed the page and it did the auto login. No idea how I got a log in prompt that one time; probably clicked login before the page finished loading
The site had disabled password login for users who had changed to oauth
yeah real question how would the website even know. Whole point is to match the 2 things together. Is hunter2 my password, well that depends who are you, we've got plenty of users that have that hunter2 password
The website could know whether the username actually exists on the system. But revealing that information is a security weakness because someone could at least learn who has an account at that site (especially if usernames are email addresses, as they often are).
Right but not only is it a security weakness, but it's also not helpful to the user. Point is the username probably exists in the system.
Say I went to a website to register TheFogan, but TheFogan already exists, so I created TheFogan2.
3 years later I go back to the website, try and log in with username: "TheFogan" password: "Hunter2", and it tells me "your username is right but your password is wrong". But in reality I have the right password for my account, but the site would just think I have the wrong password for the guy who beat me to my account.
So yeah agreed the primary reason for it is security, IE a fully user focused, while having bad security practices would be, a "if the username exists in the system, report "Username and password don't match", if the username doesn't exist report "There is no user by this name in the system". My point is the site only can know if they have a user by that username, not whether that is MY username.
Not exactly. It should check for the username and password separately. First check if the user exists, then check if the salted passwords match.
Generally speaking, unless you're using OAuth for an authentication, you would check your username and your password at the same time. It's just you wouldn't respond if either existed or not. You would just say invalid username and password combination.
What gets really complicated is the hybrid SSO integrations where they use a username and then if the account has SSO enabled it then redirects you to the sign-in page, Otherwise, it brings you to a password field.
Realistically what these sites should do to prevent that vulnerability would be to make it so you have to click a dedicated sign in with single sign on button. But not everyone does that type of flow.
Granted, this also doesn't include sites that convert your user account into a user ID. And then for your password's table, only give a user ID. Those would require two queries or a join, regardless, because it's two separate data places. One to get the user Id and one to get the passwords
Yeah that's what I do, get user id from email then check password
Not unless they store the passwords in plaintext or their hashing implemention is garbage
Cisco VDI took their security to another level. Wrong password? system down? account locked? Always "Please try again later or contact support".
If they told you the user name is wrong you may as well publish a list of usernames of your site.
My bigger beef is when I enter the wrong email and it rolls me over to a sign up screen.
Fucker, I have an account, I just don't remeber which of my 20 email addresses it is.
Website: Wrong user name or password.
Me: Password.
Website: Correct! Come right in.
The absence of details makes the website more secure.
"Something went wrong."
motherfucker I will OPEN UP THE NETWORK INSPECT TAB AND FIGURE OUT WHAT WENT WRONG.
Network tab: server returned an html page with the words "Something went wrong."
Classical error code 200
Had manager that wanted us to return error codes on a field of an API response along with an HTTP 200 because "errors bad". It needed a few of us to make him understand how that worked against common design patterns and you still had to handle error codes since you didn't know if the error would be coming from the app, web server, api gateway, local network (no internet), etc.
The UPS tracking API has a similar issue, when it doesn't find a tracking number it returns 200 and an API response with the not found error inside. The documentation even states that the API does return 404 in that case. A github issue about that mismatch is open for over a year already: https://github.com/UPS-API/api-documentation/issues/166
Ah, I see it’s a microslop product
Wrong username and password combination. Or just wrong credentials.
In cass it's not clear from other comments, if the site tells you either one's wrong but not both, you can then brute force and try out a bunch of usernames and passwords to effectively farm for both: those that say "wrong username" means that the password is valid, while those that say "wrong password" means you got the username that's in the system.
Once you've collected them, the rest is just trying out every password for every user.
So... while this seems weird for a person, it is very much intentional.
Edit after several comments: I don't know why it's hard for people to look at the OP, take it for what it is, and argue for the sake of the argument, rather than claiming that something's impossible because of common or correct technical practices.
There's no way of knowing if a password is valid without the matching username. That doesn't make any sense.
You underestimate my capacity to store passwords in plaintext and iterate over all of them for no good reason
Server should also answer: 5 characters correct, 2 on correct positions
Passwordle!
I thought for a minute that that would be a fun password manager easter egg, but all my passwords are randomly generated so it would be super hard.
Yeah a wrong username means both are wrong. That's not how it works, that's not how any of this works.