Re: [PATCH] Add support for XKCD-style wordlist passwords
On Oct 30, 2018, at 4:33 AM, Kjetil Torgrim Homme wrote: > Norwegian words are quite long... > > $ aspell -d no dump master | grep -v "['A-Z]" | wc > 489533 489533 6966844 > > average length of 13 characters. this doesn't really help entropy, > though. 489533 distinct words give 18.9 bits of entropy each, so the > above pass phrases (of four words) have 75 bits, or 5.74e+22. still not > a huge amount, but the attacker would have to know that this is the > method I use to make pass phrases to successfully reduce his search space. One key aspect of diceware/xkcd-style pass-strings is that the words that compose the string are themselves easy to remember and easy to distinguish from each other. That's why the dictionaries are relatively small -- 10,000 well-chosen words for your dictionary is much better than 489,000 words that comprise the entire dictionary but many of which are much lower quality words. Going from 8k words to 16k words only increases your entropy per word by one bit (2^13 vs. 2^14), but it is likely to make many of the additional words harder to remember, harder to pronounce and type, and harder to distinguish. For English-language words, this is why the EFF significantly improved the situation with their "long word list". It still satisfies all the goals of a diceware/xkcd-type wordlist, but the words are longer (and significantly longer on average), while still being easy to remember, easy to type and pronounce, and easy to distinguish. You compensate for low entropy per word by making pass-strings that are much longer. How much longer you make them is up to you, but if you want a pass string with 128 bits of entropy, then you could create a pass-string that is ten words long (128/13 ~= 9.84615384615384615384). At which point, yeah -- you might want to store those in a password manager. But you always -- always -- always ... assume that the attacker knows the mechanism(s) by which your passwords/passphrases/pass-strings are generated and will attack them in the most efficient manner possible. I do support -- and use -- diceware/xkcd-style passwords for certain functions, but I don't know that I'd make it a core functionality of this program. -- Brad Knowles Please forgive any typos. I'm fighting a failing keyboard on my laptop, in addition to having a broken finger. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] Add oathtool TOTP 2FA integration for pass show
On Oct 29, 2018, at 11:37 PM, binarysauce.com.au wrote: > The introduced functionality is an --otp argument for cmd_show which when > given the -o or --otp argument (additionally a token length) can show the > generated token, clip will copy the generated token but qrcode will provides > the qrcode of the original key so that it can be added to an authenticator > app. Are "clip" and "qrcode" standard *nix utilities? Or maybe provided as a part of oathtool? -- Brad Knowles Please forgive any typos. I'm fighting a failing keyboard on my laptop, in addition to having a broken finger. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [PATCH] Add support for XKCD-style wordlist passwords
On Oct 30, 2018, at 12:00 AM, Adhityaa Chandrasekar wrote: > + if [[ "$wordlist" != "" ]]; then > + pass=$(shuf -n 4 "$wordlist" | paste -sd "-" -) > + else While I think the concept is a good one, I don't think we should be depending on the user having "shuf" installed on their machine. I don't have it on mine, and I've installed a whole boatload of extra stuff that most people don't have. I'm also not sure about "paste", although I do happen to have a program by that name on my machine. IMO, you're better off sticking to more standard *nix utilities. -- Brad Knowles Please forgive any typos. I'm fighting a failing keyboard on my laptop, in addition to having a broken finger. ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: Security Vulnerability: Faulty GPG Signature Checking
On Jun 15, 2018, at 10:26 AM, Mark Gardner wrote: > I'm cool with Python. When I am not programming in Go, I am programming in > Python. It seems to be installed by default on all the Linux systems lately. > I am no longer so fond of perl, which is strange to say as I have done some > fairly big programs in perl. I found that it gets very obtuse when you need > to start creating nested data structures or use objects. Once upon a time, > perl with the the big thing. The momentum seems to have swung towards Python > these days. Speaking as one of the guys who has been a member of the team supporting postmas...@python.org since 2003, the problem with Python as a programming language today remains the split between Python 2.x and 3.x, and how many systems are still in active use with an ancient version of the language installed as part of the system. If you can write your code in such a way that it doesn't matter what version of Python you're using, then that's fine. But that's also a very tall ask. > I think you are conflating the dependencies that need to be installed to > build a compiled tool from the dependencies to install and use the tool. > Since most people install packages via their package manager, the former is > not much of an issue in my opinion. I agree that I don't want to have to tons > of separate libraries installed with the tool. I don't want to have to pull in a lot of additional dependencies in order to support a tool -- any tool. The simpler and more self-sufficient you can make/keep the tool in question, the better. > Don't know about Rust but installing a Go-based pass would be no different > than the current version. It would be just a single executable plus stuff > like examples and docs. The code would be written to check for optional > dependencies, such as git, and only use them if found. Just like the current > pass. If the code is written in go, then it has to be compiled to run on the hardware in question. I don't want to have to compile code, either. Moreover, once you have a binary that is separate from the source code, you can no longer guarantee the behaviour of the binary and that it really does correspond to the source code that may have been validated. Keeping It Simple, Silly + There Is No Compiler = Bash plus very few other options. So, KISS and TINC, please. Beyond that, I'm not too wedded to the language. But if you do want to keep it in Bash, here are tools out there that can help make that Bash code robust and pretty safe. -- Brad Knowles signature.asc Description: Message signed with OpenPGP ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: https://git.zx2c4.com Ubuntu trusty cipher compatibility
On Aug 29, 2017, at 9:06 PM, Svend Sorensen wrote: > The ciphers used by https://git.zx2c4.com are not compatible with > Ubuntu trusty's git/gnutls. Since this is the version of Ubuntu run by > the Melpa Emacs package archive (https://melpa.org/), the > password-store Emacs package is not getting updated there. The > discussion with the Melpa team about the issue is here: > > https://github.com/melpa/melpa/issues/4892 > > Would it be possible to enable one of the ciphers that Ubuntu trusty > supports? So, we know we don't want to support any NULL, ARCFOUR (RC4), EXPORT, or MD5 algorithms. We also don't want to allow SRP, PSK, or DSS algorithms. Nor single DES. 3DES is arguable, at best. SHA1 has also been deprecated. See <https://cipherli.st/> for some information on this subject. Given the above, we can greatly reduce the list of algorithms that should perhaps be supported to the following: TLS_DHE_DSS_AES_128_CBC_SHA2560x00, 0x40 TLS_DHE_DSS_AES_256_CBC_SHA2560x00, 0x6a TLS_DHE_RSA_AES_128_CBC_SHA2560x00, 0x67 TLS_DHE_RSA_AES_256_CBC_SHA2560x00, 0x6b TLS_RSA_AES_128_CBC_SHA2560x00, 0x3c TLS_RSA_AES_256_CBC_SHA2560x00, 0x3d The CBC algorithms aren't the best, we would prefer GCM instead. But of the entire list you presented, these are probably the least bad algorithms we could choose from. Note that the site in question seems to use exclusively elliptic-curve (EC) algorithms, according to the page at <https://www.ssllabs.com/ssltest/analyze.html?d=git.zx2c4.com&s=192.95.5.69>. Sadly, trusty is pretty ancient these days, and it's going to have to be abandoned by the community sooner rather than later. That is, unless the developers can update it somehow to support more modern algorithms. -- Brad Knowles signature.asc Description: Message signed with OpenPGP ___ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
Re: [pass] Mailman page is unencrypted HTTP
On Feb 5, 2016, at 10:04 AM, Niklas Hambüchen wrote: > Could the mailman config be put under https? That is best practice for Mailman, yes. Note that there have been a number of security enhancements that have recently been made to Mailman, so it would be a good idea to update, if you haven’t done that already. See the recent announcement from Mark Sapiro regarding Mailman 2.1.21 at <https://mail.python.org/pipermail/mailman-announce/2016-February/000217.html>. However, independent of that, if you’re accessing the wifi at Starbucks, I sure hope you’re using a VPN for all your traffic. -- Brad Knowles LinkedIn Profile: <http://tinyurl.com/y8kpxu> signature.asc Description: Message signed with OpenPGP using GPGMail ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
[pass] Windows use of "pass"?
Folks, So, we're looking at team password vault solutions, and "pass" looks like exactly the kind of tool we want -- gpg for encryption, storing of encrypted data in git, etc However, we do need something that is cross-platform, so we're also considering the classic "passwordsafe", and KeePassX (alpha). Maybe I missed it, but I didn't see anything about Windows support for this package, other than the obvious "it should work under cygwin". Can anyone help me understand the options here, and give me more details on exactly how the team support works? I've seen some announcement pages that give a bit more information about team support, but I haven't seen anything obviously linked from the documentation or github pages. Thanks! -- Brad Knowles LinkedIn Profile: <http://tinyurl.com/y8kpxu> signature.asc Description: Message signed with OpenPGP using GPGMail ___ Password-Store mailing list Password-Store@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/password-store
