this post was submitted on 16 Feb 2024
87 points (98.9% liked)

Programming

17579 readers
137 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 37 points 9 months ago (8 children)

I worked for the state once and the number of times I had to put my foot down for security was appalling. We're talking like getting web services updated to use basic password auth could take months and I'd be pressured by management to ignore it because some asshat using the service doesn't want to update their 30 year old batch file to deal with auth. Other people would regularly push things that could easily expose thousands of people's identifying info just to get management off their backs. A couple projects I think I was specifically kept away from because they were "mission critical" and they didn't want me slowing it down with trivial stuff like not leaking unencrypted databases...

[–] jadero 7 points 9 months ago* (last edited 9 months ago) (6 children)

That is something I just don't get. I'm a hobbyist turned pro turned hobbyist. The only people who I ever offered my services to were either after one of my very narrow specialties where I was actually an expert or literally could not afford a "real" programmer.

I never found proper security to have any impact on my productivity. Even going back to my peak years in the first decade of this century, there was so much easily accessible information, so many good tutorials, and so many good products that even my prototypes incorporated the basics:

  • Encrypt the data at rest
  • Encrypt the data in transit
  • No shared accounts at any level of access
  • Full logging of access and activity.
  • Before rollout, back up and recovery procedures had to be demonstrated effective and fully documented.

Edited to add:

It's like safety in the workplace. If it's always an add-on, it will always be of limited effectiveness and reduce productivity. If it's built in to the process from the ground up, it's extremely effective and those doing things unsafely will be the productivity drain.

[–] CodeMonkey 7 points 9 months ago (1 children)
  • Encrypt the data at rest
  • Encrypt the data in transit

Did you remember to plan for a zero downtime encryption key rotation?

  • No shared accounts at any level of access

Did you know when account passwords expire? Have you thought about password rotation?

  • Full logging of access and activity.

That sounds like a good practice until you have 20 (or even 2000) backend server requests per end user operation.

All of those are taken from my experience.

Security is like an invasive medical procedure: it is very painful in the short term but prevents dire complications in the long term.

[–] jadero 1 points 9 months ago

All excellent points. I never worked at those scales or under those conditions, neither should I have been permitted to. And I had enough self-awareness to keep myself away from anything like that.

I guess when I read about this breach or that, the real damage seems to be a result of not having the basics covered. Whatever "basic" might mean for different scales of operation, encrypted at rest seems to be the the basis of public harm through theft of data, and it strikes me that if that can't be managed at a particular scale, then operating at that scale should not be considered.

load more comments (4 replies)
load more comments (5 replies)