4 ms·

It’s about 100 records per second for a year and a half, or 10,000 records per second for 5 days. Both are easily achievable. As an engineer, why would you ever

It’s about 100 records per second for a year and a half, or 10,000 records per second for 5 days. Both are easily achievable. As an engineer, why would you ever knowingly design such a system when it’s trivial to not have this vulnerability in the first place. It’s like hosting an internal app at a company that contains a SQL injection. “Well, if a hacker can access this app, then that’s a problem that needs addressing either way.” Sure, that may be true, but it’s also true that you’re not a good software engineer.

arp242 2y ago
> It’s like hosting an internal app at a company that contains a SQL injection It's nothing like that at all because the wrong SQL injection can completely ruin people's lives due to leaking stuff it shouldn't whereas the worst an int exhaustion can do is bring some app offline. Whoopdie-doo. Okay, that's not brilliant, but it's not comparable at all. And there's a reason there aren't tons of "int exhaustion attacks": because there's little point in doing so.
- lazide 2y ago
  So taking down the apps ability to insert any rows into the table (and hence breaking the app) isn’t going to impact anyone? Including the apps ability to make money? This does happen and break people. You usually don’t hear about it (except on the SRE side) because it is so obvious when it happens to someone they really don’t like talking about it.
  - arp242 2y ago
    I never said it's "not going to impact anyone", I said it's not comparable. "Denial of service" is just not a security bug on the same level as "zomg my credit card is stolen". I have argued this many times before, e.g. https://news.ycombinator.com/item?id=39377795 https://news.ycombinator.com/item?id=39377795 – It's easy to knock most sites offline regardless just by flooding it with traffic, don't need long-term plans like this (which are likely to be detected before it even has effect). > This does happen and break people I have never heard about a deliberate attack using this method.
fauigerzigerk 2y ago
That's not a great analogy. SQL injection is a completely binary issue. A single malicious statement that gets through can do all the damage. Defending against denial of service attacks is a gradual, multifaceted problem that is pretty unlikely to hinge on the size of database keys. If your system is dimensioned to serve a few hundered users then it's not going to be a whole lot more robust if it can theoretically create thousands of trillions of user records rather than just hundereds of millions. In fact, infinite scalability is a risk in its own right because it can bankrupt you, which is arguably worse than a temporary outage. That said, I tend to use 64 bit IDs by default as well unless there is a good reason not to (because, you know, what if I'm the next Google?!?).
rattray 2y ago
Either of those situations should be very easy to catch and prevent with basic rate limiting and monitoring.

arp242 2y ago

> It’s like hosting an internal app at a company that contains a SQL injection It's nothing like that at all because the wrong SQL injection can completely ruin people's lives due to leaking stuff it shouldn't whereas the worst an int exhaustion can do is bring some app offline. Whoopdie-doo. Okay, that's not brilliant, but it's not comparable at all. And there's a reason there aren't tons of "int exhaustion attacks": because there's little point in doing so.

lazide 2y ago
So taking down the apps ability to insert any rows into the table (and hence breaking the app) isn’t going to impact anyone? Including the apps ability to make money? This does happen and break people. You usually don’t hear about it (except on the SRE side) because it is so obvious when it happens to someone they really don’t like talking about it.
- arp242 2y ago
  I never said it's "not going to impact anyone", I said it's not comparable. "Denial of service" is just not a security bug on the same level as "zomg my credit card is stolen". I have argued this many times before, e.g. https://news.ycombinator.com/item?id=39377795 https://news.ycombinator.com/item?id=39377795 – It's easy to knock most sites offline regardless just by flooding it with traffic, don't need long-term plans like this (which are likely to be detected before it even has effect). > This does happen and break people I have never heard about a deliberate attack using this method.

fauigerzigerk 2y ago

That's not a great analogy. SQL injection is a completely binary issue. A single malicious statement that gets through can do all the damage. Defending against denial of service attacks is a gradual, multifaceted problem that is pretty unlikely to hinge on the size of database keys. If your system is dimensioned to serve a few hundered users then it's not going to be a whole lot more robust if it can theoretically create thousands of trillions of user records rather than just hundereds of millions. In fact, infinite scalability is a risk in its own right because it can bankrupt you, which is arguably worse than a temporary outage. That said, I tend to use 64 bit IDs by default as well unless there is a good reason not to (because, you know, what if I'm the next Google?!?).

rattray 2y ago

Either of those situations should be very easy to catch and prevent with basic rate limiting and monitoring.