How secure is Google Chrome Sign In?

I’ve been avoiding Sign In feature for quite some time now, up until today, because security with major service providers, that are also legitimate businesses and often are not open-source, seems always to be tricky. I realized I couldn’t hold back any longer, though, because the temptation to use synced data — and Chrome/Chromium syncs basically everything and lets you recreate your browser environment on just any computer/mobile device with the Internet connection and default browser configuration — was becoming very intense.

So, I’ve ran an extensive search on Google, but there were very few detailed results that would give you the dirt. Mostly generalized statements about how secure or insecure it is. Luckily, though, some peoplewrote up excellent articles that answered my questions and made me feel confident that I can safely upload my personal data to the cloud.

Because bottom line is Chrome/Chromium Sign In feature provides a very reasonable security model.

In short, the solution is to encrypt everything and use encryption passphrase, not Google Account as a passphrase (this gets sent to Google periodically and kinda defeats the purpose, because theoretically unscrupulous/overly enthusiastic employees literally have the key to your encrypted stash of private data and could read it if they really wanted to. Not cool.)

To learn more details I highly recommend to follow these URLs and read these wonderful articles:

  1. Comparing the Security and Privacy of Browser Syncing by Gregory Szorc with Firefox who happens to work on FirefoxSync (this is exactly what I hoped to read, a fresh publication too!)
  2. How to Optimize Google Chrome for Maximum Privacy by Chris Hoffman of How-To Geek.
  3. Google Chrome Leaking Credit Card Data? by Adam Caudill, a demonstration of why you need to encrypt everything, not just passwords.

OSSEC Active Response E-Mail Notifications

Here’s a very nice page that describes how to set up OSSEC active response e-mail notifications.

There’s one problem, though. In current OSSEC version 2.6 that configuration will leave you with AR rule, if once triggered, staying in loop forever. For example, if a common web attack is detected and you’ve configured OSSEC to respond with firewall drop AR, upon the timeout the offensive IP address will be deleted from the firewall configuration and re-added immediately after that. Thus, this cycle will continue endlessly.

Continue reading

Delete files on Linux securely

I want to make one thing clear. You need to use multiple overwrites strategy ONLY when you’re dealing with a file, or a bunch of  files, size of which doesn’t equal capacity of the storage device. Multiple overwrites strategy is a legacy approach that made much sense back in the day, and to some extent today too, but largely it took on a size of an urban legend.

It’s true, though, that  if you want to completely destroy a single file you should rather use this multiple overwrites strategy to stay on the safe side. There are a couple of reasons for this is, one would be that, theoretically, underlying storage device logical addressing system (LBA) could remap sectors with data (think bad blocks recovered by hard drive semi-intelligent firmware known as error correction mechanism) to some other place and thus remains of the files, or sometimes even copies could be found on the drive despite the fact that the file(s) was deleted.

Keep in mind that in most cases recovering these remnants is not a trivial task, so if your adversary is your girlfriend or geek friend with mild degree in Geekinness, you may consider yourself reasonably safe when deleting files with rm. If you’re up against cyber police or underground hackers perhaps it won’t hurt to use the method described in this post down below.

Also, please note, that on SSD drives multiple overwrites strategy should really be embraced due to the technical design of this type of storage device (read more about it in stackoverflow thread).

Bottom line is, if you need to destroy all data on a drive you don’t have to overwrite it multiple times, just once will be enough but ONLY IF you’re sure you’re overwriting every single sector on the drive (think dd if=/dev/random of=/dev/sda). It won’t hurt but you really shouldn’t.

Here’s a nice starting point if you’re interested in deeper details of the discussion:

Here’s the deal, in most cases, on most popular distributions, on most standard Linux setups removing a file via GUI file manager or in your terminal window, including by rm command, isn’t secure at all. A file removed in such a fashion can be relatively easily recovered.

If you’re donating your old computer to a younger sister and don’t want to blush when she recovers your Inkscape drawings of  Pokemon characters and posts them up on Facebook, you need to know how to delete those files for good. Securely, so that not even Interpol can recover them with expensive hardware.

If you doubt how much this is serious, google “securely delete file linux” up and look at the numerous warnings written by many people all across the web — rm is not enough!

Even more, the filesystem type and its options may prevent you from successfully deleting a file for good even with shred. So, how do we do it?

shred is the command line utility that does the job. There are a few interesting command line options that are often omitted elsewhere on the various pages on the Internet.

Continue reading