I died a little inside reading this article. Clearly we have a lot farther to go with secure development lifecycle evangelism.
Using HTTP Basic Auth in 2022
151–160 of 345 posts
Re: Using HTTP Basic Auth in 2022
#152Earlier quoted context omitted.
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. Ther…
> 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.
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.
Re: Using HTTP Basic Auth in 2022
#153Earlier quoted context omitted.
"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…
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 trivia…
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.
Re: Using HTTP Basic Auth in 2022
#154Earlier quoted context omitted.
Your "is this password valid" cache would need to be indexed by the clear-text password. That's a separate security issue.
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.
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.
Re: Using HTTP Basic Auth in 2022
#155Earlier quoted context omitted.
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.
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.
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.
Re: Using HTTP Basic Auth in 2022
#156oauth2-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
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...
Re: Using HTTP Basic Auth in 2022
#157Earlier quoted context omitted.
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.
But still, why reinvent the wheel? There are plenty of libraries, even services available that do what you want.
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.
Re: Using HTTP Basic Auth in 2022
#158Earlier quoted context omitted.
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.
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.
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)
> 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.
Re: Using HTTP Basic Auth in 2022
#159Earlier quoted context omitted.
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= . 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…
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 with…
[deleted]
Re: Using HTTP Basic Auth in 2022
#160The 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?