5 ms·
> imagine you make a tab-completed typo when deleting a row. Yeah, you've just deleted an arbitrary row somewhere in your DB This line seems to be the sole jus
by lucideer 9y ago
> imagine you make a tab-completed typo when deleting a row. Yeah, you've just deleted an arbitrary row somewhere in your DB
This line seems to be the sole justification for the hyperbolic title. You might do tab-completed typo...
There's three justifications listed - the above (fairly minor, imo) one, information disclosure, and entity enumeration (which in this context is just another term for information disclosure).
The part on information disclosure has this line:
> all it takes to know your user count is to create an account. A number of social networks boasting impressive user bases were pwn3d this way
What? I would love a reference or explanation here. Who has been "pwn3d" by exposing their user count?
The "security through obscurity is bad" rhetoric has been rightly debunked plenty at this stage - obscurity is a valid component of layered security, but obscuring your table row count seems... odd. Why would that be a secret?
If you're worried about people being able to enter primary keys into a URL to access/scrape arbitrary records, you need better auth.
- gnu8 9y agoStrikes me as extremely reckless to edit a production database live with some tab completing editor. Is it really the norm to do that?
- LandR 9y agoI don't know if its the norm but we do it here. Right click table, edit top 200 rows to add a new row. We, unfortunately, edit the live db all the time.
- EGreg 9y agoIt would seem to me that you should strictly control what software can edit the db. If you need some special feature, build it into your app and test it first. A general purpose editor can destroy the consistency of your entire database, or parts of it which you won't know about but your users will!
- LandR 9y agoYes, I understand it's a disaster waiting to happen. I mean if we want to edit a stored proc in the db, right click it in SSMS, script to modify, make the change, F5. Hope everything doesn't blow up. It's not ideal.
- gnu8 9y agoWhy wouldn't you do that in the dev database, then push to test, then push to prod?
- LandR 9y agoWe dont' have a dev / test / live database. All dev and testing is dont against the live database. YOu just have to be very, very, very careful. It's something we are trying to implement now, honestly. It's on the TODO list. The problem I'm having is where do you start? How do you simulate the data flowing through live in the test / dev enviornment.
- thehardsphere 9y agoHere's two ideas: 1. Set up replication, with your test db the replication slave of your production database, such that changes in production are mirrored in testing nearly instantly. 2. Take your production database backups (you do have those, right?) and restore them to the test database. This is less fresh than a replication setup but if you're just doing functional testing it should be enough to say "Well, okay, this little change isn't going to blow everything up."
- j_s 9y agoUpvotes for honest anecdata and asking for advice! > How do you simulate the data flowing through live in the test / dev enviornment. Most don't, rolling with the schema and 'minimum viable' data flow instead. Make darn sure your backups work by testing restores regularly. Restoring a production backup elsewhere may be an option if it's possible to avoid sensitive data (scrubbing afterward introduces risk of missing something, and should be scripted/repeatable). Exactly matching production data flow is not as important as avoiding accidentally hosing the prod db.
- davweb 9y agoIf you're doing manual updates to a production DB, using START TRANSACTION and then checking the outcome of your changes before you use COMMIT stops typos becoming catastrophes.
- neoeldex 9y agoThere's some caveats with this approach, since your DB has to keep track of the split state since you've started the transaction, it's quite a lot busier. So don't keep transactions open for any long stretches of time ;)
- j_s 9y agoIn case it's not obvious: new auto increment IDs are skipped forever whenever a transaction is rolled back. This isn't really an issue at all but can upset those with OCD-ish tendencies.
- corobo 9y agothose with OCD-ish tendencies best hope they never lose any customers then.
- btschaegg 9y agoThis. There's so much in software development that relies on guarantees that can only be upheld by behavior like this that I _sincerely_ doubt that anyone having issues with skipped rows is in the right place. There are arguments for and against any technique, but this one seems really ridiculous to me, especially if you consider what any "countermeasure" would do to the code (which is usually much more important than the data in the long run!).
- j_s 9y agoUPDATE tbl SET deleted=1
- deleted 9y ago[deleted]
- brians 9y agoSocial media networks claimed a number of users—falsely. Reporters created a couple accounts, got the true number, exposed the lies. Pwnage.
- lucideer 9y agoThat seems a fairly terrible reason to advise against serial keys. That they expose fragrant lies about metrics made by incompetent marketing departments? Sounds like a feature.
- chronial 9y agoI think "pwn3d" does but refer to a security issue in the article, but to social networks claiming to have millions of users and outsiders being able to proof that it's far less via user ids.
- belorn 9y agoI don't understand how that would be proof. Imagine that the social network does a rewrite, and rather than converting all the old accounts/data it just uses an additional flag to indicate which database to use. In that case a user id would not be globally unique for the website, but it would be unique for the specific database. This is actually more likely than it sounds. The company can hire a fresh new team to make an experimental new site, and if it's a hit, they can make some ugly hack to do calls to the old website using web APIs to get any old users from that system. This way the new team doesn't need to learn and figure out how the old system was built, which likely lacks any documentation and where the original developers has left the company. Without a full understanding of the layers of indirection it would be impossible to determine with certainty the number of users a social network has.
- EGreg 9y agoBasing user ids (as facebook did) on an autoincrementing number exposed when a user joined the site. Mark Zuckerberg is famously 4 and you can find a lot of famous silicon valley types in the first million user ids :)
- dkarl 9y agoWho has been "pwn3d" by exposing their user count? It's less about direct "pwn3ge" than about business intelligence. The number of users could be sensitive information for some businesses, but it's not just users. Any item where your volume is valuable proprietary information, you better make sure you aren't exposing an auto-incrementing id. Number of accounts, number of daily orders, number of distribution centers, number of product models, these might be data points that a growing business would prefer not to expose to their competitors via, for example, URL query parameters. You should make competitors work harder for their intelligence.
- Veratyr 9y ago> all it takes to know your user count is to create an account Also, this is only the case if your raw user IDs are visible. You only need a very basic encryption scheme to hide them. It can be as simple as taking two large prime numbers and sending (uid + x) % y to the user.
- beckler 9y agohere's an example of someone "pwn3d" by exposing their user count: https://www.troyhunt.com/kids-pass-just-reminded-us-how-hard-responsible-disclosure-is/ https://www.troyhunt.com/kids-pass-just-reminded-us-how-hard...