Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

krebsonsecurity.com

Post reply on HN
Print view View original

81–90 of 171 posts

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#81

Post by sverhagen »

throwawaymath wrote: post #77
sverhagen wrote: post #70

Earlier 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…

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 (probably not what you were saying), because if something is "just an identifier" it may not be handled as safely, which is what this seems to be relying on in the context of security. Same as how user names were traditionally not handled as something secret or confidential. Sometimes UUIDs appear as just identifiers and are not handled with any secrecy, so they just can't always double as a security feature.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#82

Post by tptacek »

sverhagen wrote: post #81
throwawaymath wrote: post #77

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 (…

But UUIDs do, in fact, make things safer.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#83

Post by asaph »

sverhagen wrote: post #58
mattmanser wrote: post #44

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…

> 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...

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#84

Post by OrgNet »

angry_octet wrote: post #67

Whenever you are compelled to upload/send a photocopy of an ID document it is sensible to write the date and purpose / file reference on it. If it appears in a document dump at some later date you know the path and date of the leak.

that is a good idea but most of the time I need to hand over my actual ID, and not just a scan of it

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#85

Post by sverhagen »

tptacek wrote: post #82
sverhagen wrote: post #81

Earlier quoted context omitted.

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 (…

But UUIDs do, in fact, make things safer.

On average: yes. Always: no.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#86

Post by bouncycastle »

throwawaymath wrote: post #60
scarface74 wrote: post #49

Earlier quoted context omitted.

There is nothing wrong with using sequential ids in and of themselves. The typical web app has the concept of a validated user session per request. How hard is it really to Select ... From Documents where documentid = ? and userid = ? So even if the user does a GET /Document/{id+1} No documents would be returned. Every web framework that I am aware of let’s you add one piece of middleware that validates a user sessio…

No, nothing wrong with it intrinsically. But if UUIDs were used instead, the lack of authentication or authorization checks wouldn't be as catastrophic. That would be somewhat comparable to having a reset password token which doesn't expire. Still bad, but not as bad. The other commenter's point about leaking information is also correct. In the finance industry one of the basic tricks to obtaining alternative data is…

Nice. This reminds me of the German Tank problem in WWII, where the allies used samples of serial numbers from captured nazi tanks, to estimate their population. The tanks and their parts used sequential serial numbers. It could also be used to determine production rates too I guess.

The idea pre-dates web APIs many decades :-)

See https://en.m.wikipedia.org/wiki/German_tank_problem

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#87

Post by gesman »

"First American has learned of a design defect in an application that made possible unauthorized access to customer data. At First American, security, privacy and confidentiality are of the highest priority and we are committed to protecting our customers’ information..."

Who is coming up with these statements?

If you kept royally screwing something for years that you claimed to be your "highest priority" - then what can one expect from your normal lines of business?

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#88

Post by kasey_junk »

tptacek wrote: post #64
dvlsg wrote: post #48

Earlier 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.

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.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#89

Post by scarface74 »

pointytrees wrote: post #80
scarface74 wrote: post #59

Earlier quoted context omitted.

In that simple scenario. What are some ways that a hacker could break your front end API to allow it to serve requests for multiple users without having access to multiple account logins? I understand that they could possibly get access to your database but that’s a different threat. If they could somehow change your code, all hope is already lost. But I do agree with it does allow someone to determine rate of growth…

In my experience, many tables don't have a userid on the table that would be associated with the user. It would be a table join or two or three away. So the developer may think it is safe to say select value from stock positions left join account on account.id = stock position.id left join user_accounts on user_accounts.accountid == account.id left join users on user_accounts.userid == user.id where user.id == sessio…

If the cookie is spoofed and someone got another clients authorization token, then they would get any documents that user was authorized to see anyway.

But you don’t do cookie.userid.

You send the username and password to an authentication service which generates a token with a checksum. The token along with the username and permission is cached in something like Redis.

On each request, middleware gets the user information back using the token.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#90

Post by astura »

bloopernova wrote: post #41
client4 wrote: post #12

I 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.

DoD contractors are now required to have 2FA.

https://duo.com/blog/federal-contractors-must-meet-cybersecu...

Post reply on HN