Mercurial > cgi-bin > hgweb.cgi > PassMan
comparison design.txt @ 0:a6cfdffcaa94
Initial commit, incomplete but it runs sorta.
| author | David Barts <n5jrn@me.com> |
|---|---|
| date | Sun, 11 Sep 2022 16:11:37 -0700 |
| parents | |
| children | c69665ff37d0 |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:a6cfdffcaa94 |
|---|---|
| 1 * First, decide that for some reason the standard pass password manager is | |
| 2 unacceptable. One reason may be the risk of compromise or bad commits | |
| 3 (by a hostile actor). Another may be matadata leakage: pass stores the | |
| 4 name of the (username, password) pair in plaintext. | |
| 5 + Regarding the latter, my ccrypt-based solution is better than that, and | |
| 6 it immediately struck me as a bad point. Was already thinking about what | |
| 7 I would do, and it involved sqlite with all fields except for time stamps | |
| 8 encrypted. | |
| 9 | |
| 10 * Using sqlite (sqlite3) and one of {Kotlin, Golang, Swift} (in rough order | |
| 11 of likelihood) would probably be the way to go. | |
| 12 * Use a table of the following form to store the passwords (call it passwords): | |
| 13 id integer not null primary key | |
| 14 name blob | |
| 15 username blob | |
| 16 password blob | |
| 17 notes blob (can be null) | |
| 18 created integer | |
| 19 modified integer | |
| 20 accessed (read) integer | |
| 21 + id will be the low 64 bits of the MD5 hash of the encrypted name | |
| 22 case-folded to lowercase (encrypt with a zero IV, don't prepend). | |
| 23 + all blobs will be AES-encrypted with prepended IV, a'la EncryptedProperties. | |
| 24 + timestamps are seconds or milliseconds since the epoch | |
| 25 * Use four other tables to store configuration parameters (as needed) | |
| 26 integers, reals, strings, blobs. | |
| 27 + Each will have an implicit rowid field, a string name field, and a | |
| 28 value field of type integer, real, text, or blob as appropriate. | |
| 29 + Probably only put those in the schema on an as-needed basis, i.e. | |
| 30 a reals table will only exist if we have configuration parameters | |
| 31 * Four major subcommands: create, read, update, delete. | |
| 32 + Error to create a password whose name (case insensitive) already exists. | |
| 33 + Error to read, update, or delete one whose name does not exist. | |
| 34 + Read should support a --like option to do inexact matching. If one | |
| 35 match, act much like read w/o --like. If multiple matches, just list | |
| 36 the names. | |
| 37 + Read should also support a --clip option that deposits the password | |
| 38 into the clipboard without printing it. | |
| 39 + Read should also support a --verbose or --long option that causes a | |
| 40 stanza-like, key: value dump of the full record. If --clip is used | |
| 41 along with --verbose, password prints as "(in clipboard)" | |
| 42 | |
| 43 * Use same password everywhere. | |
| 44 + Use a dummy config param to ensure correct password (attempt decrypt of | |
| 45 it first, write it base64'ed). | |
| 46 + Could theoretically use different p/w's for different rows, but causes | |
| 47 headaches matching names later, so avoid. | |
| 48 | |
| 49 * Misc: | |
| 50 + Include a password generator along the lines of genpass. | |
| 51 - This should be as a --generate option to the create and update | |
| 52 subcommands. | |
| 53 - --generate allows four other options: --length, --symbols, --clip, | |
| 54 --verbose. | |
| 55 - Default length should be 12 (default no symbols). | |
| 56 - If --clip supplied, copy new password to clipboard. | |
| 57 - If --verbose supplied, print new password. | |
| 58 - Default to be silent and not put password in clipboard, just change | |
| 59 in database. | |
| 60 + Command-line only, no GUI. |