4 ms·
That kind of demand requires a simple mindset: make doing the right thing easier than not. I was impressed, when working for mature software companies, how the
by bertil 8y ago
That kind of demand requires a simple mindset: make doing the right thing easier than not. I was impressed, when working for mature software companies, how the teams providing internal tools that were easily overlooked (security, data logging, experimentation framework) managed to lead by having the best option easily accessible.
You don’t want people to write passwords in your codebase? Make getting the password as an environment variable easier to find; document where they are, how to refresh them; better: change them often and have the system that changes them support the use case better than a human with an easy to compromise post-it.
You don’t want people to store personally-identifiable information? Make all the relevant information associated with an irreversible hash; have all the business logic that process logs into something legible matching that hash. Soon, no one will use the `user_id` that is also used in the public profile URL.
It’s significant amount of initial work but that beats repeating basic things for every new joiner, by a mile.
- thaumasiotes 8y ago> You don’t want people to store personally-identifiable information? Make all the relevant information associated with an irreversible hash; have all the business logic that process logs into something legible matching that hash. Soon, no one will use the `user_id` that is also used in the public profile URL. I don't understand this. The user_id in the URL is not itself meaningful. If you know that my user_id in Slack is 642819733, that information is neither personally identifiable nor useful in any way. But if you exfiltrate a bunch of data from Slack and learn user 642819733's birthday and billing address, then you've probably managed to identify me. You've done it even if you didn't know beforehand that there _was_ a user_id 642819733. The problem wasn't that 642819733 was a sensitive value; the problem was that it was the same value in all of Slack's records. Which your solution doesn't address.
- deleted 8y ago[deleted]
- throwawaymath 8y agoThis is a little tangential to your point, but per your example: it's generally inadvisable to track objects (including users) with incrementing integer sequences.
- bertil 8y agoThe case that I have in mind assumes that you are an analyst who should know better, and was asked about… say, retention. You need a personal identifier in that table to match successive purchase by the same individual. You can easily get your friend’s `user_id` because, well they share it on-line. If it is easy for me to take that 642819733 and find how much you spend, I can confront you and claim you are registered to more Slack channel than you have told me about. So it’s less “exfiltration” and more: some junior people are commonly given detailed data, for legitimate reasons, and you should make it hard for them to abuse it. There are plenty of cases that I’ve been directly involved with where I was uncomfortable, but not sure I want to share them. I’ll just say this: Facebook analysts typically can type their own ID off the top of their head, and most know the ID of their close co-workers. I’ve never seen anything bad, but doing something bad felt a little too easy at times — and that _ease_ was a big deal.
- baby 8y agoI've heard about doing things on the other end of the spectrum as well: make insecure things harder to do. You want to look at this cookie? Well you'll have to go through some layer of encryption.