4 ms·

No it doesn't. It just requires a shift in your thinking. Having a database is a code smell. If you absolutely have to have a database, then having a `users`

by vec 9y ago

No it doesn't. It just requires a shift in your thinking. Having a database is a code smell. If you absolutely have to have a database, then having a `users` table (or equivalent) is a code smell. If you absolutely have to have a `users` table, having any columns in it other than `id`, `username`, and `password_hash` is a code smell. ...and so on. Admittedly this isn't necessarily easy in a company setting. It's in direct conflict with what the sales & marketing people want, and unfortunately that means your job is sometimes to fight with the sales & marketing team. But it's not complicated.

dsacco 9y ago
Speaking as someone who has worked in security with many different companies: I don’t think your bar is reasonable (or intrinsically desirable).
- vec 9y ago
  It's not actually a reasonable goal. Almost all pieces of software will need some nontrivial amount of data to fulfill their purpose. I am convinced, however, that it is a very useful heuristic. The platonic ideal of a perfectly secure database is a completely empty one. Every step away from that requires individual justification. That doesn't mean your database will be small, but it should mean the database is as small as possible. I treat permanently storing user data (any data, for any reason) as my solution of last resort. That doesn't mean I don't use it. It just means I have to convince myself I don't have any better ideas before I do.
  - danenania 9y ago
    So where do you store this data then? Or do you just live with forgetting everything about a user (their name, details, history) every time they switch devices?
    - vec 9y ago
      First I try really hard to not need it. e.g. I'm "vec" on HN. They don't know my real name, my physical address, or my Twitter handle. Any features that did need that data are simply not going to be implemented, and the site is designed accordingly. Next, I don't store what I cam fetch or derive. Say I'm using GitHub as an oauth provider. I don't need to store an email, an avatar, or a password hash. I can use GitHub's data. All I have to store is an opaque oauth ID. Finally, if I do really need it and I can't get it from anywhere else then I'll happily store it. I just won't do it first, and I often won't do it until I've had a talk with the designers about what's possible with the data we already have.
yjftsjthsd-h 9y ago
I work in a SAAS company whose product is used by businesses to exchange data and run reports, which are emailed. What exactly should we cut without destroying the utility of our work?
- vec 9y ago
  Without knowing anything about your software: * Build your software to stream data directly from Client A's API to Client B's API without it ever being at rest on a machine you control. * If your users want reports based off their data, then see if you can fetch the relevant data from the client on demand, build the report email in memory, then forget the raw data. * Tell your clients you prefer to use their oauth provider of choice to authorize instead of storing usernames and password hashes yourself. * Key your access logs off of an (arbitrary and short lived) session id instead of a user id. Maybe none of that's appropriate for your use case. Maybe your company already stores the minimum viable dataset for its needs, and maybe that minimum viable dataset is still huge. But the fact remains that you can't leak what you don't have, and even marginal differences can still make the data you do hold a little less valuable to thieves and a little harder to deanonymize and collate with other leaks. I use the term "code smell" in the same sense sense as "`if` statements are a code smell". It doesn't mean never to use them, it just means that solutions that don't use them tend to be consistently better than solutions that do. Solutions that store less (or no) data tend to be consistently more secure than solutions that do store more data. That doesn't mean those solutions always exist, just that one should prefer them when they do.

by vec 9y ago

dsacco 9y ago

Speaking as someone who has worked in security with many different companies: I don’t think your bar is reasonable (or intrinsically desirable).

vec 9y ago
It's not actually a reasonable goal. Almost all pieces of software will need some nontrivial amount of data to fulfill their purpose. I am convinced, however, that it is a very useful heuristic. The platonic ideal of a perfectly secure database is a completely empty one. Every step away from that requires individual justification. That doesn't mean your database will be small, but it should mean the database is as small as possible. I treat permanently storing user data (any data, for any reason) as my solution of last resort. That doesn't mean I don't use it. It just means I have to convince myself I don't have any better ideas before I do.
- danenania 9y ago
  So where do you store this data then? Or do you just live with forgetting everything about a user (their name, details, history) every time they switch devices?
  - vec 9y ago
    First I try really hard to not need it. e.g. I'm "vec" on HN. They don't know my real name, my physical address, or my Twitter handle. Any features that did need that data are simply not going to be implemented, and the site is designed accordingly. Next, I don't store what I cam fetch or derive. Say I'm using GitHub as an oauth provider. I don't need to store an email, an avatar, or a password hash. I can use GitHub's data. All I have to store is an opaque oauth ID. Finally, if I do really need it and I can't get it from anywhere else then I'll happily store it. I just won't do it first, and I often won't do it until I've had a talk with the designers about what's possible with the data we already have.

yjftsjthsd-h 9y ago

I work in a SAAS company whose product is used by businesses to exchange data and run reports, which are emailed. What exactly should we cut without destroying the utility of our work?

vec 9y ago
Without knowing anything about your software: * Build your software to stream data directly from Client A's API to Client B's API without it ever being at rest on a machine you control. * If your users want reports based off their data, then see if you can fetch the relevant data from the client on demand, build the report email in memory, then forget the raw data. * Tell your clients you prefer to use their oauth provider of choice to authorize instead of storing usernames and password hashes yourself. * Key your access logs off of an (arbitrary and short lived) session id instead of a user id. Maybe none of that's appropriate for your use case. Maybe your company already stores the minimum viable dataset for its needs, and maybe that minimum viable dataset is still huge. But the fact remains that you can't leak what you don't have, and even marginal differences can still make the data you do hold a little less valuable to thieves and a little harder to deanonymize and collate with other leaks. I use the term "code smell" in the same sense sense as "`if` statements are a code smell". It doesn't mean never to use them, it just means that solutions that don't use them tend to be consistently better than solutions that do. Solutions that store less (or no) data tend to be consistently more secure than solutions that do store more data. That doesn't mean those solutions always exist, just that one should prefer them when they do.