I’m Nick, an information security consultant, a public speaker, a trainer, a sometimes software developer, and - most important of all - a dad and husband. Read more about me…
This blog is updated now and again with talks I’ve given, thoughts I’ve had, and things I hope others can learn from.
“What’s the difference between privacy and confidentiality??” It’s a question I’ll often ask when leading developer training, or when talking to potential job candidates. At first they seem very similar! Isn’t privacy just about keeping things private, and confidentiality about keeping things confidential? I like to draw a distinction that goes like this:
Confidentiality is about any piece of information, and restricting its access to only those who have a valid need. It could be personal information, or business plans, or code. It could be open to everyone, restricted to a set of people, or just one person.
Privacy is about information on individuals, and is defined in Aotearoa by the Privacy Act. It’s about collecting as little as you need, storing it securely and for only as long as needed, and only using it for what you said you’d use it for.
This post was first published on aurainfosec.com, written by Sally Vernon and Nick Malcolm. It has been slightly modified to fit this blog.
Developers creating software and applications for today’s businesses have a wide range of things to consider – from responsive design and accessibility, through to security. Add in cost and time constraints, and it’s easy to see why sometimes security can be overlooked or outright ignored until the end of the project.
It can be hard to prioritise security when everything seems to be working fine and the business wants you to be delivering flash new features. But any organisation is vulnerable to a breach, large or small, public or private – and the risk is not just related to the work of malicious attackers either! We can inadvertently make mistakes which cause security incidents.
That’s why developers need to think about security early on, and throughout the project.
I’ve just come back from OWASP NZ Day 2020, held at Auckland University this February. As well as seeing some excellent presentations I was also able to present a talk on how developers can store their users’ passwords safely.
Every time a website gets breached you hope to hear “your password was salted and hashed” instead of “your passwords were stored in plain text” - but what does that actually mean, and why is it a good thing?
Wash your hands, don your apron, and join me for as we follow the recipe for storing passwords safely. We’ll learn a bit about cryptography and one-way functions (that’s the hash!), how to source good ingredients (bcrypt, scrypt, argon, oh my!), why adding a pinch of salt helps, how many times must we stir the mix, and what happens if we miss a step? In the face of an attacker, will our delicious password loaf rise to the occasion, or will it fall flat in disappointment and despair?!
You can flick through the slides here: https://www.slideshare.net/NickMalcolm/a-recipe-for-password-storage-add-salt-to-taste
I’ll update this post once the MP3 recording, and links to other great talks from the conference, become available.
Showing the latest 3 posts. Read older posts…