Follow

So I looked into this Scirge extension.

The good news: I don’t see any attack surface here, it’s safe.

The bad news: As I see it, the extension is essentially corporate-mandated spyware, capable of extracting users’ login credentials for any website and probably more.

Which credentials are logged is determined by a list of policies downloaded from the corporate Scirge server. The policies are determined by the server admins responsible at their sole discretion.

Passwords logged go through SHA-1 hashing, this offers almost no protection.

What makes matters worse here: there is zero transparency. All server communication is encrypted using public key cryptography (yes, in addition to TLS). This serves no purpose privacy-wise but provides quite efficient obfuscation.

Ah, Scirge website actually mentions them storing passwords in the database:

“only industry standard secure hashes are stored at the Central Server database”

Yes, calling SHA-1 “secure” is one way of looking at this… 🙄

Thanks to @varx for the discovery!

@WPalant It looks like an interesting product, and *could* be handled in a reasonable way (depending on what privacy balance you want to strike). But hashing and storing passwords with SHA-1, that one thing—that tells me volumes about the product. Not good things.

@WPalant Unrelatedly, I'm amused at how their website looks with Javascript disabled.

@varx They can and will collect quality scores for the passwords used. Presumably, their corporate customers don’t consider this sufficient and want to flag known leaked passwords in addition. Makes sense on one hand but is horrible privacy-wise. Especially given how the majority of employees is known to use their private accounts on work machines.

I also assume that this public key based obfuscation is meant for communicating with intranet servers that don’t have SSL set up. Makes sense if all you worry about is passive listening.

@WPalant Yeah, I just found this in their marketing material: « Passwords are hashed locally on the endpoint, so their cleartext form is never sent or stored anywhere else—only industry standard secure hashes are stored at the Central Server database, so password reuse, password sharing, or the use of already breached passwords can become visible to your security departments. »

Calling SHA-1 "industry standard" for passwords is cringe and I would argue even legally actionable false advertising, but it does suggest that they're checking against Pwned Passwords, which is all in SHA-1 and NTLM.

Except... they could be doing that lookup on the client side, right when they do the algorithmic quality checks. Call the Pwned Passwords k-anonymity API, get the "how bad is this password" number, include that in the report.

@varx They probably want more control over this. Like, “what if we learn about a leak later, how do we find affected passwords retroactively?”

@WPalant Ugh, yes. I have very little sympathy for people doing personal stuff on their employer-provided and -managed computer. Expectation of privacy there is *very* low. (I keep a directory called "personal" for my few exceptions such as printing tax documents at the office, which I think has a slightly higher expectation of privacy, but I don't put my faith in it.)

Much worse is people using their work *email* for personal stuff—because 1) it's already stored in a place IT can search automatically (without using spyware), and 2) it's not portable when they change jobs. In the case of Scirge it becomes a deeper privacy violation because it means Scirge would be harvesting personal passwords.

(They're only collecting passwords that are paired with a work email address, right?)

@varx I don’t think so. They will collect any account credentials if entered on any website that policies apply to. There is an is_collecting_password policy flag that will collect only passwords and is_collecting_account that will collect additional info as well. And given that policies can be regex-based, they can simply blanket-match all websites.

@WPalant Hmm, I see. Something in the marketing materials made it sound like it was just based on email address domain names, but I see from docs.scirge.com/user-guide/3.5 that there are several types of configuration you can use.

Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.