Hacker News Reader

I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 - in browser plugins) that supports many of these situations.

* The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv.

* Each password has a 'version' which you can increment. The version is considered public information and is stored locally and can easily be exported as CSV. In order to help you know that you've got the version correct, there is a visual indicator - an emoji.

* The version can be used to rotate passwords after a breech.

* My system stores all the settings that have been used on this client and lets you export them and import new ones. This lets you see if you have an account on a service.

* I don't have an explicit way of storing the username, but there are ways - you can include the username in the salt.

* The ability to list all accounts that a particular client has seen gives a partial solution to your need to see all known accounts.

> Solving any one of these problems requires a secure place to store state, but once you have a secure place to store state you can just store the passwords themselves.

This is not true. All of these things are settings related, and can be considered public information, which means you don't need a secure place to store this state, you can store it nearly anywhere, drop box, email, plain text on a website if you want. In a gist etc.

Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.

What is the advantage of this over a traditional password manager? You need to sync a file so you can obtain the state needed to generate a password, just like a password manager. Your CSV file can be stored in a publicly accessible location without losing security, but the same is true of a password manager's database. Both are useless without the master password, and both unlock everything if the master password is compromised.

It seems to me that generating a password from a master password and some settings in a file is equivalent, both in terms of convenience and security, to decrypting a password from a master password and an encrypted password store.

I agree, there's not much in it. If you're not using proper salts there is a small advantage which is that it's usually possible to work out the settings for a site even if your sync file is lost since they will tell you the allowed characters and remembering a version number for the sites where you've changed it is not too hard especially since I show the corresponding emoji every time you log in.

I also prefer it to involving a third party service which is the other way password managers often work.

If you store settings related to password system requirements on a per site basis then you're leaking the existence of your account on that site, which often needs to be private itself.

You're right. If you're worried about that, then you will need to treat that data as not entirely public. The point is just that the secrecy requirements can be much less than you'd have for keeping a password.

An alphabet isn't enough to describe some [stupid] bank password requirements (I do admit the banks are really the problem here though).

Two banks I've worked with recently:

* No consecutive digits, not your initials. Numbers cant be your day, month or year of birth. * No repeating any symbol in the entire password. Cannot contain a subset of a previous key (I don't know how long the subset is to trigger this, but I do recall reusing 4 of 8 digits and seeing this).

* is assigned by the system and cannot be changed easily (stupid in itself, but exists nonetheless)

Wow, that's pretty crazy. With this setup, if you did fall foul of one of those rules, you'd have to increment the version until you no longer did.

> Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.

How is your system different? If I get ahold of your master key, your entire thing is compromised.

This is true, but on the other hand the master key is never stored anywhere, so your chance of getting hold of it is reduced.

EDIT: as pointed out, no sensible system stores the master password. I do stand by the earlier 'single point of failure' point though. If you store a password vault somewhere and it goes down, or is encrypted by malware, or you lose the ability to access that storage for whatever reason you're stuck.

It's reduced but by how much? For example, 1Password uses PBKDF2 with something like 10k or 100K rounds to encrypt the local vault. If you were looking at ways that could be compromised, is it really likely that you need to worry about an attacker getting a copy and dedicating a lot of expensive hardware to brute-forcing it anywhere near as much as the attacker getting malware on your system which captures those keystrokes?

You're right, I was wrong. Theres no benefit from that point of view.

My system also uses PBKDF2 with 800K rounds :-)

Keystroke capture is the most scary, but I guess anything that doesn't do 2 factor is going to have trouble there.

Except 1Password is also pwnd if an attacker gets mallware on your system? They just snatch the database and record keystrokes when you unlock it.

Any algorithmic pw-manager can be attacked the same way: just record the keystrokes when the master pass phrase is entered. If the attacker has malware on your system, assume all is lost.

That was exactly my point – on something other than iOS/ChromeOS there might be a chance if the attacker manages only a partial compromise[1] but in general it's wise to assume that a compromise will get the master passphrase or could simply read the unencrypted data out of the process memory and take precautions based on that worst-case scenario (e.g. using U2F everywhere it's available).

1. e.g. if the compromised process is sandboxed enough that the secure keyboard input features work or something like the macOS securityd running as a separate user prevents unrestricted access.

Isn't this true of 1Password and similar as well? My master key for 1Password isn't stored. That's what I need to enter to unlock my vault.

> A way to list all known accounts

(I'll call this "discoverability" or "browsability".)

I'm gonna go farther and say that the entire notion of discoverability is undervalued in a whole range of scenarios, not just here. Many of us programmers are so used to the notion of "you should already know X in order to do Y" that we completely ignore how detrimental and unusable it is for mortals.

At the risk of going off-topic, another example is the fundamental difference between a GUI and a CLI... the poor user who's just trying to learn how to use the computer can always click a menu or right-click an empty window to see most things that can possibly be done (there's only so many buttons on a mouse), but good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it? On a GUI you just click the Help menu (it's already there) and look at the contents. And even the help system can't know about every command. People have to read manuals and remember a ton of things before they can use CLI tools, in contrast with GUI tools which they can discover as they go. (Obligatory note: I'm not saying they can always substitute for each other, or that even one is always better... e.g. it's obviously much harder to automate GUI tasks. Just drawing a comparison here because I think there is a larger point to be made.)

Another (off-topic) example is the difference between opt-out and opt-in systems for practically anything. In practice (maybe not in theory), people have to know what to opt out of in order to have any chance of being successful at it, but they are generally allowed to discover what they can opt into. Of course this is usually due to misaligned incentives, but the point is that knowing a-priori what to do can be a crux of what makes something practical vs. impractical for consumer usage.

> good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it?

This is one of the prime drivers behind stackoverflow (and related)'s success. I'm amazed at the number of times I run into a "how to get equipment X to behave in fashion Y" and find a cookbook recipe of exactly (or more than half of) what I need to do. It's my own personal reminder that the world is a big place with lots of people not all that different from myself.

Yeah, the random, terrible requirements of some sites is what will keep me on 1password. Yes, if I was specifically targeted I'm sure my accounts will be compromised, but the thing is I am not really concerned about that - the bigger problem is every random site losing user data every other week. If they have a throwaway password I am already better off than 95% of the population.

But honestly, it is quite unbelievable how many sites don't allow certain special characters, limit you to X characters, etc.

And I think one key factor that developers forget is convenience and UX, if a password manager is cumbersome, or only works on some sites, then the chances of a user dropping it will increase a ton.

I use a similar stateless password manager than the one where the submission originates from: https://github.com/majewsky/pwget

My tool uses a revocation list for scheduled password changes. Normally, the password is generated as

  i = 0
  return kdf(masterpassword, sitename, 0)

where kdf() is a suitable key-derivation function. However, when that password is on the revocation list, then i is incremented and the kdf() reexecuted until a non-revoked password is found.

The revocation list technically makes the password manager not-stateless, but I don't care. If I ever lose it, I can just generate passwords for each site and revoke them until I find the one that works.

For all the other concerns that you list, I have a textfile listing all my accounts, and the weird derivation rules that are required for some of them (e.g. "take first 19 chars, then append capital A"). That text file is in a private Git repo. Now you could hack my notebook to get at that repo, but if you do, all is lost anyway, so as far as my threat model goes, it's not a problem to have this text file.

I agree with all these points completely, and I'd like to extend a bit more:

* The criticism of cloud-based storage isn't really valid. Any decent password manager should only sync the encrypted data, and never move anything unencrypted. * Browser integration isn't obligatory. Lots of PM's don't use that, and lots of users are okay with that, so that attack surface isn't an intrinsic part of a classic password manager.

Since a lot of sites have unique requirements, but those unique requirements are usually a subset of 1 number, 1 special character, 1 uppercase character, why not just force the generator to always contain uppercase, always put in a number and always put in a `.` (or whatever the most accepted special character is)? Yes, it ever so slightly reduces the brute force searchspace, but that's non-trivial with a lengthy password.

Your first two points should be pretty easy to implement with this stateless approach. The second two points could be do-able if you're willing to let the tool dictate choices for you (e.g. choice of username). The last - OK probably not.

Forgot what the hash sign was otherwise known as:

https://en.wiktionary.org/wiki/octothorps

There's an episode of 99% Invisible that chronicles the history of this character and its various names and uses: http://99percentinvisible.org/episode/octothorpe/