This series, and my blog, have moved! Check it out!
In the previous article in this series we discussed why ensuring the security of sof...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.