Earlier quoted context omitted.
But UUIDs do, in fact, make things safer.
On average: yes. Always: no.
Always no? What's a situation in which you'd be better off with monotonic ids?
First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
91–100 of 171 posts
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#92Earlier quoted context omitted.
Is MSSQL's NEWSEQUENTIALID secure? I didn't think it was.
Is the point of non mono tonic is schemes to make them -secure- secure? I thought they were a bit of a hack to raise the bar a touch. In which case the crypto security properties of that function isn’t interesting. Instead the ergonomics are.
No, the cryptographic security of the identifier matters a lot. A GUID generated from an insecure PRNG can be used to predict other GUIDs. A UUID generated from 16 bytes of /dev/urandom can't be used to get anything but the object to which it refers.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#93At some point people will realise that holding large quantities of sensitive information is a liability, not an asset. Mindsets are slowly changing in this direction already. The chickens will continue to come home to roost until people treat digital security as seriously as physical security.
> The chickens will continue to come home to roost until people treat digital security as seriously as physical security Do people take physical security seriously? It doesn't seem like it. Anyway, when I was an undergrad in the 1990s and took a computer security class our professor (Gene Spafford) talked about security being primarily an economic question. And that is generally how security, both physical and digita…
Very few people take workplace physical security seriously outside of a few industries like prisons. Complete strangers have physically unlocked and opened the door for me to enter "secured" areas because they assumed that since I was walking in that direction I must be authorized to enter.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#94>At First American, security, privacy and confidentiality are of the highest priority and we are committed to protecting our customers’ information. is such a meme. Things will continue this way until there are serious repercussions for entities carelessly handling data.
The next sentence too: > We are currently evaluating what effect, if any, this had on the security of customer information. It's downright dishonest to even say "if any": they were presented with concrete examples of leaking customer information; they don't get to wonder whether it had an effect on their security anymore.
Yeah, considering that they have sent these URLs to at least tens of thousands of people, it would be hard to believe that nobody ever inappropriately accessed a document that didn't belong to them.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#95At some point people will realise that holding large quantities of sensitive information is a liability, not an asset. Mindsets are slowly changing in this direction already. The chickens will continue to come home to roost until people treat digital security as seriously as physical security.
One must hold large quantities of sensitive data forever to operate in the title insurance and settlement services business.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#96Earlier 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…
Note most databases use type 1 UUIDs by default, not randomly generated type 4 UUIDs. There are tons of security holes out there because people are using type 1 UUIDs thinking they can be used as secure tokens.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#97Earlier 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…
I don't think it's really fair to call it security by obscurity. The UUIDs have far more entropy than 99.9% of user passwords protecting them.
Not if they are type 1 UUIDs, which is the default on MySQL.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#98I did a penetration test for $NATIONALINSURER and they had an FTP site with weak credentials where all the remote offices uploaded claims. Millions of records and scans of SSNs, home addresses, bank information, etc. Their mitigating controls were: we put it behind a firewall. Then again I didn't expect much, their MSSQL in prod had SA/SA credentials active.
I'm currently fighting against management dragging their feet on using 2FA. On HIPAA PHI. (I know HIPAA doesn't actually mandate 2FA, but it's recommended by many best practices and guides.) Apparently some tech folks don't like the inconvenience of 2FA.
[deleted]
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#99Earlier quoted context omitted.
If you know the (integer) identifier, and because the bad application isn't secured with authentication, you get access to something you're not supposed to. If you make the identifier a lot harder to know, and you still have no security, that smells like the obscurity part. I can absolutely see your point that the UUID identifiers are not just a lot harder to guess, they may be impossible to guess. But the security i…
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…
Yeah, I think the understandable confusion comes from the idea that a UUID "obscures" the sequential identity of the id in the same way a password mask obscures a password, but the obscurity in security through obscurity refers to reliance on an attacker's ignorance of implementation details to secure the system rather than on a mechanism that is provably secure.
Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records
#100Earlier quoted context omitted.
You can generate uuids that play nicer with database storage / indexing. NEWSEQUENTIALID() in MSSQL, for example. The keys will be easier to guess again, but if all you have to do is guess a primary key to get access to the underlying data, something else isn't right anyways.
I think this gets to the crux of the issue. It's not about using hard-to-guess UUIDs[0], but restricting access to the underlying data[1]. [0] https://en.m.wikipedia.org/wiki/Security_through_obscurity [1] https://en.m.wikipedia.org/wiki/Access_control
It's not really security through obscurity. In these case I understand the ids where related to data that the company was making available to users through email links. A cryptographically secure 128bit UUID is impossible to guess, no more than a cryptographic access token. Now of course, you would probably rather want to have an authentication scheme on top of that, but that comes at a support cost in term of customers loosing their passwords, locking themselves out of their account, etc. And it is not clear you have increased security as people re-use passwords.
Then of course there is the issue that email is for the most part un-encrypted (or encrypted without validating certificates).