When things go wrong there are three main entities to consider:
The User
They need a coherent explanation of what happened, based on the concepts they can be expected to understand. Ideally enough information/explanation should be provided to allow them to overcome the condition.
The Maintenance
This should be a super detailed description of the error and include any possible context. The user will not reliably preserve this sort of information.
The Attracker
Could they conceivably get access to the data?
Could they get any use out of the data?
Could they cause the error condition that generated the error.
Better yet. Just use the trace id for the message. That id is correlated with all log statements already and it will allow you to in one go follow the whole flow of the user without setting up another per-request flow lookup table.
[EDIT: I’d only read up to: “So why aren’t these errors better? “Password is incorrect, try again.” or, “No account exists for this email.” Is that so hard?” — then I bailed, my bad, I should have kept reading. So my response below isn’t fair]
This ignores the security risks from being too verbose and/or specific with error messages, especially if they’re coming from a server. You’ll usually fail security/pen-test audit.
I agree that doing a better job of helping the user is laudable, but you need to know which battles to fight.
Giving a unique error number that can be referenced by a support team (who could look up the event, look at stack traces, etc.) is the best way to deal with truly exceptional events. Otherwise, if it comes to authentication or authorisation, you have to extremely careful what information you share.
When things go wrong there are three main entities to consider:
The User
They need a coherent explanation of what happened, based on the concepts they can be expected to understand. Ideally enough information/explanation should be provided to allow them to overcome the condition.
The Maintenance
This should be a super detailed description of the error and include any possible context. The user will not reliably preserve this sort of information.
The Attracker
Could they conceivably get access to the data?
Could they get any use out of the data?
Could they cause the error condition that generated the error.
For debugging purposes, because having users tell you what error they got is sometimes very useful:
generate a random number (e.g. a uuid), log it with the error, and display that number.
doesn't leak data because it's different every time, but you can uniquely pair it up with what they are seeing.
Better yet. Just use the trace id for the message. That id is correlated with all log statements already and it will allow you to in one go follow the whole flow of the user without setting up another per-request flow lookup table.
That's a good idea!
> So why aren’t these errors better? “Password is incorrect, try again.” or, “No account exists for this email.” Is that so hard?
I can tell you exactly why I don't do this, for my app.
I don't want to indicate which of the fields is an issue.
Most folks use Sign up with Apple, though, which obviates this.
The best error message is to avoid the error; either by effective design, or by good affordances.
But this is what WFM. YMMV.
> I don't want to indicate which of the fields is an issue.
Why not?
Narrows down the possibilities, for a hacker by 50%.
The answer should be that it's a privacy leak! Do you allow random actors to brute force your login?
Ideally you have enough entropy that you can spend a factor of two on making your software more pleasant to use
That’s why I use Sign up with Apple.
Fair bit of work.
The nature of the target demographic demands that I don’t cut any corners, with security.
But I’m also a big proponent of usability, so I would agree, for some applications.
[EDIT: I’d only read up to: “So why aren’t these errors better? “Password is incorrect, try again.” or, “No account exists for this email.” Is that so hard?” — then I bailed, my bad, I should have kept reading. So my response below isn’t fair]
This ignores the security risks from being too verbose and/or specific with error messages, especially if they’re coming from a server. You’ll usually fail security/pen-test audit.
I agree that doing a better job of helping the user is laudable, but you need to know which battles to fight.
Giving a unique error number that can be referenced by a support team (who could look up the event, look at stack traces, etc.) is the best way to deal with truly exceptional events. Otherwise, if it comes to authentication or authorisation, you have to extremely careful what information you share.
You should try reading past the first page of the article before making a judgment like that.
Who has time? ;)
But fair enough, I had stopped at the point where the advice was bad.
My bad. I’ve clarified in my original comment.