5 ms·

Do you know what would be amazing? The ability to change all vulnerable passwords, automatically as a group. I know it's very challenging because password cha

Do you know what would be amazing? The ability to change all vulnerable passwords, automatically as a group. I know it's very challenging because password change/reset procedures vary widely, but that part of the process is still manual. 1Password already automates logins almost entirely successfully. Perhaps password changing can be automated as well? If it were robustly automated, you cold easily rotate your passwords once a month, with very little fuss, for example. This is really something that authentication schemes could benefit from supporting an automated API for. Good work on the service. I suspect that heartbleed was the current use case, but this service will be very helpful for future breeches and issues. For example they could alert you that XYZ Service had a data breech, it's fixed, and you should rotate your password. Great work.

jfb 12y ago
As a half-way step, they could aggregate and normalize the various stupid rules that sites impose and then automatically generate valid, maximally secure passwords by default. Eventually, 1Password (or similar) could handle e.g. changing them all on a given schedule. I already try to have no passwords older than three months, and it's a PITA.
- r00fus 12y ago
  Problem: Aggregation and normalization might result in an empty set as contradictory rules prevent harmonization.
  - jarrett 12y ago
    I think the parent comment is saying that 1Password would record the rules per site, not maintain a global list of rules that satisfies all sites. The latter would indeed yield an empty set, as some sites require a special character and some require no special characters.
    - jfb 12y ago
      Yes, exactly; for each site that 1Pwd can recognize as distinct, record the restrictions. Even share these restrictions. And perhaps people could put attributes on their password entry elements (or header metadata) that would describe the limitations of their password systems, so it wouldn't be specific to any one password manager; then, too, they could retire their terrible, terrible, terrible client-side strength checking crap.
senorprogrammer 12y ago
I wish that affected sites would simply reset my password themselves, internally, and then inform me when I visit the site that I need to use the 'Forgot Password' function to reset my password. As it stands, they get to say they're patched while I remain vulnerable, and now it's my fault if my account is compromised if I don't get around to resetting my password (or they're a site I visited once, years ago, and forgot all about). Simply updating OpenSSL without fixing passwords just shifts the onus to the users.
- bdcravens 12y ago
  That's a tough call, especially for small companies. There are very real support expenses (not every app or it's users have SaaS-like support requirements) that don't make this an easy call.
AGKyle 12y ago
[I work for AgileBits, makers of 1Password] Thanks for the feedback! Filling into sites and gathering the necessary information for this I think is far easier than determining how a password change takes place. We have an algorithm that we've developed over years that is constantly changing in subtle (and not so subtle) ways to make filling more accurate. Some of the biggest changes in a long time will be coming in the 4.2 version of the browser extension, currently in beta. But you're right, sites and their password change processes differ greatly. Some require the old password, some require only the new password. Some only require the new password once (admittedly rare). I think at best though we'd only be able to do this if we went to the password change page for the site and attempted to fill the data in for changing the password. There's no way we could bulk update as that would probably require we hard code each individual site rather than relying on an algorithm for filling data into the site. It's a tricky thing, but we're always trying to come up with new ideas and ways to accomplish those ideas. Heartbleed was the first use case for Watchtower, but you're correct in that it'll be available for other situations as well. Now that the foundation is there we can leverage it for other issues in the future. Thanks again for the wonderful feedback! Kyle AgileBits
- masklinn 12y ago
  > Filling into sites and gathering the necessary information for this I think is far easier than determining how a password change takes place. Maybe start talking it out with browser developers and big websites stuff so there's a way to standardise an endpoint or in-page meta-information allowing for automated password reset?
  - ColinDabritz 12y ago
    This could be a real win. If there was a way of marking a standardized form with some meta data or tags to say "hey, this is safe to use automatically in the expected way" such as the typical form with old > new > repeat new or something. One little HTML change and it advertises compatibility. That way, classy sites could enable a 'safe enough/good enough' flag that any software could use. There is also the thought that it may be worth hard-coding for the biggest sites. The high profile sites are the most vulnerable when a vulnerability hits, there are big existing databases of user names around, and these can be exploited automatically and quickly on relatively high value targets (gmail accounts, amazon, facebook, twitter etc). Even top 10 would be helpful, but top 100 seems approachable, especially since the bigger sites are probably more consistent. The payoff here could be big next time around. Also if the framework were around for doing this, you could target a particular site or three that just had a major breech, and push the rules for reset out with the breech notification. I know it's a huge amount of work to do manually, but even a relatively focused effort could have payoffs, and if working with big sites can start a 'automated password reset' standard rolling, others might adopt it. Just thinking out loud, I know you've got to juggle priorities and features with limited time. Thanks again!

jfb 12y ago

As a half-way step, they could aggregate and normalize the various stupid rules that sites impose and then automatically generate valid, maximally secure passwords by default. Eventually, 1Password (or similar) could handle e.g. changing them all on a given schedule. I already try to have no passwords older than three months, and it's a PITA.

r00fus 12y ago
Problem: Aggregation and normalization might result in an empty set as contradictory rules prevent harmonization.
- jarrett 12y ago
  I think the parent comment is saying that 1Password would record the rules per site, not maintain a global list of rules that satisfies all sites. The latter would indeed yield an empty set, as some sites require a special character and some require no special characters.
  - jfb 12y ago
    Yes, exactly; for each site that 1Pwd can recognize as distinct, record the restrictions. Even share these restrictions. And perhaps people could put attributes on their password entry elements (or header metadata) that would describe the limitations of their password systems, so it wouldn't be specific to any one password manager; then, too, they could retire their terrible, terrible, terrible client-side strength checking crap.

senorprogrammer 12y ago

I wish that affected sites would simply reset my password themselves, internally, and then inform me when I visit the site that I need to use the 'Forgot Password' function to reset my password. As it stands, they get to say they're patched while I remain vulnerable, and now it's my fault if my account is compromised if I don't get around to resetting my password (or they're a site I visited once, years ago, and forgot all about). Simply updating OpenSSL without fixing passwords just shifts the onus to the users.

bdcravens 12y ago
That's a tough call, especially for small companies. There are very real support expenses (not every app or it's users have SaaS-like support requirements) that don't make this an easy call.

AGKyle 12y ago

[I work for AgileBits, makers of 1Password] Thanks for the feedback! Filling into sites and gathering the necessary information for this I think is far easier than determining how a password change takes place. We have an algorithm that we've developed over years that is constantly changing in subtle (and not so subtle) ways to make filling more accurate. Some of the biggest changes in a long time will be coming in the 4.2 version of the browser extension, currently in beta. But you're right, sites and their password change processes differ greatly. Some require the old password, some require only the new password. Some only require the new password once (admittedly rare). I think at best though we'd only be able to do this if we went to the password change page for the site and attempted to fill the data in for changing the password. There's no way we could bulk update as that would probably require we hard code each individual site rather than relying on an algorithm for filling data into the site. It's a tricky thing, but we're always trying to come up with new ideas and ways to accomplish those ideas. Heartbleed was the first use case for Watchtower, but you're correct in that it'll be available for other situations as well. Now that the foundation is there we can leverage it for other issues in the future. Thanks again for the wonderful feedback! Kyle AgileBits

masklinn 12y ago
> Filling into sites and gathering the necessary information for this I think is far easier than determining how a password change takes place. Maybe start talking it out with browser developers and big websites stuff so there's a way to standardise an endpoint or in-page meta-information allowing for automated password reset?
- ColinDabritz 12y ago
  This could be a real win. If there was a way of marking a standardized form with some meta data or tags to say "hey, this is safe to use automatically in the expected way" such as the typical form with old > new > repeat new or something. One little HTML change and it advertises compatibility. That way, classy sites could enable a 'safe enough/good enough' flag that any software could use. There is also the thought that it may be worth hard-coding for the biggest sites. The high profile sites are the most vulnerable when a vulnerability hits, there are big existing databases of user names around, and these can be exploited automatically and quickly on relatively high value targets (gmail accounts, amazon, facebook, twitter etc). Even top 10 would be helpful, but top 100 seems approachable, especially since the bigger sites are probably more consistent. The payoff here could be big next time around. Also if the framework were around for doing this, you could target a particular site or three that just had a major breech, and push the rules for reset out with the breech notification. I know it's a huge amount of work to do manually, but even a relatively focused effort could have payoffs, and if working with big sites can start a 'automated password reset' standard rolling, others might adopt it. Just thinking out loud, I know you've got to juggle priorities and features with limited time. Thanks again!