buttercup-desktop icon indicating copy to clipboard operation
buttercup-desktop copied to clipboard

"Change your password for security reasons" Feature

Open xburelle opened this issue 7 years ago • 7 comments

It would be a good thing to have this kind of feature in Buttercup. I found a website "haveibeenpwned.com" which has an API to get all the breached websites. It would ask for creating a new label "WebSite", used to check if this website has been hacked. There is a similar feature in 1password. Which has too, a time checker : if your password is too old since you created (or changed) it. We can as well add a security report of entries, based on it. The best would be to ask to the owner of "haveibeenpwned.com", if he's interested in this project. But for now, I'm asking you if you are interested in it. And maybe there are other websites with an API which do the same job. Let us know, your knowledge and your thoughts. If it sounds well to you, I'm ready to work on it.

Another feature can be "Do you use your credentials safely". Where you are warned when you are in http (and not https) for login. Although it's very rare, it enhances securty. It's a browser extension feature.

PS : I'm sorry for my english, that is not perfect.

xburelle avatar Jun 04 '17 14:06 xburelle

@xWayfarer Thanks for posting. Your english is fine, and your idea is great. We've previously spoken about this kind of system, but it's probably a bit more complex than it sounds.

For instance, I don't think that we should be connecting directly to a 3rd party API (you might not have meant this). This means that we need to host something ourselves. To avoid yet another NodeJS daemon on the server as a proxy or something, I would suggest that we store a JSON file there (along with deployment or auto updates etc.) that is downloaded by each Buttercup application so that all users get the warnings. That raises questions of its own:

  • Do we store all hacked account details from the 3rd party so we can alert individual users?
  • Do we notify account holders of some-hacked-website if a domain has been listed?
  • Do we show the notification all of the time, or do we memorise them having seen it and then hide it? (If we remember, it has to be per archive due to multiple users. This requires even more work: Archive "settings".)

@sallar definitely need more ideas here :)

There is a similar feature in 1password. Which has too, a time checker

This is a separate item altogether: Password expiry. Imo, like in Keepass, it should be optional and be customisable per entry. This requires additions to be made to the core (buttercup-core) (should include a notification centre of some sort).

Another feature can be "Do you use your credentials safely". ... It's a browser extension feature.

Yes, this should be created in the browser extension repo.

There's a lot here, and I think that once we've identified the tasks we should create them separately and perhaps even close this one...

perry-mitchell avatar Jun 04 '17 15:06 perry-mitchell

@xWayfarer Thanks for your idea. @perry-mitchell I agree that the other way around is better, meaning that Buttercup client would download a json file of most used passwords, or some kind of identifying data from internet, and would check the passwords "locally" against those. Sending private information to a 3rd party API does not sound safe to me.

Also, 1Password has a "Watch Tower" feature. I dont know how it works, but it will notify you of your account has been exposed. I think I read somewhere that it also doesn't send your data but rather checks them locally against a downloaded list.

sallar avatar Jun 04 '17 15:06 sallar

Sending private information to a 3rd party API does not sound safe to me.

Yeah definitely. It means that the whole list should be downloaded by the client (Buttercup).

it will notify you of your account has been exposed

Yeah that would definitely be the more complete approach. I guess we have to store the lists on our server.. but we'd definitely need a CDN if we were to use those, which is another operating cost. We should discuss this from an infrastructure perspective if we go that way.

perry-mitchell avatar Jun 04 '17 15:06 perry-mitchell

I think the most difficult thing is to gather informations and maintain a database (like a JSON file) about hacked domains. There are lot of news websites that inform you about a new website breached. But scrapping them is very hard, because it's news among the others. It demands human interaction. I though, a solution was to create a wiki database but it is not certified, and false information can be added. This API remove this problem. I agree with you about sending directly informations to a 3rd party is not appropriate.

  1. Server part

I don't kown very well but maybe we can have a JSON file "security definitions" in a Github repo. And every update the application checks if there is modification with the hash. It can resolve the CDN problem and leave Buttercup in a open source way. Of course, the file will be maintened by restricted people. The JSON file is filled with timestamp (month and year) for each entry.

  1. Application part

The application download this JSON file. After it checks if there are matches with the entries. The user is notified only if he has a entry with this domain. Like the database is timed, the application looks the difference with the modification time of password, and show by this way the notification message (not exactly all the time). This message appears in the Entry and in the report (notification center). Maybe it can, too, be displayed like a red message "You have security failure - Look more" in the head of the app.

  1. The report / Notification center
  • We can use security directives, like "Change your password every x months", to make a report. This is set globally in settings (for all password), and locally (each entry, if the user want too).
  • Warnings are displayed about new website hacked, and with a status "not resolved". The user has to change his password to change the status.
  1. History report / notifications, (mostly for multiple users)
  • What have been changed and what security failures.
  • With history expiration time in settings

I will try to add the Password expiry feature in buttercup-core, first and continue to think about this domains checker and keep in mind if there are other security verification (like most used passwords). I will come back to you when i'm done with Password expiry, it will certainly take me some time as I discover your project. Or maybe if you have other things you want to discuss.

xburelle avatar Jun 04 '17 17:06 xburelle

This API remove this problem.

I agree, and what I'm suggesting is merely mirroring their content in some format that makes it easy and practical for us to send to our apps. I don't think it's appropriate that every user connects to their API individually, for both the API's sake and ours, and so connecting to some source on *.buttercup.pw would be best.

I don't kown very well but maybe we can have a JSON file "security definitions" in a Github repo.

This would be good for contributions, but if we have access to an API, why would we accept user additions/changes? The API would be a trusted source of information which hopefully does its own auditing.

Maybe it can, too, be displayed like a red message "You have security failure - Look more" in the head of the app.

Absolutely! Being active like this is great, and it's something that'd put me at ease as well. Providing the process is seamless (the user needs to do nothing), this will work well. They already have domains and usernames in the each entry, so that should be enough to detect issues.

This is set globally in settings (for all password), and locally (each entry, if the user want too).

This is a good idea, but I would advise not to rush on it as it requires application settings.. which is a much bigger task (both in core and UI).

What have been changed and what security failures.

What do you mean by this?

I will try to add the Password expiry feature in buttercup-core

Great! Please create an issue there first as we should discuss architecture before you begin. Due to the settings part not being done, the expiry feature will only be possible to do on a per-entry basis for now (using attributes).

perry-mitchell avatar Jun 05 '17 05:06 perry-mitchell

What have been changed and what security failures.

What do you mean by this?

What are the passwords that have been changed a few time ago. And what domain breaches have been encountered. It can be seen as a monitoring part.

I already look to implement password expiry, and it really needs a settings part. I will create a issue for it.

xburelle avatar Jun 05 '17 12:06 xburelle

Ok, so revisiting this, after such a long time, it might be easier to query haveibeenpwned's API directly. Here's some example GET endpoints:

  • https://haveibeenpwned.com/api/breachedaccount/[email protected] - Gets PWN'd services for an account name
  • https://haveibeenpwned.com/api/v2/breach/MySpace - Gets PWN details for a breach, which could be displayed to the user.

The rate limit is 1 request per 1.5 seconds per IP address, so we could implement some basic request-and-retry logic until the result comes back (with forced 1.5 second wait times of course).

EDIT: This would also need UI work to show something on the Entry. Perhaps something to indicate one of 3 states:

  • OK: No breach detected
  • Breach-Inactive: Breach detected but password changed since breach date
  • Breach-Active: Breach detected, password should be changed

Thoughts @sallar?

perry-mitchell avatar Oct 09 '17 10:10 perry-mitchell