Cloudflare and passwords leaking

[Gulliver]

Greetings.

We are a relatively small organization and have just under 450 staff. Certain staff members (finance, personnel, legal etc.) use AxCrypt 1.7 to encrypt sensitive files.

We’ve not made the move to AxCrypt 2, even though it’s more convenient and supports AES-256, for two reasons:

1) You don’t allow self-extracting files (or some ‘safe’ alternative)

2) Your reliance of SSL to protect our password, and ultimately, our company documents

I heard today from a friend who works for Google that they’ve got a massive cache of extremely sensitive data (including passwords!) leaked because of Cloudflare’s ineptitude. These were publicly searchable for months… Google have now purged them from their public search engine but there’s no knowing who has got what.

Neither I nor my organisation trust SSL because we know it’s routinely subverted and we’d prefer the option to have a password which is never transmitted to a server.

Does AxCrypt use Cloudflare? If you do then you’re likely to have been caught up in this.

Will AxCrypt move towards not requiring the user to send their password to a server?

1Password have already been caught out lying about the security of their product by Tavis Ormandy (who discovered the vulnerability) after they issued a “confusing” statement (a charitable description) suggesting that data had only been vulnerable for days … yet it’s actually affected users for months. Google have their cache to prove it. 1Password backed down. And this comes just days after the company messed up  (and tried to blame Apple) their developer’s certificate acquisition.

As irony would have it my colleagues in procurement had been looking at 1Password. As a result of this vulnerability, and their bending the truth, I have dissuaded them from taking our business to them. At $11.99 per user, per month ($5,395.50 per month) that’s a lot of money for an insecure product.

We would, if AxCrypt move towards a secure non-SSL based model be interested in purchasing AxCrypt premium for the staff that need file-level encryption so I’d like to know if this is being considered and what any timescales look like.

[SvanteSpectator]

Hello Gulliver,

You pose some relevant and interesting questions.

Let me first state that AxCrypt does not use Cloudflare, or any similar service. We try to keep the number of components and services used to a minimum, partly to minimize the attack surface.

We try to be very open, in fact all of the core encryption code and the entire Windows Client is published as open source. We also physically separate our content server (www.axcrypt.net) and our account server (account.axcrypt.net) also so we can keep the server with user data as “clean” as possible.

Although we could manage most functionality technically without requiring password authentication over the Internet, some services we could not. What we have done is to actually take a decision – we *do* trust SSL. Although like any protocol it can have bugs, and there are known cases of various vulnerabilities being exploited, it still in protects much of the web. Also, most of the exploits require code injection (typically by way of physical hardware appliances) into major ISP communication centers. That’s beyond the scope of essentially all attackers except governments.

To me, it sounds a little strange that you would prefer to establish routines which involves recipients of encrypted data to click executables sent to them (self-decrypting files), while being worried about SSL security. To me, using self-decrypting files, and especially asking others to routinely expect to receive such files, with the added complication of communicating the password to the file over a *more* secure channel than SSL, does not make “security sense”.

Advocating users to click attachments to run executables is a perfect way to create a huge attack vector to your users.

How do you communicate the password to the files between users? If you are in the same office, I guess verbally in a secure room with all phones and other equipment with microphones physically turned off would work. But remotely? More securely than SSL?

Anyway, we are certainly considering a mode of operation where passwords would never leave the users computer, but it will limit and complicate things in many scenarios.

For now, we actually do trust SSL.

[Gulliver]

Thank you for your reply Svante.

Not all our staff need file-level encryption (all our systems use Microsoft BitLocker in case the hardware is stolen) but for those people who need to share files they use AxCrypt.

Some of our clients need confidential documents sent via email and we insist that they’re encrypted to protect us and them. We’ve suggested encrypted zips but not all of our clients will install third-party software. Because Windows compressed folders uses weak ZipCrypto it can’t decompress AES encrypted zips. They’re happy accepting encrypted EXEs. For the same reason they wouldn’t install AxCrypt 2 portable.

The relevant department have their own password manager with client passwords stored in; that’s a password that the client has agreed in person or split 50% over the phone and 50% via secure text (like WhatsApp). The department password database is backed up to our servers.

Our systems prevent external devices being connected, like flash drives, so there’s no chance of a rogue file being introduced by that method. We have UTM appliances which controls inbound and outbound access along with general firewalling of the network and virus protection. We allow executable files to be sent internally and externally although we’ve configured our rules to block inbound EXE files. We host our own Exchange services on premises.

It’s good that AxCrypt aren’t using Cloudflare and between me posting my original message, and me replying, I found this list of presently identified affected domains (it’s a work in progress and being updated as and when Google release more details).

https://github.com/pirate/sites-using-cloudflare

It’s a huge list and I had to use Vim to open the text file.

[Author]

Posts