Password Managers and Understanding Risk
If you’ve been following the technical news the last few days, I’m sure you’ve seen the articles about the vulnerabilities discovered in Lastpass (a popular password manager, and one that I use). You may have even seen people complaining that Lastpass was slow to fix vulnerabilities and that one shouldn’t use browser extensions and such. To me (someone who works in cybersecurity), this demonstrates yet again that most people have no idea at all how to assess risk.
This is a great example of this. The vulnerabilities announced above depend on visiting a malicious website. Think about the websites you visit on any given day. The vast majority are probably from some small set of the same sites: social media, news sites, banks, well-known shopping sites, perhaps well-known games. All with low odds of being malicious. Your only exposure might be if you click on an ad (most of us don’t do that) or click on an unknown link in an email (your mother taught you better). So, for the vast majority of people, the odds of going to a malicious website that has a newly released vulnerability that targets a specific password manager is low. Although you may see FUD (fear, uncertainty, distrust) otherwise, such as this statement on the Lastpass forums:
You mentioned exposure. There is always the possibility that someone discovered the bug previously, harvested the information and is sitting on it. Due to the nature of LastPass the level of the compromise is greater than any other tool or device as it would provide information to all passwords (as I understand it), not merely a matter of changing the password to your email or facebook account but could consist of updating 100’s of passwords. That 2FA appears to have been side stepped by this compromise is a large worry.
(2FA refers to two-factor authentication). Let’s assume, as this author did, that someone discovered the bug previously, harvested the info, and is sitting on it. Exploitation still requires visiting a malicious website, and it having a targeted attack in place. From the Lastpass blog on the subject:
To exploit the reported vulnerabilities, an attacker would first lure a user to a malicious website. Once on a malicious website, Tavis demonstrated how an attacker could make calls into LastPass APIs, or in some cases run arbitrary code, while appearing as a trusted party. Doing so would allow the attacker to potentially retrieve and expose information from the LastPass account, such as user’s login credentials.
Based on this description, they wouldn’t even be obtaining all passwords. They would have to do so one at a time. If you practice good security hygiene and enable 2FA whereever you can (not just Lastpass), even if you did visit a malicious website, and even if they had a targeted attack, and even if they guessed one account right, 2FA would defeat them on that account, or you would have noticed something. In other words, low odds of it being exploited.
As for the time to correct the problem, Lastpass had updated extensions in place (which auto-update) within 24 hours. The researcher that identified the vulnerability even acknowledged as much in this updated article (scroll to the bottom). We’ve gotten used to reported Windows vulnerabilities - which might be in the wild - being corrected in a month if we’re lucky. Similarly for Flash vulnerabilities. Both see much greater use, and much greater exposure. Here you had reasonably rapid correction of a bug.
Tavis Ormandy @taviso : Two more LastPass bugs fixed today https://bugs.chromium.org/p/project-zero/issues/detail?id=1188 … and https://bugs.chromium.org/p/project-zero/issues/detail?id=1217 …. Very quick response from LastPass, < 24hr.
Tavis Ormandy @taviso : Very impressed with how fast @LastPass responds to vulnerability reports. If only all vendors were this responsive
Lastly, there are folks out there that believe software should be bug-free. Programmers believe that as well, but recognize it is an impossibility. Turing Award Winner C.A.R. Hoare said it best:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.
Dahl, Dykstra, and Hoare, back in 1972, also noted that provably bug-free software is impossible: “Program testing can be used to show the presence of bugs, but never to show their absence.” We should expect our software to continue to have bugs, perhaps becoming more esoteric and harder to exploit as time goes on, but there none-the-less. All we can ask then is rapid patching.
This entry was originally posted on Observations Along The Road (on cahighways.org) as this entry by cahwyguy. Although you can comment on DW, please make comments on original post at the Wordpress blog using the link below; you can sign in with your LJ, FB, or a myriad of other accounts. There are currently
comments on the Wordpress blog. PS: If you see share buttons above, note that they do not work outside of the Wordpress blog.
(Click Here to Comment)
P.S. This post is an auto crosspost of the version posted at Dreamwidth, which itself is a crosspost of the version posted on California Highways. Please comment on the blog by clicking on the big green sign. You can comment on LJ or DW, but it is discouraged (there are
comments on DW).