[HN Gopher] Web Authentication Methods Compared
___________________________________________________________________
Web Authentication Methods Compared
Author : luord
Score : 74 points
Date : 2020-12-23 18:33 UTC (4 hours ago)
(HTM) web link (testdriven.io)
(TXT) w3m dump (testdriven.io)
| jgalt212 wrote:
| 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.
| caseyohara wrote:
| Are people still using Apache web server in 2020?
| forgotmypw17 wrote:
| Yes.
|
| What are you using, njinx?
| caseyohara wrote:
| Nginx, Caddy.
| forgotmypw17 wrote:
| people still use nginx in 2020?
| forgotmypw17 wrote:
| 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 wrote:
| What do you use the private key for?
| ape4 wrote:
| 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 wrote:
| 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.
| ape4 wrote:
| 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 wrote:
| I haven't seen such implementation in the wild. "To remember
| you are you" means switching to another authentication method
| which is needless complication.
| l0b0 wrote:
| 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.
| eatonphil wrote:
| 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.
| groundthrower wrote:
| 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.
| combatentropy wrote:
| 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.
| tptacek wrote:
| That's a point a lot of people have made, because it's
| basically true. JWT is a bit of a cargo cult.
| ravenstine wrote:
| 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.
| lemonspat wrote:
| >> 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.
|
| I've never heard anyone say that's the problem, rather the
| issue is the network latency + dependency of hitting a
| cache/database for every future request. It's not a problem
| for everyone's apps, but pretending it's never a problem
| for anyone is shortsighted. Session cookies are just fine
| for many/most apps, and JWTs add new problems, so I dont
| recommend them. YMMV
| darkhorn wrote:
| It doesn't mention client certificates.
| eqvinox wrote:
| 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)
| uptown wrote:
| 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 wrote:
| My vote is for http://www.passportjs.org
|
| It's modular and seems to work just fine
| slezyr wrote:
| > 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.
| tptacek wrote:
| 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.
| franky47 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dchest wrote:
| There's no need to use PAKE in a web app.
| dchest wrote:
| 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.
| combatentropy wrote:
| 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 wrote:
| 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
| [deleted]
___________________________________________________________________
(page generated 2020-12-23 23:00 UTC)