I don't find it weird for a password manager webextension to use a native binary, as password managers may be used in other contexts than browsers, and as it allows to use well-established cryptographic tools.
Of course, serializing to HTML and parsing it out of the browser seems like a very bad idea. I suppose it was made this way because their neuronal network was written for HTML.
I wonder what made Kaspersky use a neuronal network to recognize password fields. It seems over-kill to me, but I may underestimate the complexity of properly handling password fields.
As someone who built a machine learning field detector that works only on the source html, there are a few challenges to detecting these in the browser:
1. JavaScript is not a great language to build high speed low resource inference engines.
2. Sending user's HTML to your cloud to do so is a privacy, security and latency nightmare.
3. Regex matching doesn't get you anywhere near 95% field accuracy (not even talking about form accuracy, identifying all fields on a page correctly) on the web. You'd be amazed (or maybe not if you're a web dev) at the lack of consistency in field names - from machine generated field names to missing names to duplicate names... It's magical. Even to a human observer looking at a rendered page, it can be confusing which field is which. Just look at chrome try and fill a complicated address form out for you using a saved persona.
4. Even if achieved in JavaScript, the model would be simple to pull out and reuse elsewhere, possibly to learn how to game it.
5. Good models will be built by good data scientists, whose favorite tools likely don't produce models that can be serialized for use in a JavaScript inference engine.
This comes down to the approach taken here - put the inference in the code where it runs (and that was likely the same that trained the model) and interface with the page via extension to ship it there and back. It's local so it never leaves the machine.
It's very high stakes to take user controlled HTML into unsafe memory. Large surface area doesn't automatically mean an insecure implementation.
> JavaScript is not a great language to build high speed low resource inference engines.
This is a browser plugin analyzing html downloaded at human browsing speed. I doubt performance is a primary requirement.
> Even if achieved in JavaScript, the model would be simple to pull out and reuse elsewhere, possibly to learn how to game it.
The binary model is obfuscated but still distributed. I expect that the added difficulty of working with the binary model is small compared to the overall challenge of gaming it.
> Good models will be built by good data scientists, whose favorite tools likely don't produce models that can be serialized for use in a JavaScript inference engine.
Models built in research-optimized environments can be translated after the fact to match production needs. (It is getting easier with e.g. standard interchange formats for neural models.). Kapersky is a resource-rich org working on security software -- exactly the folks whom, if diligent and well intentioned, should invest in such hardening.
Getting a sparkML serialized model to drop into a JavaScript interpreter is not possible today from what I can see (and certainly wasn't the case 2 years ago). There does seem to be some good progress in the field with tensorflow.js and ml.js but nothing I'd put in production with a few million users. In native Scala the inference engine with a loaded model takes a few hundred MB of memory, I'd imagine with some JavaScript transpiling with emscripten or similar that would get ballooned quite a bit.
I'd be really glad if there was a viable method to do this without murdering the end user device.
I find this extremely strange. I cannot even come up with a good metaphor to explain to non-technical people how untrustworthy this makes most AV software look to me.
I mean, we all make mistakes, but the kind of bugs that have been found in various AV products are so obviously stupid one can easily get a concussion from face-palming. If I were to roll my own crypto, there are all kinds of subtle mistakes that I could, nay: would, make that I might not even understand if someone explained them to me very patiently. Like, redirecting system calls from a "sandboxed" process, but then executing them as SYSTEM? How can I trust a company that allows such dumb mistakes in their code to build software that is supposed to make a system more secure? It is like finding out that the surgeon who is supposed to operate on you lacks basic knowledge of human anatomy.
I don't. AV software is virtually impossible to vet for a customer; it is the literal stone to keep tigers away (do you see any? It must therefore work). So 100 % of selling AV software is marketing, not functionality.
"Independent tests", e.g. how much slower the computer is made by AV software disfavour solid design: All else being equal an AV software where the signature engine runs directly in the kernel code intercepting FS calls will always be faster than the properly designed software were the signature engine runs at lower privileges (requiring task switching), and the FS filter driver has to delegate.
Tests where well-known malware is fed into engines and the red flag comes up are also pretty meaningless; signature scanning works, that's not the problem of the product.
The problem of the product is that the only things a customer can measure disfavour good execution of it and that signature detection is fundamentally inept in countering relevant attacks and therefore no real protection. Heuristics (or ML or whatever) doesn't really work well, either.
"Microsoft was not the first to sandbox Windows Defender. Last year, experts from security outfit Trail of Bits, who also specialize in virtualization, created a framework that could run Windows applications in their own containers. Windows Defender was one of the projects that Trail of Bits was able to containerize successfully and open-sourced it."
I have always somewhat naively assumed it is best to never use a password manager plugin but instead use a separate binary with less convenient integration to reduce the possibility of browser exploits exposing my entire password db. Is there any truth to that?
It's a tradeoff. You get that advantage, but then you open yourself up to phishing attacks that browser plugins avoid by checking the domain. My ideal would be a browser plugin that sends the domain, and nothing more, to a standalone process.
A bit more must still be done. The browser-plugin must find the fields to fill with the data. It must also allow adding new entrys or changing existing entrys. Actually finding the correct username-field seems to be slightly more complex on a bad designed page, because it has no special type like the password-field.
Oh, do we know whether it's really just a simple passwordmanager, and not also some autofill-manager, session-restorer, or other security/comfort-snakeoil?
Not so much browser exploits, but the browser extensions often have issues. If your password manager is a separate binary, you usually don't have to worry about websites exploiting it. On the other hand, it won't protect you against phishing attacks (it doesn't know what site you are on) and will usually require that you to handle passwords via the clipboard.
Isn't it worth noting that LastPass / Dashlane / and others claim they are storing your binary blob on their cloud to be decrypted only on your machine and never theirs?
I think that's an area between "we store your passwords on our server" and "this file I store has all my passwords". No?
At least in case of LastPass you shouldn't buy the marketing statements. Not only isn't it really a binary blob that they are storing, they don't really care about protecting it from themselves either. https://palant.de/2018/07/09/is-your-lastpass-data-really-sa...
I don't think that's naive. A browser plugin is another component that you have to trust. But maybe you haven't considered all threats.
I use the Chrome password store. Copying passwords over clipboard seems quite unsafe to me. And I have to trust my browser with my passwords anyway, even if I use no password manager at all.
Of course, if you (really) control all software running on your machine, the clipboard is no issue. But I'm lazy and don't have the time to read all source code and compile everything myself.
The downside is that I've considered changing to Firefox as my primary browser a couple of times, but the passwords make switching harder.
Some password managers like Keepass put the password into the clipboard only temporarily. And their Auto-type actually splits input among simulated key presses and clipboard data.
This is what I use. Although it is not perfect, it does require an exploit targeting it specifically. Until it becomes a de facto standard, I would expect this type of exploit to be found largely in targeted attack on an individual or specific organization rather than in a broadly sweeping virus.
There is an air of arrogance to the article that isn’t explained. Why is the implementation so weak and how should it have been done? Or rather: are passwords at risk? Is there an actual possible attack? Is this explained already and am I missing it?
As mentioned in the article, I'm bad at reverse engineering. I merely point out the massive attack surface, and I'm pretty certain that this can be misused into infecting users with malware. But that's up to other people to prove, I'm not going to sink more time into this that nobody is going to pay for.
How it should have been done: stay in the JavaScript sandbox for all the logic, rely on the browser's existing functionality, use an absolutely minimal communication interface to the application.
Yes, bug bounty programs usually dislike being told about inherent architectural issues. So far I've only come across one where all security-relevant feedback is welcome: Mozilla. Which is exactly why I'm not submitting this via the bug bounty program. This way it's far more likely to reach somebody who is responsible for the code.
In essence that's what I do, except with a Keepass file in OneDrive. It's been working pretty well for me the last few years. Not sure how insecure it is, though. I imagine it'd take someone cracking my OneDrive password to gain access to the Keepass file which they'd subsequently have to crack. Assuming the passwords are of high enough entropy (mine are(I hope)), you'd probably be pretty safe.
It's funny they tell people to use different password for all sites except the presence of master password makes it far more vulnerable especially when people can be using weak password as they don't want to lose it.
If you are using a weak password, that's always a problem...
But a masterpassword for offline storage is a completely different story, because even if the world knew your masterpassword, they still couldn't do anything with it, because they need to get to your dropbox file first.
If you use similar passwords everywhere, any site can read your password and use it to login somewhere else... You are supposed to use long random passwords for websites because you have to assume that every single password gets compromised and the website you are on tries to hack all other accounts.
Depends on the length of your password, really, and how and where you enter it. All it takes is a keystroke logger to get your master password, and this can be done even with copy/paste.
Probably worse than my mom's LastPass setup, I think.
* Assuming your dropbox doesn't have every-login 2FA, you're missing on that. Relying on the master passphrase (notice I didn't say password) alone for anything is a bad idea imo. But I'll give you the option here of saying "yes, my dropbox has 2FA". In your case you have a dropbox password AND a master pass to remember. That's 2:1 right there.
* Next we have that your encrypted excel is zip encrypted last I looked - I could be wrong - but I at least thought that Office encryption was just them using zip. So that's vulnerable to an offline attack if someone has your file. Symmetric 256bit AES encryption (again, iirc) so it really doesn't matter how good your password is if 256bit AES isn't good enough for you. Compare this to an offline blob from something like LastPass that uses much stronger 1024 or 2048bit asymmetric encryption.
* Next, we have that your excel file when opened on some foreign computer is maybe going to sit in the %temp% folder until it's cleared. The entire thing will be clear-text in ram at once no doubt. Compared to you accessing LastPass or similar from a browser that's designed to clear itself after logging off and only one password is in RAM at at time (supposed to be anyhow).
* Small things like immediate access, organization, accessing on your phone... All areas that password managers will win no doubt.
* Almost done, but using a password manager will let you do things like "detect password change" on a site you're accessing and update that password automatically. It'll let you sign in to sights for the first time and auto-create a new entry. This goes a LONG way into keeping an updated and current list.
* Finally, in terms of just general security... I can open my pass manager and access a password without copy and paste, and without anyone standing over my shoulder seeing it, I can share to a non-secure friend or co-worker in a way that at least encourages good behavior and when I update it they get the new pass without me informing them. With an excel file you can reliably do none of those things.
That's not to say someone couldn't do it better than a pass manager. Just that I lead with my point. My Mom has a more secure setup than many tech people because she wasn't allowed to make any errors.
Is Dashlane guilty of the same? I'm curious as they require you to install a native desktop app before the plug-in can work, which presumably is farming out most work to binaries installed with the app.
I have LastPass installed and thought the binary component was only for native desktop applications and not for their extension. I do not recall installing any binary components for the LastPass Chrome extension, but it's been awhile....
It's worth noting that LastPass for a specific browser and LastPass for Desktop work differently.
On the LP FF or LP Chrome it's only listening to that program. On desktop it's trying to listen to all browsers at the same time and watching for other apps it recognizes.
It would make sense if LP Desktop had a broader attack surface.
They also have an extension (which is the default version on Linux/Chromebooks) that does not require the 1Password application. I have used it since the betas in Linux and it works nicely.
Also, this thread seems to imply that having a binary component is always bad. It can also increase security. If the extension is rate-limited in retrieving passwords from a vault, then a compromised browser can only extract a limited number of passwords, whereas with a browser-native extension the attacker could extract all passwords.
Yes, they use it because they don't know how to do the same things in JavaScript - without it you get very awkward import/export for example. Tavis Ormandy already demonstrated in the past that this binary allows turning an extension vulnerability into code running with privileges of the logged in user. So it's very advisable not to install it.
Man... now a days, it's impossible for a modern web app to not use JSON parsing. Can't see this as problem for a password manager. If you can't trust in the browser, you are dead. Ok, Kasp want to sell they fish, but, we need good arguments.
Installing any sort of critical closed source software related to security or privacy that could potentially be influenced by the Russian, US, Chinese, or any other government has always seemed like a funny proposition to me.
Nah, money is a strong motivator, and the sale of private information on the dark net is a lucrative world wide enterprise. How could you possibly know if one anonymous party has less of an interest to make money than another, simply because they're "foreign"?
Of course, serializing to HTML and parsing it out of the browser seems like a very bad idea. I suppose it was made this way because their neuronal network was written for HTML.
I wonder what made Kaspersky use a neuronal network to recognize password fields. It seems over-kill to me, but I may underestimate the complexity of properly handling password fields.