Using HTTP Basic Auth in 2022
281–290 of 345 posts
Re: Using HTTP Basic Auth in 2022
#282Earlier quoted context omitted.
>Search crawlers won’t be able to index the site, which protects me from haters finding my content, and RSS feed urls can just hardcore some u/p without consequence. Sadly, I've seen at least one exception to this rule. Somehow, a search engine crawler wised up to my admin/admin captcha, and I had to change it.
Yeah, one exception will always exist somewhere, but I'm not much worried about the exceptions.
When browsing a handful of trusted sites from behind a NAT on a secure network, I don't think it's that much of a security risk.
Re: Using HTTP Basic Auth in 2022
#283HTTP 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 po…
Re: Using HTTP Basic Auth in 2022
#284Earlier quoted context omitted.
> "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…
Scenario 1: Attacker compromises ECOMMERCE_SITE where you have a login. The ECOMMERCE_SITE uses md5 for logins, so the attacker just brute-forces the hash and then uses that password to compromise your logins on other sites. Scenario 2: The ecommerce site has upgraded to SHA512, so cracking isnt an option. But the site is relying on basic auth, so the attacker simply sniffs your password when you auth. Scenario 3: th…
While I'd like that to be true, it really isn't. There have been loads of card skimming operations injected into production sites which weren't noticed for sometimes months.[0][1][2][3]
[0]: https://blog.malwarebytes.com/hacking-2/2020/03/criminals-ha...
[1]: https://www.wired.com/story/british-airways-hack-details/
[2]: https://www.riskiq.com/blog/external-threat-management/magec...
Re: Using HTTP Basic Auth in 2022
#285HTTP 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 po…
Don’t even stop there. Instead of typing in a username and password, have my browser give me a drop down with my identities so I can use just one of them. Then have the browser sync my (encrypted with my pass phrase) identities across all my browsers/devices. No more passwords.
Re: Using HTTP Basic Auth in 2022
#286Re: Using HTTP Basic Auth in 2022
#287Earlier quoted context omitted.
> "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…
> 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 cha…
You have full control over it, as long as you don't embed any third-party maps or crap like ads.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Re: Using HTTP Basic Auth in 2022
#288Earlier quoted context omitted.
PAKE is highly phishing resistant. If you type your password for an important website into a browser-controlled PAKE UI, but you’re being phished and the browser tries to authenticate to a malicious website, the worst the website can do is guess one single password. It can’t relay the password to the real website.
Good point that it protects against a phishing site that exactly replicates the victim site but with a different URL. But the phishers could do a slight variation. They could create a website that looks very similar to the browser's Basic Auth popup, but implemented in HTML and Javascript. Most people won't notice the difference. Most people don't understand the line of death[1]. [1] https://textslashplain.com/2017/0…
In the context of the pop-up: a simple pop up can be faked. But what if the browser would flash all the borders (and other stuff outside the line of death) when the real popup is displayed?
I'm not saying any of this is 100% foolproof, just that we should be doing some UI experiments on real people to see what works better.
Re: Using HTTP Basic Auth in 2022
#289Earlier quoted context omitted.
>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 a…
> impractical Completely agree. My points generally apply a lot more to large scale systems. > every request is a login request While it's true that every request has something being verified for authentication purposes, login is a higher risk activity: username/password can get harvested in lots of ways, while session cookies etc. generally are harder to steal, meaning there is less risk of an attacker being present…
BasicAuth isn't more at risk of this than other methods however. Unless a website doesn't use HTTPS, but if that's the case, all talk about security is out the window anyway.
> The way I've seen browsers implement password auth generally blocks interacting with the rest of the page.
BasicAuth Challenge -> Wrong Password -> Server replies with 200 + "Did you forget your password klick here ..." page instead of 401. There, pwd recovery system implemented using BasicAuth.
Re: Using HTTP Basic Auth in 2022
#290The primary flaw isn't BASIC AUTH. It's the password itself. Brute force attacks are easy. The only good way of securing anything is through an Authenticator app.