Permanent storage is something most applications want to have in one way or another. Selecting the right storage wouldn't be a choice at all if there weren't so many options out there, and a lot of these come with their respective advantages and disadvantages.

When writing a user system for a client-side encrypted application, you first have to start with the universe. Well, that might be too much, so let's start a bit further ahead.

We're really starting to get to know each other, hm? Having gone through writing an auth token library in parts 1 and 2, and the first steps towards protecting our API with an auth process in part 3.

One of the most important features of an API, besides usability, is resilience. A big aspect of a more resilient API is a restricted amount of information communicated. This is important to keep in mind, since every bit of information you give away, aids in an attack against your API.

Continuing this series on writing and developing an authentication process with Phoenix and Elixir, so far we've covered developing our authentication library authtoken in part 1 and 2.

Last time, in Tokens, cookies and sessions: an auth story (Part 1), we talked about the decision-making process behind our authentication mechanism.

When deciding which way to go with communicating and storing authentication information, one can easily drift into a bad trip and start wondering how anything ever works.

Custom types in Ecto are a really nice way of abstracting away some functionality you need in a lot of places concerning your schemas. That sounds really nice, but let's break that down to something more digestible.

Last time we went over creating a secured infrastructure and network for our SaaS operation.

The decision behind every SaaS DB: MT or MI? Do you host everything in one large database or do you split apart your users and give each their own database?

Our decision to run the rewrite of Sealas with Elixir came out of our interest in the language and the architecture behind it.

A secure infrastructure is pretty useless if the application being transported is not reliably secure. So this week we will talk about securing our deployment and continuous integration process.

Last week we talked about the application's threat model. Now let's talk about securing our infrastructure.

Before we can properly develop our application, it helps to have a clearly formulated idea about what you want to do, and why. When it comes to an application whose goal is to provide a secure environment for its users, it is important to have a concrete threat model. This way we know what to protect against - and also why.

Sealas was our our first attempt to create a SaaS.

It started out as a simple idealistic idea: frustrated with the available options, we wanted to create an easy to use accounting application, that encrypts all user data before storing.

But we failed horribly.

Every cloud service you may use implicitly requires you to trust them with all your data you work with.

This means that your service provider will always know everything you do when using their product, whether you agree to that or not.