4 ms·

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

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
nathancahill 13y ago
You've hit the nail on the head here, comparing "slow" DB/IO operations to a "faster?!" HTTP request. I don't even.. "You'll likely get the same latency you'd have writing to a Cassandra database locally". Nope, no I won't. Not even close.

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

nathancahill 13y ago

You've hit the nail on the head here, comparing "slow" DB/IO operations to a "faster?!" HTTP request. I don't even.. "You'll likely get the same latency you'd have writing to a Cassandra database locally". Nope, no I won't. Not even close.