4 ms·
I use a system that I wrote https://github.com/kybernetikos/sinkless https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this art
by kybernetikos 9y ago
I use a system that I wrote https://github.com/kybernetikos/sinkless 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.
- bengillies 9y agoIf 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.
- kybernetikos 9y agoYou'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.
- angelsl 9y ago> 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.
- kybernetikos 9y agoThis 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.
- dangoor 9y agoIsn'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.
- acdha 9y agoIt'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?
- tokenizerrr 9y agoExcept 1Password is also pwnd if an attacker gets mallware on your system? They just snatch the database and record keystrokes when you unlock it.
- deleted 9y ago[deleted]
- hobarrera 9y agoAn 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).
- Xylakant 9y ago* is assigned by the system and cannot be changed easily (stupid in itself, but exists nonetheless)
- kybernetikos 9y agoWow, 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.
- mikeash 9y agoWhat 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.
- kybernetikos 9y agoI 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.