Since the point of this proposal is to inform password managers (or other user agents) that a password needs to be changed, a slightly different approach could be to specify "if you created an account in this timeframe, you should change your password." Then there's no need to specifically address which vulnerabilities existed when.
from: <datetime>
to: <datetime>
change_url: https://www.linkedin.com/sorry-we-lost-your-password-our-bad/
... where the file must be requested only via https and the domains must match.
And then LastPass or 1Password or your browser or a plugin looking at credentials stored by your browser could routinely check sites where you have accounts, and say "Hey, LinkedIn says that your password is at risk and should be updated. Would you like to do that now?"
This is roughly equivalent to having LinkedIn send an email to all affected accounts (which is mandatory good citizenship, right?), but maybe will increase the success rate. It's another way for sites that have big embarrassing security breaches to try to do the right thing.
Possible downsides:
- Might teach users a behavior that makes them more vulnerable to phishing?
- More worryingly, if an attacker was able to MITM requests, they would be handed a list of every site where you have an account, and a way to affirmatively reach out and ask you for your password to those sites.
- Attackers might be able to detect the list of sites you have accounts at just by analyzing encrypted traffic. That could be valuable info on its own.
- An attacker who gained the ability to write to password_revoke (but no direct access to user data) could potentially escalate the attack by revoking everyone's passwords (although it's not clear to me how much more dangerous that would be than being able to write to password_revoke in the first place, and it might be a quick way to blow their cover).
I'm wondering if this is too specific. The other alternative proposal that someone floated in response to my proposal -- a file containing just CVE numbers and timestamps for when the site was no longer vulnerable to each of them -- seems more generalized and covers more than just passwords.
I'd extend that proposal to allow a CVE to be listed with a special token indicating "never vulnerable" (perhaps "1970-01-01T00:00:00Z" as the patched-at timestamp) and perhaps to allow a CVE listed with two timestamps indicating the range of time during which the site was vulnerable.
Comments
Since the point of this proposal is to inform password managers (or other user agents) that a password needs to be changed, a slightly different approach could be to specify "if you created an account in this timeframe, you should change your password." Then there's no need to specifically address which vulnerabilities existed when.
Something like:
https://www.linkedin.com/.well-known/password_revoke:
... where the file must be requested only via https and the domains must match.And then LastPass or 1Password or your browser or a plugin looking at credentials stored by your browser could routinely check sites where you have accounts, and say "Hey, LinkedIn says that your password is at risk and should be updated. Would you like to do that now?"
This is roughly equivalent to having LinkedIn send an email to all affected accounts (which is mandatory good citizenship, right?), but maybe will increase the success rate. It's another way for sites that have big embarrassing security breaches to try to do the right thing.
Possible downsides:
- Might teach users a behavior that makes them more vulnerable to phishing?
- More worryingly, if an attacker was able to MITM requests, they would be handed a list of every site where you have an account, and a way to affirmatively reach out and ask you for your password to those sites.
- Attackers might be able to detect the list of sites you have accounts at just by analyzing encrypted traffic. That could be valuable info on its own.
- An attacker who gained the ability to write to password_revoke (but no direct access to user data) could potentially escalate the attack by revoking everyone's passwords (although it's not clear to me how much more dangerous that would be than being able to write to password_revoke in the first place, and it might be a quick way to blow their cover).
Interesting idea anyway.
I'm wondering if this is too specific. The other alternative proposal that someone floated in response to my proposal -- a file containing just CVE numbers and timestamps for when the site was no longer vulnerable to each of them -- seems more generalized and covers more than just passwords.
I'd extend that proposal to allow a CVE to be listed with a special token indicating "never vulnerable" (perhaps "1970-01-01T00:00:00Z" as the patched-at timestamp) and perhaps to allow a CVE listed with two timestamps indicating the range of time during which the site was vulnerable.