WatchTower and Imports
Today I happened to notice something disturbing while I was running one of my wallet conversion scripts. After I imported an eWallet converted wallet, I went to check WatchTower's status for various entries. And of course, WatchTower shows nothing because the Last Modified date of each imported record is the time of import. I see that I can set the updatedAt value in 1PIF, however I can do nothing for CSV imports (which I'm likely to deprecate anyway in favor of the more robust 1PIF), nor can I affect users who have already converted and imported.
So I can see a couple of lines of attack, the first one I can handle, but the latter ones AgileBits might want to address/consider:
I can update my scripts to set the updatedAt to some arbitrarily chosen old date (like 1/1/2000) so that WatchTower is triggered, or use any wallet's program's Last Updated value if it is available. Edit: I've updated and tested one script, but it doesn't appear that setting updatedAt is sufficient generally to trigger WatchTower. Suggestions welcome.
1P4 should automatically set the WatchTower status to unchecked (for vulnerability candidacy) for all CSV imports.
1P4 should support a means for users to mass reset the vulnerability candidacy so that after an import they could see which items are potentially vulnerable. This would cover users who have already imported via CSV or script-produced 1PIF.
I realize that WatchTower is probably just checking the Last Modified date against the site's last changed certificate change, so some means for users to reset this to trigger a check against the database would allow WatchTower to work with imported data, even if overly aggressive.
Comments?
Comments
-
Hi @MrC,
I just wanted to let you know that I've passed your question along to our security gurus. Since it's the 4th of July, I'm not sure we'll get a response out to you today, but we will get back to you just as soon as possible. ;)
Happy Independence Day (if you are from that neck of the woods!)
0 -
Hi again @MrC,
I've been talking to some of our tech gurus, and I think I've learned enough to update you a bit on the situation here.
The problem is that the only way we can know for sure when the password was last changed is if there are password history entries in the item in 1Password. In the absence of that, the oldest (and only, really) thing we have to go on is the time the password was created in 1Password. When an item is imported into 1Password, the creation date for the password is set as the date that the item was imported into 1Password.
Our concern with automatically setting all imported entries as potentially vulnerable is that it could be frustrating for users who have just changed their passwords prior to importing.
You do raise a good point however - users who have recently imported their data into 1Password from another source should be made aware that WatchTower is not going to be able to analyze their imported Logins in the same way it can analyze their 1Password-created ones. To that end, I've filed a request in our internal tracker to update our documents to include information about WatchTower.
internal reference number: DOCS-138
0 -
Thanks for the updates, Megan.
I'll suggest however that 1P4 should error on the side of security when possible and practical and less on the side of side-stepping user frustration in lieu of security. I appreciate its a fine balance, but the frustration aspect can be mitigated with an option for users to clear the WatchTower status for the selected entries. I would like to be able to do this in any event (I'm tired of changing my Google password needlessly just to clear WatchTower) and other users have requested this too.
I believe it is better to suggest a site might be at risk, and let the user clear a warning, than to remain irresponsibly silent out of fear of offending.
0 -
Thanks for your additional thoughts on improving this, @MrC. As you probably already know…
To remove the Vulnerability Alert from a Login item and retain its current password, one method is to temporarily change the item's password value and then change it back to the original. Another is simply to duplicate the item and delete the original, but that also removes previously used passwords history from the new item with its side effect that @Megan mentioned in her last reply:
In the absence of that [password history], the oldest (and only, really) thing we have to go on is the time the password was created in 1Password
I prefer the first workaround, which is certainly less tedious than repeatedly changing site passwords that really don't need to be.
internal reference number: WT-16
0
