4 ms·

>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.

>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?

yuliyp 5y ago
> 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 with auth cookies vs seeing a username / password > account recovery The way I've seen browsers implement password auth generally blocks interacting with the rest of the page. While a normal login form might have a "forgot password / email" link, with basic auth the user is stuck with a modal that the web site owner has no control over and cannot build such affordances. > integration with other auth systems In general, other auth systems take a set of credentials and then issue a token that can be used for further authentication. Basic Auth's design is that the same credential is used for every request. I guess you could build a hybrid auth system that can accept either cookies/headers from an alternative system, or basic auth and just have some sort of rules for dealing with what happens if both are present, but at that point why not just use a normal login page if you're already dealing with support for session tokens of some sort?
- usrbinbash 5y ago
  > username/password can get harvested in lots of ways, 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.
  - yuliyp 5y ago
    My comment about username/password being harvested was talking about how someone's password can get stolen: you can have malware, password reuse across sites, phishing, or other social engineering. For session cookies, you have basically malware as the compromise vector. Hence, passwords should be treated with more suspicion by an authentication system.
    - usrbinbash 5y ago
      All these attack vectors work regardless of the Authentication system used.
      - yuliyp 5y ago
        They don't, though. Users don't reuse session cookies between sites, so another site compromised doesn't mean you have to worry about existing sessions being compromised on your site. Users also don't know their session cookies so are far less likely to go typing them in to a phishing site or hand them out over the phone. A password is vulnerable to all of these scenarios.

yuliyp 5y ago

> 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 with auth cookies vs seeing a username / password > account recovery The way I've seen browsers implement password auth generally blocks interacting with the rest of the page. While a normal login form might have a "forgot password / email" link, with basic auth the user is stuck with a modal that the web site owner has no control over and cannot build such affordances. > integration with other auth systems In general, other auth systems take a set of credentials and then issue a token that can be used for further authentication. Basic Auth's design is that the same credential is used for every request. I guess you could build a hybrid auth system that can accept either cookies/headers from an alternative system, or basic auth and just have some sort of rules for dealing with what happens if both are present, but at that point why not just use a normal login page if you're already dealing with support for session tokens of some sort?

usrbinbash 5y ago
> username/password can get harvested in lots of ways, 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.
- yuliyp 5y ago
  My comment about username/password being harvested was talking about how someone's password can get stolen: you can have malware, password reuse across sites, phishing, or other social engineering. For session cookies, you have basically malware as the compromise vector. Hence, passwords should be treated with more suspicion by an authentication system.
  - usrbinbash 5y ago
    All these attack vectors work regardless of the Authentication system used.
    - yuliyp 5y ago
      They don't, though. Users don't reuse session cookies between sites, so another site compromised doesn't mean you have to worry about existing sessions being compromised on your site. Users also don't know their session cookies so are far less likely to go typing them in to a phishing site or hand them out over the phone. A password is vulnerable to all of these scenarios.