5 ms·

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

by yuliyp 5y ago

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

codazoda 5y ago
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 5y ago
Did you even read the post?
- yuliyp 5y ago
  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.
gjsman-1000 5y ago
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 5y ago
  > 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 5y ago
    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 5y ago
      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 5y ago
      > 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 5y ago
      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.
forgotmypw17 5y ago
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 5y ago
>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.

by yuliyp 5y ago

codazoda 5y ago

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 5y ago

Did you even read the post?

yuliyp 5y ago
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.

gjsman-1000 5y ago

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 5y ago
> 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 5y ago
  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 5y ago
    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 5y ago
    > 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 5y ago
    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.

forgotmypw17 5y ago

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 5y ago

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