On 2016-12-17 18:08:16, Tobias Girstmair wrote: > I'm against it. IMHO the `pass` philosophy is to utilize UNIX tools instead > of rolling one's own.
I believe that "head", "base64" and "tr" are UNIX tools. It's not like i implemented a password generator in pure bash (which would be $RANDOM, and probably horrible). > `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. so i haven't had trouble with this so far. Jason A. Donenfeld <ja...@zx2c4.com> schrieb am 23:57 Samstag, 17.Dezember 2016: > I'll seriously consider replacing pwgen. I didn't know it was so > horrible. I'll investigate and make a decision. to be fair, it is much better than it was now. i don't think there are any known vulnerabilities in pwgen at this point, and I don't want to make people believe that pwgen -sy is completely insecure: I have reviewed the code and it seems fair. i just find that the *default* of pwgen is insecure and should therefore not be encouraged. having it as a dependency encourages it... > I like the idea of using /dev/urandom directly, but piping it into > base64 is a terrible idea. why is it a terrible idea? can you be more specific? you need a reduction function of some sort. pwgen does it by having different set of allowed characters, which you choose with commandline flags. pass only supports --symbols, but there's also --capitalize, --no-vowels, --numerals, --ambiguous... my opinion on this is that it is unnecessary: what we want is to generate a string with a high level of entropy (base64 doesn't affect the entropy level) that is highly "portable", that is, easy to copy-paste. pwgen -ys, half the time, generates a password i can't copy-paste by simply double-clicking on it (because of symbols like [>;.]). you might argue that you're supposed to use -c, but that is optional and there are reasonable use-case where you can't use the clipboard to transport the password. so you need to take the 255 possible values from /dev/random and reduce them to *some* space. i chose base64 because it sticks with a conservative 6-bit range of characters that works across email, shells and whatnot. i do not need to worry about what happens when i send a latin1 character, LF, null or whatever /dev/random can throw at me: there's a standard to convert arbitrary bytes into portable strings, and I am using it. > I've got some ideas on how to do this. I'll code a few different ones > up and see how it goes. I'll also evaluate pwgen competitors. There > was a nice one somebody on this list proposed a while ago. here are the ones I know of: * head -c $ENTROPY | base64 | tr -d '=\n' * pwqgen - uses a wordlist and a specified entropy level * diceware - uses a wordlist and dicerolls (or /dev/random) the latter two are meant to be "human-memorable". i am not sure that should be a goal of pass: the whole point of a password manager is to *not* have to remember passwords. making passwords memorable makes them weaker and easier to bruteforce, and should be avoided in our use case. a. -- Wherever they's a fight so hungry people can eat, I'll be there. Wherever they's a cop beatin' up a guy, I'll be there. If Casy knowed, why, I'll be in the way guys yell when they're mad an' I'll be in the way kids laugh when they're hungry an' they know supper's ready. An' when our folks eat the stuff they raise an' live in the house they build, why I'll be there. - John Steinbeck, The Grapes of Wrath _______________________________________________ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store