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
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