This series, and my blog, have moved! Check it out!
In the previous article in this series we discussed why ensuring the security of software is an elusive task; application security is hard to achieve with how the InfoSec and software development industries and education system(s) currently work. We talked about the importance of starting security actives early in the SDLC and formalizing them as part of your process. But what ARE these actives? How do they work, and when do we do what? That, dear reader, is what this article is about.
As you recall from the previous article, the system development life cycle generally looks like the image below:
System Development Life Cycle (SDLC)
Whether you are doing Agile, Waterfall, or if you have a DevOps culture at your office, you always need to know what you are building (requirements), you need a plan (design), you need to code it (the fun part), testing is obviously a must, and then you release it out into the wild (hopefully you also maintain and monitor it as well, which is all part of the “release” phase). Each one of these phases should involve security activities. Let’s look a little deeper, shall we?
Top comments (18)
I really enjoyed this article thank you. <3
But I would like to discuss something, and I am torn. Shouldn't we be letting the users opt-in to check if their password is compromised? Sending their password to a third-party does invade their privacy.
Especially if it's without the user's consent.
I know that users shouldn't be allowed to have insecure choices.
Again, I'm kinda torn.
Tari,
Thank you for bringing this up, I clearly didn't explain it well enough. When you send the info to the API to check the password it's the last couple digits of a hash of the password. What that means is that you do a 1-way cryptographic algorithm against the characters of the password, it creates something new that is unrecognizable, then you send part of it to the API. This means at no point have you shared the user's password. But I probably should have said this in the article! Thanks for letting me know this is missing. :-D
But I definitely agree with you; we should never share our user's passwords with anyone, not even our own software developers.
Tanya
Ah, okay. I did know about how the API works. It was more of a "shouldn't we warn the users' passwords are getting sent to a third-party?".
After all they should have choices how their data is handled.
But another problem out of that is, it could scare them to not use it at all because they don't know the technical details of how it works to make sure no one can figure out their password.
I suppose if the software developers implementing the HaveIBeenOwned service don't understand the security behind it, and how the passwords are compared, I do see that they may be reluctant to use the service. There are also paid services that can do this for you, I believe that 1Password offers such a service. Maybe using a paid service would seem more secure and "legit" than using an open source and free service? This is a good point.
I guess when you're signing up or changing your password/passphrase you could have a little check box saying "Check if your password/passphrase is compromised." that defaults to off.
And of course a information link that first explains to a average user, then more technical details if they're smart enough to understand it.
It seems like a good balance to me. I feel like a lot of people would want to check that box when registering an account. Perhaps that's just me.
Of course this is experimental, which would require research. None of all the services I have seen on the internet implement this.
But I think it would be a good balance.
Hi,
We (you developer, me security person) need to make a lot of decisions on behalf of our users. Just like a car designer makes many decisions for me that I do not understand, we (software builders) need to make decisions for the users of the software that we create. No users will understand if we give them this choice. It's too much; only professionals would understand, and that's no fair to the average user, who make choose incorrectly. The same would be true if my car manufacturer offered me airbag X or airbag Y, and listed all the reasons to choose one or the other. It would be a waste of time because I'm not a professional car designer/do not have the knowledge to fully understand. Does this make sense? Offering them this choice would just be confusing, not helpful, to any regular (non-IT professional) user visiting a website.
Many services on the internet check for breached passwords all the time, Facebook does it and many, many more. They are doing this to protect their users from a vulnerability called "Credential stuffing", which means attackers using stolen credentials on sites and then stealing or harming the victims. It's happening quite a lot and it's extremely damaging, because many users reuse the same password on many different platforms. Many websites, that we all use, are currently doing this. None of them ask for the user's consent, because they are not sending the password or personal information, it's part of a hash, which is not recognizable to the original password.
If you want to know more about how the partial password hash is passed for the haveibeenpwned.com API, you can read the spec here: haveibeenpwned.com/API/v2
I hope this helps?
Hmm, you're right. I guess we shouldn't be giving users any choices that could potentially allow them to shoot themselves in the foot.
It's really hard being into security and trying to develop solutions for people who don't understand.
Because you have to think and feel like a end-user, when you're really not.
I hear you! I'm a big advocate for usable security features, which means testing with real-live users, not putting someone like me as a tester (because I'm inherently biased, being a security professional).
I am hoping that as the years continue the security industry works harder to make every aspect of security easier and better for the consumer, with the goal of one day having the easiest way to do something will also always be the most-secure way to do it. This is my dream!
I also want to make security easier for Devs. Because right now it is Way. Too. Hard.
Yeah, it is really hard. I think systems should be designed with security from the start. Like you pointed out in your first article. I really wished the ActivityPub protocol was designed with cryptography implemented, but ... of course. It wasn't. And now we have a standardized social network protocol without confidentiality, and authenticated integrity.. which should've been baked in.
Yep. We are biased.
Things are getting better, slowly. We do have Libsodium for cryptography. Still, even then it can be confusing to those who don't understand.
But there isn't really a way to automatically implement secure code with cryptography built into the heart of it.
Only recently I've started thinking about security for the average user. Obviously still having a hard time ...
This Twitter post might interest you, about notifying users:
twitter.com/stebets/status/1017366...
I like everything on this list bar this item: 'Allow users to cut and paste into the password field, but disable password autocomplete features"
IMO, anything that interferes with password managers or lowers their adoption is a major loss. If you want a password field that can't be attacked computationally, have a debouce and a lockout after 20 attempts.
I agree completely, password managers are absolutely necessary. Allowing for cut and paste will allow Password Managers to function properly, while disabling the browser from performing autocomplete will ensure that users don't accidentally save passwords into their browsers accidentally (unsafe place) and think they are using a Password Manager (safe place to store passwords and other sensitive data). Auto-complete is a browser feature, and disabling it will not interfere with your password manager. :)
I think we agree but perhaps my phrasing was not clear? Should I update the article?
Thank you for your comment!
Great article!
But why is a Browser-Built-In Passwort Manager like Firefox' PW-Manager unsafe? (assuming a master pw is set or the computer is only used by 1 person)
Btw. turning off autocompletion doesn't work in most browsers anyway:
support.mozilla.org/en-US/kb/passw...
Or did i simply misread your comment?
Browser-Built password management functions are not as secure as as an actual password manager. It is not an overly safe place to keep it. Another reason is that you have no idea who is using your site, nor which computer they are using it from; if someone is in a hostel backpacking across Europe and accidentally says "yes" to the "would you like XYZ browser to save your password?" they have unwittingly saved their password for all the hotel users to use later. Unfortunately we need to design assuming the worst case (public computer, not-technically-savvy user), rather than the best case (for instance you personally, someone who is knowledgable enough to read and understand my blog, is the absolute best case scenario for an app user).
Does this make more sense? Is it helpful?
Also, yes; sadly not all browsers support all of the same features, rules or standards. But we do what we can.
PS Thanks for the really nice comment!
Can't hurt to clarify.
I updated it, thanks! :)