Why I created Underscore Backup

I started running a server for storing all my projects as well as various multimedia artifacts in 1999 with a small desktop computer and a 20GB HDD. As the size and personal importance of this server grew within a few years I started running RAID5 and then RAID6 to make sure data was not lost from single drive failures. Despite this, in 2006 the current incarnation of this server encountered a catastrophic 3-drive failure which I only managed to recover from after a tremendous amount of work and a fair amount of luck which included among other things manually patching the Linux RAID kernel code to remove certain fail-safes as I pulled data off the partially assembled RAID.

"The Server" in its current iteration.

This episode led me to look for ways to safeguard against this ever happening again. Looking through what options were available to me I found Crashplan which did address all my needs at a reasonable price. My initial backup to Crashplan took several years to complete over my 20mbit/s broadband uplink as my server had at this point grown to several TB.

A few years after I started using Crashplan they stopped offering consumer backups and the only way to keep using them was to migrate to their business plan which I did. However, Crashplan only allowed you to migrate a few TB per computer at the time which meant that I had to re-upload most of my backup again. Fortunately, at this point, I had gotten a fiber internet connection with a reasonable uplink that allowed me to re-upload this data in less than a year. As my backup of this server grew Crashplan also started showing its flaws where it required several GB of memory to be able to back up my server, but it did work and allowed me a reasonable peace of mind for the contents of my server.

This went on for a few years after which I was contacted by Crashplan (Now called Code42) and told that unless I reduced the size of my backup to under 10 TB, they would terminate my account since they considered me violating their terms of service by keeping too large a backup.

From: Support Ops (Code42 Small Business Support) 
Date: Feb 6 2020, 10:38 AM CST 

Hello Administrator,

Thank you for being a CrashPlan® for Small Business subscriber. We appreciate the
trust that you have placed in CrashPlan - that relationship is important to us.
Unfortunately, we write to you today to notify you that your account has
accumulated excessive storage, which will result in degraded performance. You 
have one of the largest archives in the history of CrashPlan. It is so large, we
cannot guarantee the performance of our service. Due to the size of your
archive, full restores of your backup archive, and even selectively restoring 
specific files, may not be possible.

As a result, we are notifying you, per our Master Service Agreement and
Documentation, to re-duce your storage utilization for each device to less than
10TB by June 1, 2020. Note that we have extended your subscription to June 1, 
2020 to give you ample time to make changes. If you do not do so by June 1, 
2020, your subscription will not be renewed, and your account will be closed at
the end of your current subscription term.

…

Thank you, 
Eric Wansong, Chief Customer Officer, Code42

The server I was using was Linux based and as far as I could tell Crashplan was the only competitor on the market providing cloud-based backup solutions for that OS. This was when I decided to start working on Underscore Backup as a means for me to continue making backups of my server as I couldn’t find any existing alternatives that fulfilled my needs. The first version was command line only and very primitive even though it did support point-in-time recovery, backup sets as well as obviously efficiently handling my very large backup. Another feature that was built in from the beginning was a strong focus on encrypting everything as much as possible so that any medium could be used for backups even if it was not properly secured from prying eyes. Creating the initial backup of my server using Underscore Backup used a more or less sustained 600mbit/s (To be compared with the at the time impressive 60mbit/s that I experienced using Crashplan on the same connection).

At the same time, I also started using the iDrive service for backing up my laptops and various other smaller Windows and MacOS based machines. I did this because I didn’t think the CLI (Command Line Interface) only implementation of Underscore Backup was just not convenient enough to be used on these machines). This situation continued for a few years when the CLI-only version of Underscore Backup backed up my server data to cloud block storage and my other machines were backed up by the iDrive service. This all came crashing down when my main development laptop of several years had a catastrophic SSD failure and I had to restore my data from iDrive. I found out two things about how the iDrive service works.

The first is that even though iDrive keeps track of versions of your files they do not keep track of directory contents and deletions of files. This is critical to any developer, and I restored a large developer repository with files that I have been working on as I have been running iDrive in the background. For those of you who are not developers, we rename files a lot. And every one of the old names of all my renamed files was restored back when I did a full restore of the contents of my laptop’s hard drive. That meant, that any repository of code that I had basically worked on since I started using iDrive was no longer in a buildable state without a considerable amount of work.

The second surprise to me was that even though to me the iDrive backup of my laptop was relatively small, only around 50GB in size it took almost 2 weeks to restore. Granted it contained a large number of files (Around 3 million, mostly small, files) but I was shocked at the slowness of its performance. I also opened up several support cases with iDrive about this but it was nothing they could do to help me. For comparison, on the same network with roughly the same sized backup in both files and total storage Underscore Backup would complete a similar restore in about 5 minutes (And it would do it properly keeping track of deleted files).

At this point, I evaluated other solutions available but could not find any that would be suitable for my needs. Carbonite does not allow you to specify what files should be backed up but instead in the interest of simplicity tries to be smart about it, when I tried it on my development files it decided to back almost none of them even though I specifically said to include the directory. Backblaze is a very solid solution but also does not keep track of deleted files for a true point-in-time recovery same as iDrive. In the end, I decided that I would put in the effort needed to create an easy-to-use user interface for Underscore Backup so that it would be suitable for use on things other than servers. The end result of these efforts was the first stable release of Underscore Backup in the summer of 2022 and which at that point graduated to be the only backup solution I used on all my computers.

The problem at this point though was that even though I had a backup solution that fulfilled all my needs it was still very tricky to set up for most users since to use it you generally had to supply your own cloud storage such as Amazon S3. It was also quite tricky to access data from other sources you had backed up since every source had to be set up individually on each client you wanted to restore the source on. The sharing functionality, even though present was also so complicated that I am relatively certain nobody managed to set this up except for myself. To solve all of these problems I decided to leave the service-less nature of the software I had followed up until that point and create a service to both remove the need to provide separate cloud storage and also help manage multiple sources and set up shares. This was a relatively large undertaking, but it eventually led to the launch of Underscore Backup 2.0 in the first half of 2023.

This current release as of this writing is the upcoming 2.2 release which has made it very easy to set up backup of multiple computers of any size while staying true to the original guiding principles of security, durability, efficiency, and flexibility.

This post was cross posted from the Underscore Backup blog.

Announcing Underscore Backup 2.0 and service general availability

First stable version of Underscore Backup with support for the companion service is now available. The service itself is also generally available.

Even with the new service, the main focus of the application is privacy, resiliency, and efficiency. The new service does significantly simplify setting up cloud backups and sharing though compared to use

The main new feature in version 2.0 is the introduction of a companion service that will help with many aspects of running Underscore Backup such as.

• Keep all your sources organized in one place to easily restore from any of your backups to any other backup.
• Help facilitate sharing of backup data with other users.
• Optionally allow private key password recovery.
• Easily access application UI even if running in a context where a desktop is unavailable, such as root on Linux.
• Use as a backup destination. Storing backup data is the only feature that requires a paying subscription, giving you 512GB of backup storage for $5 per month.
• Support multiple regions of data storage supporting North America (Oregon), EU (Frankfurt), and Southeast Asia (Singapore) regions to satisfy latency and data governance requirements.

On top of the companion service changes, the following features and improvements have also been implemented.

• Added support for continuous backups by monitoring the filesystem for changes.
• Introduced a password strength meter which requires a score of at least “ok” when setting up.
• Switched from pbkdf2 to Argon2 for private key hashing function.

On top of the companion service changes, the following features and improvements have also been implemented. Get started by downloading the client now.

Launching Underscore Backup service and first beta of the version 2.0 of Underscore Backup application to use it

Finally launched the first public release of the Underscore Backup service. A backup service that is a companion to the Underscore Backup application I have now been working on for a few years. I am really excited about this since adding a service component to the application solves a couple of user pain points with my previous releases, such as.

• Its now easy to coordinate and keep track of multiple sources so you can easily restore data from another computer you are backing up.
• It comes with the ability to use the service for storage so that you don't have to deal with configuring S3 or something similar. The storage also supports 3 regions in the US, EU and the Asia Pacific region and is priced lower than S3.
• It makes it easy to set up sharing between users.
• The service can provide optional secret key recovery.
• You can easily keep track of where the administration interface of the application is available even if the application is running in a context that does not have access to your desktop.

There is also a ton of other additional features included such as improve password hashing algorithms, log rotation, integrated password strength meter and built in new version notification.

You can head to the site to download the latest version and sign up for the service. The service is entirely free, however you do need a subscription for using storage as detailed on the pricing page.

Building for high availability: Security

Courtesy www.bluecoat.com I have a plan on doing a series of concerning things to think about when designing, building, and operating systems and services with reliability and high availability in mind. I will focus specifically on building services on a cloud services and my examples will generally be AWS, because that is what I know best. But most of the general principles should translate to any cloud provider of sufficient minimum functionality.

It is worth pointing out that the advice here is specifically for reliability and high availability. If, for instance, your goal is to be able to do rapid prototyping or being able to quickly go to market the advice would be very different (Perhaps I will do another series of posts on that once I am done with this topic). Sometimes it can be hard to explain to your Product Manager that even though somebody created a working prototype of something in less than a week it will still take 2 months to create the real thing, and this is one of the reasons why. As a preview of the difference between the two is that you can skip this entire section if you are only creating a prototype because security really does not matter for that (But be wary of the risk of the prototype making it to production, because then you would not have wanted to have skipped it).

There are many different things that can affect the availability of a service or site that you are building but probably the first and most important one is to make sure that your site is secure. Other failures, although severe would not result in the kind of disaster that a security failure could lead to. Not only could your entire service be taken offline or deleted, but all data you have stored could also be let loose on the dark web.

Defense in depth

The key for designing for security is defense in depth. You should not assume that you can establish a perimeter around your service and trust everything inside the service. Instead, you should consider how you can make each subcomponent as secure as possible. This will mean that if one of your components do get compromised it will not necessarily mean that your entire service or all your data is compromised. Additionally, by having each component always validating and logging access appropriately also means that any potential breach in one component can be detected earlier when an attacker unsuccessfully tries to extend the breach to other components.

The Least Privilege Principle

Each component should only have the minimum privileges needed to perform its job. If you have a component that needs permission to read a specific S3 bucket to perform its job, only grant read access to that specific bucket and not any bucket in your account nor allow it to do anything but reading from S3. Same thing goes to database access. This way if a component does get compromised only the data available to that component is potentially put at risk instead of all the data in your service.

Avoid fixed credentials

In AWS, most services allow you to grant permissions based on your execution environment such as EC2, ECS or Lambda execution roles without the need to distribute any credentials. This is a great feature that avoids the possibility of any credentials being lost in the wind and turning up in the wrong places.

If you do have to use fixed credentials such as to a RDBMS, then make sure that these credentials are automatically rotated often so that for instance ex-employees will not accidentally retain credentials to your systems.

In the case of AWS make sure you take advantage of the strong authentication options for the AWS console. And heed the advice of never using the root credentials for anything.

Limit your attack surface

Do not have any component of your service available from the internet that does not absolutely need to. Usually this would mean only your public API and your website being accessible through the internal.

Make sure that all your internal components are only available to the other internal components that need to communicate with them. In AWS you can accomplish this either through internal API:s inside of a VPC, or you can use AWS secured primitives to communicate between components such as queues or event buses.

If you need to be able to get access to the internal network for operational reasons make sure that all this access goes through a Bastion hosts that is truly locked. In AWS consider not using a Bastion host at all and instead rely on the System Manager Run & ECS Exec functionality to avoid the bastion host all together.

Avoid managing your own infrastructure and have a patching strategy

Using managed versions of almost any services means that when there is a problem with that service it is not your problem to fix it anymore, instead there is a specialist team available to handle the issue and you can just sit back and wait for the issue to be resolved. Granted, it does mean that you lose some control. But general the headache of needing to have a specialist on hand for every component you use in a complex system. It also means that for every component you have you need to have a comprehensive upgrade and patching strategy. In today's environment you must be prepared to be able to patch within hours of a critical vulnerability if not sooner or risk complete compromise of that component as evidenced most recently in the massive Exchange Service hack that has compromised at least 30k corporate email servers. If you are using managed services for your components the headache of patching, especially security vulnerabilities, is entirely handled for you.

This also extends to trying to use alternative methods of compute such as AWS Fargate and AWS Lambda to remove the burden of patching any OS that you are deploying your code on. That said, you are still responsible for patching your own code and making sure you are not relying on libraries that have known vulnerabilities in them. Using the Github code repository will provide you with automated vulnerability scanning for your code though if you are using standard dependency managers.

Encrypt everything

Always encrypt everything you save both in transit and at rest. Any intra component communication should always use TLS. Almost all AWS primitives that store data will have an option to encrypt data at rest using your own provided KMS key or at least a service owned key. Quite often though this functionality does need to be turned on explicitly, make sure you do this. Furthermore, make sure that the access to the keys for data that is sensitive is only provided to the components that need it. This is an extension of the Least Privilege Principle above. If an adversary does break into your system, this is another way that you can minimize the amount of data that is accessible and exfiltratable.

Pick the right tool for the job

When building a new system, it is important to pick the right language and framework because some are simply safer by design that others.

The first kind of language that is unsuitable is any language that contains unchecked primitives for direct memory access. This group includes languages such as C, C++ and obviously assembly language. The main danger with these kinds of languages is that it is just too easy to make a mistake and create a buffer overflow issue.

The second kind of language and or framework to avoid are languages that do too much "magic" to help you be productive. Most frameworks that involve Ruby or PHP fall in this category in my opinion. Not only do these languages lead to hard to maintain code, because it is very hard to understand the real ramifications of a change. Because so much is happening underneath the hood that you as a developer are probably not aware of, it is very hard to ensure that this "magic" is not doing something that will also lead to a security vulnerability.

Languages that I generally find suitable for building internet facing services include Java, C#, Python and Typescript. This is not an exhaustive list though and there are many more.

Avoid SQL

This is really a special case to call out in this section. The tip to avoid RDBMS:s will come up repeatedly during this serious of blog posts because they are generally not suitable for building high availability systems for many reasons. However, this specific tip is not specifically about RDBMS:s but about using any kind of database with the SQL query language. Regarding security, probably the most common reason for security breaches today is still SQL injection attacks and this kind of attack is only possible if your underlying database access language is SQL. There are almost always better choices for databases than SQL for your specific use case. Educate yourself on your options and pick anything that is not SQL. By doing this you also have the added benefit of removing even the possibility of being the target of this entire class of attacks.

Various other security related tips and tricks

This section contains some additional tips and tricks that might be more AWS specific for helping you to build secure services.

Be wary of deleting

Some cloud primitives such as S3 related to storing data allow you to not be able to delete or overwrite data. If you enable versioning in S3 and remove the permission to delete data, all together and instead use life cycle rules to expire data you can remove the threat of ransomware all together from that portion of your system. Similarly enable deletion protection to all other aspects of your infrastructure if available such as Cloud Formation stacks. This will protect you both from intentional vandal acts, but also unintentional accidents that could potentially take down your service by accidentally deleting critical infrastructure.

Safety of a crowd

When implementing your service perimeter take advantage of a managed components that sit between your service and the internet to protect yourself against both carefully crafted payloads designed to attack your service and also being able to weather the massive load of a DDOS attack. Examples of these kinds of services is not just AWS WAF, but also services such as Amazon S3, Amazon CloudFront and Amazon API Gateway. This does not include services that are simple load balancers though as these generally are provisioned to handle a single routing task explicitly and even though they do scale, it is at a slower rate and they also generally do not protect you against any kind of malicious payloads as the other services might.

Limit internet access from your components

Assuming the worst, that an adversary has broken into your system, one way that you can limit the damage that can be done is to remove access to the internet from inside your system. Quite often a service only needs to be accessible from the internet through a load balancer and all the internal components only really need to talk to other services of your cloud provider. If this is the case for you, using AWS PrivateLink for accessing the AWS services needed and otherwise have no internet connectivity from your internal service network will greatly increase the difficulty of any attacker to exfiltrate any data that they may have gained access to.

Summary

Do:

• Implement defense in depth
• Encrypt everything
• Limit attack surface
• Use the right language and framework

Don't:

• Manage your own infrastructure if you can avoid it
• Use fixed credentials
• Use SQL

Announcing the first public release of Underscore Backup

The first Underscore Backup pre-release is available for immediate download from Github.

• Public key based encryption allows continuously running backups that can only be read with a key not available on the server running the backup.
• Pre-egress encryption means no proprietary data leaves your system in a format where it can be compromised as long as your private key is not compromised.
• Runs entirely without a service component.
• Designed from the ground up to manage very large backup sets with multiple TB of data and millions of file in a single repository.
• Multi-platform support based on Java 8.
• Low resource requirements, runs efficiently with only 128MB of heap memory.
• Efficient storage of both large and small file with built in de-duplication of data.
• Handles backing up large files with small changes in them efficiently.
• Optional error correction to support unreliable storage destinations.
• Encryption, error correction and destination IO are plugin based and easily extendable.
• Currently supports local file and S3 for backup destinations.

Best of all it is available as open source for free under a GPLv3 license.

For now this software is still under heavy development and should not be relied upon to protect production data.

Released Your Shared Secret Service

I recently published Your Shared Secret service which allows you to safely and securely ensure that private information that you have is not lost if you are in any way incapacitated.

The basic premise is that information is submitted through your browser where it is encrypted before it is ever sent to the service. The key to decrypt the information never leaves your browser. The key is then then chopped up into multiple pieces which are securely handed out to a number of people that you chose to act on your behalf and only by a group of them collaborating (You chose how many) can they together assemble the key required to access your information. For a quick introduction you can check out this video.

I really went all out on the privacy aspect of this website and service and have gone out of my way to not collect any information not needed for the operation of the service. The site have no third party links except for when collecting payments and it does not collect any visitor analytics such as for instance Google Analytics.

You have complete control over who of your caretakers is able to initiate accessing the information and also how many of the total group of caretakers need to participate to access the information. Even better the service does not even need know how to contact the caretakers. This information is only known by the unlocking caretaker and the owner of the information.

Furthermore the act of one of your caretakers trying to assemble the key will give you as the creator a notification that allows you to cancel the unlocking information or delete the information all together within a 7 days quarantine period. For more information on how the service works see the Usage section on the website.

The entire service operates on a zero trust model where all the functionality is ensured with cryptographically strong primitives with the single exception being the 7 day quarantine period. There is plenty of detailed information on how the encryption works in detail and how the service has been built. To ensure what is claimed on the site is actually what is happening the source code to the entire service is published on GitHub and you can even run the entire website locally by just cloning the website repository and just run.

npm start

The service is available for an introductory price of $1 or if you want to have completely anonymity you can also pay with either Etherium or Bitcoin although that is slightly more costly because of the value fluctuations of these currencies.

The service is available now so feel free to get started now keeping your information safe without you.

Oracle apparently knew about the current Java exploit in April

According to this article Oracle has known about the current 0-day exploit since April but have not acted to patch it.

I would seriously consider trusting mission critical data to software from a company that apparently have such a lax attitude towards security flaws as Oracle has displayed in this case.

Unpatched Java exploit found in the wild

In case you missed it there is an unpatched security flaw in Java that is being actively exploited on the internet right now.

The vulnerability affects both Windows, Apple OSX and Linux versions of Java irregardless of what browser you use. Oracle has not announced any plans to patch the vulnerability with an out of cycle patch (The next scheduled Java patch is months away).

Now might be a good idea to disable Java in your browser. Usually you can do this by finding the settings for addins. In chrome you have to go to the URL chrome://plugins/ and find Java in the list and disable it (There is no item for this in the menus as far as I can tell).

Why we still have spam

According to a report from Microsoft and Google spammers world wide rake in around $200 million in profits, however while doing this they are also costing the receivers of that spam around $20 billion. Unfortunately given that the $20 billion is paid by all of us and not the people that are making the $200 million I don't see them stopping voluntarily anytime soon.

There are fortunately some encouraging developments that could end spam forever (At least in its current incarnation). For instance DMARC which combines Sender Policy Framework and DomainKeys Identified Mail seems a promising technology. If you want to know more about DMARC there is a whole episode on it with Security Now. One of its most important features is that it is supported by all the big guys like AOL, Gmail, Hotmail, Yahoo Mail and Facebook. That said it is something you need to set up on your own mail domain so it will probably take a long time before this is supported universally. Hopefully we are moving in the right direction though.

Is your VPN secure? The answer might surprise you!

During DEF CON 20 a new attack against the MS-CHAP 2 protocol was announced that basically reduces the complexity of cracking a MS-CHAP login down to a single DES 56 bit brute force attack. The announcers also combined this with a new services on the site CloudCracker which will handily brute force this DES for you in less than 24 hours.

The input required is a network capture of the MS-CHAP 2 handshake. For now there are a few manual steps, but they shouldn't be beyond anybody with a basic understanding of networks and using command line tools. The payoff is huge though, once you have the cracked token you can both listen in on any subsequent traffic from the authenticated user and also authenticate as the user yourself.

CHAP authentication is currently used in almost all PPTP VPN networks (It is usually the default authentication). It is also often used in enterprise WiFi authentication but there the handshake is already encrypted using TLS so the attack is usually not possible in this case.

Microsoft has put out a security advisory (Although they are by no means the only affected vendor) advising everybody to switch to EAP authentication for PPTP. However the change is not an easy one since it needs to be configured both on the client and the server side of the VPN tunnel.

Did you know that anybody can create new BMW keys?

Did you know that anybody with a kit for around $300 can create their own BMW keys? I didn't and it kind of freaks me out a bit. Especially in a convertible where someone can just jump in (I park with my top down all the time) and get their own key for the car in around 10 seconds.

For some reason BMW has the ODB (On Board Diagnostic) port on the car powered on even though the car is off and through this port you can read the key data needed to program a new key and also add that key to the car. All BMW models are affected that have the option of key less entry except for the new 3-series 2012 sedan, but that could just be because the software hasn't been updated yet.

This is by no mean a BMW only issue, but it is exasperated on for this brand by the fact that this port is on when the car is off and also that it has no security required to access it. BMW is trying to down play the issue, but has as of yet offered no solution.

How to protect your digital life

I've already written in another article about how to digitize your life and what benefits that can bring. When you do this you need to start thinking about how you make sure it stays secure though as was highlighted in a spectacular fashion by Mat Honan who almost lost everything he had in a digital form including all his photos of his 1 year old daughter. So I figured I would write up some stuff that you can do to help you protect yourself online.

Securing your central email account

Almost every service you use will allow you to reset your password through by sending an email to an account you gave them when you signed up for the service. This obviously means that it is critical that you protect this account as much as you can. To this end make sure that this account has two factor authentication and make sure you enable it. It is a little bit of an extra hassle to set it up, but the extra security it buys you is absolutely worth it. Currently as far as I know GMail and Facebook do support this (Your phone being your second factor in both cases). Unfortunately Yahoo, Outlook or Hotmail do not.

Furthermore, don't use work or your internet provider as your central account. It will be a pain in the ass if you ever need to get a new internet provider or move to another job if you do, because all of a sudden you need to go in and reconfigure all your accounts to another email address. Furthermore keep in mind that your employer has the right to read and use your company email address so using that for anything you want to keep for yourself is just a bad idea.

Can add as a note that if you use Google Authenticator for your Google account you only have one chance to set up a device for this (Or you have to start over from the beginning setting it up), so if you want to have it on more than one device make sure you set them all up while you still have the chance.

Handling your passwords

Creating secure passwords are getting harder and harder. Here are some tips about what to do now.

• Make sure they are at least 8 characters long, preferably longer.
• Use lower case, upper case, digits and special characters in your passwords.
• Don't use passwords that are words or combination of words.
• Don't use the same passwords for all your sites. At least use special passwords for sites that are important (For instance your central email account or accounts that deal with real money or sites where you have saved your credit card information).
• One method to make a password more security is to use password haystacks.

What I am trying to say here is that you really can't realistically remember all your passwords everywhere and I can totally recommend LastPass to help you out. For a detailed evaluation of it's security model check out this Security Now episode.

In case you don't have 2 hours to watch the video here it is in short.

• It is completely Trust No One, meaning LastPass can never retrieve your passwords even if they wanted to.
• It supports two factor authentication (Using Google Authenticator from above).
• It supports every platform that I use. The iOS support kind of sucks though. On Android you will want to use either the Dolphin or Firefox browser.
• It contains a password generated so you don't have to think up good passwords yourself.

Make sure you have a backup of everything

This can't be repeated enough. Even though data is rarely lost from online services it does happen and worse an attacker might wipe an account once they are done with it just to wipe out their tracks (As happened in the Mat Honan case mentioned above).

Backupify is a great service that allows you to back up a lot of online services. For your computers I can recommend Crashplan which is very cheap, is easy to set up but still has tons of features for the advanced user. If you make a backup onto an external drive make sure that drive is not stored somewhere in your house since a fire or a robber might be able to get to both the original and the copy if they are stored in the same place.

Don't enable remote wipe of your laptop

One of the main reasons the Mat Honan hack turned so disastrous was that he had enabled remote wiping on his laptop and when a hacker compromised his iCloud account they could also wipe his laptop. Remote wipe is a feature that makes a lot of sense on a cell phone that most of us has lost at least a few by this point in our lives. Laptops are lost a lot more rarely and unless you have critically secret stuff on it I don't think the chance of someone being able to remote wipe it simply by getting into one of your cloud accounts is worth the benefit. If it is for you though, make sure you have that backup.

Keep your password recovery questions secret

A lot of services allow you to set up security questions that allow you to reset your password. Make sure that the answers to these questions are not available online.

For example your first school is probably not a good idea if you grew up in a small town like me since there aren't that many schools to choose from. Other bad examples are your mothers maiden name or what was your first car (You sure you didn't post a picture of it somewhere?).

Also don't post your exact address online. Knowing your address is a good place for someone who want to hack your accounts to start. It might help with both security questions and social engineering. Just don't do it.

Online banking

The state of security for online banking in the US is just atrocious compared to Sweden but there is at least one thing you can do to at least make it a little bit safer.

Many banks allow you to select your username and password to log into it. Make sure that both of these are secret and not related to any publicly known information about you. On Wells Fargo and Bank of America you can reset the password by knowing your ATM card number, PIN and online username. This means that if your username is for instance your name (Which is also printed on the card) and someone skims your ATM card they can also hack into your online account and potentially do a lot more damage.