Web Authentication Methods Compared

https://testdriven.io/blog/web-authentication-methods/

by luord • 6 years ago

181 102 6 years ago

l0b0• 6 years ago

Good overview, but I'm not sure I agree with the assertion that OAuth/OpenID is unconditionally more secure. It still depends on both the provider and the intermediate site doing things properly, like generating actually random values, not reusing randomness, not leaking tokens, and all the stuff you have to worry about normally.

slezyr• 6 years ago

Session-based Auth
It's stateful. The server keeps track of each session on the server-side. The session store, used for storing user session information, needs to be shared across multiple services to enable authentication. Because of this, it doesn't work well for RESTful services, since REST is a stateless protocol.

What stops you from keeping the JWT token in there? In fact, I doubt that it's some random session ID and not some encrypted payload that gets decrypted instead of looking it up in the database.

tptacek2• 6 years ago

Nothing, except that then you're inheriting all the complexity of JWT for not even a pretense of the JWT's supposed benefit of statelessness. You should do the simplest thing that works for your application; usually, the simplest and safest thing is session-based authentication with a random session ID.

groundthrower• 6 years ago

Used jwt for our web app before - changed to session cookies. To make jwt secure for web apps it feels like you are reinventing session authentication.

tptacek2• 6 years ago

That's a point a lot of people have made, because it's basically true. JWT is a bit of a cargo cult.

ravenstine• 6 years ago

JWT is the authentication equivalent of blockchain. Besides a handful of things, people try to apply blockchain to problems that aren't real. JWT is using cryptography to solve a problem that doesn't exist, which is that storing and retrieving user sessions on the server is burdensome, even though it's one of the least expensive computations you can make on a server. In fact, unlike blockchain, I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. It just sounds really awesome until you realize that, no matter what, you're going to need to keep and fetch some information about the user on the server, and that it's really not helpful at all to offload user data into a client side token. As someone who used to be enthusiastic about JWT, I kind of wish it would die in a fire. Cookie auth is much easier to implement without the need for a 3rd party library and is also more secure.

combatentropy4• 6 years ago

Many agree. There was an article discussed in 2016, https://news.ycombinator.com/item?id=11895440, and again in 2018, https://news.ycombinator.com/item?id=18353874.

combatentropy4• 6 years ago

It calls some of these stateless, but don't they all have to run a secondary look-up?

For example, in Basic Authentication, you still have to check the username and password against a database, whether that be a file, a relational database, LDAP, etc. For JWT, to verify the signature you must look up the issuer's pre-shared or public key.

Is it even possible for a request be stateless if it requires authentication?

Shmebulock• 6 years ago

I agree the article is confusing wrt state.

Basic Auth is stateless on the client side but not on the server side.

Token auth is stateless on server side; it does not need to store any more public/private key pairs as the number of authenticating users increases. It can just use one. So authenticating users does not affect state

combatentropy4• 6 years ago

it does not need to store any more public/private key pairs as the number of authenticating users increases

That's a good point. Thank you

jgalt212• 6 years ago

Basic Authentication is a pain with a web app sitting behind Apache as it strips all "sensitive" headers before passing along the request to the web app.

caseyohara2• 6 years ago

Are people still using Apache web server in 2020?

forgotmypw174• 6 years ago

Yes.

What are you using, njinx?

jlgaddis2• 6 years ago

Are people still using Apache web server in 2020?

Yes.

In fact, about one-fourth of the "top million busiest sites", 24.6%, are "still using Apache in [December] 2020" [0] -- more than any other web server.

More "active sites" also use Apache (25.6%) than any other web server.

When it comes to "all sites", however, nginx (33.48%) is the most widely used, followed by Apache (27.07%) and Microsoft (7.94%).

[0] https://news.netcraft.com/archives/2020/12/22/december-2020-...

Jiocus• 6 years ago

That's why could should use nginx and cooperate with the app. Maybe 'http_auth_request_module' for subrequesting to the right service, but I'm guessing passing correct headers will could do as well

franky47• 6 years ago

Another interesting method, overkill for most applications but absolutely required for end-to-end encrypted apps where no password must be sent to the server (eg: password managers): the Secure Remote Password (SRP) protocol[1].

It's a form of zero-knowledge proof-based verification that the password provided during account creation matches the one provided during an authentication challenge, all without transmitting the password at all. As a bonus, it also act as a key exchange on the client and server, that can be used for securing transmissions over untrusted channels (at the cost of having stateful connections).

[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

throw0101a• 6 years ago

SRP was good for its time, but things have moved forward in the password-authenticated key exchange (PAKE) world. See for example OPAQUE:

Currently, the most widely deployed (PKI-free) aPAKE is SRP [RFC2945], which is vulnerable to pre-computation attacks, lacks a proof of security, and is less efficient relative to OPAQUE. Moreover, SRP requires a ring as it mixes addition and multiplication operations, and thus does not work over plain elliptic curves. OPAQUE is therefore a suitable replacement for applications that use SRP.
This draft complies with the requirements for PAKE protocols set forth in [RFC8125].

* https://tools.ietf.org/html/draft-irtf-cfrg-opaque

More on PAKE generally:

* https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

* https://news.ycombinator.com/item?id=18259393

If you're looking for a challenge-response system for your application, then it's hard to go wrong with SCRAM (which Postgres went with a while ago):

* https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...

anirudhan• 6 years ago

I have been checking out OPAQUE for sometime. But I couldn't find any reliable javascript implementation that I can use in my webapp. Do you know of any such implementations.

dchest4• 6 years ago

It's not absolutely required for end-to-end encrypted apps (that encrypt data with password or use it for authentication). The two benefits of SRP-like (aPAKE) protocols are:

- a password hash (verifier in SRP) is not transmitted during authentication. (But is transmitted during registration and stored on the server). This isn't really required if the secure channel is already established — e.g. TLS — you can as well just send the password hash via TLS, which the server will hash again and check against the stored hash. For registration you already need some kind of non-password based secure protocol to transfer the verifier anyway.

- mutual authentication (that is, client also learns if the server knows the password/verifier). For this case, an app would already come with some kind of mechanism to ensure that the server it talks to is authentic (e.g. TLS with pinned certificates or some other public key protocol with hard-coded keys). So the benefit of verifying that this authentic server is the one that stored your verifier is also limited.

To summarize, there's not much use for SRP in a typical e2e app, since it already needs a secure connection between a client and the server, and SRP verifier is a client-side password hash.

SRP is useful if you need to establish a secure connection with a password and nothing else, but it requires first to store the verifier on the server somehow.

forgotmypw174• 6 years ago

I use hybrid basic and cookie auth in my application.

Basic auth functions as a captcha and invite code, eliminating users not invited and almost all bots.

After that,s done, the user gets a cookie (and a private key in LocalStorage) and is not prompted next time.

The beauty of cookies and basic is that the cookie is sent before auth takes place.

mauflows• 6 years ago

What do you use the private key for?

forgotmypw174• 6 years ago

The private key is used for signing actions like writing and voting which the user performs.

This allows the application to be truly decentralized.

eatonphil• 6 years ago

With the web developer hat on I most prefer working on apps with cookie based authentication since it makes it easy to use the browser to debug/make additional requests. If the cookie already exists I can go to any API url in the browser and it just works. Putting the secret in localstorage or only in app memory makes that not possible.

On the API side I prefer to support both cookie and Authorization header so you get the benefits in browser but don't overcomplicate the CLI side of things by requiring cookie state.

darkhorn• 6 years ago

It doesn't mention client certificates.

eqvinox• 6 years ago

I was about to say it's missing Kerberos/Negotiate too, but that was more of a joke. Certs are "proper" missing on the list.

(Both are very much a corporate thing, but to my knowledge certs are used significantly more widely than krb5)

neilv2• 6 years ago

HTTPS client certs are one of my favorite authn mechanisms for certain purposes, and I'm planning to next use them for an IoT appliance.

tialaramex6• 6 years ago

Also, TLS mutual authentication (what you have with client certificates) is impossible with MITM unless both parties agree to the MITM (in which case WTF?) which can help free you from obnoxious management imposed middleboxes at an organisation where it's futile to try to get anybody senior enough to just understand why they're a bad idea.

Suppose you work for HugeCorp. You built a service available on say https://service.huge.example/ and it has a bunch of users who are thus HugeCorp customers. Maybe they are prisons, or fast food restaurants, or whatever, it doesn't matter, except these are clearly not humans. (Client certificate management UX is awful for humans)

Ordinarily sooner or later HugeCorp IT will decide you need a fancy middlebox - from say Cisco, or Fortinet, or dozens of other companies - to tick a box on some executive's list. Ordinarily they just impose the middlebox and, since it can't do its job otherwise, they insist your private keys and certificates get copied to the middlebox. Now it's impersonating your https://service.huge.example/ site and every bug in that middlebox is now a bug in your service. Does it offer any benefits? Probably not really unless you did a very poor job of building the service, but it did tick a box on a list, and the manufacturer got paid. Good luck, have fun.

But with mutual authentication that can't work. They could reach out to every single user of the service and agree that all these users will actually now be separately authenticating to the middlebox. If any of them don't want to, you can't offer the service to them any more. So this won't end up happening, although feel free to propose it in meetings if you want the executives to explode.

Instead they'll have to except your service from the stupid middlebox, and you are freed from wasting your time chasing bugs that are in somebody else's product. Remember to send pity donuts to the teams trying to "fix" such problems in other services that weren't as lucky.

Finally TLS 1.3 makes client certificates work a little better, because it allows a server to give more sophisticated guidance on what sort of certificates it actually wants. In prior versions the only guidance the server is permitted to give is, "I trust these CAs, show me a client certificate they signed".

Still never use this for humans though, the human facing UX is not at all good. Good for machines talking to machines.

ape42• 6 years ago

For Digest the article says "Credentials must be sent with every request"... but not really. Once you're logged in the server can remember that you are and not ask for it each time. The client can only send it when requested.

mattmanser• 6 years ago

Perhaps I am misunderstanding you, but you actually stay 'logged in' by sending an authentication token with each request, usually handled by a cookie in most web frameworks that is all handled for you.

So you actually are sending some sort of credential every request.

ape42• 6 years ago

Sorry I wasn't clear. With http/2 you establish a connection and then send multiple requests on it. So I wrote an implementation that just asks for the Digest auth the first request on the connection. The server doesn't issue another challenge until the next connection.

rini17• 6 years ago

I haven't seen such implementation in the wild. "To remember you are you" means switching to another authentication method which is needless complication.

uptown• 6 years ago

What’s everyone’s preferred auth library for NodeJS based server use? It’ll be interacting with both a React based front-end from desktop as well as a SwiftUI front end from mobile.

kube-system• 6 years ago

My vote is for http://www.passportjs.org

It's modular and seems to work just fine

tester7562• 6 years ago

Tokens cannot be deleted. They can only expire. This means that if the token gets leaked, an attacker can misuse it until expiry. Thus, it's important to set token expiry to something very small, like 15 minutes.

But can be black listed.

mooreds2• 6 years ago

Sure, or your token issuer could implement https://tools.ietf.org/html/rfc7009 (if the JWTs are generated using OAuth) or you could build a revocation system.

But at that point you've negated one of the two benefits of such tokens. (The other one being you can verify that the contents haven't been modified, since they are signed.)

Why not just use session cookies then?

pier252• 6 years ago

Which is not stateless

cratermoon5• 6 years ago

Meh. I'm getting a sense that the author's grasp of authentication and authorization protocols is incomplete. I don't mean in the sense that the author left out some popular protocols, which is true, but in the sense that there's details wrong. For example, oauth and OpenID are mentioned only in the context of social login, and the differences between oauth, oauth2, OpenID and OIDC aren't covered (and OIDC is almost entirely unrelated to the original OpenID). Also, the author has a section at the end "GitHub social auth" as if it were somehow different from regular oauth used all over the internet.

https://www.wikiwand.com/en/List_of_OAuth_providers

IX-103• 6 years ago

I didn't get past the Basic Auth part where the author said the cons were both that you have to send credentials with every request and that there was no way to log out.

For one, both of those cannot simultaneously be true (as omitting credentials becomes equivalent to logging out).

In addition, all of the methods described require credentials with every request. Some just are stored in the cookie jar instead of the browser's auth handler. But whether it ends up in an auth header or a cookie header, it's still part of the HTTP request.

aaronharnly• 6 years ago

Yes, though I suppose they might have meant the inclusion of permanent credentials rather than a session key or temporary token?

jimktrains22• 6 years ago

They may have meant that there is no way to tell the browser to stop sending credentials.

neilv2• 6 years ago

Coincidentally, just yesterday I was looking for the usual simple in-server form&session Web site authn functionality for a Rust Web framework (and, ideally, also client certs).

I was confused by what this page says is available, and what it didn't: https://www.arewewebyet.org/topics/auth/

I get why OAuth2/OpenID is popular, in a tech professional environment comfortable with leaking information about users, and also desensitized to the risks of a single Web site having numerous third-party service&CDN dynamic dependencies for a page load... but I still expected the basic default authn mechanism to be form&session, and then some of the other mechanisms to build upon some of the same authn (and perhaps autho) session&events&UX foundation.

flowerlad2• 6 years ago

Not mentioned: passwordless authentication

See:

https://www.microsoft.com/en-us/security/business/identity/p...

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE...

In passwordless authentication, the device creates a public and private key when registered. The private key can only be unlocked using fingerprint or PIN. If an attacker knows the PIN he also needs the device. If he has the device he also needs the PIN.

ketamine__• 6 years ago

I associate "passwordless" with login via link sent in email.

I actually prefer this as long as the email is instant.

flowerlad2• 6 years ago

The "passwordless" described by Microsoft is 2-factor (but is just as convenient as 1-factor). Login link sent via email or text message is only 1-factor.

toomuchtodo2• 6 years ago

Isn’t this FIDO2/WebAuthN/CTAP?

https://fidoalliance.org/fido2/

https://www.w3.org/TR/webauthn-2/

tialaramex6• 6 years ago

Mostly. Microsoft seems to really hate just saying "Do this standard thing" and prefer to say "Do this special Microsoft thing †" with an asterisk explaining somewhere that it's basically the standard thing but with a Microsoft logo and also your Microsoft Certified Partner will charge extra.

For example Microsoft used to tell its customers they need a "Unified Communications Certificate" for SSL/TLS. And some companies would advertise specifically that phrase. What's special about UCC? Nothing, it's just an ordinary PKIX compliant certificate using SANs, which is what all the providers are always required to do anyway. But I guess in principle Microsoft felt this way if you bought something else somehow, that's not a "Unified Communications Certificate" so that's why it didn't work.

In the case of WebAuthn Microsoft really wanted to do RSA PKCS#1.5 even though that was obviously at best a weird choice and arguably a bad choice. So the standard says you can do RSA PKCS#1.5 and as I understand it a pure Windows system does, but nobody else wanted that, it's slower, it's clumsier, there is no formal security proof that it's even safe. Everybody else does an elliptic curve signature, I think either ECDSA or EdDSA.

I've built a toy WebAuthn implementation and I literally have no clue whether it works with Microsoft's clients because I was not able to test that yet because they are different from everything else. It fails closed, so if it doesn't work I guess I locked out all Windows users. But all the widely available popular solutions should work.

1vuio0pswjnm73• 6 years ago

From the section on session-based authentication:

https://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.h...

"To mitigate replay attacks (re-use of a sniffed cookie), the value of the cookie used for authentication SHOULD NOT contain the users credentials but rather a key associated with the authentication session, and this key SHOULD be renewed (and expired) frequently."

Session cookies are often defined as cookies that expire when the browser is closed. The truth is that session cookies do not necessarily expire when the browser is closed. Indeed they are lost to the browser, but the user can save them to a text file. If they are truly expired then they should no longer work. However, in some cases, the cookie in the text file can be reused to avoid login, long after after the browser is closed and across subsequent reboots. For example, one such case is a very popular webmail provider. Since the provider now forces users to run Javascript in order to login, this technique can be used to check, read and send mail from the command line using clients that do not include a Javascript interpreter. There are many other examples where session cookies can be used after the browser is closed to avoid having to keep logging in. Unless the website is one that logs the user out after a period of inactivity, there is a good chance "sessions cookies" can be used long-term.

edoceo• 6 years ago

I wanna read your writeup on that webmail workaround.

hunter2_5• 6 years ago

In my mind, of course the server doesn't know if you took a cookie you received from the previous instance of your browser and placed it into the next instance of your browser, because the act of closing your browser doesn't call every server saying "don't consider this cookie valid ever again," the act of closing your browser just deletes cookies that have a lifetime of 0 (but does not delete cookies with a nonzero lifetime, IIRC).

CharlesW3• 6 years ago

Hey auth gurus! I have a newb question for a scenario that this article doesn't appear to cover, so I hope folks don't mind if I ask it here.

Is there any way to authorize a front-end app to use private back-end services without requiring a login? (I have people abusing APIs which were intended to be private, and which may otherwise force me to require user accounts.)

xupybd• 6 years ago

Client side keys are an option. It's easy to setup.with Apache, not sure what stack you're using no not sure what to recommend.

respondo2134• 6 years ago

What about having your front end app authenticate with an auth provider to get a limited life token which in turn is sent with you api request? this is typically how I'd adopt a JWT scenario

CharlesW3• 6 years ago

That's an interesting idea. I'll look into it, thank you!

jlgaddis2• 6 years ago

X.509 certificates issued by your private PKI would do the trick.

You'd have to implement a registration / enrollment process during which you'd handle the setup but that'd be a one-time thing (plus a "renewal" process every few years or so).

Although it isn't necessarily the most "user-friendly", pretty much every HTTP(S) client and server in existence supports using certificates to authenticate clients.

As a security nerd, this is what I think I'd prefer, however...

An alternative that's probably more popular and "user-friendly" -- and more likely to be recommended (especially here on HN) -- would be to allow users to generate and manage API keys tied to their accounts.

You could then either 1) require everyone to authenticate to the back-end services using their API keys (even "free" users) or 2) make authentication optional but implement strict rate-limiting and/or quotas for unauthenticated requests.

EDIT: There are two other similar / closely related methods that I forgot to mention which are quite easy to deal with (both client-side and server-side) and supported practically everywhere (as, if memory serves, they've been around since HTTP 1.0 and 1.1, respectively!): HTTP Basic Authentication and HTTP Digest Authentication. The latter is basically the former with MD5 hashing added, although neither are particularly "secure" nowadays compared to the alternatives. This is much less of a concern if all requests and responses are being carried over a TLS-encrypted session, however.

u801e• 6 years ago

Although it isn't necessarily the most "user-friendly", pretty much every HTTP(S) client and server in existence supports using certificates to authenticate clients.

It's also not limited to HTTPS. Other protocols like SMTP and IMAP can use these as well.

One good way to get 2FA is to not only verify the client TLS certificate server side, but also require the user to send their username and password when logging in. Server side, the verified certificate could be checked against the credentials provided to see if they match.

CharlesW3• 6 years ago

Thanks! I appreciate the thoughts, and I'll definitely explore this.

zmmmmm• 6 years ago

It seems like for simple 2-party exchanges, as soon as you are using TLS and assuming you trust it, I'm not sure what the advantage is of doing anything more than basic authentication? Perhaps if you want to throttle authentications to prevent brute forcing it becomes a problem.

For sure, if you have more complex auth needs (more parties, granular access, etc etc) then you can start to justify more complex things ... but I'm curious what other weaknesses are there in that scheme?

0xbadcafebee• 6 years ago

Well if you don't want employers finding their users' private passwords in network logs it's worth doing more than basic auth. Inspecting TLS traffic is commonplace nowadays.

867-5309• 6 years ago

but is employers sniffing packets or brute forcing keys commonplace?

hunter2_5• 6 years ago

The password always gets sent at some point. It's just much more frequent with basic auth.

pier252• 6 years ago

Vulnerable to CSRF attacks

Is this really still an issue with cookies?

We now have cookie options like same-site and secure which AFAIK prevent the vast majority of attacks.

tialaramex6• 6 years ago

It makes no sense whatsoever to "compare" Web Authentication methods for humans in 2020 without even mentioning WebAuthn since that's literally why it's called WebAuthn (Web Authentication) and that's exactly what it's for.

In one sense this is bad news for this comparison, but it's also bad news for the general state of security on the web, because this item is 8 hours old and I'm writing this top level item now, which means for eight hours people who think of themselves as "web developers" didn't even ask "Why not WebAuthn?"

PudgePacket• 6 years ago

Just tried webauthn.io. Doesn't even work :/ I clicked register and it said "Use your security key now or cancel". What does that even mean? What's a security key? Is it a setting in my browser? I have lastpass installed, can it use that? Is it supposed to integrate with the Mac keychain somehow? Gave me no options but cancel.

Pretty underwhelming if that's the future of web auth..

tialaramex6• 6 years ago

A Security Key is a physical object. For example here are some reviews by tech press people:

https://www.zdnet.com/article/best-security-key/

https://www.wired.co.uk/article/best-security-keys

Or here's an actual expert writing about them a few years ago if you suspect "tech press people" are worthless:

https://www.imperialviolet.org/2018/03/27/webauthn.html

Or, more practically, if you have a nice phone, try visiting it on that. If it's a relatively modern iPhone or high end Android with a touch sensor running the current OS version you can use that.

Since you mentioned Mac keychain, if your Mac has TouchID that will work on the current OS (in Safari at least) too. Some Windows PCs with fingerprint sensors likewise.

webstrand• 6 years ago

I think that's a bit uncharitable. WebAuthn isn't terribly useful right now simply because most users lack hardware tokens. And from a backend services perspective, which the article seems to take, there's no good place to install hardware tokens for cloud services. If you own the physical server, only then does WebAuthn provide advantages.

I hope that someday, users can just plug their phone into their computer and use it as a security token.

Justsignedup• 6 years ago

Session based auth is what we used to do in the olden days. It was horrible. Sure it was easy to log in a keep a session cookie, but man... restarting servers = logged out, unless you persisted sessions. Session replication. It adds all sort of complexities after the initial implementation.

hardwaresofton• 6 years ago

It seems we're at a (local?) maximum with JWT over cookies + refresh tokens + blacklisting.

I'm not sold on refresh tokens being a strict benefit because in the end you still have to maintain state to make sure they can't be used indefinitely.

In the end though, opaque tokens are still the easiest and are way simpler to wrap your head around. Allow calls to redis or the auth server itself early on, and if that extra call really becomes a problem, start doing a push model (where the auth server pushes out updates to others) with caches near every service.

hunter2_5• 6 years ago

I find it amusing that this article starts off explaining the difference between authN and authZ and then immediately proceeds to a describe an authN scheme where the authN transaction utilizes a request header called "Authorization" (used in reply to a response header that doesn't have this quirk, oddly enough). Would be nice to see a footnote apologizing for what I'd consider a linguistic blunder on par with "Referer"...

Web Authentication Methods Compared

Related Stories