7 ms·

Maybe each request needs to be authenticated?

stanmancan 12y ago
If you're authenticating with a username and password on every request you're doing something wrong. Once a user is logged in you should be setting a cookie, session, or some other token to identify the user.
- ryan-c 12y ago
  I believe HTTP basic auth checks the username and password on every request. It's pretty rarely used these days though.
  - artursapek 12y ago
    Only for secret admin tools :D
- giaour 12y ago
  A fair number of APIs offer basic auth, even in 2015.
  - carbocation 12y ago
    Hell, the Reddit API uses basic auth in 2015.
    - stanmancan 12y ago
      Yikes... I guess I've been pretty lucky with the API's I've had to work with in the past, I can't recall ever coming across this.
orthecreedence 12y ago
Authenticate once, generate a token, and use the token for auth from that point. I can't think of a case where you'd need to send the u/p on each request.
- proksoup 12y ago
  Does that token not become a new attack vector that also needs a certain level of security or encryption? Or because it expires, the duration means it doesn't matter if it's compromised?
  - toong 12y ago
    Exactly this. I see that token used - sometimes in the http request header - but most of the time as a param in the GET request, over plain http. Does it even matter if my auth was secure ? I just need to get hold of some access logs and I can impersonate everyone ?
    - uxp 12y ago
      If you're writing http headers out to your apache logs on your production server, you're doing it _severely_ wrong. edit: I'm specifically talking about http basic auth with a precomputed "Authentication: base64($username + $passwd)" header, not a GET of "/foobar?api_key=12345abcd". The latter is obvious in it's failures and is not related to http basic auth.
      - toong 12y ago
        Obviously :-) If you're going after basic-auth-headers, you'd probably be sniffing the network. > Authenticate once, generate a token, and use the token for auth from that point. If that token is passed back and forth in the http url, it ends up at places where it's easy to find/intercept. You can use a gazillion bcrypt rounds to store the password: they still send me a link to a page, including their auth-token.
    - toong 12y ago
      Edit: My intention was to get some input on how to properly use auth-tokens.
astrodust 12y ago
Highly unlikely. If you've got an API or site designed around validating passwords on each request you've failed as an engineer.
- proksoup 12y ago
  Oh --- so this bcrypt stuff does not apply to session tokens? Those are okay to leave unencrypted in memory or on disk or something?
  - tptacek 12y ago
    No, of course not. The CS problem behind a password hash (or KDF) is to exploit time and memory to convert a low-entropy secret into something with the strength of a high-entropy secret. But when you're securing individual HTTP requests with session tokens, you simply use high-entropy secrets, and thus don't have the password hash problem.
    - proksoup 12y ago
      If users picked really good passwords, full sentences with high entropy --- would we not need to encrypt them? Sorry I think you already explained this, I'm just swimming. I probably should have basic CS understanding to be in this conversation ....
      - tptacek 12y ago
        If users picked 128 bit random numbers as their passwords, any hash function would suffice to store authenticators for them. You'd still want to hash them, because presumably users will re-use the same 128-bit random number on several machines. But it would be infeasible to brute force them, so MD4 would do just fine. There is no reason to hash a secure cookie, because they aren't used across several machines. The compromise of a stored session key implies that every system where that cookie is valuable is also compromised.
        12y ago

If you're authenticating with a username and password on every request you're doing something wrong. Once a user is logged in you should be setting a cookie, session, or some other token to identify the user.

ryan-c 12y ago
I believe HTTP basic auth checks the username and password on every request. It's pretty rarely used these days though.
- artursapek 12y ago
  Only for secret admin tools :D
giaour 12y ago
A fair number of APIs offer basic auth, even in 2015.
- carbocation 12y ago
  Hell, the Reddit API uses basic auth in 2015.
  - stanmancan 12y ago
    Yikes... I guess I've been pretty lucky with the API's I've had to work with in the past, I can't recall ever coming across this.

orthecreedence 12y ago

Authenticate once, generate a token, and use the token for auth from that point. I can't think of a case where you'd need to send the u/p on each request.

proksoup 12y ago
Does that token not become a new attack vector that also needs a certain level of security or encryption? Or because it expires, the duration means it doesn't matter if it's compromised?
- toong 12y ago
  Exactly this. I see that token used - sometimes in the http request header - but most of the time as a param in the GET request, over plain http. Does it even matter if my auth was secure ? I just need to get hold of some access logs and I can impersonate everyone ?
  - uxp 12y ago
    If you're writing http headers out to your apache logs on your production server, you're doing it _severely_ wrong. edit: I'm specifically talking about http basic auth with a precomputed "Authentication: base64($username + $passwd)" header, not a GET of "/foobar?api_key=12345abcd". The latter is obvious in it's failures and is not related to http basic auth.
    - toong 12y ago
      Obviously :-) If you're going after basic-auth-headers, you'd probably be sniffing the network. > Authenticate once, generate a token, and use the token for auth from that point. If that token is passed back and forth in the http url, it ends up at places where it's easy to find/intercept. You can use a gazillion bcrypt rounds to store the password: they still send me a link to a page, including their auth-token.
  - toong 12y ago
    Edit: My intention was to get some input on how to properly use auth-tokens.

astrodust 12y ago

Highly unlikely. If you've got an API or site designed around validating passwords on each request you've failed as an engineer.

proksoup 12y ago
Oh --- so this bcrypt stuff does not apply to session tokens? Those are okay to leave unencrypted in memory or on disk or something?
- tptacek 12y ago
  No, of course not. The CS problem behind a password hash (or KDF) is to exploit time and memory to convert a low-entropy secret into something with the strength of a high-entropy secret. But when you're securing individual HTTP requests with session tokens, you simply use high-entropy secrets, and thus don't have the password hash problem.
  - proksoup 12y ago
    If users picked really good passwords, full sentences with high entropy --- would we not need to encrypt them? Sorry I think you already explained this, I'm just swimming. I probably should have basic CS understanding to be in this conversation ....
    - tptacek 12y ago
      If users picked 128 bit random numbers as their passwords, any hash function would suffice to store authenticators for them. You'd still want to hash them, because presumably users will re-use the same 128-bit random number on several machines. But it would be infeasible to brute force them, so MD4 would do just fine. There is no reason to hash a secure cookie, because they aren't used across several machines. The compromise of a stored session key implies that every system where that cookie is valuable is also compromised.
      - 12y ago