[HN Gopher] Using HTTP Basic Auth in 2022
___________________________________________________________________
Using HTTP Basic Auth in 2022
Author : codazoda
Score : 261 points
Date : 2022-01-01 19:25 UTC (3 hours ago)
(HTM) web link (joeldare.com)
(TXT) w3m dump (joeldare.com)
| worik wrote:
| What is authentication for? What is it protecting?
|
| Sometimes the effort and expense protecting a thing is more than
| the value of the thing protected. Often there is nothing really
| to protect, "authentication" is just administrative convenience.
|
| So simple is best. Cheep and cheerful!
| jerf wrote:
| HTTP Basic Auth was deprecated a _long_ time ago, back when HTTPS
| was a very expensive exotic thing that only large sites used. I
| 'm not sure it would be worth deprecating freshly today if it
| came up, now that anyone who wants HTTPS can get it easily. It
| may not be the perfect solution to everything but it does fill in
| a nice space, even in its current form. If browsers would just
| pay a bit more attention to it it could become very nice; most of
| its worst quirks are technically in the browsers, not the
| protocol.
| efitz wrote:
| I died a little inside reading this article. Clearly we have a
| lot farther to go with secure development lifecycle evangelism.
| forgotmypw17 wrote:
| I use it as a captcha.
|
| It's great for keeping crawler bots out, and easy enough for
| humans to get past.
|
| Once a user logs in, I set a cookie, and the user is not prompted
| for the auth again.
|
| The beautiful thing about this scheme is that the cookie is
| always sent, so I can create a rule which bypasses auth when the
| cookie is present.
|
| Basic Auth is one of the most supported features of HTTP,
| supported even by Mosaic. There's one Chrome release, I think
| 65.x, which screws it up when used together with gzip and
| requires a page reload after authenticating, but that's the only
| exception I know.
| justsomehnguy wrote:
| > The beautiful thing about this scheme is that the cookie is
| always sent, so I can create a rule which bypasses auth when
| the cookie is present.
|
| You don't even need the basic auth for that.
|
| Years ago I needed to expose my pfsense WebGUI on the default
| HTTPS, but I didn't want it to be so obvious, so I made a
| couple of HAProxy rules, which allowed me to open
| https://pfsense.tld/open-sesame to set a cookie, after which I
| could open the default https://pfsense.tld/ just fine and see
| the WebGUI. Without the cookie there was just 404 for everyone.
|
| It wasn't the best realisation (and some parts of webgui didn't
| like it) but it worked and allowed me to access it even on the
| smartphone.
| tlrobinson wrote:
| Kind of like "port knocking" but for HTTP.
| diarrhea wrote:
| Embracing security through obscurity like that is also how I
| decided to help protect my password manager, Vaultwarden.
| It's open to the internet on 80/443, but its URL is
| `subdomain.domain.tld/some-secret-path/`. It's dead simple,
| but indeed no unwanted visitors even _see_ that site. Of
| course, even if they did, the regular login prompt with MFA
| appears.
| zinekeller wrote:
| > There's one Chrome release, I think 65.x, which screws it up
| when used together with gzip and requires a page reload after
| authenticating
|
| Fortunately, that Chrome version is dead in the water (unlike
| Chrome 49, which is the last version for XP and Vista)
| diarrhea wrote:
| > unlike Chrome 49, which is the last version for XP and
| Vista
|
| Oh God.
| mooreds wrote:
| Agreed. My sympathies that the GP even needs to know this.
| Waterluvian wrote:
| Something I'm practicing more often is to keep something dead
| simple and then later adopt a library or some higher abstraction
| when necessary.
|
| For example, just handling a websocket myself before later using
| some sort of library for it.
|
| In the past my concern was that I'll have to make breaking
| changes to some protocol or message structure. But I'm learning
| now that it's actually a good thing: it makes me think about how
| I'll evolve and grow without the answer being "just preemptively
| grow it so you don't have to think about it."
|
| And naturally I'm discovering that the basic tools go far further
| than I expect and sometimes I never need to pay for that
| abstraction at all.
| klysm wrote:
| I find a lot of libraries don't make the underlying systems
| easier to use per se, they just map a lot of use cases to
| configuration instead of code. I would rather just use the code
| hiding behind that static configuration.
| Waterluvian wrote:
| After years and years of production experience with thousands
| of mobile robots that use this weird xml + yaml as
| configuration, I am 100% in the "just use code as
| configuration" camp.
| smitty1e wrote:
| I put stuff in config.py
|
| Then I just `import` at will.
|
| The need for a separate configuration format was what,
| again?
| Waterluvian wrote:
| My probably wrong belief is that it was a misguided but
| noble idea of abstracting complexity.
| mooreds wrote:
| Reminds me of this: https://adamdrake.com/command-line-tools-
| can-be-235x-faster-...
| combatentropy wrote:
| Apache has had form-based authentication for about 10 years:
| https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html
| devmunchies wrote:
| I like basic auth (Header of `Authorization: Basic
| username:password`) but for persistent session auth I prefer the
| Bearer tokens[1][2] (Header of `Authorization: Bearer
| my_token_here`).
|
| It's easy to generate a hash after the user logs in and then just
| store it in a cookie. The user doesn't have to store their
| password locally and I can delete the token from the database to
| force them to re-login. You can reuse the same token generation
| infra for APIs too so its pretty dynamic.
|
| I've basically moved away from JWTs in favor of this simpler
| approach.
|
| [1]: (list of auth schemes) https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Authentica... [2]: (Bearer auth spec)
| https://datatracker.ietf.org/doc/html/rfc6750
| incanus77 wrote:
| I don't recall seeing a lot of good info on how to use HTTP Basic
| Auth back in the day, to the extent that in 1998 I wrote my first
| technical how-to to post on my own website. It still lives on
| here:
|
| https://codesorcery.net/old/authentication/
| kjaftaedi wrote:
| You should take a closer look at AppWrite, AzureB2C, or Google's
| Firebase.
|
| You can even have Azure or Google connect to your own custom
| identity provider.
|
| It's only a few lines of code to implement user management using
| identities you control.
|
| I get not wanting to get locked into these things, but once you
| learn how they function, you can switch between identity
| providers in minutes.
|
| I do get the sentiment though, but for something like this my
| vote would be for certificates instead of basic auth.
| mholt wrote:
| Caddy comes with basic auth support because it's still useful for
| a lot of use cases.
|
| IMO the biggest weakness of basicauth (when deployed over TLS) is
| the fact that most server configurations store the passwords in
| plaintext, usually in a config file. This is like storing
| passwords in plaintext in a database. Caddy does not allow this.
| You have to use a secure hash on the password before adding it to
| your config:
| https://caddyserver.com/docs/modules/http.authentication.pro...
|
| Of course, password hashes are slow, so KDF'ing a plaintext
| string at every HTTP request can grind even powerful servers to a
| halt. So Caddy can optionally cache hash results in memory (we do
| expect memory to be safer than a config file -- and Go is a
| memory-safe language in this regard). And while this can
| introduce nuanced timing variances (fast if recently hashed),
| they do not necessarily correspond to correct passwords.
|
| If you think this stuff is interesting and want to help make
| Caddy's basic auth even better, feel free to contribute or
| sponsor: https://github.com/caddyserver/caddy
| LAC-Tech wrote:
| happy new year. Caddy is such a great piece of software. It has
| great defaults 'out of the box' but at the same time doesn't
| feel like I'm drowning in incomprehensible magic. We need more
| software like this!
| lgvld wrote:
| Yeah caddy is such an awesome server! ;-)
| mholt wrote:
| Thanks for the kind words!
| hasel wrote:
| Is this supposed to be used to put entire domains behind basic
| auth or should you use it for specific end points?
| g_p wrote:
| You can do this for specific endpoints in Caddy, or whole
| domains/sites.
|
| If you create a matcher like
|
| @wp-admin { path /wp-admin\* path
| /wp-login\*
|
| }
|
| Then you can just service up that handler's endpoints:
|
| handle @wp-admin { basicauth {
| username pwhash_goes_here username2 pwhash2
| } # reverse proxy config etc, e.g.
| reverse_proxy http://127.0.0.1:8080
|
| }
|
| And now only the wp-admin and wp-login endpoints are
| protected, but the rest of the site is unaffected.
| makeworld wrote:
| It can be used for either. Depends what you'd like to do.
| Maybe the domain is admin.mysite.com and so you want to wall
| the whole thing off. I've used it for specific endpoints as
| well though, like to protect certain folders of a file
| server.
| mholt wrote:
| You can do either. To Caddy, "entire domain" or "specific
| endpoints" are all the same thanks to request matchers. You
| can precisely customize which requests have basic auth
| applied to them:
| https://caddyserver.com/docs/caddyfile/matchers
| nichochar wrote:
| I love simplicity.
|
| the reasons you provide for using it are really strong, and I
| think it's a much superior option to prototyping leveraging oauth
| 3rd parties (which has tons of downsides).
|
| It would be good to have a hard rule as to when you migrate, and
| what the reasons are (if a project has more than N users, if you
| store field X which is pretty sensitive, etc..)
| thorum wrote:
| As a counterpoint, learning the basics of a good OAuth library or
| service like oauth2-proxy, auth0, next-auth or keycloak is well
| worth your time as a developer. Once you get over the initial
| learning curve, it's almost as easy to add to a project as basic
| auth. You don't need to reinvent the wheel with each project,
| building login pages and database code - other people have done
| the work for you - and you can create a more usable and
| professional experience for your users.
| 1vuio0pswjnm7 wrote:
| https://www.ietf.org/rfc/rfc7617.txt
| tunesmith wrote:
| I don't know if it really holds up to scrutiny, but I use http
| basic auth for a semi-public website. It has members (like less
| than twenty) that I don't know personally other than through the
| website, but I don't want the website public because I don't want
| to deal with with TOC, GDPR, legal stuff in general. Once you're
| past basic auth, it actually does have a login/registration flow,
| but it seems like I'd need to see a lawyer if I ever wanted to
| make a member-driven website public and I just haven't gotten
| around to it yet, so... http basic auth. Is this sound thinking?
| I don't know.
| emj wrote:
| The GDPR/Cookie rules are just the same common courtesy that
| all projects I've been invovled with always has had. No ad
| trackers and no personal data stored about what I did on the
| site unless necessary for the function provided. There is no
| exemption for personal sites. Point being, I'm from the EU but
| some times that has not always been important and only come up
| after working with someone online a couple of years.
|
| Basically; HTTP Basic auth does not make you website anymore
| private than a login page. Just treat you users fair and be
| straight forward with what you do with the data, and you won't
| need any lawyers.
| ithkuil wrote:
| How do you logout?
| sdze wrote:
| You can still apply a session id to the client and destroy the
| session after the user clicked on logout...
| bobkazamakis wrote:
| I'm storing sessions now? jesus what a disaster.
| codazoda wrote:
| Great question. This is a downside, there is no built-in
| method, but there are some tricks. If I remember correctly you
| can send headers with incorrect credentials. I'll have to do
| some research and add that to my template.
| yosamino wrote:
| If I remember this correctly, you send a request with
| incorrect credentials either via javascript, or by sending
| the user to a "/logout"-endpoint where you disallow any
| authentication credentials, causing the browser to prompt the
| user for a new username and password. This not great in terms
| of UX and depending on something implicit for something as
| important as logging out does not seem great for security.
|
| Why browsers do not have better functionality built in for
| authentication is something that's always been a bit
| baffling...
| mrweasel wrote:
| While your point is correct: It's not design with a logout in
| mind, but you can do it. For instance clicking link that will
| send invalid credentials, that will return a 401 and work like
| a logout.
|
| Mostly I just close my browser, that clear everything in my
| setup.
| throwawayboise wrote:
| I don't see anything wrong with a convention "to log out,
| close your browser" especially for little internal utility
| pages.
| pmontra wrote:
| People could have many open tabs with work in them. Maybe
| they would have to login again in some of them. Other could
| come back in a different state, especially with SPA.
| deepersprout wrote:
| Send an ajax request to your api with invalid credentials. The
| response returns a 401 and loggs the user out. Then redirect to
| the pre-login page.
| [deleted]
| theamk wrote:
| Last time I used HTTP basic auth, we've had a page which would
| unconditionally send 401 error code -- it'd invalidate
| credentials cache (effectively logging out the user) and then
| pop up new credentials dialog. I am not sure how standard-
| complaint this was, but it seemed to work in most browsers.
|
| One downside is that in trivial implementation (/logout page
| returning 401), you'll end up with credential prompt where no
| credentials work, and this can be pretty confusing if someone
| leaves the compute in that state. I think it can be worked
| around with "expiration" URL parameter or a cookie, but this is
| somewhat finicky to setup.
| pmontra wrote:
| With Firefox, from the Preferences, select only "Active logins"
| in the Clear History dialog [1]. Very odd that it belongs to
| history and far from ideal. However it's not something a lot of
| people use nowadays so I'm not surprised that they tucked it
| under the carpet.
|
| I use Basic Authentication for a few web services running on a
| server of mine and that I'm the only user of. It saves me a lot
| of work. I set the user and password in a file on the server
| and let nginx deal with it.
|
| [1]
| https://security.stackexchange.com/questions/192828/firefox-...
| sdze wrote:
| This is perfectly fine. Nothing to be ashamed of. At least you
| don't need to create a logon form
| SavantIdiot wrote:
| But if you are rolling your own auth, you still need to create
| the signup, change password, reset password, confirm account,
| delete account, etc. pages. What's one more? Given that a logon
| form is >5% of the total amount of work to roll auth, seems
| kinda pointless to use this.
| jeofken wrote:
| Implementing magic email sign in links is more
| straightforward and secure.
|
| You implement a login route which takes an email address. You
| symmetrically encrypt the email with a secret key from an
| environment variable, and send a link to
| /login?secret=<email-ciphertext>. This route handler checks
| that the ciphertect decrypts into the email, and if true,
| save the ciphertext as a cookie and check that it decrypts to
| the right email every time you require auth
| lukevp wrote:
| So anyone who compromised the cookie can login as this user
| forever? There's no expiration or revocation in this
| protocol. Once you layer on expiration, this is basically
| sending someone a link with a JWT in the get request. Or
| you can hit the DB to check a secret key that's in the
| email, and if it has expired, but this is worse than JWT
| because it requires a DB to verify the identity, where JWTs
| can be verified without interaction with the issuing system
| .
| [deleted]
| zanny wrote:
| I definitely think doing openid logins is way easier than any
| home rolled auth scheme.
|
| Delegate responsibility where you can, which includes use
| authentication. It sucks that Persona died all those years
| ago because web browsers really could use an identity system
| for users to authenticate themselves against sites with their
| browser accounts.
|
| The problem is then ofc getting browsers to cooperatively
| allow cross sign in. If messengers are anything to go by,
| siloed products really do not want to interoperate,
| particularly I imagine Edge and Safari.
| Jolter wrote:
| Author mentions internal tools, so I assume they already have
| a user database they integrate with on the back-end? LDAP or
| similar.
| amelius wrote:
| But still, why reinvent the wheel? There are plenty of
| libraries, even services available that do what you want.
| SavantIdiot wrote:
| I recently re-rolled a password auth protocol because Auth0
| and AWS Cognito were just so goddamn complicated. Ages ago
| I used stormpath because it was so simple,
|
| I realize there are many options today for federated
| logins, 2FA, SMS / phone password resets ... i just wanted
| an old-school password system for my dumbass personal site.
| smasher164 wrote:
| I found that sites (like fb messenger) which block URLs to
| certain sites can be easily bypassed by using HTTP Basic Auth
| with empty credentials. I built a small service
| (https://rot13.akhil.cc) that takes in a rot 13'd URL and
| redirects it to the original with HTTP Basic Auth. The nice part
| is that the credentials are cached, so visiting it again won't
| show the dialog.
| tdeck wrote:
| That's really clever!
| tzahifadida wrote:
| The problem is not with small projects. Who cares if it gets
| hacked. The problem is with real life SSO. If you used a 100 apps
| and 1 gets hacked then you have to change the other 99 passwords.
| Sound bad right? That is why you should not use basic auth and
| use openid connect or similar tech.
|
| Sometimes it is a bank, and no SSO involved. It is not well
| understood but SSL has termination points. E.g. the gateway and
| each gateway all thru the last layers. SSL becomes vulnerable at
| these termination points. If basic auth is used, then you just
| lost a whole lot of cash. Otherwise use challenge response,
| encrypted passwords within the SSL, and all kind of out of this
| world tech for risk assessment. Basic auth? Really?
| ufmace wrote:
| I like the reminder that this is out there and mostly available.
|
| I think many of the comments here are missing the point - they're
| saying it's useful for small-time projects with one or a few
| users and not needing to be integrated into a sophisticated
| infrastructure. No need to worry too much about hashing, logouts,
| the full chain of account management, etc. Use a full-featured
| solution if you need that, keep Basic Auth for a thing with a few
| admin pages where anything unusual gets handled over SSH.
|
| This also reminds me - Gemini uses client certs for a similar
| purpose. Gemini doesn't seem to have much going on, but it does
| make a good case for using client certs better. Right now,
| they're technically supported, but the UI for both browsers and
| server support is really clunky. Build a decent UI on both sides,
| and it could be a nice simple solution for higher-security
| authentication.
| kevincox wrote:
| I have always wondered how feasible it would be to use the basic
| auth URL syntax for thinks like API tokens and email validation.
| Ideally these values would not be logged but if you want a user
| to click them they basically need to be in the URL. So either you
| don't log URLs or you need to redact all of these parameters.
| Most systems are smart enough to avoid logging passwords so if
| you could just use URLs like randomtoken@example.com/confirm-
| email. However it seems like browsers usually put up scary
| warnings and most email providers will consider this a
| spammy/scammy pattern.
|
| Of course another problem here is that you just want it for one
| URL, whereas basic auth is usually preserved for the session.
| ChrisMarshallNY wrote:
| I just use it once, to generate an API key, then use the key, and
| a server secret (in the basic auth header), after that. The key
| could be generated by something like Sign In With Apple.
|
| Not Fort Knox, but fairly good.
|
| Because of FastCGI, I have to have an option to pass login creds
| in the URL, but that is not by default.
| throwaway984393 wrote:
| Spend an hour to set up an OAuth2 Proxy
| (https://oauth2-proxy.github.io/oauth2-proxy/) instead.
|
| You can use the one proxy for entire subdomains / unlimited
| number of apps. No plaintext passwords, scales well, open source,
| industry standard, and you get SSO for free. Hell, you don't even
| have to manage accounts! It makes your life simpler and it's more
| secure. You can't say that often.
| tlrobinson wrote:
| I used to use Basic Auth for small personal/internal services,
| but these days I prefer a proxy like Traefik/NGINX with a simple
| authentication service like Authelia or Traefik Forward Auth.
|
| It's a little more work to setup but not much and there are a
| bunch of benefits: SSO across multiple services, control over
| session expiration, works better with password managers, 2FA,
| etc.
| kij wrote:
| I am very happy with the this caddy extension:
| https://github.com/greenpau/caddy-auth-portal.
|
| Sorts this precise use case for me, need for common login
| provider. Without the banality of basic auth.
| billpg wrote:
| Wouldn't you need to the substantial workload of PBKDF2 (et al)
| for each and every HTTP request? Maybe have the images, JS, CCS
| etc handled by a separate server, but there's still going to be
| many requests that need to be authenticated for.
| klodolph wrote:
| I don't see why that couldn't be cached.
| TedDoesntTalk wrote:
| You can also enforce HTTP Basic Auth on only sensitive URLS
| while allowing images and css, for example, to be downloaded
| without auth.
| billpg wrote:
| Your "is this password valid" cache would need to be indexed
| by the clear-text password. That's a separate security issue.
| klodolph wrote:
| Why would you need to index it by the clear-text password?
| You don't need to retrieve the clear-text password, it
| doesn't have to be stored in the cache at all.
|
| The cache itself would be in the memory of a process which
| had access to cleartext passwords _anyway,_ so presumably
| an exploit which allowed you to read the cache would be
| damning no matter what.
| diarrhea wrote:
| The parent commenter possibly meant: with an incoming
| request, sending a password in clear-text, how do you
| cache it? You hash it, then store the fact that
| authentication was valid with some expiry.
|
| Once the next request, again with clear-text password,
| comes in you need to look up its validity. You want to
| check _without hashing_ , that's the entire point. If you
| look up whether the hash is validly cached, you gained
| nothing. Hashing was required. To look up without
| hashing, you will need to use the clear-text password
| _somehow_. Hence it has to be part of the cache somehow,
| i.e. its index.
|
| If that's all in memory in a memory-safe language, I
| guess it can be argued that's not unsafer than before,
| but I'm no expert.
| klodolph wrote:
| > You want to check without _hashing,_ that 's the entire
| point.
|
| It's not the point. There is no attempt to avoid hashing.
|
| At this moment I'd like to be careful and distinguish
| between ordinary cryptographic hash functions (SHA-2,
| BLAKE2, etc) and key derivation functions (PBKDF2,
| Argon2, etc), even though both are often referred to as
| "hashing" in this context.
|
| The thing about key derivation functions is that they
| make brute force attacks harder, because the
| computational cost of verifying the password is higher.
| They are typically parameterized so you can adjust
| verification cost. This is the cost we want to avoid.
|
| However, just because you are not using your ordinary key
| derivation function with the parameters you normally use,
| it does not mean the only other option is to store
| passwords in plain text. You could use a key derivation
| function with different parameters, an HMAC with an
| ephemeral secret, or an ordinary cryptographic hash.
| These are all options, with different security tradeoffs.
|
| Part of the evaluation of key derivation functions and
| their parameters is the evaluation of the risk that the
| hashed value is compromised. These values are stored in
| files or in databases, and there is a correspondingly
| higher risk of compromise... e.g. through backups. Your
| conclusions would be different for an in-memory cache
| which is harder to compromise and contains fewer entries,
| so you would naturally choose a different way of storing
| the passwords. Different algorithms or different
| parameters.
|
| (There are also other interesting solutions around...
| like using an HSM to MAC the passwords.)
| codazoda wrote:
| Yes, if you use PBKDF2 for the hashing and you do it with every
| request.
|
| In my template I'm using bcrypt and I'm doing it with every
| request. That might not scale well.
|
| One commenter suggested storing a session token, probably one
| that expires, and not authenticating if that exists.
|
| But, I'm using this for MVP's to see if they'll gain any kind
| of traction. Once a tool gets the kind of traction where this
| will be a problem it will be time to rethink the auth method.
| Denvercoder9 wrote:
| Huh? HTTP Basic Authentication doesn't use PBKDF2 (or any other
| key derivation function).
| billpg wrote:
| The server will have a clear-text (leaving the base64 to one
| side) password in the HTTP request and a PBKDF2 (or similar)
| token loaded from the user database.
|
| Unless you store the user's password in the clear inside your
| user database, but will have other security issues.
| Denvercoder9 wrote:
| Ok, but if you handle that in the app, it doesn't get
| invoked for CSS/JS/images/etc requests.
| [deleted]
| nuccy wrote:
| I find HTTP basic auth very useful to "protect" gitlab, wiki,
| forum, et al. internal resources exposed to the internet. With a
| simple apache/nginx config it is possible effectively to hide
| those from the intenet and in addition to their built-in
| authentications (ldap-based) have a fense reliable enough to
| prevent zero-day vulnerabilities of these populular web
| applications. Having them as sub-folders of a single web-domain
| (with proper rewrites added to apache/nginx) prevents numerous
| HTTP basic auth requests so authentication is required just once
| after the browser has been restarted.
| mbreese wrote:
| I have a few webpages that have to be protected this way, due
| to an external client that only supports HTTP Auth. I've
| actually been pretty happy with this setup. I have nginx
| configured to use subauth authentication so I can still have
| external username/passwords stored in LDAP, etc. It's been a
| surprisingly good combination.
| loevborg wrote:
| I do the same, e.g. to expose static resources like API docs in
| an S3 bucket to the world (you can configure CloudFront to
| check Basic Auth). However, at some point you run into issues
| (doesn't work well with password managers, how do new team
| members learn the password, no easy way to rotate passwords
| when offboarding, etc.).
|
| Now I want to upgrade to a proper OAuth wall. Some server needs
| to act as a reverse proxy that has permission to access the
| private resource but checks your identity as a, say, Google
| Apps user.
|
| Assuming a private bucket on S3, what's the easiest way to
| accomplish this today?
| zorr wrote:
| I used vouch-proxy with nginx for something like this.
|
| The nginx auth_request module authenticates each request
| against vouch-proxy before it executes the proxy_pass. Vouch-
| proxy can be configured to authenticate users against google
| apps or other oauth/iodc providers. And there are some
| options to pass along username, groups or other data as
| headers to the proxied service.
| rmbyrro wrote:
| Maybe combining Lambda integration with CloudFront (CF)?
|
| You could intercept every HTTP request before it reaches CF,
| check auth data and decide to let it through or respond with
| 401 already. The CF auth password could be kept as an
| internal secret. You rotate temporary passwords on Lambda
| environment variables (bit insecure) or using AWS Secrets
| Manager (very safe).
|
| Requests successfully authenticated on Lambda level gets
| rewritten with the master CF password to make them succeed
| there.
|
| It's a lot more trouble than simply setting up basic auth,
| but you setup only once and theoretically it works.
| foepys wrote:
| > doesn't work well with password managers, how to new team
| members learn the password, no easy way to rotate passwords
| when offboarding
|
| This is where LDAP and similar are really strong.
| Unfortunately a lot of companies know that and charge big
| bucks for this simple feature, often hiding it behind
| "enterprise" subscriptions where you need to contact them for
| pricing.
|
| It's also the reason why companies love Exchange and the rest
| of Microsoft's ecosystem.
| loevborg wrote:
| That's the thing though - I don't want the complexity of
| Exchange, LDAP, etc. Complexity kills. This is a simple
| problem calling for a straightforward solution.
| VTimofeenko wrote:
| Technically as far as I understand the client side
| certificates and signing/revoking them through internal CA
| solve the same problems.
|
| However I have yet to encounter such setup used in a
| professional environment for humans. Is the complexity of
| such approach just too high compared to LDAP and the
| passwords?
| mooreds wrote:
| You can use API Gateway to delegate to any auth server that
| can generate JWTs. https://docs.aws.amazon.com/apigateway/lat
| est/developerguide... has more details.
| dbetteridge wrote:
| Amazon cognito?
| mckmk wrote:
| Google Cloud offers Identity Aware Proxy and AWS offers
| Cognito integration with their Application Load Balancers
| which can do this.
| loevborg wrote:
| That's helpful thanks. Googling "CloudFront cognito" gives
| me a bunch of interesting links:
|
| https://awslabs.github.io/aws-cloudfront-
| extensions/deploy/d...
|
| https://aws.amazon.com/blogs/security/protect-public-
| clients...
| showerst wrote:
| I do the same thing; really nice for those things you just
| can't put behind a VPN for one reason or another.
| nuccy wrote:
| A nice alternative to VPN (especially when you don't have a
| root to set it up) is using ssh tunnels: _ssh user@server -D
| 1234_ and Firefox with socks proxy set to _127.0.0.1:1234_
| (e.g. using Foxyproxy addon, though possible without it via
| the Firefox network settings). Then all Firefox trafic is
| exiting on the server side (including DNS requests).
| znpy wrote:
| > including DNS requests
|
| Don't be sure about that!
|
| There's an additional setting to check to be sure dns goes
| through the proxy.
|
| Can't recall the details now, but it's there!
|
| Or maybe it was due to dns over tls not being proxied?
| yuliyp wrote:
| This has many flaws that make it impractical beyond hobby
| projects or projects with a small set of users: - It's trickier
| to throttle credential checks as every request is a login
| request, effectively - It's hard to easily build account recovery
| flows or captchas into the login process. - The UX of logging
| in/out is browser-dependent and confusing for users - it can't
| integrate well with other auth systems - Sending a password on
| every request requires care to avoid accidentally logging
| passwords - Every request needs to do password validation,
| presenting additional load on the authentication
| systems/datastores
| gjsman-1000 wrote:
| I wonder if there would be an audience for an HTTP Basic Auth
| 2.0 spec.
|
| Some of your criticisms aren't exactly accurate though.
| "Sending a password on every request requires care to avoid
| accidentally logging passwords" applies to almost every login
| system ever made. Unless you use browser-based hashing with
| JavaScript, but that has significant known flaws and doesn't
| add much security.
|
| And "Every request needs to do password validation, presenting
| additional load on the authentication systems/datastores" also
| applies to almost every login system ever made and HTTP Basic
| Auth doesn't make this better or worse.
| Operyl wrote:
| > And "Every request needs to do password validation,
| presenting additional load on the authentication
| systems/datastores" also applies to almost every login system
| ever made and HTTP Basic Auth doesn't make this better or
| worse.
|
| Not true. Once you get authenticated you can store that in a
| cookie with expiration, or any number of other ways to reduce
| load on auth services.
| usrbinbash wrote:
| 1. You could do the same in a BasicAuth system.
|
| 2. How is validating the session-cookie validity different
| from validating the username/password?
| jerf wrote:
| For 2, in many cases validating username/password
| requires hitting an external system. If you want to give
| your IT department a fun day, write a moderately popular
| internal web service that accidentally hits LDAP freshly
| for every single web request. It's really easy to
| accidentally do in some environments. Session cookie
| validation will typically only involve local resources.
|
| For many of my internal tools I don't even bother with a
| database and just store it in local RAM, especially when
| I have no other database involvement, because having all
| sessions reset every few months during a reboot or
| restart is worth it to not have to stand up a database
| solely for that purpose. In that case it's just a quick
| lock&lookup in a map/dict/whatever your language favors
| to see if the token matches or not.
| marcosdumay wrote:
| > How is validating the session-cookie validity different
| from validating the username/password?
|
| Validating codes is done with fast crypto algorithms,
| while validating passwords uses purposefully slow
| algorithms.
| freedomben wrote:
| A non-trivial difference is that to validate password you
| need to run it through bcrypt or similar algorithm which
| is intentionally slow. With a token or cookie, you can
| use a regular fast hashing algorithm.
| usrbinbash wrote:
| Nothing prevents me from using BaseAuth for the login,
| and then issuing a session cookie to the user.
| manigandham wrote:
| That's exactly the same with HTTP Basic Auth. Set the
| cookie and skip checking the credentials.
|
| Another user even mentions doing exactly this:
| https://news.ycombinator.com/item?id=29762073
| dqv wrote:
| >I wonder if there would be an audience for an HTTP Basic
| Auth 2.0 spec.
|
| Yes! I remember in the early aughts, IE6 would present this
| cool login screen [0] for (what I think, but may be
| remembering incorrectly) HTTP Basic Auth. I always wanted to
| do that, but didn't really understand anything other than
| making basic HTML pages.
|
| It _could_ help improve security. It 's a ubiquitous login
| screen that makes it really obvious which domain is
| requesting credentials - no need to check if the page looks
| off to detect possible phishing. Oh and you wouldn't run in
| to the issue of accidentally logging in on the sign up page!
|
| [0]: https://blog.stevensanderson.com/2008/08/25/using-the-
| browse...
| gjsman-1000 wrote:
| I wouldn't bet on it improving security, personally.
|
| If I was a hacker, I can use the User-Agent to know what OS
| they are using (or close enough). I also know what browser
| they are using.
|
| I can use this information to create a custom webpage with
| a white background and similar imagery to look like the
| native browser form. If the user was unsuspecting, they
| might not realize it's not a separate window, and think
| that they were logging into the correct site.
| easton wrote:
| "Press CTRL-ALT-DEL to log into this webpage."
|
| (/s, you just reminded me of the help text for the log in
| screen circa 2000/XP)
| forgotmypw17 wrote:
| That's not necessarily true, because you can combine it with
| cookies.
|
| This is actually exactly how I use it: HTTP Auth is the first
| step to get in, then set a cookie which bypasses HTTP Auth in
| future sessions.
|
| Effectively, it is a captcha.
| usrbinbash wrote:
| >This has many flaws that make it impractical
|
| Just because something is simple doesn't make it impractical.
| Not every application requires a complex auth-flow.
|
| >As every request is a login request, effectively
|
| This is the case with basically every single Authentication
| flow in existence...at the end of the day, no matter how and
| where credentials are verified, there is a token that has to be
| sent with every request and verified server side.
|
| >hard to easily build account recovery flows
|
| Why?
|
| > UX of logging in/out is browser-dependent and confusing for
| users
|
| Its a display with username/password and one or 2 buttons, one
| of which says "Login", the other of which says "Cancel" or
| something similar. How is this confusing?
|
| > it can't integrate well with other auth systems
|
| Why?
| codazoda wrote:
| Probably true. I'm not suggesting it for your enterprise
| project. I'm just trying to remove personal roadblocks so I can
| test an MVP before I invest too much development time.
| hiptobecubic wrote:
| Did you even read the post?
| yuliyp wrote:
| Yes, I did. Hence why I pointed out one of the
| characteristics that made it work fine in the scenario
| mentioned (that it has a relatively small set of users that
| can be trained), and many of the concerns I mentioned are not
| particularly applicable to the situation which the OP
| presented. I was making the point that the OP's success is
| not necessarily transferable to large scale applications.
| [deleted]
| skywal_l wrote:
| Stupid question: why not use nginx? Configuring basic auth is
| about 4 lines of config.
|
| Nginx is fairly simple and is overkill only for dev setup for
| which you don't need auth anyway.
| prpl wrote:
| oauth2-proxy is as simple as HTTP Basic Auth (and can also accept
| HTTP Basic as well) - no great reason to not use it, along with
| REMOTE_USER header
| RedShift1 wrote:
| HTTP basic auth RFC is 14 pages. The OAuth2 RFC is 76 pages,
| and that's only the framework. Perhaps we have a different
| understanding of what "simple" means...
| yegle wrote:
| It's always easy to add Oauth flow to a website that uses basic
| auth, by using an identity aware reverse proxy (e.g.
| https://pomerium.io).
| smitty1e wrote:
| One non-technical advantage is prototyping.
|
| Going this route says to the consulting client: this is NOT the
| full solution. This is only work-in-progress. If you treat this
| as the final delivery and deploy this to prod, you're making a
| big mistake.
|
| Not that I've ever seen that happen, mind you.
| bdcravens wrote:
| I use it for an internal API that needs credentials to make
| additional calls. It lets me keep the HTTP semantics super clean.
| Shadonototra wrote:
| HTTPS is a mess, certificates are a mess
|
| Not everything needs it and yet it is mendatory for everything
| you want to do
|
| Just had get throught all of that mess for a simple websocket
|
| This is beyond sad
| kogir wrote:
| My big problem with HTTP basic auth in 2022 (squints at Netgear
| router) is that in Edge/Chrome 1Password can't auto complete it.
| It gets really annoying really quickly.
| xnaas wrote:
| Bitwarden has 0 issues 'autofilling' basic auth. It just passes
| the login credentials on connection and you never see a basic
| auth prompt.
| jeroenhd wrote:
| That's actually a gripe I have with Bitwarden, because you
| can't turn that feature off. If an attacker can take over a
| single endpoint, Bitwarden will happily send your credentials
| to an iframe from a malvertiser without ever telling you.
|
| It's a fine feature and the WebExtension API won't let them
| solve basic auth in any other way, but it's a security risk
| in my opinion. I'd much rather see browsers provide an API to
| HTTP Basic auth prompts instead so the user can select an
| identity from the list if they've got a saved
| username/password combo that matches a given set of
| requirements.
| watermelon0 wrote:
| It only supports a single user/pass pair for each site. There
| are many cases where you would want to use multiple
| identifies and switch between them.
| progforlyfe wrote:
| 100% this! At least Firefox with 1password seems to handle it
| okay.
| cadence- wrote:
| This is great for small projects and services that have just a
| few users and an easy way to change passwords and create/delete
| accounts directly in the backend. It's secure (although you must
| use HTTPS) and is very easy and fast to use, especially if you
| have a password manager that automatically fills out the login
| form.
| zimbatm wrote:
| HTTP Basic Auth could be so much better with a little help from
| browsers. If it was a bit better, most websites wouldn't need to
| implement login pages over and over again. Plus it would be more
| secure since the popup is in its own security context.
|
| * Add a button to log out. Logout never really worked across
| browsers with basic auth.
|
| * Allow to inject a logo or a tiny bit of customization for
| branding. The default popup looks too ugly.
|
| * Improve the Digest auth to modern crypto standards. Stop
| passing plain passwords over the wire.
|
| That's it. It's not a massive amount of work and it could enable
| to simplify a lot of the Internet.
| LinAGKar wrote:
| Digest auth is fundamentally less secure, as it requires the
| server to have access to the plain text password, whereas with
| basic auth you can store it salted and hashed. And you should
| be using HTTPS regardless.
| slim wrote:
| Stop passing plain passwords over the wire
|
| this is already solved by https
| [deleted]
| lukevp wrote:
| Only partially. If the client and server have an agreement on
| a hashing protocol, there's no reason that the browser
| shouldn't be able to hash as well and prevent the password
| from ever leaving memory on the client system. HTTPS is still
| vulnerable to many man in the middle attacks, and many
| corporate and business networks do deep packet inspection to
| decrypt https (they control the machines so intercepting the
| cert issuance and installing their own root CA is easily
| doable). Another issue is that improper logging on the server
| (or depending on the implementation, even intermediate load
| balancers) could accidentally leak the plaintext password.
| Client side hashing is a much better solution to this, and if
| it's a native browser supported protocol, it would even work
| without JS.
| axiosgunnar wrote:
| Your suggestion is vulnerable to the
| https://en.m.wikipedia.org/wiki/Pass_the_hash attack.
|
| Your suggestion is basically going back to the days where
| databases stored plaintext passwords in the database, just
| that the plaintext happens to be a hash.
| lixtra wrote:
| > If the client and server have an agreement on a hashing
| protocol, there's no reason that the browser shouldn't be
| able to hash as well and prevent the password from ever
| leaving memory on the client system.
|
| Shouldn't it be a proper challenge/response? Otherwise the
| hash is barely better than the password.
| ncann wrote:
| How do you do client side hashing without the server
| sending the salt/pepper to the client, which is a really
| bad thing?
| notfed wrote:
| There are answers to this. I asked myself this a few
| years ago, which led recursively to new tricky questions.
| I eventually solved the tree of the questions: I designed
| myself into a solution that I later realized was
| essentially an asymmetric PAKE (e.g., analogous to
| OPAQUE).
|
| So, an attempt to solve your question eventually leads to
| using an asymetric PAKE. But, this is way, way more
| complex. You'd really have to squint your eyes to believe
| that the diminishing returns are worth it.
| jeroenhd wrote:
| What does it matter? If a criminal gains the hash, they can
| log in and be malicious anyway. If a criminal can do a
| MitM, they can substitute the Javascript that's hashing
| your password with all the nonces and salts and peppers you
| add to it and send the password anyway.
|
| If you just hash the password, the hash becomes the
| password. You're not solving the problem that way, you're
| just switching around definitions.
|
| There is an alternative that's supported in most platforms,
| and that's WebAuthn. Not even a need for a password
| automatic secure handshakes and with the right protocols,
| the keys differ per site so they're very hard to spoof
| through phishing. You can achieve much of the same thing
| with client TLS certificates, but the UX for that is even
| worse than the UX for HTTP Basic.
| staticassertion wrote:
| > What does it matter? If a criminal gains the hash, they
| can log in and be malicious anyway.
|
| To that one site. But users reuse passwords and if a
| criminal only has a hash they can't reuse it across
| sites.
| jeroenhd wrote:
| But the attacker controls the TLS connection already, so
| they'll just strip out the hashing functionality or send
| a piece of JS to steal the password directly from the
| password field.
|
| It's not that I don't understand where you're coming from
| (I once almost started writing such a library a few years
| back!), but I just can't think of a threat model where
| this makes sense. That's also what moved me away from
| working on such a system.
|
| To me, this approach feels like an attempt to recreate
| software-only U2F, but outside the browser. I don't think
| client side code can fix these problems. It can make
| stealing passwords more difficult for criminals if every
| website uses their own bespoke password processing
| script, but that'll also add a huge attack surface to
| your code and it'll be a burden to maintain.
| staticassertion wrote:
| I don't know why people are assuming the attacker:
|
| A) Controls the code running the auth API
|
| B) Controls the javascript
|
| As if that's the common attack.
|
| The common attack is that the attacker has a read on the
| hash, either through injection vulnerabilities or other
| leaks.
|
| Your attacker, as described, has _remote code execution_
| on a server that hosts the auth API and the Javascript in
| one place. That is a very specific, powerful attacker!
|
| > but I just can't think of a threat model where this
| makes sense
|
| 1. An attacker has CSRF and can trick your code into
| sending the hash to them. This significantly reduces the
| harm of that attack.
|
| 2. An attacker has an injection vulnerability giving them
| read access to hashes ie: sql injection, perhaps the most
| significant and relevant attack to discuss with
| passwords.
|
| 3. An attacker takes advantage of a timing attack,
| bruteforcing the server and measuring response times to
| leak its value. They can now only leak the hashed value,
| which is going to take way longer to leak and doesn't
| expose their password.
|
| And more!
|
| This defense tackles what are very very arguably the
| major threats to consider with regards to password
| security (they're the big ones in OWASP top 10).
|
| > It can make stealing passwords more difficult for
| criminals if every website uses their own bespoke
| password processing script, but that'll also add a huge
| attack surface to your code and it'll be a burden to
| maintain.
|
| You can significantly reduce harm and attack surface with
| all of 3 lines in your frontend code.
| salt = hash(username + static_salt) password_hash
| = pbkdf2(plaintext_password, salt)
|
| it's trivial to implement this.
|
| I'll grant you that PAKEs may be more complex to
| implement today, but even if we talk about a _very_ basic
| implementation of client side hashing I think there 's
| obvious value.
| StefanKarpinski wrote:
| The password is still revealed to the server. There are
| password verification protocols where the password is not
| revealed to the server either, which is much more secure as
| it means that you're not at the mercy of whether the sever
| operator follows good security practices about not saving
| your password in plain text somewhere.
| LinAGKar wrote:
| >The password is still revealed to the server.
|
| And with digest auth, the server must have the plain text
| password already. But sure, maybe there is a third option.
| thaumasiotes wrote:
| > There are password verification protocols where the
| password is not revealed to the server either, which is
| much more secure as it means that you're not at the mercy
| of whether the sever operator follows good security
| practices about not saving your password in plain text
| somewhere.
|
| Well, the most common such protocol is TOTP, which still
| requires the server to store your full password. In that
| sense it's worse than a naive password exchange, which only
| requires the server to store your hashed password.
|
| There are other password protocols that require neither
| transmission nor server retention of the full password, but
| it seems worth noting that the protocol we actually have
| didn't bother with that.
| teekert wrote:
| Does it matter if the pw is stored salted and hashed?
| thaumasiotes wrote:
| Yes, that's why we do that.
|
| I'm not sure what you want to ask.
| gjsman-1000 wrote:
| "Stop passing plain passwords over the wire."
|
| If you are using HTTPS, you are equally as good as any other
| login form.
|
| Some have suggested using JavaScript to encrypt passwords
| before send - but in my opinion, this is generally stupid
| because it breaks support on browsers without JavaScript, and
| this doesn't protect you from the server at all because a
| hacker could just change the JavaScript to send plaintext
| copies somewhere. You are reliant on the server being a source
| of truth either way.
| dllthomas wrote:
| You've responded as if the bit you've quoted is advice to
| individual developers in the present context, but the topic
| of conversation was about extending browsers so that the
| standard login form would do this (... better than existing
| auth digest). If we did that and people were used to using
| the browser's built-in login dialog, and (as with https) we
| made it visible what security features were enabled, then a
| trivial server-side change _wouldn 't_ compromise user
| passwords.
| gjsman-1000 wrote:
| Right... that would be awesome. But it would still be
| susceptible to a hacker replacing it with a traditional
| login page with some logging... unless somehow you could
| prevent any traditional web pages from working.
| madacol wrote:
| And users WILL NOTICE before that happens
|
| Please, stop using those strawman arguments
| gjsman-1000 wrote:
| I beg to differ. You'd be surprised how many users
| probably would not recognize any difference whatsoever as
| long as the hacker got things looking relatively
| identical.
| oconnore wrote:
| No, it would be much better to use a zero knowledge proof
| (typically called a PAKE -- password authenticated key
| agreement) to demonstrate that the user knows their password
| without sending that password over the channel.
|
| Sending the password over HTTPS doesn't expose the password
| to passive observers, but it does unnecessarily expose the
| password to the server.
|
| https://en.m.wikipedia.org/wiki/Password-
| authenticated_key_a...
| geektips wrote:
| Intresting idea, this kind implementation would have
| prevented password leak from something like Cloudbleed[0]
|
| [0] https://en.m.wikipedia.org/wiki/Cloudbleed
| michaelcampbell wrote:
| > No, it would be much better to use a zero knowledge proof
|
| Yes, it would. A further improvement to an improvement
| doesn't take away from the first improvement. Don't let the
| perfect be the enemy of the good.
| armchairhacker wrote:
| idk if you even need a zero knowledge proof.
|
| Server sends client a salt, client hashes the salt and
| password and sends back to server.
|
| Implement this as a built-in feature of the web browser,
| and the browser can show a special icon or symbol to mark
| that the password will be sent hashed (and later show a
| warning on password fields sent via plaintext).
| xmprt wrote:
| Could that really work? Sounds like it's highly abusable
| if someone compromises the database and gets a list of
| all the hashes. Now, they don't even need to use rainbow
| tables or any brute force to compute the password. They
| just send the hash to the server and will be logged in.
| thrashh wrote:
| But most login forms don't do that anyway so it wouldn't be
| any worse than how things are already done.
| gjsman-1000 wrote:
| > "but it does unnecessarily expose the password to the
| server"
|
| Yes - it does - but I am having a hard time thinking that
| this actually matters in the real world.
|
| I can understand why not sending the password to the
| server, would be theoretically more secure. However in
| practice, what hacking attempts does this actually prevent?
|
| If I was a hacker, I can add JavaScript to send plaintext
| somewhere. If I was a hacker, I could change the login form
| to stop hashing them client-side and instead send them over
| to the server for hashing and inspection.
|
| It's theoretically more secure... but against _what?_
| Accidental logging? I mean, I guess, but then just set up
| your logs correctly instead of breaking login for anyone
| without JavaScript.
|
| In my opinion, client-side hashing is security theater. It
| sounds impressive, but it doesn't really stop any real-
| world attacks, and the attacks it does prevent can be
| prevented using simpler methods. Ironically, the other
| methods (i.e. making sure your logs are clean) are so much
| simpler to implement it's probably more secure than trying
| to build a secure client-hashing implementation in the
| first place.
| almost wrote:
| Credential stuffing is a thing. So it's pretty good if a
| compromised website just cannot leak your password.
|
| But as the other comment pointed out the current
| situation with web form login is that password is sent to
| server so it wouldn't be worse than the the status quo.
| gjsman-1000 wrote:
| I hope you are kidding.
|
| A compromised website that was well designed _should not_
| leak your password any more than a client-side hashing
| implementation. This is because the passwords are hashed
| in the database. Client-side hashing means that, yes,
| initially the website is not receiving plaintext
| passwords, but a few quick code edits to maybe add some
| logging JavaScript or disable the client-side hashing
| implementation will fix that.
|
| And credential stuffing? Client-side hashing does
| absolutely nothing to prevent credential stuffing other
| than that you may need a GPU to do a lot of hashes
| quickly. Client-side hashing doesn't make a server handle
| more or less authentication requests.
| masklinn wrote:
| > A compromised website that was well designed
|
| Ah yes, "if nobody makes any mistake there's no problem",
| that's worked so well forever hasn't it?
|
| > Client-side hashing means that, yes, initially the
| website is not receiving plaintext passwords, but a few
| quick code edits to maybe add some logging JavaScript or
| disable the client-side hashing implementation will fix
| that.
|
| That makes quite literally no sense, did you miss the
| entire thing and go off with whatever?
|
| The request here is to make _the browser 's support for
| HTTP authentication better_. The entire point is that
| there is no "quick code edit" without owning the entire
| browser at which point you're quite thoroughly owned
| anyway.
| garbagecoder wrote:
| I don't think he understands salts or really hashing at
| all and this is messing up the logic in his posts.
| garbagecoder wrote:
| If "should" were a word that meant what people thinks it
| means, we wouldn't need security at all.
| weaksauce wrote:
| I could be missing something but they are not suggesting
| to use a javascript version but the version where the
| zero knowledge algorithm is used at the browser level.
| the password would never be outside the secure context of
| the browser and nothing other than the algorithm bits
| would be sent.
| masklinn wrote:
| You're not missing anything, GP is.
| fivelessminutes wrote:
| If someone gets a copy of the encrypted traffic - and we
| know that 'full take' is being done routinely for some
| parts of the internet - the credential in the plaintext
| means that if they are ever able to decrypt it even weeks
| later, they can make fresh connections using the valid
| credential afterwards.
|
| If the server issues a different challenge each time,
| decrypting one response doesn't buy you anything.
| gjsman-1000 wrote:
| I guess this makes sense - but who is capable of
| decrypting it weeks later unless the original private key
| was stolen, in which case it could be decrypted almost in
| real-time? Maybe if you were concerned a nation-state or
| something was trying to get your private key, but you've
| got bigger fish to fry at that point.
| w3ll_w3ll_w3ll wrote:
| Also, using TLS with Perfect Forward Secrecy (all modern
| ciphers), it's not possible to just capture the traffic
| and dectypt it later. You have to know the private key
| and do MITM.
| throw0101a wrote:
| > _If I was a hacker, I can add JavaScript to send
| plaintext somewhere. If I was a hacker, I could change
| the login form to stop hashing them client-side and
| instead send them over to the server for hashing and
| inspection._
|
| If a zero knowledge (ZK) system combined with HTTP Basic
| was used, then account entry would come from the browser
| itself and not a web form that could be intercepted by
| JavaScript.
|
| Further, a ZK system would help with the silliness of
| folks using bad algorithms (straight MD-5 / SHA-1) to
| store passwords, or even storing them in plain-text.
| gjsman-1000 wrote:
| Right - it would, I don't disagree, it'd be awesome. It's
| something like WebAuthn.
|
| I'm arguing here more against some people who think that
| using a JavaScript-based system to hash the password
| entry before sending it to the server is a good idea.
| madacol wrote:
| So you are strawmanning?
| masklinn wrote:
| > I'm arguing here more against some people who think
| that using a JavaScript-based system to hash the password
| entry before sending it to the server is a good idea.
|
| So you're arguing against something nobody is arguing
| for?
| oconnore wrote:
| - If you share your password across sites that used a
| hypothetical browser-implemented PAKE, site A cannot
| login to your account on site-B
|
| - If a site is attacked, there is no risk that password
| material was extracted from application memory -- site
| operator can dump session tokens and safely re-auth
| users.
| gjsman-1000 wrote:
| This sounds like an interesting system, but I think you
| are arguing for a system that as-of-now is only
| theoretical and is very different against the current
| crop of JavaScript-powered client-side-hashing methods
| which I am arguing against.
| indymike wrote:
| The first implementation was Bellovin and Merritt's
| Encrypted Key Exchange in 1992. In 2000 a provably secure
| implementation was released. PAKE has been around for
| quite some time and is proven, and is in wide use in the
| field. Here's a decent article on the subject:
| https://blog.cryptographyengineering.com/2018/10/19/lets-
| tal...
| gjsman-1000 wrote:
| I don't dispute the technology exists - I dispute that
| this technology can be deployed on a web app to general
| users effectively. I don't believe that is currently
| possible in production effectively in a way that
| neutralizes my arguments that an attacker could just
| change the JavaScript to record passwords somewhere.
| madacol wrote:
| That's why the browser's built-in login Form could be so
| useful, it would have its own security context, so I, as
| a user can be sure that no Javascript could read that
|
| I would happily sign up and reuse a password for a
| website that I didn't trust if it were as secure as
| described (PAKE + browser built-in login)
| staticassertion wrote:
| PAKE isn't theoretical at all and the post you're
| responding to didn't say client side hashing it said zero
| knowledge proofs.
| gjsman-1000 wrote:
| PAKE is theoretical from a web-development perspective
| because there is no secure way for me to implement PAKE
| in my web app for a user to log in with in 2022. It
| doesn't exist - you tell me how to implement PAKE login
| right now.
|
| Zero Knowledge Proofs would be awesome (something like
| WebAuthn/FIDO right now?) but I am arguing more in
| general against client-side hashing methods that are
| currently usable, mainly JavaScript-based ones.
| staticassertion wrote:
| Not sure what you mean.
|
| 1. There is, of course, a way to implement it in your web
| app. I don't know what you mean by "no secure way" ?
|
| > I am arguing more in general against client-side
| hashing methods that are currently usable, mainly
| JavaScript-based ones.
|
| Even a trivially implemented client side hashing approach
| protects against a number of attacks.
| gjsman-1000 wrote:
| I meant, let's say I picked a framework. Django, Laravel,
| Express, similar.
|
| How would I implement PAKE login for my users? How would
| I get every user to log in with PAKE? How would I ensure
| that my code for PAKE could not be overwritten if a
| hacker took over part of my server?
|
| It doesn't exist, AFAIK, on a user-facing front at this
| time in a secure way that a hacker couldn't just change
| the logic for.
| cassonmars wrote:
| PAKE isn't about preventing compromise at the serving of
| the front end. That's still the responsibility of the
| server maintainer. PAKE is about reducing damage
| potential. The responsibility of keeping your servers
| secure applies regardless of use of PAKE. PAKE just makes
| it possible that if your database is leaked in some
| smash-and-grab someone can't just run a rainbow table
| against it to suss out passwords against emails.
| staticassertion wrote:
| Implementing opaque isn't overly hard. You can find
| pseudocode, implementations, state machine diagrams, etc,
| online. Here's a good post that links to implemented
| code: https://blog.cloudflare.com/opaque-oblivious-
| passwords/
|
| I know nothing of framework support, I don't use
| frameworks. I'm likely going to contribute some open
| source code in the near future from my company to
| simplify things though.
|
| But you could also just have your client do:
| salt = sha256("your company name goes here" + username)
| password_hash = pbkdf2(plaintext_password, salt)
|
| and get some nice benefits.
|
| > How would I ensure that my code for PAKE could not be
| overwritten if a hacker took over part of my server?
|
| Depends on the server and the level of control. But it'll
| help in a number of cases. You're assuming the attacker
| has full control over the web-page's contents (among
| other things - even if an attacker had the web page's
| contents CORS means they couldn't send http only cookies
| to an attacker controlled server), which is a very
| specific, powerful position to be in.
| pests wrote:
| What benefits would you get though?
|
| You are still exposing the password_hash to the server
| and any compromise there (software or hardware, as
| described in your link) would still let an attacker grab
| password_hash, craft a custom client, and send it as if
| the original client had hashed the plaintext_password to
| begin with.
|
| The attacker doesn't need to know plaintext_password,
| just the string you use to authenticate with in order to
| replay it. The password_hash becomes the new password.
|
| Then due to the salt being on the client, it still opens
| the password up to rainbow table attacks etc.
| staticassertion wrote:
| If the attacker only has access to the hash that hash is
| only usable for your website. If the user uses the same
| password for another site an attacker can not log into
| that other site using the hash.
|
| That's really the main benefit of this approach - it
| reduces the impact of password reuse.
| wswope wrote:
| If I'm understanding your argument correctly (I may not
| be) - implementing PAKE would only be helpful in a
| scenario where an attacker gets access to hashed
| passwords, but isn't able to modify front-end code to
| directly intercept unhashed passwords, right?
| staticassertion wrote:
| You are correct. I (and I think most people?) consider
| that to be the most common attacker scenario.
| scoopertrooper wrote:
| Not theoretical, you can do it today.
|
| https://www.npmjs.com/package/libopaque
| na85 wrote:
| >Yes - it does - but I am having a hard time thinking
| that this actually matters in the real world.
|
| In the 90s and early aughts it was fashionable for php
| sites to store passwords hashed, usually some combination
| of a salt with md5 and later the SHA variants.
|
| For a brief few years there were entire communities on
| IRC and elsewhere dedicated to making rainbow tables for
| cracking stolen password hashes.
|
| Often the salt would be common across all passwords, so
| if you got a database dump it was a gold mine for
| credentials.
| staticassertion wrote:
| A trivial fix here is to:
|
| a) Add a static value to the salt ie: your company's name
|
| b) Add the user's email address to the salt
|
| The "right" way would be a zero knowledge proof.
| na85 wrote:
| Yeah well PHPnuke wasn't exactly written by secure coding
| experts.
| gjsman-1000 wrote:
| Right - but that's been resolved, PHP and others now
| store the unique salt used with the password together, so
| every password has its own salt.
|
| That didn't need client-side hashing to fix it.
| garbagecoder wrote:
| Gee, it's almost like on the internet there are computers
| between you and the destination.
| garbagecoder wrote:
| Is this a parody of a webdev?
| staticassertion wrote:
| > Accidental logging?
|
| Yes, it happens all the time that passwords get logged.
|
| > I mean, I guess, but then just set up your logs
| correctly instead of breaking login for anyone without
| JavaScript.
|
| I have no idea what "set up your logs correctly" is
| supposed to mean but clearly no one's doing it. What is a
| "clean log" ?
|
| > If I was a hacker, I can add JavaScript to send
| plaintext somewhere. If I was a hacker, I could change
| the login form to stop hashing them client-side and
| instead send them over to the server for hashing and
| inspection.
|
| This assumes you have full control over the client page.
| But that's not necessarily (or often? most people don't
| serve JS from the same code that serves their auth API)
| the case.
|
| 1. The JS could be loaded from a CDN, not the same
| service that has access to the password. You may have
| absolutely no control over the JS on the page.
|
| 2. Every point between the browser and the password DB is
| a point where the password is in cleartext. So a
| compromise of any of those, including any logging paths,
| is a compromise of the password.
|
| 3. I don't think anyone cares about breaking login for
| users who don't use JS, nor should they.
|
| What's more, ZKP means that if your password database is
| owned the impact is _far_ less. If you 're doing things
| right for password storage on top of ZKP you can
| practically make your password db public.
|
| Even if we're talking about a basic client side hashing
| approach you're significantly improving security, but to
| be clear, the parent poster is talking about ZKPs, which
| involve more than that.
| gjsman-1000 wrote:
| > "I have no idea what "set up your logs correctly" is
| supposed to mean but clearly no one's doing it. What is a
| "clean log"?"
|
| As you admitted, passwords get logged "all the time." So
| the reasonable solution in most cases would be to ensure
| all applicable logs were clean and not logging passwords,
| _not_ over-engineer a JavaScript-powered client-side-
| hashing algorithm. That 's like taking a sledgehammer to
| a nail.
| staticassertion wrote:
| Sorry, but the idea that implementing "clean logs" is:
|
| a) Tractable
|
| b) Simple or straightforward
|
| compared to client side hashing is _absurd_.
|
| Client side hashing is a one time solution forever that
| exists in one place, requiring no 'cooperation' from
| other code to be safe. "Cleaning logs", which you still
| haven't defined at all, is going to be a constant
| maintenance burden that can break in any place where you
| log ie: absolutely fucking everywhere by absolutely
| fucking everyone.
| gitgrump wrote:
| gjsman-1000 wrote:
| How complex and unusual is the authentication system you
| are working on?
|
| If it was a consumer-facing web app, it's not like your
| password is logged in a million different places. It's
| possibly logged by your web server software (nginx in my
| case), and it's possibly logged by your web app
| framework's requests handler. It's not terribly hard to
| ensure that these points where the password passes
| through do not have passwords in their logs, or to ensure
| that said passwords are not logged to begin with.
|
| If it was a massive enterprise system, I would hope that
| you would use a single-sign-on system with a centralized
| login page rather than exposing passwords to every web
| app within it. And then, just ensure that said passwords
| are not stored in logs. This is what I meant by clean
| logs - anywhere the password is used, ensure there is no
| record. How much code and how many layers does a password
| need to go through?
|
| And yes, maybe client-side hashing does resolve some
| attacks, but I remain convinced that it is overkill and
| less protective than it initially seems. And in the
| future we would move to Zero-Knowledge Proofs but we
| aren't there yet for general users.
| staticassertion wrote:
| Plenty of very simple web apps terminate TLS at the edge
| ie: at something like API Gateway. So if you then turn on
| request logging... voila. Hardly a complex scenario,
| happens all the time. Or at the application layer:
| @path("/login") def login(request):
| print("I have a bug, I'll just log the whole request real
| quick to see wtf is up!", request)
|
| It's actually very hard to ensure that the password
| doesn't get logged. It requires _constant discipline and
| maintenance_. Any bug or change could expose it.
|
| > I would hope that you would use a single-sign-on system
| with a centralized login page rather than exposing
| passwords to every web app within it
|
| Implementing SSO is a great idea. Not everyone wants to
| use SSO though. If I were hosting a porn site I wouldn't
| expect my users to happily "sign in with Facebook". It's
| also much more work than a basic client hash.
|
| > This is what I meant by clean logs - anywhere the
| password is used, ensure there is no record. How much
| code and how many layers does a password need to go
| through?
|
| You underestimate the places logs can be generated or
| passwords can be accidentally persisted.
|
| 1. Your proxy
|
| 2. Crashes, stack traces, segfaults, core dumps, thread
| dumps, VM snapshots, free'd memory
|
| 3. Firewalls, both network and host
|
| 4. Audit logs for security, such as via ebpf or other
| auditing frameworks
|
| 5. The application, at any layer. In Python, did you know
| I can get a reference to the calling function? I've done
| this for logging purposes before, in fact. So even if
| your caller is super careful not to pass the password in,
| saving me from accidentally logging it, I can crawl back
| up the stack and get it anyway.
|
| 6. Your database logs
|
| 7. Services/ RPCs that sit between your auth API and your
| database
|
| And as your business grows and your code changes you'll
| have to track all of that.
|
| Orrrrrrrrr, you can just hash your password on the client
| side and significantly reduce the damage of a leak. Or
| put the extra work in to implement OPAQUE. Or use
| webauthn, that's cool too.
| jstummbillig wrote:
| > It's not a massive amount of work
|
| Oh, sweet summer child
| vbezhenar wrote:
| I don't really see it simplifying a lot of internet. Everyone
| will make his custom login page anyway, you need to add links
| to registration, password recovery and so on. And sending
| password on every request, hashed or not, is just bad security,
| you need session token anyway.
| adolph wrote:
| I think second party controls are probably the reason why
| browser intermediated login was never pursued until the
| present era of password management--the browser is a third
| party that can facilitate/intermediate communication between
| the first party (user) and second party (website). It would
| be foolish for a website operator to hand their users over to
| Microsoft back in the day, just as "social login" is a
| convenience/optimization trap today.
| ClumsyPilot wrote:
| "you need to add links to registration, password recovery and
| so on"
|
| All of which could be easilly standardized
| mooreds wrote:
| > Add a button to log out. Logout never really worked across
| browsers with basic auth.
|
| In my experience, the way to logout is to close the browser. Is
| this standardized anywhere?
|
| > Allow to inject a logo or a tiny bit of customization for
| branding. The default popup looks too ugly.
|
| I think that this would be nice, but most anyone who wants
| customization will want to control everything, and wouldn't be
| a fit for the limits of basic auth.
|
| > Improve the Digest auth to modern crypto standards. Stop
| passing plain passwords over the wire.
|
| As others have mentioned, TLS helps with this, but I agree that
| it would be a good idea to hash it anyway.
|
| Have you thought about submitting these improvements to
| chromium and firefox (as feature requests)?
| merlinscholz wrote:
| Please do not add logo customization. This will end with
| prompts asking you for your Apple and Microsoft passwords which
| are difficult to differentiate from official prompts (at least
| for end users).
| adamzochowski wrote:
| One of my favourite auth is the NTLM/SSPI which came out of the
| the windows NTLM world.
|
| Users don't even see they are being asked to be authenticated,
| they are either logged in, or told they don't have access.
|
| Works great in corporate world.
| RedShift1 wrote:
| I love it too, when it works... When it doesn't, the users
| get the login prompt like the basic auth one, which can be
| confusing because you have no opportunity to add information
| to that prompt.
| fzzt wrote:
| There's a lot more to that. A bank doesn't want the "back"
| button to work forever; they want to control the lifetime of
| your session, ideally on the server. Google wants to let you
| sign into multiple accounts on the same origin. Many others
| want to have seamless single sign-on across several of their
| web properties. Sometimes, you want the change of your password
| to invalidate other sessions (say, when recovering a
| compromised account); other times, you don't want to kick out
| your smart thermostat and have to set it up from scratch.
|
| Admittedly, there are some simple use cases where HTTP auth is
| all you need, but it's just way too inflexible, unless you turn
| it into some mammoth spec that is never going to be as flexible
| and tempting as managing user identity yourself.
|
| Especially since HTTP auth doesn't actually mean you can stop
| doing that anyway. You're still handling account creation,
| password checking, all the abuse / bot detection bits... all
| you're getting rid of is the sign-on and logout functionality,
| which is really not that complicated to begin with.
| madacol wrote:
| Maybe we don't want them to be able to do any of that
|
| And I think you are missing the point, the goal it's not to
| standardize logins, it's about making impossible for servers
| to know my password, hence impossible passwords leaks
|
| That would allow people to reuse strong passwords, and not
| need passwords managers, because that's what they are doing
| anyway!
| [deleted]
___________________________________________________________________
(page generated 2022-01-01 23:00 UTC)