Does Free Software Foundation's guidance about SaaS disallow usage of password vaults?

Question

Password vaults, which utilize public and (likely passwordized) private keys to host and protect principally-non-human-memorized-passwords, are a kind of SaaS that remotely stores and supplies password data to a user over a network. They have become quite common in the last five years; I even had a case when two information security "experts" (the best word I can use two describe them in that context) were surprised to know that I don't use a password vault.

I know that Richard Stallman (who is the founder of the FSF) is totally against SaaS, so I ask:
Does the Free Software Foundation's definition of "Free Software" disallow the use of password vaults (which are always SaaS)?

Answer 1

Short answer: under the FSF's definitions, I'd say the remote storage of encrypted passwords is too simple and too secured of an operation to count as problematic SaaS. However, modern password managers may do much more than this core functionality, which could run contrary to the FSF's recommendations.

Full analysis:

The FSF regards SaaS as an issue that is distinct from proprietary software:

SaaS and proprietary software lead to similar harmful results, but the causal mechanisms are different. With proprietary software, the cause is that you have and use a copy which is difficult or illegal to change. With SaaS, the cause is that you use a copy you don't have. [...]

Many free software supporters assume that the problem of SaaS will be solved by developing free software for servers. [...] But if the programs on the server are free, that doesn't protect you as the server's user from the effects of SaaS. They give freedom to the operator, but not to you.

The FSF's issues might be restated as

1. With SaaS, you give away your data to an external operator, and

2. You cannot modify a SaaS offering, even if the source code is free (instead, you must modify the free code and make your own service), so your computing done on someone else's service is done in a way that you cannot control.

However, the FSF makes it clear that not all network services are objectionable SaaS:

Does avoiding SaaS mean you refuse to use any network servers run by anyone other than you? Not at all. Most servers do not raise this issue, because the job you do with them isn't your own computing except in a trivial sense.

The original purpose of web servers wasn't to do computing for you, it was to publish information for you to access. Even today this is what most web sites do, and it doesn't pose the SaaS problem, because accessing someone's published information isn't a matter of doing your own computing. Neither is publishing your own materials via a blog site or a microblogging service such as Twitter or identi.ca. The same goes for communication not meant to be private, such as chat groups.

So, could the remote components of a password vault be said to be "doing your computing for you" in any substantial way? It seems like a password vault service has two parts:

1. A client to generate, encrypt, decrypt, and output your passwords

2. A service to store and serve encrypted passwords to the client

Functionality #1 has no network component, so we can be sure it is not problematic SaaS. #2 handles an extremely simply use case that neatly matches the FSF's acceptable use of a network service "publish[ing] information for you to access".

Functionality #2 needs only to store encrypted blobs of data. It is possible for a service to do this without giving away your sensitive data (since it is encrypted before submission) and without preforming any other computation beyond storing and re-serving that encrypted data upon request. In fact, these requirements are so easy to satisfy, they can be abstracted onto any arbitrary storage provider: one practical example is KeePass, a FOSS password manager, which supports a number of external services (Dropbox, OneDrive, as well as arbitrary network locations via FTP and SSH) to store and serve your encrypted passwords.

All of this means that remote storage and retrieval can be done in line with the FSF's recommendations: there does exist (both in theory and in actual fact) a password manager with remote storage that the FSF would find unobjectionable. However, it is also completely possible for a particular software/service to supply vault functionality in a way that does not conform to the FSF's recommendations. In particular:

• Any storage model that does not let the user enforce privacy of their passwords with cryptographic certainty is worthless from a privacy perspective. If the service remotely holds or generates either cryptographic keys or unencrypted passwords, then there can be no guarantee that the service respects the privacy of your passwords.

• A storage model that doesn't let you retain your passwords locally puts you at risk of the service failing to give you your own passwords one day (e.g., either because they went bankrupt or you didn't renew your subscription).

Answer 2

With great respect to apsillers' analysis, and with complete submission to the observation that "if you want to know what Stallman thinks on a particular point, you need to ask him", I'm not quite so sure that "the act of using a service to store encrypted passwords is one that the FSF finds unobjectionable". Quoting from the same essay that my colleague quotes, I note the view that "SaaS does not require covert code to obtain the user's data. Instead, users must send their data to the server in order to use it. This has the same effect as spyware: the server operator gets the data. He gets it with no special effort, by the nature of SaaS".

I couldn't have more clearly summarised what I think is the major problem with online password stores: that you send them your secrets, and they promise to look after them. When cleaved, this problem falls into two issues: firstly, that the service has access to your secrets, and secondly, that if the service goes away (business fails, servers go down, etc.) you don't have access to your secrets. In my analysis of these issues from a free-software standpoint, I should clarify the alternative: a personal GPG keypair, used to encrypt a file of stored passwords (which is stored on as many of your computers as seems prudent) and used to decrypt same when access to one is required. I'm a consultant sysadmin, so I have a lot of secrets to look after, and that's what I do.

The first of the two issues seems unsurmountably problematic. No doubt all those secrets are strongly encrypted at-rest by the SaaS provider, but who has that encryption password? If they do, they have access to your secrets. If only you do, then you've simply swapped the problem of storing one password securely with the problem of storing another, and worse, you have no control over the strength of the algorithm chosen for this, nor over how long the key is, nor how securely it's generated.

The second issue seems similarly problematic: if you want to survive the loss of the online password manager service, you have to have kept a secure-but-accessible copy of all your passwords somewhere else, and then you're left with a more complex setup than the free alternative.

As the FSF writes in that essay on how to avoid the SaaS trap: "For the simple case, where you are doing your own computing on data in your own hands, the solution is simple: use your own copy of a free software application." I can't think of a more clear example of doing your own computing on data in your own hands than storage of your important secrets. Until someone can take Dr. Stallman's mind on the question, I am far from convinced that the FSF would be happy with online password storage.