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

Former employees say Lyft staffers spied on passengers

techcrunch.com

Post reply on HN
Print view View original

121–130 of 253 posts

Re: Former employees say Lyft staffers spied on passengers

#121

Post by dpweb »

mpolichette wrote: post #5

When I did an internship at a national lab, a lot of the hard rules about security relied on the fact that you had gone though their hiring process and would follow the rules. There were different access levels, for sure, but only like 2 or 3. You might have "had access" but you shouldn't be anywhere you didn't have a good reason for being. Lyft should be checking on this, running audits and whatnot, but they also sh…

Better to not expect anything from anyone, and you wont be disappointed.

What you do is simply restrict data to employees on a need to know basis. Not difficult to do.

Re: Former employees say Lyft staffers spied on passengers

#122

Post by ryan_j_naughton »

Having seen this at too many companies, we at fair.com decided to adopt stronger policies to prevent this, viz:

- all inbound API requests first go to our API proxy in the secure layer.

- the API proxy encrypts all PII using the encryption service in the secure layer

- then API proxy sends the request on to the appropriate service, having swapped all PII for tokens.

- all services in the general layer are not able to talk to the encryption service to decrypt data.

- thus all data that would normally be considered very sensitive (e.g. credit reports) can be stored or passed around the services because values like SSN and others are tokenized.

- our services with UI's like our CRM, wherein the customer service rep needs so see the data unencrypted, works perfectly bc the response from the API proxy outbound decrypts the data, but selectively so based on the person's permissions through our abstracted auth layer.

Thus in the Lyft example, the majority of employees could have access to "God view" but with all the PII encrypted (so they couldn't search their friend's account by email, for example) but they can still look at rides and transactions, while just those who need to see the decrypted PII could be given those permissions.

Of course, this assumes that the encrypted PII is sufficient for anonymization. If you can look for all rides within a block of an address in their God view, then you could quickly figure out which person was your friend by narrowing down to rides originating from his house and his work. But again that comes down to properly limiting certain search capabilities in the UI.

I don't get why more companies don't follow our approach. I've seen way too much personally sensitive data in plaintext in databases over the years.

Re: Former employees say Lyft staffers spied on passengers

#123

Post by jjeaff »

ryan_j_naughton wrote: post #122

Having seen this at too many companies, we at fair.com decided to adopt stronger policies to prevent this, viz: - all inbound API requests first go to our API proxy in the secure layer. - the API proxy encrypts all PII using the encryption service in the secure layer - then API proxy sends the request on to the appropriate service, having swapped all PII for tokens. - all services in the general layer are not able to…

While I like that, and is a cool approach, what is really the difference between just storing PII encrypted in the same database and then keeping your keys locked down based on permission levels?

The API proxy would be great if you have a trusted 3rd party in charge of it or something. But abstracting it out to a separate layer doesn't seem necessary since it's all within the same company anyway, and developers will need access anyway

Re: Former employees say Lyft staffers spied on passengers

#125

Post by aiiane »

rtpg wrote: post #116
lobo_tuerto wrote: post #109

Earlier quoted context omitted.

"Just because you have access to something doesn't mean you're allowed to touch it without a valid business reason." Then you should not have access to it? People will touch them if they can. That's why Access Control rules exist.

There's a bit of pragmatism involved in the level of control. If you add too much friction to the process of accessing information, then it can actually impede on actually handling user support. For example, having access to someone's ride history when trying to resolve a dispute seems relatively normal. Of course in Lyfts case it seems pretty clear that there can be more programatic locks. And auditable logs are abl…

That last bit is actually relatively straightforward - you send them a response with a link they click on taking them to a permission prompt.

Re: Former employees say Lyft staffers spied on passengers

#126

Post by erulabs »

I can't even imagine how much PII is sitting in AWS Redshift from various startups... It's brutally slow if you don't tune the encoding types _extremely carefully_, which no one ever does. One has to wonder, if this is such a big deal, what the access rights from AWS' perspective looks like xD

Imagine the data team convincing the rest of the company that they're doing anything to make their redshift _slower_. Encryption? People want their graphs, damnit!

Re: Former employees say Lyft staffers spied on passengers

#127

Post by chipperyman573 »

walshemj wrote: post #51
x0x0 wrote: post #46

Earlier quoted context omitted.

> Basically, I think its reasonable to both allow many people access and expect them to not abuse it. I couldn't disagree more. Eventually, you're going to hire an idiot (and/or budding rapist). When you have PII of this nature, if you're going to allow lots of people access, you need individual access controls, logging, and most importantly, auditing of the aforementioned data. And auditing may not be enough; you pr…

I remember a briefing when I worked for BT in the UK some one looked up for a mate his exes new address - who then got murdered. There was also the case involving hit men who found the address of a targets mom and dad who where also killed by bribing some one. BT took security v seriously and you had better hope if you did something bad that the cops or the even the secret service (MI5) got to you before the internal…

>BT took security v seriously and you had better hope if you did something bad that the cops or the even the secret service (MI5) got to you before the internal security team did.

I would rather be "dealt with" by BT than with the cops or secret service. BT can fire you, the cops and SS can take away your rights (with due process)

Re: Former employees say Lyft staffers spied on passengers

#128

Post by brisance »

jjeaff wrote: post #123
ryan_j_naughton wrote: post #122

Having seen this at too many companies, we at fair.com decided to adopt stronger policies to prevent this, viz: - all inbound API requests first go to our API proxy in the secure layer. - the API proxy encrypts all PII using the encryption service in the secure layer - then API proxy sends the request on to the appropriate service, having swapped all PII for tokens. - all services in the general layer are not able to…

While I like that, and is a cool approach, what is really the difference between just storing PII encrypted in the same database and then keeping your keys locked down based on permission levels? The API proxy would be great if you have a trusted 3rd party in charge of it or something. But abstracting it out to a separate layer doesn't seem necessary since it's all within the same company anyway, and developers will…

Probably due to granularity of permissions, key revocation etc reasons. Parent's method is analogous to a high school hall pass to access the restrooms; your proposal is to tell the janitor a "secret" password.

Re: Former employees say Lyft staffers spied on passengers

#129

Post by Consultant32452 »

mikeash wrote: post #66
Consultant32452 wrote: post #35

Earlier quoted context omitted.

Well, back in the old days if we wanted to complain we'd write it down on a piece of paper, wrap that piece of paper inside another piece of paper, and then put that in an unlocked box out in our yard. That's similarly how we'd order products, out of magazines. Only in that case on the paper we'd include things like our bank account information that we'd put in the unlocked box in our yard. I'm not suggesting that th…

I generally agree with you, but I think it should be pointed out that unauthorized access to that unlocked box carries severe punishment. A big part of the problem with things like this is that not only are there no controls preventing access to private info, but there are also few if any consequences.

How much control do you think there was in the businesses that got those wrapped pieces of paper with your banking account information? Sure, there are penalties while it's in the box in your yard, but not really once it was at its destination. I bet it's much more strict today than it was a few decades ago.

Re: Former employees say Lyft staffers spied on passengers

#130

Post by ryan_j_naughton »

jjeaff wrote: post #123
ryan_j_naughton wrote: post #122

Having seen this at too many companies, we at fair.com decided to adopt stronger policies to prevent this, viz: - all inbound API requests first go to our API proxy in the secure layer. - the API proxy encrypts all PII using the encryption service in the secure layer - then API proxy sends the request on to the appropriate service, having swapped all PII for tokens. - all services in the general layer are not able to…

While I like that, and is a cool approach, what is really the difference between just storing PII encrypted in the same database and then keeping your keys locked down based on permission levels? The API proxy would be great if you have a trusted 3rd party in charge of it or something. But abstracting it out to a separate layer doesn't seem necessary since it's all within the same company anyway, and developers will…

There is a big difference.

- Logs: we can log all params within the general layer without worrying about leaking PII to the logs

- Monitoring Network traffic. If I need to use wireshark or something similar in the general layer, all the data there is already encrypted/tokenized so it is safe to do so.

- If you let each service encrypt the data itself, then all of those services are in scope from a security perspective. Access to those services from engineering's perspective would have to be considerably more locked down, potentially preventing engineers from access to their ENV variables, memory dumps, sshing into those boxes/containers, etc, for fear you could get the encryption keys (of course while many of those things should be locked down anyway).

- Further, having each service do the encryption itself means you are duplicating that solution over and over again and introducing more opportunities for error. Having a single encryption service within the secure layer allows us to change our approach more cleaning than it being spread out everywhere.

And the list goes on and on...

Post reply on HN