Platter technology will end up being pushed to the NAS/SAN, which is why WD is making their red line of drives.

Perhaps HDDs, now that speed and capacity are secondary, they will start evolving down the path of reliability, perhaps replacing tape as an archival medium.

NAS drives are going to be a big market, especially with devices like Apple's new MacBook with limited expansion capability, so people will use WiFi Direct hard drives as their main backup source, as opposed to USB drives. In this use, capacity is limited on the MacBook, and speed is limited, so drive makers (hopefully) will end up working on leapfrogging each other for reliability and security.

I have a third option: An admin passphrase that is a lot longer than my user passphrase, but had more retry attempts. That way, if the short passphrase gets typoed, I can still unlock the device with the admin one.

You are right about backups... that is why I have three of the USB tokens, just in case.

Had a similar choice when giving a laptop to a relative. I went SSD instead of SSHD because SSDs are physically more resistant to shock.

However, if given the choice with a desktop... I'd probably still use SSD, just because when I delete a file and fstrim the drive, the file is -gone- for good, since the drive controller will come around, write "1"s to all the pages that file used and call it done. Of course, keeping good backups when using SSDs is wise, just due to this exact thing.

I wonder if the ideal password manager would be one that would use a typed in password as a seed/IV (hash a seed and the sitename), with exceptions stored for sites which don't allow passwords generated with that tool to work. Some sites require a number, a capital letter, lower case letter, a symbol (well, not all symbols work), or some other random, annoying combination of the above.

Of course, the ideal password manager would store the password database with a master volume key, then each device accessing it would have the MVK encrypted to its public key. This way, if someone wants to add a device, they just allow access on another device. If someone wants to remove access, it is doable, but it would be wise to re-encrypt the DB to a new key for security. This is how PGPDisk did its encryption, and it completely deters brute-forcing, should someone get access to the data stored on the cloud, since there is no password, so the attacker has to deal with the entire key's keyspace.

Since the private key is on the device, the user just needs a PIN to unlock (with a timeout after too many wrong attempts), rather than a longer passphrase. Both iOS and Android have secure storage (KeyChain for example) which makes this easy to implement securely.

I prefer 2FA when possible. Even a very tough password means nothing if by some means, it gets sniffed by some keylogger, or the password database on a cloud provider gets brute-forced.

For storage where one is using a passphrase for encryption, as opposed to authentication, I like using cryptographic tokens. TrueCrypt used to work with a PKCS#11 library so I could store a keyfile on a set of Aladdin/SafeNet eTokens. This not just made the key immune to brute force guessing... someone who physically possesses the token has three guesses of my unlocking passphrase before the token locks itself forever and zeroes out the stored keyfile. This also works with Symantec's PGP version, except that generates a public/private keypair, the private keypair always remaining on the token, while the public part is used for the file/drive encryption.

If 2FA isn't possible, then as above, some mechanism to help with password reuse is very wise. This is useful just in case some website decides to store passwords in plain text, so a person's secure "correct horse battery staple" is now compromised and added to every blackhat's brute forcing library.

All consumer level ones are that shitty. Time Machine does have some OS level protection, but most just dump data to an external drive. Overwriting the files or just a format of the filesystem can easily destroy that backup.

Windows Server Essentials 2012 R2 has "pull" functionality to grab data from desktops. Another utility is Retrospect which can have a client installed on desktops.

Of course, the ideal would be a backup appliance like an EMC Avamar that deduplicated. Think Time Capsule, except that the appliance initiated the backups, stored them securely, and did the deduplication. Add decent disk encryption (perhaps a startup password or PIN entered on the appliance's webpage to mount the backup drives), and this would help versus malware.

Most backups would be erased or encrypted by the ransomware. The problem is that people think in terms of disk failures or hardware failures, so have their backup solution based around this. Just this in mind, going with two SANs that replicate with each other asynchronously is the best thing to do, since the data is always available.

However, this doesn't factor in software designed to corrupt/encrypt backups over a long haul. This is going to take a dedicated backup server that pulls backups and stores them in a place where a machine cannot access (and thus tamper) with stored data. It also takes a long data retention policy, just in case.

However, in a lot of places, backups are like security -- they are viewed as having no ROI, so at best, you might get some mechanism to stash stuff on disk, but if a machine can back up to the disk directly, it likely can erase/modify stored data.

One scenario that I worry about with cloud providers is exactly this. The provider goes bankrupt, sells all data to someone else, and they now have all the servers and can use the container information, free, clear, with nothing the clients of the former cloud provider able to do about it legally, barring copyright violations.

Both Borders and RS both show a lesson -- yes, there is a privacy policy with company "A", but when the servers get under the ownership of a new company, that policy is out the window, and the data can be used for anything that the new owners desire. Multi-TB torrent? Perfectly legal.

If a cloud provider changes hands, I can see a new company digging through data just to extort people. Say they find a sex toy maker's customer list on a server. They can then send out a note that all customers of this maker will have their named published unless they "buy into" a privacy policy (removing the name from the list) for the low price of $99.99. Since the new company 100% owns the data, free and clear, this is perfectly legal.

http://goo.gl/z8ti3D

From a root command line, you can do:

vdc cryptfs changepw newpass

(where newpass is your new password for the dm-crypt volume... which is your /data partition.)

There is also apps that do this as well, but you need root.

Of course, when you change your screen lock PIN, it will change the boot password, but that is a given.

Those are some good suggestions. I might add a few myself:

1: If your device is rooted, you can separate the password that unlocks the /data partition from the PIN that unlocks the screen. This way, you have 4-5 digits that are quickly typed in... but if a thief decides to reboot the phone or power it off, they are facing the 20-30+ character passphrase... and most newer Android ROMs only allow 30 guesses before they do an erase.

2: Enable encryption of the /data partition. This is worth mentioning.

3: There is an app that will detect if the power button is pressed six times quickly, and send out a duress code. Forgot the name, but might be worth having.

4: Some ROMs will do some form of encryption on the SD card. If not, you can get an EncFS app, or BoxCryptor (which is a commercial/subscription version that uses EncFS as its base.)

5: Consider a backup program like Titanium Backup which uses a very reliable encryption mechanism (it uses a passphrase for a private key, and uses a public key for backups), and can save the encrypted backups to a cloud provider.

6: Consider a utility that requires a PIN to access some apps. For example, the app for a terminal and other rooted apps on my Android phone is PIN protected, FB and other apps are under another PIN, etc... so if a bad guy gets the phone while its unlocked, they might have access to the Web browser, but not the other parts. If they reboot the phone, they are faced with a very long /data encryption password as stated in #1.

That's not the point.

Terrorism isn't about making the statement "We can hurt easy targets". It's about the statement "we can hurt any target."

The World Trade Center was a giant building. With control of a plane, it would have been easy to hit. The terrorist aspect is that the hijackers interrupted a regular normal daily routine to commit their chosen atrocity. Now, it's doxing. ISIS is claiming that they have supporters in the US who are willing to kill anyone with a name and an address.

Sure, they've picked a few soldiers now, but the subtext is that their targets could be anyone. A few articles later on the front page, there's discussion of video gamers calling in SWAT raids. 4Chan makes a point of identifying anyone for any reason for the fun of it. Anyone paying enough attention to understand what ISIS is threatening today knows that they could end up a target next week, and it's probably too late to scrub their records from public systems. There is no defense against the doxing, and if ISIS really does have a hidden network of bogeymen in the United States, there's nowhere to hide.

That's the real message ISIS is saying here: You could be next if you piss us off. Bow in fear, praise our particular flavor of deity, surrender all of your free will to our self-interested leader, and so on and so forth.

Your "gut feeling" is also often wrong, but you don't notice because of your confirmation bias.

The paranoia's adorable, but here in the real world, everything I do is a balance between risk and reward.

Sure, our data could be sold off, but that's what contract lawyers are for, just like any other business deal. Sure, I risk a malevolent company holding my data hostage, but even at increased prices, it's still cheaper than handling the data myself. Sure, I could be using the same rack a terrorist uses, but he could also be renting office space in the same building we use.

My company could, of course, buy its own building, own its own servers, manage all of its own data, and run all of its own processing... and then promptly go bankrupt, because the cost to do that is too high for the extremely limited benefit.

Well, yes...

The problem is that we don't know what the problems will be. Today, Network neutrality is the hot-button issue the FCC is finally forced to deal with, but tomorrow, who knows? Maybe we'll have to have regulations on compliance (or not) with encryption-busting wiretaps, DNS hijacking, advertisement injection, or something completely different.It's taken long enough for the FCC to move on this that we've already had a few cases of effective extortion by an ISP, and maybe those issues will be even more problematic.

The solution, then, is to bring the FCC in as an advocate for the American citizen, since that's pretty much the government's primary job. This establishes a process where the FCC can say "You're not breaking rules now, but you're getting really close" and give the ISPs a chance to avoid sinking investment capital into systems that will be outlawed as soon as people notice. Cooperating with regulators, especially by asking permission rather than forgiveness, is also a great way to reduce future penalties if the FCC's policies do turn against them.

If the ISPs' new business models don't piss off the FCC, then they don't have to worry about new regulation in the short term. Only ISPs with predatory business models to hide should be worried.

Not quite the same ring to it...

The upside is that my problems are now someone else's problems.

I no longer need to manage my long-term backups for my team's projects. They go off to a cloud provider, and if we really need something, we can get it back, and I don't have to worry about keeping tapes or disks around, and I don't have to be the one going through the library to find some old media. Data is encrypted prior to archival, so privacy isn't really a big deal.

I no longer have to worry about constant availability. If my local servers go down for a few minutes, maybe a user will notice. If they're down for an hour, I'll probably get an annoyed email, but I will get that email because our constant-availability services are hosted elsewhere.

Now, I do still have local servers to manage. I do still keep a decent number of nines, and I do still make my nightly backups, but I don't need to be managing every aspect of every problem. I can push that responsibility elsewhere, and make my workload more manageable without bringing on significantly more risk.