3 ms·

How do people have "scaling" problems with authentication? I have never heard of the source of a scaling problem be related to user accounts.

dangerlibrary 13y ago
healthcare.gov is the only example that comes to mind.
rch 13y ago
Maybe he meant authorization and entitlements, which can easily run into scaling problems. The articles seem to conflate 'authorization' with 'authentication' for sake of simplicity.
- dvanduzer 13y ago
  No one in the industry can really agree on what AAA means once humans get involved. Ping added a fourth A for Account Management in an Attempt to Address the Ambiguity: https://www.pingidentity.com/resource-center/authentication-authorization-audit-logging-account-management.cfm https://www.pingidentity.com/resource-center/authentication-... But trust and authority are deeper concepts than just usernames and passwords for the latest web app. Managing a sprawling system with multiple levels of access and demonstrating proof of security? The computers running the services and protocol translations aren't the parts that have trouble scaling anymore. (Hint: The L in LDAP. Compared to what?)
  - rch 13y ago
    I have a friend that is emphatic about the benefits of what he terms 'realm-role' security[1], which I do prefer over some of the more byzantine approaches I've dealt with. The levels of complexity stack up on the user side too, especially if you try to accommodate wandering contexts in multitenancy scenarios. His model doesn't try to address those requirements, which may be for the best. [1] http://www.bivio.biz/bp/Realm_Role_Task/Diagram http://www.bivio.biz/bp/Realm_Role_Task/Diagram
rdegges 13y ago
Good question! There are a lot of issues (that I've experienced personally): - Hashing passwords is CPU intensive if you're doing computationally expensive stuff (bcrypt, scrypt). - If your site has user accounts, it's likely that every single page on your site requires some sort of user data: maybe files, videos, links, custom information, whatever. This means that for most people, every site request generates cache hits / database queries which can end up slowing things down substantially if you have a non-trivial amount of users. There are also other issues out there as well, e.g: you're building a service oriented application, so you have a lot of internal services (myapp-www, myapp-billing, myapp-logs), and you need to share your user data between them securely -- how do you do that? Share your user database with all applications? Build your own internal user API service? Hope that helps!
- OhHeyItsE 13y ago
  Look, I'm not trying to be intentionally confrontational - I actually find your product interesting. However, I'm just not understanding the angle you're going for here. > Hashing passwords is CPU intensive if you're doing computationally expensive stuff (bcrypt, scrypt). If you are continually logging-in so many accounts that hashing the supplied password is becoming a performance problem, you are either doing something terribly wrong, or you are so big that no SaaS could possibly support you anyway (FB?, Google?). > If your site has user accounts, it's likely that every single page on your site requires some sort of user data This, in fact, IS a scaling problem, but I don't see how it's related to authentication. It's a content/caching problem. And even if the problem here was related to auth - are you suggesting that whichever DB/IO operation is causing it can be made faster by a HTTP request going out of the datacenter? Not really sure that's how I'd fix it...
  - rdegges 13y ago
    Ah, this is also a great question. So, regarding the hashing stuff: password hashing is supposed to be slow, which is why bcrypt / scrypt are so popular. A lot of people (probably not most HN readers) sometimes don't realize that this can actually cause performance implications on busy servers. Even if you're running a small business on a reasonably sized EC2 instance, handling the password hashing on an already busy server can definitely cause problems if you're serving several requests per second (or more). It's not a big issue, but certainly a real one that many people don't realize they have. (Interestingly, if you use NewRelic and do Bcrypt stuff -- check it out!). In regards to user data -- you're completely correct. It's not an authentication problem. I wrote about that quite a bit as I think it's important as user data is also sensitive information. Just like you wouldn't want to leak user password hashes, you also wouldn't want to leak user data. At stormpath, we provide the data service because we think it's critically important to have your user data secured in the same fashion as your user authentication information -- and as a side effect -- it helps users scale this. If you're on EC2, you'll likely get the same latency you'd have writing to a Cassandra database locally (with very small overhead) from the Stormpath service. Furthermore, our clients implement really smart caching rules, and can do interesting stuff like transparently handle object caching to a memcached or redis cluster, smartly handle data synchronization, etc.). Hope that helps! Also: I really do appreciate these comments, it's an incredibly interesting topic, and it's really useful to hear what other people think! Thank you :D

dangerlibrary 13y ago

healthcare.gov is the only example that comes to mind.

rch 13y ago

Maybe he meant authorization and entitlements, which can easily run into scaling problems. The articles seem to conflate 'authorization' with 'authentication' for sake of simplicity.

dvanduzer 13y ago
No one in the industry can really agree on what AAA means once humans get involved. Ping added a fourth A for Account Management in an Attempt to Address the Ambiguity: https://www.pingidentity.com/resource-center/authentication-authorization-audit-logging-account-management.cfm https://www.pingidentity.com/resource-center/authentication-... But trust and authority are deeper concepts than just usernames and passwords for the latest web app. Managing a sprawling system with multiple levels of access and demonstrating proof of security? The computers running the services and protocol translations aren't the parts that have trouble scaling anymore. (Hint: The L in LDAP. Compared to what?)
- rch 13y ago
  I have a friend that is emphatic about the benefits of what he terms 'realm-role' security[1], which I do prefer over some of the more byzantine approaches I've dealt with. The levels of complexity stack up on the user side too, especially if you try to accommodate wandering contexts in multitenancy scenarios. His model doesn't try to address those requirements, which may be for the best. [1] http://www.bivio.biz/bp/Realm_Role_Task/Diagram http://www.bivio.biz/bp/Realm_Role_Task/Diagram

rdegges 13y ago

Good question! There are a lot of issues (that I've experienced personally): - Hashing passwords is CPU intensive if you're doing computationally expensive stuff (bcrypt, scrypt). - If your site has user accounts, it's likely that every single page on your site requires some sort of user data: maybe files, videos, links, custom information, whatever. This means that for most people, every site request generates cache hits / database queries which can end up slowing things down substantially if you have a non-trivial amount of users. There are also other issues out there as well, e.g: you're building a service oriented application, so you have a lot of internal services (myapp-www, myapp-billing, myapp-logs), and you need to share your user data between them securely -- how do you do that? Share your user database with all applications? Build your own internal user API service? Hope that helps!

OhHeyItsE 13y ago
Look, I'm not trying to be intentionally confrontational - I actually find your product interesting. However, I'm just not understanding the angle you're going for here. > Hashing passwords is CPU intensive if you're doing computationally expensive stuff (bcrypt, scrypt). If you are continually logging-in so many accounts that hashing the supplied password is becoming a performance problem, you are either doing something terribly wrong, or you are so big that no SaaS could possibly support you anyway (FB?, Google?). > If your site has user accounts, it's likely that every single page on your site requires some sort of user data This, in fact, IS a scaling problem, but I don't see how it's related to authentication. It's a content/caching problem. And even if the problem here was related to auth - are you suggesting that whichever DB/IO operation is causing it can be made faster by a HTTP request going out of the datacenter? Not really sure that's how I'd fix it...
- rdegges 13y ago
  Ah, this is also a great question. So, regarding the hashing stuff: password hashing is supposed to be slow, which is why bcrypt / scrypt are so popular. A lot of people (probably not most HN readers) sometimes don't realize that this can actually cause performance implications on busy servers. Even if you're running a small business on a reasonably sized EC2 instance, handling the password hashing on an already busy server can definitely cause problems if you're serving several requests per second (or more). It's not a big issue, but certainly a real one that many people don't realize they have. (Interestingly, if you use NewRelic and do Bcrypt stuff -- check it out!). In regards to user data -- you're completely correct. It's not an authentication problem. I wrote about that quite a bit as I think it's important as user data is also sensitive information. Just like you wouldn't want to leak user password hashes, you also wouldn't want to leak user data. At stormpath, we provide the data service because we think it's critically important to have your user data secured in the same fashion as your user authentication information -- and as a side effect -- it helps users scale this. If you're on EC2, you'll likely get the same latency you'd have writing to a Cassandra database locally (with very small overhead) from the Stormpath service. Furthermore, our clients implement really smart caching rules, and can do interesting stuff like transparently handle object caching to a memcached or redis cluster, smartly handle data synchronization, etc.). Hope that helps! Also: I really do appreciate these comments, it's an incredibly interesting topic, and it's really useful to hear what other people think! Thank you :D