Re: Pass DBs reveal password lengths + PEBKAC issue
On 23/02/2017 13:51, Thibault Polge wrote: The consequence is a serious reduction of the complexity of brute-force attacks, IMO, this is a non-issue. Suppose each position in my password is taken from a set of N possibilities, and then I tell you that my password is exactly 10 characters long. Indeed, that means you don't have to brute-force all the 1 to 9 digit passwords. But (N^1 + N^2 + N^3 ... + N^9) is far smaller than N^10; approximately N times smaller. Hence the saving in brute force is a factor of 1/N. If I'm using base64 passwords then N=64 and I've saved you about 1/64th of the total work, or less than 2%. Not telling you my password length is a form of security through obscurity. The strength of the password comes from its length and its randomness - not from keeping its length secret. In any case: by the time I've added metadata to passwords on subsequent lines (URLs, usernames, comments) you're unlikely to get any dependable info about my password length from the gpg file length. Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: pass-otp: A pass extension for managing one-time-password tokens
On 15/02/2017 03:21, Thomas Harning Jr. wrote: The nice bit about the key URI format is that it bundles all the OTP details in an optional way with defined defaults and helps keep all the OTP details in one place. Plus it can be rendered as a QR code, and hence auto-loaded into a device like a phone. In fact, "pass show --qrcode" is in git already. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: encrypted file and directory names?
On 05/02/2017 21:22, Adam Spiers wrote: The first thing to note is that if the mechanism for calculating obfuscated filenames is a simple hash such as SHA-256, then in order to implement pass show google.com we simply perform SHA-256 on "google.com", and then look for a file called ~/.password-store/d4c9d9027326271a89ce51fcaf328ed673f17be33469ff979e8ab8dd501e664f The trouble with this discussion is that no threat model has been proposed, so we can just argue round in circles. You said you are worried about certain types of attack (e.g. an untrusted sysadmin on the same machine, who is able to read system memory) - IMO such an attack is meaningless to try to defend against. If the attacker has root on the system you're using, you are toast whatever you try to do. There are a million ways they can intercept what you're doing. I gather than you don't want people to learn which websites you have visited. Well, if they have root on your system they will learn this anyway. So if that's not it, perhaps the threat is from people who don't have access to your machine, but do have access to the git repo? If they have access to the repo, even if the filenames are encrypted or salted and hashed, they'll be able to infer useful things from the number of subdirectories, the number of files in each subdirectory, and the commit history in each subdirectory. (You could keep everything in one flat directory, but then you lose the ability to encrypted to different sets of keys, with a different .gpgid file in each subdirectory) So if your paranoia level is high, then as others have said, it may make more sense to encrypt the whole directory tree rather than each file individually. I like pass because it's simple, it's open, it does the job I care about, and its security model is abundantly clear. I worry that adding obfuscation will make it not really any more secure, but less practical to use. Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: encrypted file and directory names?
On 05/02/2017 03:53, HacKan Iván wrote: I thought the same, but implementing it is a real pain in the ass. I'm currently working on something I'll send soon, and then I'm gonna work on an extension to do just that :) If this is implemented I'd definitely prefer to see it as an extension, because I like the way pass works today. My threat model is different to yours :-) I'd say that the main benefit of putting separate passwords in separate files is that you can have independent changes to the git repository and they are less likely to cause merge conflicts. If you added a single encrypted file at the top of the repository, mapping password name to token, that benefit would be lost. In fact, you might as well just keep all your passwords in a single file (instead of name -> token it would contain name -> password) Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Generate new password for multiline entries
On 29/01/2017 12:18, Emil Lundberg wrote: If you use gpg-agent, you can instead use `git log -p `, which shows you the diff for each commit in the log. Git will automagically decrypt the files before diffing. "Binary files a/xxx.gpg and b/xxx.gpg differ" - some .gitconfig magic is required to make it happen. After some googling and tweaking: git config --global diff.gpg.textconv "gpg --decrypt --use-agent" echo "*.gpg filter=gpg diff=gpg" >> ~/.gitattributes But here's a scenario where this doesn't work. You are in a team; all your files are encrypted to A, B and C. After a while, new team member D comes along. You 'pass init A B C D' to re-encrypt to repository. However, D still does not have any access to the previous versions of each file. Re-writing the *entire* git history to re-encrypt every previous revision is not an easy task. Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Generate new password for multiline entries
On 28/01/2017 16:42, Simon Lackerbauer wrote: On 01/28/2017 05:34 PM, Brian Candler wrote: I like this idea a lot. I like keeping history of passwords, as sometimes you come across some forgotten system which still uses a password from one or more generations ago. Isn't that what's basically the point of the git integration? Each change of any file in the pass store is separately committed anyways and easily searchable with the appropriate git tools. Yes I know, but it's not trivial. First you 'git log ' (where filename is relative to the current directory) until you find what you think is the commit you want. Then since you've forgotten the command, you google for it. Then you run "git show :" (where, this time, filename is relative to the top of the repo), remembering to pipe it into gpg -d to decrypt it. Whereas what I do is just have a file containing: ... so that when I'm logging into a system, I have the various generations of password there right in front of me. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Generate new password for multiline entries
On 28/01/2017 16:21, Patrick Burroughs (Celti) wrote: I think there's room in this idea for a `pass rotate` subcommand, that will shove the old password down a line, then generate and insert the new password. Should be relatively easy to implement*and* would help satisfy some systems that have synchronisation issues around password changes. I like this idea a lot. I like keeping history of passwords, as sometimes you come across some forgotten system which still uses a password from one or more generations ago. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: best use of yubikey with pass
On 06/01/2017 22:13, Oliver Albertini wrote: Forgive me if this is is the wrong place to ask, or if it has already been addressed. Also, thanks to the developers of pass, it is a really useful program. What is the best practice for using a yubikey to authenticate gpg in the context of pass? Which kind of Yubikey do you have? I have a Yubikey standard (no longer available). It does OTP in the first slot. I could use the second slot to store my GPG passphrase as a static string - but I don't, since I know it :-) Since it just types in the static string, it would be vulnerable to keyloggers. A Yubikey U2F isn't usable for this application as far as I can see. It's intended for 2FA to web apps. A Yubikey 4 or Yubikey Neo has the ability to store your GPG private key, and decrypt messages inside the key. That would be the strongest solution I think, but I've not tried it yet. There's a nice writeup here: https://malcolmsparks.com/posts/yubikey-gpg.html It sounds like the PIN is cached, which is useful for bulk operations like "pass grep" which has to decrypt all the files in your repo. HTH, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass][new feature] item information
On 31/12/2016 11:04, Vahid Ma'ani wrote: "grep" option search content of crypted files and i should type passphrase some times for each search. Not if you use gpg-agent. It keeps your passphrase for 5 minutes. gpg-agent is invaluable for certain operations on the repo. For example, using "pass init" to change the set of keys that the passwords are encrypted for - it has to decrypt and re-encrypt every single file. And indeed, you don't want to have to type your passphrase for every one :-) ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] stop using pwgen
On 20/12/2016 10:17, Daniel Dörrhöfer wrote:
I have tested this implementation with the -no-symbols / -n option
turned on and have noticed that the password contains a single quote (').
e.G. 7S3b4wJ4R7'RfWGagkhaM95'6
To reproduce this, you have to generate a couple of passwords.
Good catch :-)
+CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-'[:graph:]'}"
+CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-'[:alnum:]'}"
has spurious quotes. Try changing to:
+CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
+CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] stop using pwgen
On 18/12/2016 15:20, Jason A. Donenfeld wrote: https://git.zx2c4.com/password-store/commit/?id=f2a6078885c61040737c602a99ee75ba8009f17f Any criticism of this? Well firstly, it doesn't even work under OSX. I tried this: #!/bin/bash length=25 characters='[:graph:]' read -r -N $length pass < <(tr -dc "$characters" < /dev/urandom) echo $pass Result: $ ./badpass.sh ./badpass.sh: line 4: read: -N: invalid option read: usage: read [-ers] [-u fd] [-t timeout] [-p prompt] [-a array] [-n nchars] [-d delim] [name ...] tr: Illegal byte sequence Looking at the bash manpage: read [-ers] [-u fd] [-t timeout] [-a aname] [-p prompt] [-n nchars] [-d delim] [name ...] ... -n nchars read returns after reading nchars characters rather than waiting for a complete line of input. But even changing -N to -n, OSX's tr doesn't work with binary data. The problem is that 'tr' is complaining about invalid unicode characters. You can fix it like this: read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom) And now it works: $ ./badpass.sh 6t-_'EOXaKZv1@#Z:yk@P\MSJ But more seriously, there is the risk that this will consume a pipe-buffer (4KB? 8KB?) of entropy, only to discard most of it. That's extremely wasteful. Furthermore, despite consuming so much entropy, it doesn't even guarantee that every password generated has at least one upper-case, lower-case, digit and symbol - i.e. the password may still be rejected by many websites! With the default password length of 25, the probably of *not* including at least one digit is: p(no digits) = ((95-10)/95)^25 = 0.062 That is, 6.2% of the time, it will generate a password with no digits. (Probabilities of no upper-case, no lower-case and no symbols are much smaller and can be ignored) (*) I think we need a pluggable password generator, so at least we don't have to argue and people can use whatever generator they prefer. And as for a default, well pwgen is (in my opinion) better than the one in that patch. Regards, Brian. (*) Aside: using random bytes into base64 also doesn't guarantee at least one symbol from each class of course. However, if you don't care about symbols, base64 does a better job. A 24-character base64 password, consuming 18 bytes from /dev/urandom, has a smaller probability of no digits: p(no digits) = ((64-10)/64)^24 = .017 p(no upper) = p(no lower) = ((64-26)/64)^24 = .037 However, about half of passwords will have no symbol: p(no symbols) = ((64-2)/64)^24 = .467 You can probably keep sites which require at least one symbol happy just by appending one fixed symbol to the end, like "=". This is not making your password any weaker, so why not? ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] stop using pwgen
On 18/12/2016 14:02, ilf wrote: I also proposed a method to do this without base64: ilf: Here's a simple way to generate passwords from /dev/random directly in shell: tr -dc "[:graph:]" < /dev/urandom | head -c 32 As I said at the time, that's terrible because it will consume 4KB or 8KB of data from urandom for every password you generate, most likely depleting the entropy pool completely. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] stop using pwgen
On 17/12/2016 23:22, Antoine Beaupré wrote: base64 turns each group of 3 bytes into 4 characters, so 18 bytes => 24 characters ah. yes. i was counting the last = sign, sorry. "=" signs are only added if the input isn't a multiple of 3 bytes: $ echo -n "abc" | base64 YWJj > > `base64` is not compatible with any password rules that require a special character. > > actually, it is, often. i have observed that base64 will yield a + or / > sign in about one out of 3 generated passwords. My experience is also that 16-character base64 passwords are accepted most of the time, as long as the generated password has a mix of upper-case/lower-case/digits. There are some sites which require a special symbol. However I also recently came across a site which rejected a base64 password because it did not allow + or / in a password. You can't have one algorithm which always works :-( Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] stop using pwgen
On 17/12/2016 22:02, Antoine Beaupré wrote: a 18 bytes password contains (naturally) 144 bits of entropy and base64 turns that in a 25 character password base64 turns each group of 3 bytes into 4 characters, so 18 bytes => 24 characters base64 passwords are more portable and incur only a ~13% size increase compared to original byte stream. 4/3 = 33% increase But anyway, I'm happy with the proposed approach for default password generator. Undoubtedly there will be people who want something else, so it would be good if it could be pluggable. (Aside: I don't actually see any need for entropy > 96 bits: brute forcing 2^95 combinations, at a trillion attempts per second, would take 1.25 billion years. But I suppose burning a bit more entropy and storage does little harm) Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Protect .gpg-id
On 07/12/2016 16:52, Emile Cantin wrote: I think the key here is that 'pass init' reads and re-encrypts everything with the new key(s), but Eve didn't actually use 'pass init' but did it manually (because she can't read the files). This leads to a situation where files in the directory are encrypted with a different set of keys than the ones present in .gpg-id, which might be detectable. Perhaps we can try to detect that kind of situation and throw a big nasty warning in these cases? Interesting idea. Simplest option: whenever re-encrypting an existing file (either via 'pass init' or via 'pass edit'), check if the set of keys it was previously encrypted to is different to the new set. *** WARNING: foo/bar *** THE SET OF KEYS BEING USED TO ENCRYPT THIS FILE IS NOT THE SAME AS BEFORE! >>> Encrypting using new key: 0123456789ABCDEF >>> No longer encrypting for key: 56789ABCDEF01234 Are you sure you want to continue? That would be a start, although you have to trust everyone else to be vigilant. I suppose it would still be possible for Eve to: - update .gpg-id to point to A/B/E - put in a dummy (e.g. blank) password file, encrypted with A/B/E - hope that the next time A or B accesses it they think that the empty file was a bug, and replaces it with the correct password?? ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Backing up pass
On 04/12/2016 21:26, Jacob MacDonald wrote: The repository is not stored as bare; That way I can access the files in the repository directly from Drive Warning: doing "git push" to a non-bare repository is generally not recommended, although you can do it with a post-update hook, or you can use a feature introduced in git 2.3 called "push to deploy": https://github.com/blog/1957-git-2-3-has-been-released To use this, you have to set config "receive.denyCurrentBranch = updateInstead" on the server copy of the repository. Otherwise: normally what happens is pushing to the repo updates the objects in the repo but *not* the checked-out working copy, which can get your repo into a very confusing state. See: https://git.wiki.kernel.org/index.php?title=Git_FAQ=23811#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Backing up pass
On 04/12/2016 18:58, Soham Chakraborty wrote: I have pass set up in my work computer. And I would like to have the contents of my password store into my home computer as well. I am looking to know how you folks manage such use case. Do you backup existing password store and then restore it on the new computer? If so, can someone point me to a guide or just layout the steps. You can use any file synchronisation tool you like - e.g. something cloudy like dropbox / sparkleshare / owncloud, or something peer-to-peer like syncthing or unison or osync. Or you can use the git version control system, which password-store supports natively. In that case, you would still want a central machine with a "bare" repository that the other two machines pull and push to; that could be any server with an ssh account. Choose whichever mechanism you're most comfortable with. HTH, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Cannot edit existing password using vim (or gvim)
On 01/12/2016 12:20, ads wrote: If I do mkdir /dev/shm/foo, then touch /dev/shm/foo/bar, the file bar gets written correctly. And what if you do "gvim /dev/shm/foo/bar" ? Is it possible that there is an apparmor policy for gvim, which is preventing it opening files under /dev ? Somebody else suggested setting nobackup in vim, and I have tried that (and nowritebackup too). No difference. I have also removed my .vimrc file and .vim directory, and no difference. I'm very puzzled. It might be useful to do an strace to see the actual system call it tried to do and the error it got back: strace -f pass edit 2>strace.out This will generate a ton of splurge in file strace.out, but if you search through it for EPERM somewhere near the end, or just before it prints the error message, it may give a clue. Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Sorted .. now ... iPhone?
On 23/11/2016 14:34, Cycle London wrote: Second: is there a way to get my passwords onto an iPhone or Android, without an ssh client and running the command directly on the host? There are links from https://www.passwordstore.org/ to android app and iOS app (but I haven't tried them) ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: Mac Version of pass not asking for gpg ID?
On 23/11/2016 13:44, Tao Bror Bojlén wrote: Could it be that your GPG passphrase is saved in the macOS keychain? That would explain why you aren't prompted for it after a reboot. Try opening the macOS keychain and seeing if anything comes up when you search for "gnupg". I second that explanation. I had to debug something similar for someone else, but in this case their ssh passphrase was being stored in the keychain after an upgrade to macOS 10.12. However it wasn't visible in keychain access. It needed to be removed manually using a sqlite command: http://apple.stackexchange.com/questions/253779/macos-10-12-sierra-will-not-forget-my-ssh-keyfile-passphrase The same might also be true with gpg passphrases and 10.12. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] generate passwords natively instead of dependency
On 14/11/2016 21:27, ilf wrote: Here's a simple way to generate passwords from /dev/random directly in shell: tr -dc "[:graph:]" < /dev/urandom | head -c 32 Aside: even though urandom doesn't block, I still think it's a really bad idea to consume 4KB or more of data from it to generate a single password. As it says in the random(4) manpage: Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of data from this device will have a negative impact on other users of the device. The amount of seed material required to generate a cryptographic key equals the effective key size of the key. For example, a 3072-bit RSA or Diffie-Hellman private key has an effective key size of 128 bits (it requires about 2^128 operations to break) so a key generator only needs 128 bits (16 bytes) of seed material from /dev/random. While some safety margin above that minimum is reasonable, as a guard against flaws in the CPRNG algorithm, no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel ran- dom pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skilfully implemented. So if you want to generate a 32 character password, using a 95 character set (6.57 bits of entropy per character), then you should consume 210 bits from /dev/urandom - no more. Then you should deterministically map those bits to the desired output character set - not just throw away good quality random bytes which don't match the 'tr' pattern. This is something which is easy to do in a good general-purpose programming language, which the shell is not. (In any case, passwords don't need 210 bits of entropy. 128 is more than enough) Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] generate passwords natively instead of dependency
On 14/11/2016 21:27, ilf wrote: Currently, pass depends on pwgen to generate passwords. I think it would be easy and desirable to drop this dependency and generate passwords natively. Here's a simple way to generate passwords from /dev/random directly in shell: tr -dc "[:graph:]" < /dev/urandom | head -c 32 We could also use "alnum" instead of "graph" and/or "base64" instead of "head". I really see no reason to add an extra dependency, just for its single use on line 457 of src/password-store.sh. Also, we gain being in control of (and responsible) of password generation ourselves. In the past, there have been issues with pwgen using low-entopy: http://www.openwall.com/lists/oss-security/2012/01/22/6 http://www.openwall.com/lists/oss-security/2013/05/24/7 What do you think? I think whatever is done won't satisfy everyone, so it needs to be easily pluggable. I would prefer not in an environment variable - but that would probably mean introducing a config file, either in the user's home directory, or inside the repo itself (like .gpg-id) ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Change the default text editor for pass
On 14/11/2016 09:58, Micha Rosenbaum wrote: On Mon, Nov 14, 2016 at 10:51:26AM +0100, Uwe Kaminski wrote: >What do you think regarding this functionality especially if you do >not use vi as default editor? Have you tried to set your wanted editor with the environment variable $EDITOR? Try: export EDITOR=joe && pass edit Your/Passphrase In addition, if this is an Ubuntu system, there is a generic /usr/bin/editor which points to whatever is the current default editor. So if you do EDITOR=editor pass edit foo it will use the system default. And to change the system default editor, " sudo update-alternatives --config editor" ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Provide symbol set as command line argument
On 11/11/2016 10:05, Henrik Christian Grove wrote:
tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~' head -c 32 && echo
>
You're absolutely right, I totally missed that first head which is
totally unneccessary.
Note that if you pipe /dev/random directly into tr like this, you are
likely to consume 4KB or more of random data, which will unnecessarily
deplete your entropy pool, and indeed may block waiting for more
entropy. It's a highly wasteful approach, as entropy is a valuable
resource, and this in turn may impact on the performance of other
cryptographic operations taking place on the machine.
If you are using 'pass' then I suspect you are making passwords to
copy-paste rather than remember and type. Therefore the benefits of
having a larger character set are minimal, when you could just have
longer passwords to achieve the desired level of entropy.
Consider that the base64 set has 64 symbols, and hence 6 bits of entropy
per character. The set in that 'tr' line has 95 symbols, so has 6.57
bits of entropy per character.
So to get a password with 96 bits of entropy, you need a 16-character
base64 password, or a 15-character password from that extended set. I
don't consider the benefit of saving one character to be worthwhile,
especially considering the difficulty of locating some of those
characters on different keyboards, or the fact that many sites may
reject some of those characters (different sites having their own
policies as to which characters are acceptable)
A good-quality 96-bit password can be generated consuming the minimum
amount of system entropy like this (*):
head -c 12 /dev/random | base64
However if you really *do* want to use shorter passwords with more
symbols, then I think it would be better to use a dedicated external
program to generate passwords. The shell is *not* a good general-purpose
programming language.
I think 'pass' should have a simple default, and a configuration setting
to choose an external password generator.
Regards,
Brian.
(*) Some sites insist that your password *must* include at least one
upper case, lower case and digit, and occasionally this formula will
generate a password which doesn't meet those requirements - roughly 1
time in 15.
p(no digits) = ((64-10)/64)^16 = .0659812552
p(no uppercase) = p(no lowercase) = ((64-26)/64)^16 = .0002385931
However there are only two symbols in the base64 set, so if a site
requires at least one symbol then you're quite likely to fail.
p(no symbols) = ((64-2)/64)^16 = .6017103034
I find that in practice, passwords generated like this are fine, and if
very occasionally I have to generate another one, that's not a big deal
- certainly less work than having to configure a program with the rules
for a given site.
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Provide symbol set as command line argument
On 09/11/2016 19:32, Kevin Cox wrote: You do have a bug though. You shouldn't use head because then if you happen to draw 10 newlines before the characters you need your generated password will be shorter then you expected. Try the following. Alternatively: dd if=/dev/urandom bs=1 count=12 | ... I tend to just pipe to base64; this gives a longer password with few or no symbols. 12 random bytes = 96 bits of entropy, and base64 gives a 16-character password. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] [PATCH] Allow custom subcommands
On 04/10/2016 05:45, Sylvain Viart wrote: Pass itself could be signed. By the user at init. But why? Do you have a version of Linux which only executes signed scripts/binaries? As for the admin being tricked into installing a malicious plugin - what's the difference between that and installing a malicious version of 'pass' itself? The only protection for 'pass' is installing it from a trusted location, and/or verifying the code by eye. Surely the same applies to plugins? Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Add 'Change Dir' Functionality
On 18/09/2016 12:52, Jakob Holderbaum wrote: Both tools allow to specify the optional working dir with -C in front of the actual command. For example: `git -C ~/dev/dotfiles status` or `make -C ./build test` Wouldn't it be great if pass could provide the same interface: `pass -C ./secrets show production/database_password` Another option I would like to see is to be able to use multiple git repos within the tree. This could then be combined with symlinks: e.g. .password_store/secrets -> /home/me/secrets .password_store/customer1 -> /home/me/customers/one/password_store Then you could do: pass show secrets/production/database_password as if it were were a single pass tree (but actually commits would take place within secrets/.git) Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] gpg: [don't know]: 1st length byte missing
On 31/08/2016 15:44, Sylvain Viart wrote: Nope, it has a non-zero size: ls -l ~/.password-store/web/framapad.org.gpg -rw--- 1 sylvain sylvain *528* juil. 19 15:27 /home/sylvain/.password-store/web/framapad.org.gpg gpg -d /home/sylvain/.password-store/web/framapad.org.gpg Does it give the same error? If so, it would appear to be corrupt. > I was more thinking about some gpg hidden switch to try more to guess the content. If the file is truncated, it's almost certainly going to be missing the data you want :-( Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Feature request – combined insert/generate/edit for new entries
On 18/07/2016 08:53, Adrián López Tejedor wrote: I sent this path the 17 of June with exactly that. I have added the "--edit" option to generate. Excellent, thank you. I have applied this by hand. Note: I intentionally don't use a gpg agent, and I notice with "pass generate --edit" I get prompted for the passphrase twice - once after the generation has displayed the new password before entering the editor, and once after the editor. But I can live with this. The other thing is that when --edit is specified I think it's not necessary to display the newly-generated password to stdout: but as long as you remember to clear your scrollback buffer afterwards, that's OK too. Regards, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Feature request – combined insert/generate/edit for new entries
On 15/07/2016 22:29, Marcos Alano wrote: I agree with Kenny. Pass has so much potential even being based on so basic principles (lots of encrypted files). A good interface to add new entries with an option to generate a random password is a nice idea. I like this idea too. Perhaps something similar to "pass generate -i", but which created the file if it were missing, and put you into the editor before saving. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] list of passwords with its age
On 20/05/2016 12:36, Renato Alves wrote: I don't know if gpg stores any kind of date as part of the metadata of the encrypted content but encrypting a timestamp seems like the only resiliant approach. You could simply sign the data when encrypting it: the signature includes a timestamp. https://www.gnupg.org/gph/en/manual/x135.html ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] [Add passphrase feature 1/4] add new command 'passphrase'
On 10/05/2016 16:43, Martin Bless wrote: Am Tue, 10 May 2016 15:51:24 +0200 schrieb Joschka Tillmanns: Hello Joschka, >May I get some feedback for this patch? I don't like the idea of introducing the dependency of "aspell". For example I'd like to use "pass" in combination with "Ansible" to set up a server. But I don't want to have to deal with aspell there. Aside 1: it could just read /usr/share/dict/words directly, rather than run "aspell" Aside 2: there is a dictionary in rfc2289 appendix D (although I think these are less memorable) Better make generating passphrases a utility of its own. I agree with this. Passphrases are for things that you commit to memory (like your gpg passphrase); whereas I think the primary role of password-store is for storing passwords which are hard to remember. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Easiest way to change gpg key?
On 09/05/2016 16:06, Lukas J wrote: I would like to change the key I use for encrypting my password. I couldn't find an option for pass to do that. Is there an easy way to do it? Do you mean, re-encrypt all your stored passwords with a different GPG public key? I think "pass init " should do that. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
[pass] "pass edit" and multiple passphrase prompts
I am using pass under OSX without gpg-agent [^1] Something I've noticed: - "pass edit foo/bar" when it creates a new file, doesn't ask for your passphrase - "pass edit foo/bar" when editing an existing file asks for your passphrase both before *and* after editing I thought this meant that it was signing it in the second case - however the file doesn't appear to be signed. Does anyone else see this? Regards, Brian. [^1] installed from homebrew, plus the following patch manually applied: http://git.zx2c4.com/password-store/patch/?id=a619988f7986d72f4e0ac7256ce48596df6a2a34 Clue from: https://github.com/jvenant/passff#readme ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
[pass] Multiple git repos in single tree
(I don't know if this has been discussed or proposed before) I have multiple git-backed password stores for different clients. Right now I am using wrapper scripts to set the base directory, e.g. #!/bin/sh PASSWORD_STORE_DIR=/Users/brian/git/client1/password-store pass "$@" #!/bin/sh PASSWORD_STORE_DIR=/Users/brian/git/client2/password-store pass "$@" However this is a bit messy, and means I have to type the correct command variant each time. What would be nicer is if the various git repos could go as subdirectories under .password_store: ~/.password_store/c1/ ~/.password_store/c2/ Then password abc/def from client1 could be extracted by "pass -c c1/abc/def" with no wrapper scripts required. In principle, pass already lends itself to this quite well: e.g. c1 and c2 have their own .gpg_id files, and "pass c1" already lists all the subfiles if c1 is a directory. I think the issues are: 1. "pass git push" and "pass git pull" currently enforce that there is a .git directory at the top level, and in any case wouldn't know which repo I was talking about. It would have to be extended e.g. "pass -p c1 git push" or "pass @c1 git push" 2. git adds and commits have to take place in the right repo. This will involve either: - walking back up the tree from the leaf to find a parent with a .git subdirectory, and setting GIT_DIR to this; or - cd to the directory where the file exists, and let git itself walk upwards 3. What happens if I put my personal password store (also a git repo) at the top level, and client password stores as subdirectories? This means I'll have a git repo within a git repo. Maybe git submodules would be required, but that makes things complicated. But I can sidestep that just by keeping them in separate directories. ~/.password_store/me/ ~/.password_store/c1/ ~/.password_store/c2/ Any comments? Cheers, Brian. ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
