Nick Malcolm
Blog
Misuse & Abuse Cases
Most who have worked in an Agile team will be familiar with user stories and use cases. “As a millenial in their 30s, I want access to 90s cartoons, so I can bask in nostalgia”. Many teams go further and identify ways a system can be misused or “hacked”, and worked to prevent those to make the system secure. But not enough get past misuse cases, and work to keep people safe.
In this post - by way of examples - I want to talk about “abuse cases”, as distinct from misuse cases. In short: misuse cases are how users might unintentionally or intentionally misuse the features of your product. Abuse cases are how humans might abuse other humans with your product. The features are technically working as intended, but are facilitating abuse.
Written 5 November 2020
Speaking @ Christchurch Hackers Conference 2020
At CHCon 2020 I reprised an improved version of my talk titled: “A Recipe for Password Storage: Add Salt to Taste”. This time, there’s a video available from the live stream (starts at 2h09m19s):
Written 30 October 2020
Privacy vs. Confidentiality
“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.
Written 24 October 2020
"Secure by Design" – Weaving security into the development process
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.
Written 20 August 2020
OWASP 2020
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.
A Recipe for Password Storage: Add Salt to Taste
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.
Written 28 February 2020
Three easy steps for securing your next project
This post was first published on aurainfosec.com.
Technology managers and business owners understand that they are kaitiaki, or guardians, of their organisation and customer data and that they must take steps to safeguard it. This responsibility is heightened during projects which change the way we interact with or store data – whether it’s creating a new website on AWS, lifting-and-shifting a legacy application to Azure, or switching from on-premise office to Office365. There is a perception that security is hard or requires expertise, so it’s easier to ignore it until the end of the project, but this line of thinking is letting the perfect be the enemy of the good. There can be a middle ground!
There are three straightforward teams can take to deliver a secure solution that your customers can trust. First, think about what could go wrong; second, leverage the tools, frameworks, and knowledge which already exists; and third, verify before go-live.
Written 20 January 2020
OWASP Top 5 - The top 5 most useful OWASP resources
What actually is OWASP?
For many development teams, OWASP is the go-to resource when starting to think about security. Usually we look at the “OWASP Top 10” (or say we do…) but there is much more to OWASP than that.
OWASP is the Open Web Application Security Project, or - more accurately - coming up on a hundred projects. These range from mature “Flagship” projects to up-and-coming “Lab” and “Incubator” projects, amongst a field of old and unloved wiki pages. Even though you see company policies issuing commandments to “follow the OWASP standards”, only a handful of them could be interpreted as “standards” or “guidelines”. So where to start, if you’re looking to get some good security guidance?
This post is going to provide what I consider the Top 5 OWASP Projects. We’ll answer two simple questions - what is it, and when’s the best time to use it.
Written 15 January 2020
Using AWS Lambda to call and text you when your servers are down
Getting a phone call in the middle of the night when your servers are on fire is a necessary evil for many developers and network administrators. If your site is being used around the world, then it needs to be available 24/7. Paid incident management tools exist, like PagerDuty, VictorOps, and OpsGenie. They handle escalating incidents through your team, and notify via multiple channels. Cabot and OpenDuty are open source equivalents you can self-host.
Our team is pretty small though, and I thought it’d be fun to see how easy it’d be to get a simple incident alarm going with AWS SNS, AWS Lambdas, and Twilio. Hint: very easy. Best of all it’s serverless, so there is nothing to maintain. You don’t have to worry about your incidence response server going down! In this post I’ll walk you through how to achieve this yourself.
Ingredients: an AWS account and a Twilio account with a voice-capable phone number.
Cooking time: 15 minutes.
Result: you’ll get a voice call and a text message when your service is down / degraded.
Written 5 December 2016
Using "CRAFT" to answer 'Do I need to add extra security?'
With all the breaches and hacks going on around the world, businesses are asking themselves “Do I need to add extra security?” It’s a simple question, but the answer is “it depends”. In this post we’ll look at a framework which will give us a much more useful answer. It’s an acronym called CRAFT, and it helps you gauge if and when you need to add a security product.
Written 24 November 2016
An introduction to passwordless logins
Logging in without a password? It’s a pretty unusual idea, but one that is quickly gaining traction. In this post I’ll give a quick introduction in to how you might achieve passwordless logins in your own applications by emailing users magic links.
Written 15 September 2016
Making a Rails Health Check which doesn't hit the database
In a production application you usually have many servers, and each of those servers get checked periodically to make sure they’re still alive. If they are, then requests can be routed at them, for example by a load balancer. If a server doesn’t respond to the healthcheck, then it is presumed to be dead or unhealthy, and requests are sent to the healthy servers instead. When your production environment uses automated scaling, servers can be killed and rebooted when they’re unhealthy too.
Written 31 August 2016
Advancements in Android's Trust and Authentication platforms
Passwords and pin numbers are so annoying that most people don’t use them on their mobile devices. Passwords for online accounts are often forgotten and reused. It’s an environment where users expect safety, but the cost is too high. Google is trying to do something about that. Android usually gets a bad rap in the security community, primarily because the platform relies on vendors to push out updates, leaving many many people with insecure phones. But at Google I/O this year and last, Android has proved they’re taking some massive steps forward in the authentication space, and it’s pretty exciting.
70% of users forget their password once a month, and on average try 2.4 passwords before we get the right login
- Regina Dugan - Google SVP in 2015
In this post we’re going to take a quick look at what Google has been doing in this space, and in particular their new Trust API which enables continuous authentication.
Written 2 August 2016
How I could log in to Yahoo Mail with any password
A little over a week ago I discovered a startling vulnerability in Yahoo Mail. I could log in to any of my accounts, and I presume many others, with any password. It seems to be fixed now, but Yahoo’s response left much to be desired.
First I’ll outline the vulnerability, then I’ll discuss Yahoo’s response.
Written 20 May 2013