I think this is a topic of great importance but mostly ignored by this forum, in comparison with a flood of purely technical, minuscule, very detailed, RW-centric issues.
When any new set of rules, like GDPR, comes to life, many (if not most) web developers get pissed, because they see them as a set of complications (if not blockades) on their path.
I say, security is not that complicated, if treated not as something to comply with, but rather something to strive for. Make it an inseparable part of website development – at an early stage. Complicated is cleaning up the mess after a security breach which shouldn’t happen in the first place. So, start with getting a SSL certificate for your website (free) from Let’s Encrypt (many hosting companies provide that as part of their service). I suppose, this is obvious for all of us. What’s less obvious is the fact that getting a SSL certificate is just the first step towards making our sites safe and secure.
In addition to that, I’d suggest for everyone to subscribe to security news feeds, like Naked Security and/or Krebs On Security. These are recommended not only for web developers but for every person that ever uses Internet. Here are some links for RSS feeds:
And how to take advantage of these security news feeds? If you are not using a RSS-reader yet, I recommend to download and install one. My favored one is Net News Wire (requires macOS 10.14.4 or newer). Here’s a review of that reader on CSS-Tricks.
P.S. There is also a “Privacy Framework” guide issued by the US government’s NIST (National Institute of Standards and Technology) agency. This Framework is purely instructional and voluntary to follow.
The article describing the NIST Privacy Framework can be found here:
I think, perhaps, it would be good to separate the links/info about security from the links/info about privacy.
Even though they’re not the same at all, they are related. Security is often used to keep things private.
Privacy
GDPR is privacy: specifically about the rights you have to control how your private information is collected, stored, transmitted, and – most importantly – how it’s shared. GDPR contains security standards too – but only as they relate to securing your private information.
Security
SSH, SFTP, and https are secure network protocols. These protocols encrypt communication for privacy, but do more too. They also use certificates and digital signatures to ensure you communicate with whom you intend to communicate and only with them.
SSL (a.k.a. TLS) is the underlying protocol that all three of the above use for security.
Let’s Encrypt is an organization that provides free SSL certificates.
Don’t cross the streams
Because security tech, like encryption, is used to protect our private information, people often swap one for the other, muddle them together, or just treat them as the same thing.
Personally I find tackling one at time makes understanding a bit more manageable. Both together is biting off more than my brain can chew Holy mixed metaphors Batmann!
And I’m not talking about our https website or online store with SSL. No, this is an API that stack developers can use to secure the updates to their stacks AND a separate API that lets developers hide their proprietary private information.
Stack Code Privacy
A number of Stack developers came to me a few years ago worried that their hard work was being copied by other unscrupulous developers.
To discourage copying Stacks uses simple public key encryption. The Stacks public key is included in the API. Developers encrypt their stacks using this key. Since only Stacks has access to the private key, only Stacks can decrypt them.
A very negative way to look at this is that it keeps nosey folks from peeking where they probably shouldn’t.
More realistically, the suspicions and anxieties between developers can make it hard to be friends with other developers. It was really hurting our developer community.
Adding a layer of encryption lets developers stop worrying about each other so much.
Stacks Update Security
Stack developers and users need to be sure that updates are handled securely – this comes in three parts
Private Key Signature
Stacks digitally signs all update requests using the Stacks private key. Developers can verify the request on their update server using the Stacks public key.
developers can be sure requests come only from Stacks.
developers can be sure the request hasn’t been modified in any way.
Public Key Signature
Stacks also signs update requests with the public key in the stack. Developers can use their own private key to verify the signature.
when combined with stack encryption, developers can be sure requests come only from those who already have one of their stacks.
Signed Response
If Stacks sent a public key signature (#2) , then it will only accept a response that is also signed. The signed response is verified with the same public key from (#2).
Stacks can be certain that a stack with a public key signature is only updated with the developer that created the stack.
Why Not Use SSL?
You might wonder why Stacks doesn’t simply use SSL like the web?
Well, of course, we do use SSL too, if the developer’s update server has SSL.
But SSL is not a panacea. SSL ensures that no one else can see the info as passes through the internet. And it also ensures that if Stacks contacts https://elixirgraphics.com that they’re not talking to someone else masquerading as Elixir Graphics, or some hacker using the same WiFi at Starbucks. SSL is good for those things.
And that’s all a good start – but it doesn’t solve many of the other challenges of keeping a stack update safe. Adding our security and privacy layers on top of SSL gives us:
Privacy:
devs know their proprietary info is hidden
Security:
devs know that the update request came directly from Stacks
devs know that the update request came from one of their own stacks
Stacks knows that the update response came from the right developer
Want to learn more
If you’re a developer and you would like to learn how to keep your stack private or secure your updates, you can read more about it on the secure stack api pages on GitHub. There is a walkthrough of the entire API, simple command line scripts for generating public/private keys, example Php to use on your update server to sign and verify updates, and quite a bit more.
If you have questions, feel free to stop by the Slack group and chat.
Holy mixed metaphors Batmann!