Introduction

Introduction

Most or all of us have many accounts with various service providers in the cloud, and many of those accounts require a password. And, most or all of us know that we shouldn't use the same passwords for these many accounts, because of the danger that that poses for us, if one or more of those service providers have a security breach that affects our passwords. But, when we're talking about tens or hundreds of different cloud accounts, doing so is impractical without the help of a tool. We need a password manager of some sort...either one that is publicly available or one that we build ourselves (whether that be on paper, in Excel, or in some software that we develop). The solution described in this article, Rosetta Salt, aims to improve upon the currently available password managers, in terms of cost or security or both.

Context

In order to secure a service, service providers in the cloud need to authenticate us...that is, make sure that we are who we are proclaiming to be when we provide them with some sort of identifier (like an email address or username). In order to authenticate us, they need to use some combination of the things we know (like a password that they have on record for us), the things we are (like having an eye or a finger that matches some template they have on record for us when it is scanned), or the things we have (like some number that is generated by a device they have given us or that they have sent to us via an email). Each of these things is sometimes known as a factor, and you may have heard more and more about two-factor authentication (2FA) and multi-factor authentication (MFA) in recent years. 2FA and MFA approaches use two or many of these factors to improve the probability that we are who we are claiming to be.

Problem

When we have accounts with many service providers in the cloud, and when many or all of these service providers use a password as a factor for authentication, then we have an important decision to make. On one end of the spectrum, we can decide to use the same password for all of our accounts with these service providers. On the other end of the spectrum, we can decide to use a different password for each of these accounts. And, of course, we can decide to take some sort of hybrid approach. But, for the sake of argument, let's assume that we need to choose one end of the spectrum. Each end of the spectrum leaves us with a different problem.

If we use the same password for all of our accounts, we put the information that we entrust with all of these service providers at a higher risk. If one of our service providers has a security breach related to the passwords they store for tens, hundreds, thousands, or even millions of clients, then it could put our personal information that is managed by other service providers at risk. For example, if a small service provider with tens of clients doesn't have adequate security mechanisms in place and my password is stolen from them, my financial information that is maintained by my bank could also be at risk.

On the other hand, if we use a different password for each of our accounts, we need some sort of tool or strategy to manage all of those passwords (unless we're one of the few who can remember tens or hundreds of different passwords that are also secure enough for their purposes). This site claims that a Dashlane analyis of information from more than 20K survey respondents in 2015 found that people on average had 90 online accounts. I would imagine that that number per person has only increased over the past number of years, although the only information I have to bolster that is my own experience. And, the number of accounts per person isn't the only aspect of this problem: some of our passwords need to be reset after certain periods of time (even though this is no longer the NIST recommendation).

One tool or strategy to manage all of the passwords for all of our cloud accounts is a password manager. One type of password manager is a notebook (or similar), where we write down and maintain each password in it. Another type of password manager is a general purpose spreadsheet, where we do essentially the same thing. A third type of password manager is a password specific software solution, which generates new passwords for us, keeps track of them for us, and stores them securely for us (via encryption or otherwise).

Now, there are already lots of password managers that are available to us...just perform a Google search for "password manager" and you'll see what I mean. So, a reasonable question might be: why not just use one of those pre-existing password managers instead of building our own and then deploying that to AWS? That's a fair question and my understanding is that lots of them are a good choice.

But, the problem I have with the password managers that are currently available to us (at least of the ones that I know) is that they seem to lack a proper balance between cost and security. If their cost is fine, their security may not be...in particular, I take issue with a set of passwords being encrypted in one place and then being exposed if their encryption key is guessed or exposed. If their security is fine, their cost seems high...in particular, I take issue with having to pay tens of dollars a month or hundreds or thousands of dollars a year for a password manager. And with some of the password managers, neither their cost nor their security seems ideal.

Solution

So, I decided to build my own and to try to strike the right balance for myself. And, I'm describing it here for you, in case you'd like to do the same for yourself. As well, and as an aside, my hope is that the description of this full solution will be beneficial (I sometimes find myself wishing that the author of an article would describe a full solution, rather than just the minimum for the problem that they're trying to solve or teach).

To address my issue with the cost of some existing password managers, I developed the server-side aspects of this solution with AWS serverless technologies...if you are currently unfamiliar with those, you'll learn more about them if you read the full article, but the gist is that no resources are pre-provisioned and you only pay for what you use. After having it deployed with these serverless technologies for several months, and with only my family using it, its usage levels are well below the free-tier levels at AWS. And, even if enough others choose to join me in using this particular solution and end up putting its usage above those free-tier levels, then I will only be charged for the actual usage and thus could make it available to them at a lower cost (as compared to a pre-provisioned approach or other password manager costs). The only ongoing costs with this serverless solution so far are related to the domain name I reserved for it: rosettasalt.org. However, a reserved domain is just a convenience and thus you should be able to deploy this solution for free, if that's your goal.

To address my issue with the security of some of the existing password managers, I decided to avoid storing the passwords altogether, and instead decided to derive just the password that is needed at any given moment. This solution avoids storing passwords by combining transient information from the user on the client (their passcode) with information transferred from the server for a particular cloud account (the salt value and the transformation rules for that cloud account), and then deriving the relevant password (using the passcode, the salt value, a hash function, and the rules). By taking this approach, it forces a malicious actor to steal the user's passcode at runtime, because no persistent information exists that can be reverse-engineered to unlock the set of passwords for that user (hash codes are non-reversible and at best the actor would have the relevant salt values, transformation rules, and some of the user's actual passwords...if the actor already had all of the user's actual passwords then there would be no point in trying to figure out the user's passcode so that they could then derive the user's password for a particular cloud account).

In contrast, the password managers that I know of either store all of the passwords for a user on their client devices, or they store all of the passwords for all of their users in their server environment, or both. With that approach, a malicious actor who is able to steal a password "database" from one persistent store or another can make use of external computing resources over an unbounded period of time (if necessary) to try to crack the relevant passcode and unlock all of the passwords in that database. By taking that approach, these other password managers give a time advantage to any malicious actors that are able to breach the client platform, the server platform, or both.