131–140 of 171 posts
That is an incredibly low friction interface to our documents. /s What are the odds they have access logs going back to 2003?
Pretty good, everything was probably set up and configured with default settings by that unpaid intern they had running their infrastructure back in 2003.
Yet another security vulnerability caused by: 1. Using sequentially incremented integer sequences as object IDs, and 2. Failing to protect sensitive data using some kind of authentication and authorization check. This is becoming a trend with data breaches. Several of Krebs' other reports on behalf of security researchers were originally identified by (trivially) walking across object IDs on public URLs. My cynical t…
I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…
And yes, Google also posted a sitemaps file (or rather, 50,000 sitemap files) with all profile IDs. But that was last marked updated in March 2017, for some reason. Being able to validate that would have been nice.
But as a mitigation against blind bulk scrapes, a useful tool. I'd consider that one of G+'s good design elements.
Earlier quoted context omitted.
That's what everyone (including myself) said after Equifax but just this week their credit rating was downgraded by Moody's: https://www.darkreading.com/attacks-breaches/moodys-downgrad...
Equifax should have been fined billions not just had a credit downgrade.
Still not enough.
Earlier quoted context omitted.
Is not the tech a part of the organizations way of doing business? These things are highly related to what’s going down in a thread [1] from yesterday (about “shitty projects”). I’m sure these guys spend many millions each year on security products, but either people in the know on the tech side is ignored, or they have no competencies left. In the thread I mention above I have actually posted about my general experi…
> In short, in the middle of the workflow, customers journals was written to CD and mailed to physicians. Encryption? Eh, no... Any process in place to ensure safe keeping and return/destruction? Uh, forget about it... That's a manually initiated transaction done internally and should be a red flag to anyone. Data outside of the organisation is data with no control. You could keep escalating this. That's an example o…
What I’m saying is that in spite of having, in a sense, all the resources at their disposal, this process was chosen by the business, for the business.
An encrypted on-line service could, and should, have been implemented. But being far from tech & dev the business choose a process matching their compentecies.
Messing with this several years in, and trying to digitize a process obviously in need for it, is met with much resistance.
Another gem of a process:
Many (like hundreds) employees needed personal printers. But why?!
Because:
- printing claim from “modern” client/server system.
- Pinning an also printed bar-code to the pages from step one
- scanning these in to software that reads the bar-code and adds them to queues for mainframe processing.
D/A -> A/D? Huh?!
Holy cow! I almost fell off my chair...
And the inherent security risks in play here, not to mention acres of forrest consumed during the years. My mind is boggling...
Am I actually living my working life inside a Dilbert strip?! It’s not even funny, because it’s true.
What I’m saying is that many large corps are anything but in fine tune with tech.
It’s gonna’ cost em’ in the long run.
Earlier quoted context omitted.
I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…
I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…
In this kind of system you can also generate deterministic UUIDs, which are useful for idempotency (e.g. The same event can be recognised as a duplicate)
Earlier quoted context omitted.
I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…
From https://littlemaninmyhead.wordpress.com/2015/11/22/cautionar... > Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. HN discussion: https://news.ycombinator.com/item?id=10631806
Earlier quoted context omitted.
That's not what people usually mean by "security by obscurity" when they critique the concept. Unfortunately the term is overloaded so it's lost its way over time. To illustrate this for you, let me turn it around a bit. Is it security by obscurity if the only thing stopping someone from logging into your account is knowing your password? Security by obscurity is when you (for example) roll your own cryptosystem and…
I think context matters here. If someone wants to hand out tokens, for instance via e-mail verification, I'm fine with relying on that being a UUID. When you make it harder (impossibly hard) to guess a "record number" by using UUIDs, which is what we were probably talking about, that's great too. (I already yielded that point.) But let's not lead the general population into thinking that UUIDs make everything safer (…
I can see your point. If UUIDs are handled in such a way that they are discoverable by anyone, they are not enough to make the references secure.
I think the point tptacek and others are making is that this is an instance of the defence in depths principle, though. In scenarios where UUIDs are not simply discoverable, using UUIDs is inherently more secure than using a monotonic ID, simply because the monotonic ID can be easily guessed. Yet, they are still not enough in isolation and you should be additionally using proper access control (due to eventual leakage of particular UUIDs in emails and such).
Earlier quoted context omitted.
> In short, in the middle of the workflow, customers journals was written to CD and mailed to physicians. Encryption? Eh, no... Any process in place to ensure safe keeping and return/destruction? Uh, forget about it... That's a manually initiated transaction done internally and should be a red flag to anyone. Data outside of the organisation is data with no control. You could keep escalating this. That's an example o…
Of course I was being ironic about it being ”finely tuned”! What I’m saying is that in spite of having, in a sense, all the resources at their disposal, this process was chosen by the business, for the business. An encrypted on-line service could, and should, have been implemented. But being far from tech & dev the business choose a process matching their compentecies. Messing with this several years in, and trying t…
I recently opened a new bank account in the UK and chose a 'challenger' bank. The process was secure, very smooth, the customer support very nice. They have no branches. This is regulationtech, not so much fintech, and challengers are coming from all sides, including in insurance. I wish these challengers well as being on the inside of incumbents I'm just left scratching my head "Why?".
Earlier quoted context omitted.
I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…
Sure, that's fine. The context of my point about IDs is for user-facing APIs. Note that user-facing really means "publicly accessible", even in the case of private APIs. As I mentioned elsewhere, market research groups will be happy to extrapolate as many metrics as they can from your APIs integer object IDs. That being said I'm a little surprised to hear about the complexity. Are you able to share which DB/stack you…
But it's not just the support that's such the problem. You're testing, you need to switch category, you can't just change a 1 to a 2. You have to go find what random uuid the categories had added to it. You can't just go into the DB and add a new line, you have to open a UUID generator. You can't just quickly add a foreign key relationship, you have to look up the UUID. And a ton of other little annoyances.
Actually, categories are an excellent example of something that shouldn't be a UUID, they're actually supposed to be discover-able.
I think my present project has UUIDs on the user, company, invoice and payments tables, but still ints as the primary key. Everything else isn't worth it. There's a merchant table, but again, they're all supposed to be discover-able (and aren't editable by the merchant themselves).
I also generally implement controller level security that checks access to the root object being returned by default, so I can't really make a mistake exposing an unauthorised object. There's an occasional controller where I've made a conscious decision not to implement that level, generally actions that allow both authenticated and unauthenticated users (e.g. viewing merchants or categories).
Earlier quoted context omitted.
I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…
> For instance, it's convenient to generate identifiers in a decentralized manner. For an elegant solution to this problem, check out Twitter's Snowflake[0]. [0] https://blog.twitter.com/engineering/en_us/a/2010/announcing...