Macpass: Pwned Passwords Support

[switchtrue]

Is your feature request related to a problem? Please describe.
Integration against Troy Hunts Pwned Passwords API would be a great addition for this app. A check could be run to compare all passwords in the database against Pwned Passwords.

Describe the solution you'd like
Flagging of passwords that have appeared in breaches by using the Pwned Passwords API.

Describe alternatives you've considered
Doing it manually myself.

Additional context
This may be better served as a plugin.

[mstarke]

This is an awesome idea for a plugin. 1password offers a WatchTower that does a comparable thing. It might be even worth considering adding this as a core feature.

[bmp]

This would be a great feature!

[yepher]

I would be open to implementing this if someone can offer a UX design for how it should look/feel.

I was thinking it would be a different view but I could see some value of it just being integrated into the existing list/details views.

[mstarke]

I'm unsure how the UI should look. The simplest way is another column with a mark for pwned passwords which will however yield a high amount of API calls. Another idea is an additional search parameter including only pwned passwords. A combination of both might be good.

Another idea is a separate view that can be invoked by the menu. This way it's the most flexible but it might be bad for gaining access a specific entry however this is an entry point for a simple tool and it limits the API calls to just once. A better way might be an actual item in the outline to access those items. This is in line with the concept of adding searches in the outline view.

[yepher]

You are right Some of the HIBP API can be called only once every 1500 msec or so. There is a header in the API response that indicates when it can be called again so I don't think it will be much of an issue to process all the domains and data. I expect I will want to cache the results somehow that does not add some vulnerability (not sure where yet but for sure won't store passwords anywhere). Also as I understand the password API does not have a rate limit so that should not be an issue.

I was thinking if the user has populated "URL" then the domain can be processed to give an indication if/when it has been compromised.

I am pretty confident about how to implement the API and process the responses. I am not super familiar with how MacPass UI structure is laid out so that will take me a little bit to sort through. I was thinking another option is to show the background of a cell as RED or Orange if it is compromised. This could be instead of adding another column. Thoughts?

I think there should probably also be a property to enable/disable the processing for this feature.

On initial review of the decryption process and document structure I am leaning towards kicking off the API calls around here: MPDocumentWindowController:: showPasswordInputWithMessage if the data is successfully decrypted.

Stop Gaps

• pcdc is a nice tool where you can process your data that has been exported as XML.
• KeePass-Leak-Detector this is a KeePass plugin. I personally lean towards this being a core feature of MacPass rather than a plugin (mainly because I am not familiar with MacPass plugin architecture). I am not sure if it would be easy to do UX changes as a plugin in MacPass.

[mstarke]

The plugin architecture for MacPass is in its infancy. The idea was to jump start it with the MacPassHTTP plugin which doesn't require that much plugin API and go on from there. Anything that wants to hook into the UI needs a better API so I would try to flesh this out as it's needed. This seems to be the best solution to invest only the time needed for the desired feature.

Adding this as a core feature is viable too. The plugin system tends to shift some pressure away from the main application to add features and allows to side-track those to plugin development (and even supports more contributions)

As for the entry point. My inital idea for the architecure was to drive the model (MPDocument) and hook the UI onto it by observing notifications and then performing the apropriate changes in the UI. The main UI works that way, that is, it displays the password input and then waits for the MPDocument to post a MPDocumentDidUnlockDatabase notification upon which it will display the unlocked database. Then those subviews will tell the document what groups and entries are selected and the inspector shows the corresponding editors.

A better spot to kick off the checks IMHO would be in the "_didUnlockDatabase" of the MPDocumentWindowController since this is the first time the UI tries to display the new content and it can be sure the data is decrypted.

Marking the password via color or an icons is something quite nice and the better way compared to an extra column and should be rather straight forward. What would be awesome is if it's property on a string and its KVO compliant which would make it bindable in the UI and frees up a lot of code to simply update states.

And before I forget, thank you for wanting to put some effort into MacPass. It's a good thing others can dig into the code and complain about all the shortcoming to get things cleaned up a bit.

[yepher]

Thanks for the feedback. I will use _didUnlockDatabase as you suggest. Yes, definitely hope to make this KVO compliant to make the magic just sort of happen :)

I've been using MacPass for years so least I can do to help out. I really appreciate your App.

[Ashok-Varma]

@yepher / @mstarke any update on this ?

[Blackbaud-ChristiSchneider]

There's a couple of versions for the Windows app:

• https://github.com/andrew-schofield/keepass2-haveibeenpwned
• https://github.com/mihaifm/HIBPOfflineCheck

It would be really nice to have this.

[ericmoret]

Any update?

[mstarke]

Nope. Sorry. @yepher did you hit any roadblock in implementing the plugin?

[georgesnow]

I would value this plugin as well. I would consider looking into it, but it falls behind the other priorities I have committed myself to wanting to complete. (MPRevealer in core code, TouchID support, etc..)

[yepher]

No sorry, I've dropped the ball on this.

[mstarke]

The API seems to require a paid account since it was abused. I might be able to fund this out of my GitHub Sponsors in the future but please do not bet on it…

[Blackbaud-ChristiSchneider]

New API: https://haveibeenpwned.com/API/v3#PwnedPasswords

Cost is US$3.50 per month. This would allow 57.6k requests per day if all requests were perfectly timed - would have to think about how not to get banned - might need multiple keys or to block requests that are going to exceed the rate limit (although it sounds like you're blocked for only a couple seconds now rather than a day). Additionally, the API key would need to be protected behind a server so that may incur additional costs. We'd need to make sure that bad actors can't abuse our service to exceed the rate limits on the keys as well, and I'm not sure the best way to accomplish that.

Blog post about why it is paid now. This also provides an example of a CloudFlare worker to hide the server key.

Authorisation is required for all APIs that enable searching HIBP by email address, namely retrieving all breaches for an account and retrieving all pastes for an account.

This, plus the lack of 401 response on the range request in the docs indicates to me that the range request endpoint does _not_ need a key. Maybe we can use this instead - you wouldn't be able to check that a combo of account name + password was lost but you can check if the _password itself_ has been compromised.

[georgesnow]

Just thought but what if you require the end user to enter their own API key? and if you store it Macpass could just use field reference to grab it?

Then if user really wants the feature. It’s up to them to pay for it.

[Blackbaud-ChristiSchneider]

I like that, and it solves the server problems and greatly simplifies things.