7 ms·

What is authenticating millions of users per second? Facebook has 900M monthly users, 30M per day and probably most of those are cookied in. Even if not that's

What is authenticating millions of users per second? Facebook has 900M monthly users, 30M per day and probably most of those are cookied in. Even if not that's only 350 authentications/sec...

proksoup 12y ago
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
nly 12y ago
You're right, authentication rates are low. But Moxies point of concern with regard to requiring a heavier CPU and memory commitment on the server is still valid, particularly when faced with malicious traffic. You need to make sure your login system can handle malicious clients, brute-force attempts from individual IPs, or against particular accounts, dropping back to CAPCTHAs or some other means of resource control when things look bad. This isn't a particularly easy problem to solve, and if you do it incorrectly you open yourself and your users up to a denial-of-service. IMHO, some of the new fancy password-based authentication protocols, like AugPAKE, which do hashing client-side, might ease this problem... but they're still stateful (SYN floods anyone?) and therefore still depend upon good DoS protection. Edit: Oh poop, you're djb.
- tptacek 12y ago
  That's not Daniel Bernstein.
  - sarciszewski 12y ago
    I have to admit, when I saw the username, I sorta hoped it was.
- worklogin 12y ago
  There are separate concerns of brute-force mitigation that people should look into regardless of their hashing technology. Things like exponential-growth cooldowns per IP/user account (with lots of caveats to prevent cooldown-DDoS) should be used. http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication http://stackoverflow.com/questions/549/the-definitive-guide-...
- IvyMike 12y ago
  > Moxies point of concern with regard to requiring a heavier CPU and memory commitment on the server is still valid, particularly when faced with malicious traffic.h How about this: Save two hashes, one low cost, one high cost--both must pass for login. Don't run the high cost unless the low cost one works first. Note: not a security guy, so I'm probably overlooking something silly. Edit: the two responses below (thus far) are reasons you should not do this. Duh on my part.
hackcasual 12y ago
Not normally, but it does open up a DoS vector that at the very least will prevent legitimate users from logging in.
- tptacek 12y ago
  It's one of thousands of DoS vectors, all of which are addressed the same way: coarse ad-hoc anomaly filters.
  - mox1 12y ago
    But its a non-obvious (imo) attack vector opened simply by switching to scrypt / bcrypt. In a perfect world, quality web apps have rate limiting built into their auth schemes. But it's important to acknowledge these two algorithms will put a much heavier burden on your CPU.
    - tptacek 12y ago
      Most DoS vectors are non-obvious, so this seems like a very weak reason to change the way you do password hashing.
yxhuvud 12y ago
Think infrastructure rather than appliances like Facebook. What do you think happens if certain state keeping big authentication servers or routers reboot? We have a customer that has more than one million users on a GGSN (which is a glorified router). If that happen to restart every single customer will immediately and automatically try to reconnect. The systems involved actually doesn't tend to handle this many in reality (the ISP in question restrict it to some 20-30k/s to our system). These systems are starting to be better at supporting keeping state through restarts, but there can still be pretty impressive spikes of authentication traffic if the wrong system is rebooted (or crashes!).

What is authenticating millions of users per second? Facebook has 900M monthly users, 30M per day and probably most of those are cookied in. Even if not that's only 350 authentications/sec...

proksoup 12y ago

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

nly 12y ago

You're right, authentication rates are low. But Moxies point of concern with regard to requiring a heavier CPU and memory commitment on the server is still valid, particularly when faced with malicious traffic. You need to make sure your login system can handle malicious clients, brute-force attempts from individual IPs, or against particular accounts, dropping back to CAPCTHAs or some other means of resource control when things look bad. This isn't a particularly easy problem to solve, and if you do it incorrectly you open yourself and your users up to a denial-of-service. IMHO, some of the new fancy password-based authentication protocols, like AugPAKE, which do hashing client-side, might ease this problem... but they're still stateful (SYN floods anyone?) and therefore still depend upon good DoS protection. Edit: Oh poop, you're djb.

tptacek 12y ago
That's not Daniel Bernstein.
- sarciszewski 12y ago
  I have to admit, when I saw the username, I sorta hoped it was.
worklogin 12y ago
There are separate concerns of brute-force mitigation that people should look into regardless of their hashing technology. Things like exponential-growth cooldowns per IP/user account (with lots of caveats to prevent cooldown-DDoS) should be used. http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication http://stackoverflow.com/questions/549/the-definitive-guide-...
IvyMike 12y ago
> Moxies point of concern with regard to requiring a heavier CPU and memory commitment on the server is still valid, particularly when faced with malicious traffic.h How about this: Save two hashes, one low cost, one high cost--both must pass for login. Don't run the high cost unless the low cost one works first. Note: not a security guy, so I'm probably overlooking something silly. Edit: the two responses below (thus far) are reasons you should not do this. Duh on my part.

hackcasual 12y ago

Not normally, but it does open up a DoS vector that at the very least will prevent legitimate users from logging in.

tptacek 12y ago
It's one of thousands of DoS vectors, all of which are addressed the same way: coarse ad-hoc anomaly filters.
- mox1 12y ago
  But its a non-obvious (imo) attack vector opened simply by switching to scrypt / bcrypt. In a perfect world, quality web apps have rate limiting built into their auth schemes. But it's important to acknowledge these two algorithms will put a much heavier burden on your CPU.
  - tptacek 12y ago
    Most DoS vectors are non-obvious, so this seems like a very weak reason to change the way you do password hashing.

yxhuvud 12y ago

Think infrastructure rather than appliances like Facebook. What do you think happens if certain state keeping big authentication servers or routers reboot? We have a customer that has more than one million users on a GGSN (which is a glorified router). If that happen to restart every single customer will immediately and automatically try to reconnect. The systems involved actually doesn't tend to handle this many in reality (the ISP in question restrict it to some 20-30k/s to our system). These systems are starting to be better at supporting keeping state through restarts, but there can still be pretty impressive spikes of authentication traffic if the wrong system is rebooted (or crashes!).