Skip to content

Comment on Using www-authenticate for user authenticationparent

Comments

There isn't anything in the standard to support a "Go here to reset your password" link or a "Go over here to create an account" - I really appreciate HTTP auth for somethings - but it's not great if you don't have a user base that is registered for your site through some non-web based interaction. It's certainly possible to have a user creation flow that ends up auth'ing with Basic Auth but it's not particularly user friendly.

The browser could redirect the user to a form after cancellation or a certain amount of failures (say, 3 or 5) with recovery options. Add a nice retry button on there and you've got yourself a very simple login flow.

Stock nginx/apache configurations will basically let the user retry infinitely or show a plain error page after user authentication fails too often, but these pages are configurable and don't need to be handled by the web server itself.

One thing this mechanism doesn't provide is brute force protection through systems like CAPTCHAs.

Logging in and password recovery are two tasks that usually happen to extremely fatigued users. I'd like to briefly state that I absolutely loathe a lot of modern design decisions when it comes to authentication flow - the two page challenge system (first U/N then password) in particular provides an overly opaque login process that breaks a lot of password managers. That said - forcing the user to fail to auth before they can land on a page that lets them recover their password is a bad design. A lot of users know they've forgotten their password before they even try typing it. If it takes 3-5 failures to actually get the information on how to recover an account you'll lose a few users before the first failed attempt (they'll just walk away from your site) and most users by the time they've failed twice. Users have been trained that three failed login attempts can lock you out of an account - most will not just spam "blakdnasfnasnjsaja" into the password box three times in the hope that it gives them a forgot your password prompt... nearly none will do that five times.

On every page or widget you ask for authentication for you should have a clear nearby link that says "Forgot your Password?" this link shouldn't be in the standard information display text color (i.e. maybe black or a soft grey) and un-underlined because "it looks slick" - it should be obvious as hell, it's probably one of the best places to make sure of the old "color: blue; text-decoration: underline" styles[1] just so that users that are unfamiliar with your standard link coloration have absolutely no confusion.

I consider myself to generally not be a design oriented person, but I've seen this particular mistake cost so much business over my career that it is a hill I'm willing to die on. "Forgot your password" links need to be clear and constantly accessible - you should push back aggressively against anyone who wants to pop a little paper clip in there with a speech bubble of "It looks like you may be having trouble logging in" or anything else that deviates from those three words. When we're frustrated with a site we all just want to see "Forgot your password?" in blue and know immediately what we need to do - we never want to need to endure your design decisions or technical limitations to get there.

This component needs to be easy.

1. Ubisoft is a great example of this - they've got an extremely javascript laden login page for UPlay and yet "Forgot your password?" is written using that precise three word spell and is in "I'm a link from the 90s" blue - they decided to remove the underlining which is a frequent design decision these days (one I disagree with) but otherwise they're making it as blatant as possible https://account.ubisoft.com/en-US/login There's a bunch of stuff I'd complain about on this page (including the fact that on my browser on a 1080p screen I somehow end up with two different scroll bars) but it knows what's important.

If it takes 3-5 failures to actually get the information on how to recover an account you'll lose a few users before the first failed attempt

That's why you should also show the information when they cancel the prompt. Users will click the login link (because that's where password recovery is normally located), see a login popup, click close or cancel, and be greeted by a recovery page. No need to fill in fake info that way.

There's also no reason not to link to the recovery page! You could just as easily add a link underneath or next to the big green buttons that say "login" and "register". It all depends on how barren ("clean") you want your front page to be.

I abhor modern authentication systems (Google and Microsoft don't even show the password field next to the username field anymore for fuck's sake, you have to pass some kind of AJAX/Javascript validation logic), that's why I want authentication to return to the browser itself. There's a lot to be fixed regarding browser auth UI, most importantly better password manager integration, but taking auth flow control away from over-eager web designers can solve a lot of usability issues.

Browser auth is actually quite successfully implemented on mobile through U2F. I can click login, tap my thumb on the fingerprint sensor, get directed to a recovery/signup page if my device has no keys for that website or get authenticated automatically. On the desktop side TPMs should become available more often now that Windows 11 requires them (macs already have their own TPM implementation, of course). The quicker websites adopt this flow, the easier auth will become. That said, I've seen webauthn sites that don't ask you to validate your email after signing up, and that's a recipe for disaster, so the system isn't 100% perfect.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.