Problems with Stateless Password Applications and Some Solutions

[deleted]

Stateless Password Managers, which Spectre is one of, have common problems that generally have not been solved by the many iterations or versions that exist.
Here are some blog posts and articles that have various criticisms:
Nov 22, 2016 - 4 fatal flaws in deterministic password managers - Tony Arcieri
Nov 23, 2016 - In defense of deterministic password managers - Mahdi Mohammadinasab
Jan 17, 2018 - Problems with pwdhash - sjoerdlangkemper
Jun 19, 2020 - Stateless Password Manager Usability - Amir Szekely(kichik)

They all basically repeat the same 4 issues:

Inconsistent password restrictions lead to creating a state.
Fixed or unchangeable passwords don't work, and other sensitive data such as credit card info, ID Numbers, etc is unstorable.
Password Iterations(having to change your password for some reason) requires creating a state.
Remembering multiple usernames for multiple websites is difficult, leading to the creation of a state.
Any solution that leads to the creation of a state requires syncing.

I have some solutions for these problems.

1. Inconsistent password restrictions lead to creating a state.

Thankfully, the solution to this one can be solved without creating a state, or at least, an individual state. The best solution for this one I think is a de-centralized database (possibly blockchain) that keeps a record of various website's abnormal password restrictions and requirements. This is already public information, all one has to do is sign up for the website and they'll find out what the restrictions are, so keeping this saved to an individual state isn't necessary.

2, 3, & 4 all lead to the creation of a state.

The solution to the problem of having to create a state is a matter of implementation. Where do you store the state, and how do you transmit the state between devices?
My proposed solution is to have the process of transferring state be as convenient and easy as possible, while simultaneously being as secure and safe as possible.
Imposed Limitations:
No central server or cloud storage of state. This excludes using Google Drive or DropBox.
Minimal user input in process.

With those imposed limitations the only ways to pass the state from one device to another are using these different processes:
1) QR Codes generated in the App, presentable on the screen, and sharable/printable. With Covid everyone knows how to use these. The downside is that now the app needs access to the camera. Upside is that it is platform agnostic, so as long as you have your master password, you can take anyone's phone, download the app, enter your master password, and aim the camera at the QR code and you have your entire state loaded with no internet connection required. If you print it off and keep it in your wallet you can wipe your phone of state after every use if so be it.
2) For updates and and sync between devices, it depends on the device ecosystem. If using Android devices, the App should be able to update and sync with other instances of the app on other devices using the WiFi Direct protocol.
For Apple devices, the MultiPeer Connectivity Framework would be something to consider. This should allow Apple devices to push state updates to each other again without requiring and internet connection.
I don't have a solution for bridging the Apple Android divide for devices that don't have a camera that doesn't involve connecting to the internet or using some sort of file transfer app.

-Thoughts?

lhunath

Hi and welcome!

I don't know that I can comment fully on each of your articles, though feel free to ask about any specific points in them if there is anything in particular you'd like me to comment on.

That said, let's start by addressing the 4/5 issues you raised, at least from the perspective of Spectre as it operates today.

Inconsistent password restrictions lead to creating a state.

I assume this is referring to the fact that different websites may use different password policies, requiring us to potentially craft different types of passwords in order to pass website password validation checks.

While this is indeed a concern, Spectre handles this situation in a way that mostly resolves any practical concern. Spectre's default password type was engineered specifically to be high in entropy, legible/memorable in output, and conforming to most website password policies. You will be able to use this output in almost all cases.

Where a website's password policy does not permit you to use this type of password, Spectre allows you to select another from a small set of pre-determined templates. It is true that changing the password template means that some "state" needs to be recorded for this site. However, this really isn't the Achilles' heel it is made out to be. This type of state is recoverable metadata. Spectre's primary goal is to avoid unrecoverable secret state. This goal is still met even if the user records some metadata for some websites. The metadata can be stolen but does not compromise the user. The metadata may be lost and can be recovered by the user. It's fine.

Fixed or unchangeable passwords don't work, and other sensitive data such as credit card info, ID Numbers, etc is unstorable.

Spectre does allow you to store some additional information with your site. For instance, you may store a login name or attach a URL. It could theoretically store additional information. As previously indicated, storing information is not a problem for Spectre – it's just that this information in Spectre has the same issues that it does in any other password manager: it is encrypted state, and as such, it is vulnerable to loss, just like it is in any other store.

Password Iterations(having to change your password for some reason) requires creating a state.

Spectre deals with this situation through the use of a counter, and the counter is indeed state. As previously indicated with regards to password types, this state is recoverable metadata and keeping it doesn't create a real issue. Yes, it's state, and that is fine.

Remembering multiple usernames for multiple websites is difficult, leading to the creation of a state.

It is not the job of a password manager, let alone a stateless one, to remember user names. But that said, as previously indicated, Spectre can still store this information. What's more: it can generate random login identifiers which you might be able to use as a unique login name with the website, with some luck. These generated login names would be fully stateless.

Any solution that leads to the creation of a state requires syncing.

This is a loaded statement with many unspoken assumptions.
In reality, the statement is plainly false. A stateful solution does not require syncing, at all. It can (and it does) work just fine without syncing. If you personally feel syncing is required, that need is likely a complex need coming from the combination of several factors, at least one of them being a sense of anxiety about permanent access to recoverable state. Regardless, I'm not going to try to fully unpack the hidden assumptions in this statement.

Instead, I'll just state the obvious: Spectre is primarily an algorithm for generating non-recoverable secret tokens that make up your digital identity. It does a great job at this. Spectre is secondarily a hybrid solution which allows you to store recoverable metadata on sites for your convenience. This state can be synced, if desired. There is a standard file format to facilitate Spectre implementations across platforms and devices collaborating with each other on state. Even if you don't: Spectre works great even if you choose not to sync your state and either ignore it or manually maintain any separate Spectre instances.

With that out of the way, let's move on to your suggestions.

Let me begin with stating the obvious fact that it would absolutely be great if either there was less state to sync, or if the state that does exist was more "indestructible". I have taken great care to minimize the need for state and this continues to be an ongoing area of research for improvement, since I am equally committed to these goals as you appear to be. To that end, let's dive into your suggestions which I am certainly happy to have.

Inconsistent password restrictions lead to creating a state

You propose "a de-centralized database (possibly blockchain) that keeps a record of various website's abnormal password restrictions and requirements".
Firstly, let me point out that there are some efforts underway for documenting website password policies. For example, consider: https://github.com/apple/password-manager-resources
However, we can acknowledge that the web is vast and documenting its array of services will always be an "incomplete" project. It would be great if we could have some sort of universally accepted standard that websites can use to advertise their password policies, such as HTML attributes on their password fields, or a Sitemaps-style advertisement.
I am also continuing to look into improving Spectre's default password type for increased compatibility.

2, 3, & 4 all lead to the creation of a state.

I largely agree with your constraints. Very early versions of Master Password (the predecessor of Spectre) offered iCloud syncing but this was removed intentionally. I will not lock my users in to any walled garden, nor will I condone any cloud storage or third-party synchronization platform. Spectre's core principle is that the user should be in full and sole control of their data. Synchronization through any service tends to violate this core tenant.

There are of course ways to still transfer your data between devices. Spectre deliberately uses a well-defined and documented file format in order to facilitate this. Currently it allows users to export the data using whatever application on their phone they desire. iOS users can send it to their other devices using Airdrop, copy it and let it transfer through Universal Clipboard, or access it from On My iPhone or through iTunes Sync. It will even allow you to keep your Spectre user in a third-party application such as Dropbox and open it straight from there, if you so choose, allowing you to keep the metadata managed entirely by your third-party application.

A QR code is a good suggestion, too, of course. I will keep this in mind as Spectre evolves to the other platforms, though naturally we acknowledge that cameras aren't universally available on compute devices and QR codes might be easy to spy from afar.

I have also been thinking about some other mechanisms. Whatever I end up with however must be universally accessible, secure, and respect all of Spectre's core principles.

Thank you for your contributions and please feel free to continue the conversation!

Moen

After reading your long an reflected post. I want to append my thoughts.

Point 1: That has happend to me once. Having a singn up that did not want spesific characters or to long pw. I spesifically think about roborock, with those there is a issue. But i cannot remember what i actually did use so i got to use the forgot password function.

Soving this issue could possibly have been done locally by custom rules of the password(i belive the different ones that are in the app, did not match.)

Wich then lead to a wanted savestate... but the data that would be saved wold not contain anything more than the allowed characters/length

2: i pesonally do not need / want that from a password manager. And this will require personal data to be stored.

3: I would like a feature to allow the count of the password to be synced. As no1 it does not requre personal data to be synced

4: usernames not a big concern for me and not something i need of a password manager. This could be handled as no 1 and 3.

As for syncing a simplifyed file export/import. wich overwrites old data (based on tinestamp?) could be sufficient.
Share a file over bluetooth and importing it onto an other platform would make wonders.

I did look into copying over the database to my new computer, but i figured i did not have much need to do it.

A problem you have not mentioned is that the master password cannot be changed without changing all the passwords. If it would be leaked, or bruteforced there is no way out of it.
Tbh most likely chance is for it to be leaked.