Re: FESCO request to revert password confirmation change in F22
On Mon, Mar 9, 2015 at 6:53 PM, Björn Persson Bjorn@rombobjörn.se wrote: Nico Kadel-Garcia wrote: I'm the guy that brought up the XKCD comic. I did it first. ;-) The classic storage is the Post-it note on the secretary's desk, but I see a lot of people who should know better writing them into source control systems that everyone in the company can read. Or even source control systems that everyone in the *world* can read: http://arstechnica.com/security/2015/03/ubers-epic-db-blunder-is-hardly-an-exception-github-is-awash-in-passwords/ Björn Persson And Subversion, storing its own plaintext passwords by default in $HOME/.subverson/ for almost 15 years now. And the chef 'nrpe' and 'mysql' cookbooks, storing MySQL and other database passwords in plain text for system configuration, and the 'users' cookbook storing private SSH keys in unencrypted data bags with no hooks to encrypt the stored private keys. Yeah, the list goes on, and on, and on for tools that store unprotected credentials. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Kevin Kofler wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. Björn Persson pgpTJmoZV1fI6.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 10 Mar 2015, at 07:00, Matěj Cepl wrote: On 2015-03-10, 10:15 GMT, Björn Persson wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I think certainly there should be some protection against passwords like monkey (why monkey and not kangaroo, for example?) or iloveyou (as the Pope Francis said our message should be based on love not hate!), but when it tries to do too much more it is getting in the way even to the people who actually know what they are talking about. VM machine used only for temporary compilation on the old platform just doesn't have to have 63-random-chars password from https://www.grc.com/passwords.htm At the risk of complicating someone's life: Given that pattern-based attacks make meaningful password quality checking nigh impossible, why not just drop password quality checks. Instead, give a simple explanation that a secure password should: * be at least xx random characters in length, utilize both lower and upper case letters, as well as numerals and special characters, and not contain any human recognizable pattern -- and that any pattern that one can easily remember is probably insecure; or * be generated by a suitably random password generator, such as a 7 word Diceware password. Then embed a random password generator, such as /usr/bin/apg, and give the user a choice of generating a random password of whatever length the user wants, or simply entering whatever insecure password the user deems appropriate given the anticipated use of the installed OS. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 2015-03-10, 10:15 GMT, Björn Persson wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I think certainly there should be some protection against passwords like monkey (why monkey and not kangaroo, for example?) or iloveyou (as the Pope Francis said our message should be based on love not hate!), but when it tries to do too much more it is getting in the way even to the people who actually know what they are talking about. VM machine used only for temporary compilation on the old platform just doesn't have to have 63-random-chars password from https://www.grc.com/passwords.htm Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Tue, Mar 10, 2015 at 5:38 PM, Björn Persson Bjorn@rombobjörn.se wrote: In the hope of clearing up any misunderstandings I'll make these statements: Thanks for the clarifications. My own clarification is that what I wrote is directed at large, not only to you personally. Usage of you was intended to be plural/generic. · The assertion that users in general know what a good password is is not a valid argument, because it's so obviously false that it's plain ridiculous. I'm uncertain how these things are even graded. There's a wide assortment of opinions on the subject, so I'm not convinced the problem is well enough understood by experts let alone users in general. What probability of a successful brute force attack distinguishes between good and weak passwords? Enough of this is sufficiently complicated by features such as rate limiting, attempt limits, reducing attack surface in various ways, that the same password may be sufficiently good in one case but not another. And users in general have no way of knowing or assessing such things. To what degree are they simply lucky because they're never or only very lightly and rarely attacked? There are many distortions here. · A policy that would permit Tr0ub4dor3 because it contains upper case, lower case, digits and symbols, but forbid correct horse battery staple because it's all lower case, would be counterproductive and a terrible mistake. Sure. Literally those passwords are disqualified because they're published. But as far as password types go, any leetspeak encoded dictionary word or words is suboptimal. It's a question of attack efficiency at what point in an attack a 3-4 word passphrase is guessed relative to leetspeak words, I have no idea if efficiency algorithms figure that leetspeak is more or less likely to be chosen by a human user thinking it meaningfully obfuscates attacks. The actual intended Anaconda password policy is unclear, not least of which is it's not stated in the UI. The change log suggests an 8 character passphrase with some complexity is necessary, however in practice it requires 10+ characters with some complexity. Completely random 8 and 9 character passwords are rejected. Efficiency wise, I'd expect passwords of 8 characters with some complexity to be guessed before 3-4 word passphrases. However, I'd expect 3-4 word passphrases guessed before password of 10-12 characters with some complexity. And in any case efficiency wise I think without any other mitigating factors like rate and attempt limiting, the time frame for a successful attack is sufficiently short for all of these that the password quality change proposed lacks efficacy and doesn't solve the problem it's intended to solve, and and a high UX cost. So I'd still say, if Fedora really wants to go down the road of being a policy enforcer (uncertain), if it really thinks it has the political capital with the community that this sort of might does make right, I'd say they're better off using it in a bold meaningful fashion rather than one that's next to meaningless. And that'd mean disallowing anything less than 25 characters. Give or take. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Tue, Mar 10, 2015 at 4:15 AM, Björn Persson Bjorn@rombobjörn.se wrote: Kevin Kofler wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. I do not deny that weak passwords in certain contexts expose users to risks *I* don't feel comfortable with. Educating them is appropriate to the degree I think it's an obligation. Coercing them is inappropriate to the degree I'd rather see them hacked. Propose an ethical challenge to that. What's been proposed (and implemented) in the installer right now embraces the slipper slope of taking responsibility for a class of users. This is fraught with epistemic questions, including ethical ones. And the choice is to go after very weak passwords, but not weak ones. Why? What happens to this debate if the minimum passphrase is set to 25 characters? This has sound basis, congruent with all of the concerns from various popular web sites and services, to the cited XKCD, Ars Technica, Schneier articles, and others I've cited elsewhere including security@ list on this topic. Today Schneier raises the possibility the NSA has broken Microsoft's BitLocker. And yet we're debating whether to babysit users passwords. It's a juxtaposition that amuses me greatly. But it's a digression. So why not a 25 character limit? How does that change the debate? I for one would stop even debating it. I think even Kevin could consider just giving up the debate, because at that point, there would be thousands of users who would be having conniption fits. I doubt anyone would dispute this. So what does that tell us? It tells us people don't like being coerced. They don't like their judgement questioned. And it tells us password enforcement proponents presume that all of these ethical problems can be swept under the rug when there are few complainers. Ergo, might makes right. And promptly you've arrived at the very old debate of Thrasymachus. You do not get to just set it aside just because you don't like either its questions or its conclusions. What is Fedora going to be as it grows up? An enforcer of principles? An encourager of principles? An aggressive educator of principles? Let's try a real world example: Briefly opine on the fact on my mobile device I don't set a password at all. It's just a lock screen. Anyone can unlock it. I also don't encrypt it. Does it make you nervous on my behalf? Do you think it's bad judgment? Do you lock and/or encrypt your wallet? If not, why not? How is a mobile device different from a wallet (other than the obvious physical differences)? Are Google, Cyanogen, Apple, Microsoft acting wrongly by permitting no passwords on mobile devices? If so, why would they do this? I use a relatively strong 6 word passphrase for FDE on my laptop however. How do you account for this difference in policy? If you can't explain this sufficiently that you can enable it as an enforceable policy, I don't see how you've done the very basic (though extremely difficult and expensive) epistemic work to start forcing people to change their behavior rather than just educate them. Because without that, I think you'll lack sufficient mandate for a might makes right policy. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Tue, Mar 10, 2015 at 2:16 PM, Chris Murphy li...@colorremedies.com wrote: So why not a 25 character limit? That's maybe confusing. Why not a 25 character minimum? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Björn Persson wrote: Kevin Kofler wrote: The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. There are two possible reasons why you would say that. Either you haven't even looked at the Ars Technica articles that have been discussed in this thread, or else you believe that a majority of users of all sorts of web services think it's all right if all the spies and script kiddies in the world have full access to their accounts. The replies to that message make me wonder if perhaps some people misunderstood what I meant. I haven't clearly expressed any opinions about enforced requirements on passphrases, and some people may have made assumptions about my opinions. In the hope of clearing up any misunderstandings I'll make these statements: · The fact that we don't have a good algorithm for calculating passphrase quality is a good argument against trying to enforce a minimum passphrase quality. · The fact that use cases exist where there is little need for access control – for example temporary and isolated test installations – is a valid argument against trying to enforce a minimum passphrase quality. · The assertion that users in general know what a good password is is not a valid argument, because it's so obviously false that it's plain ridiculous. · A policy that would permit Tr0ub4dor3 because it contains upper case, lower case, digits and symbols, but forbid correct horse battery staple because it's all lower case, would be counterproductive and a terrible mistake. Björn Persson pgprS4myxtORW.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 03/06/2015 06:55 PM, Michael Catanzaro wrote: Well... yes, I suppose if you've left your computer on and locked, and the attacker wants to make sure you do not notice the reboot, or wants to get a RAM dump that would be lost when shut down (e.g. for my gnome-keyring passwords), then there is some benefit, but to a quite limited extent IMO: the attacker is still limited by the speed at which PAM and gdm allow you to try logging in. Every guess takes something like three seconds. So I think a weak password suffices. *cough* https://bugzilla.gnome.org/show_bug.cgi?id=731616 *cough* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Mike Pinkerton wrote: I guess one response would be to give up any pretense of password quality checking, although I am not advocating that. Why not? The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Nico Kadel-Garcia wrote: I'm the guy that brought up the XKCD comic. I did it first. ;-) The classic storage is the Post-it note on the secretary's desk, but I see a lot of people who should know better writing them into source control systems that everyone in the company can read. Or even source control systems that everyone in the *world* can read: http://arstechnica.com/security/2015/03/ubers-epic-db-blunder-is-hardly-an-exception-github-is-awash-in-passwords/ Björn Persson pgpi1R6k9DyHC.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Mon, Mar 9, 2015 at 4:53 PM, Björn Persson Bjorn@rombobjörn.se wrote: Nico Kadel-Garcia wrote: I'm the guy that brought up the XKCD comic. I did it first. ;-) Sorry, I think it was adamw who referenced it on anaconda-devel@ over a month ago when this topic first came up. :-D And I referenced it again on security@ list when I pointed out Adam's correcthorse and correcthorsebatterystaple are accepted by Anaconda, while the XKCD troubadour password it railed against is accepted. Now, that's not the part that's Anaconda's fault. It's not even really libpwquality's fault per se because this is actually a difficult problem to score passwords. However, it's ironic that a now widely published passphrase, including two simple dictionary words, is permitted yet shouldn't be if we really care about this problem, while the actually bad password is permitted. Hence why I think the Anaconda change is utterly pointless, brings no meaningful security gain, for a lot of needless controversy. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Why not? The user surely knows better what a good password is than the software does. If the user picks a crappy password, there's probably a good reason. You have an alarmingly naive understanding of our user base... (not that *I* want to give up control of my passwords, but I'm not an average user) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Am 08.03.2015 um 17:24 schrieb Nico Kadel-Garcia: There's also a counterproductive effect. Passwords that are enforced, by policy, to be nonsensical gibberish tend to be written down, because no one can remember them. And because no one can remember them, they're written down in easily accessed locations. The classic storage is the Post-it note on the secretary's desk, but I see a lot of people who should know better writing them into source control systems that everyone in the company can read correct not so problematic in case of a policy rejecting insecure passwords *but* the real problem are security auditors claiming you have to disable the option to store a password in your browser for web-applications yes, if someone can access that password store you have a problem but given you have a master-password configured the access to the whole firefox profile is pointless if you are forced to note in somewhere it's likely a more dangerous place, if someone combines that policy with you have to change your password every month he is a fool with a theoretic view not aware what damage he does as example my my passwords are 26 chars long, the generator is self written even using openssl random stuff and if some idiot forbids me to store that *impossible to remember* passwords and enforce to change them all the time he gains nothing but problems signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 8 March 2015 at 08:41, Mike Pinkerton pseli...@mindspring.com wrote: Ok, to bring this back around to where we started -- password quality checkers on Fedora: 1. By positing a strategic attacker, we have now reduced the time we expect it to take him/her to crack our 29 character password ( rastafarianestablishmentarian), with whatever amount of entropy it has, to a matter of weeks or months rather than millions of years. Even if we had used a slightly longer password with upper case and numerals -- Rastafarianestablishmentarian2015 -- that would probably still be true because it matches a common pattern of initial upper case and appended numerals. 2. Humans are so good at patterns that we tend to embed them in everything we do, knowingly or unknowingly. Given that, any password or passphrase that a random user can easily remember is likely to match a fairly common pattern. 3. How do you get your password quality checker to recognize all such patterns, rather than just computing a string's entropy? You can't give an absolute number in deterministic time because the problem you are trying to solve is pretty much the travelling sales person problem in one form or another. You can come up with short cuts to give approximate level of 'strength' but you can't give an absolute 0/1 answer. The problem is that the better that you want me to gauge your password's strength the more resources (memory, time, etc) I need to do it. At a certain point it is not worth it so we are going to have to choose a methodology as a first guess and go with that. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Mike Pinkerton wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/ will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass- phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. Quoting Ars commenter epixoip, who claims to be one of the reporter's sources: | However, it is much more complicated to crack a passhrase comprised of | several words selected at random, with say a random word generator. I | have a combinator program that I've written that allows you to combine | an arbitrary number of wordlists together (similar to combinator.bin in | hashcat-utils) and accepts an array of characters to use as word | separators. Sounds awesome, but it's slow as shit and rather | impractical (which is probably why combinator.bin only accepts two | lists.) So while there are some flaws with that XKCD comic's logic, | it's not exactly terrible advice. http://arstechnica.com/security/2012/08/passwords-under-assault/?comments=1post=23189016#comment-23189016 The catch is that the words must be *randomly* chosen. XKCD doesn't stress that point much, and humans are notoriously bad at choosing randomly. I suspect that many people make up some highly nonrandom four-word passphrase and think they have a correct horse battery staple-quality passphrase. I don't think randomness matters at all, only whether the words are in the word list(s) used by the attacker. That means that you assume that the attacker will try to brute-force the passphrase – try all the possible combinations without any optimizations. The Ars Technica article that Bruce Schneier quotes and the second one that he links to both describe at length how the password crackers analyze patterns in passwords so that they can optimize their searches by trying other strings that follow the same patterns. It is naive to assume that they don't analyze patterns in phrases in the same way. And indeed, epixoip says We're already very good at cracking passphrases that are derived from quotes, proverbs, verses, lyrics, or whathaveyou. To avoid getting cracked by such an optimized search you can choose a passphrase with no patterns in it. That is a random passphrase. A truly random passphrase can only be cracked with brute force, so then it's just a matter of estimating how long it needs to be to make brute force impractical. Up-to-date knowledge about the cost of processing power and fairly simple mathematics can yield a good estimate. If you choose a nonrandom phrase to be able to remember it better, for example a grammatically correct phrase, then you need to make it much longer to compensate. Figuring out how much longer it needs to be to make the crackers give up will be mostly guesswork. So as you can see, randomness matters immensely. Björn Persson pgpOg67JLKUNp.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Mike Pinkerton wrote: I was responding to Björn Persson's suggestion that, in discussions of password quality, correcthorsebatterystaple would be an example of a safe password. Safe_r_. Security in passphrases isn't a binary thing. XKCD 936 demonstrates that correct horse battery staple is much more secure than Tr0ub4dor3. (It shows the math in nice graphical form, very easy to follow.) Whether one or the other is secure enough depends on what you use it for. (Of course those two specific examples are worthless as passphrases now that they're famous.) My point is that, if attackers are using strategies other than brute forcing, which the Ars Technica article suggests is the case, then constructing long passwords out of known words is probably not a safe strategy. Those strategies are designed to crack bad passphrases that adhere to common patterns. They don't help with cracking *random* passphrases. And again, the security lies in *how many* words you use. Because the word lists used by attackers are lists of strings that they have scraped from various sources -- human language dictionaries, password strings found in previous attacks, passwords publicized by Adam on mailing lists, strings constructed on patterns (e.g., 7kids, 8kids), etc. -- a string that one would normally think of as four words -- correcthorsebatterystaple -- once it has been discovered as a password once and added to the attacker's word list, becomes only one word for all future cracking attempts. And that's why you shouldn't use a passphrase that is likely to be chosen by anyone else. You should use a *random* combination of several words, or a long *random* string of characters (stored in a password manager). Or else you should make it so long and so individual that no one else is likely to come up with the same phrase – but that's much harder than people think. I bet the person who came up with all of the lights thought it was long and individual enough, but obviously it wasn't. When I was seven, my sister threw my stuffed rabbit in the toilet. might have been. Except that the attackers aren't brute forcing long passwords. Apparently, they can successfully crack a ridiculously high percentage (90% in the Ars Technica experiment) in the space of a day using other techniques. Because a ridiculously high percentage of passwords are badly chosen. Björn Persson pgpwKO6nTL5fN.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 7 Mar 2015, at 20:35, Stephen John Smoogen wrote: On 7 March 2015 at 15:33, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 15:52, Stephen John Smoogen wrote: On 7 March 2015 at 11:53, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass-phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. They limit it to 1-2 words because it takes a LONG time to crack SHA512crypt passwords. You can do on average 32k - 128k hash crypt checks per second per password. A two word dictionary of diceware would have 2^25.85 passwords in it. A single system is going to take 256 seconds on 2 words. Add in 3 words (2^38.775) and it is 24 days. Add in a 4th word and it is 544 years. Add in a 5th word and it is 4.5 million years. Apparently Diceware's creator is not as confident as you -- he nows recommends more than 5 words. http://arstechnica.com/information-technology/2014/03/diceware- passwords-now-need-six-random-words-to-thwart-hackers/ Perhaps improvements in graphics cards have changed the calculus in recent years. Yes and no. 1) He has always wanted to make sure that an attack was going to take billions of years for the US government on. Thus his level of threat is the 100 billion dollar cluster... Which yes 6 or 7 words would be needed if not 8. Your password of completely random characters will also need to be a lot longer. 2) He is also aware that most of the hacks out there have not been SHA512crypt but MD5sum/SHAsum/NT password breaches. If you are lucky they used md5crypt or the original sha1crypt. Those are formats that yes millions of attacks per second can be done in an offline attempt. If you have no control over how the password is stored then using 4 or 5 words is not enough. 3) Yes graphic cards improve with more cores but they do not increase word size as often because there really isn't much need other than cracking large passwords (bitcoin which is the primary use for video cards doesn't get faster with a larger word so it isn't something people will pay for.) Without a larger word size the various code for doing a SHA512crypt gets slow. Neither of the first two items are things which are going to be general users of Linux are needing to deal with. If you are having to worry about that sort of attack then you are going to need a lot more work than a 100+ bit entropy password. While writing this up I went and checked that the whole thing is outlined point for point in wikipedia http://en.wikipedia.org/wiki/Password_strength To estimate the time just do the following: $15,000 computer - 128k/sec = 2^17. Lets assume moore's law comes in and we have 2^20 by 2020. Take the possible entropy and subtract the 2^17 and that will give you the worst case. I believe it may be 1/4 of that so make it subtract 2^19 currently for one system and 2^29 for a cluster of 1024 computers (so 15 million dollars). 2 words is going to be (25.85-19) 115 seconds for one system and 0.1 for big ass cluster. 3 words is going to be (38.78-19) 236 hours ). 1 day for big ass cluster 4 words is going to be (51.70-19) 221 years). 1 year 5 words is going to be (64.63-19) 1.7 million years) 1700 years. (or 1.7 years for a 15 billion dollar investment). To get equivalent strength from say an all lower case password you are going to need 14 [a-z] characters. Now here is the funny thing. All that speed to get 128k is if the password is less than around 12 characters for most cracking software due to the way the hardware and algorithms have been optimized. If the string is longer
Re: FESCO request to revert password confirmation change in F22
On Sun, Mar 8, 2015 at 8:44 AM, Björn Persson Bjorn@rombobjörn.se wrote: Mike Pinkerton wrote: I was responding to Björn Persson's suggestion that, in discussions of password quality, correcthorsebatterystaple would be an example of a safe password. Safe_r_. Security in passphrases isn't a binary thing. XKCD 936 demonstrates that correct horse battery staple is much more secure than Tr0ub4dor3. (It shows the math in nice graphical form, very easy to follow.) Whether one or the other is secure enough depends on what you use it for. (Of course those two specific examples are worthless as passphrases now that they're famous.) Right. I'm the guy that brought up the XKCD comic. The actual message of the comic is entertaining, and enlightening. Our modern password creation policies are forcing us to follow arbitrary mathematical rules that make our passwords *impossible to remember*. And it gets worse. If you have RSI, or a bad keyboard or visual issues, or use a speech-text system, and you're having to type an 8 character mixed case, non-alphabetical passphrase that *you cannot visually review or confirm*, password generation becomes nightmarish. My point is that, if attackers are using strategies other than brute forcing, which the Ars Technica article suggests is the case, then constructing long passwords out of known words is probably not a safe strategy. Those strategies are designed to crack bad passphrases that adhere to common patterns. They don't help with cracking *random* passphrases. And again, the security lies in *how many* words you use. There's also a counterproductive effect. Passwords that are enforced, by policy, to be nonsensical gibberish tend to be written down, because no one can remember them. And because no one can remember them, they're written down in easily accessed locations. The classic storage is the Post-it note on the secretary's desk, but I see a lot of people who should know better writing them into source control systems that everyone in the company can read. Except that the attackers aren't brute forcing long passwords. Apparently, they can successfully crack a ridiculously high percentage (90% in the Ars Technica experiment) in the space of a day using other techniques. Because a ridiculously high percentage of passwords are badly chosen. Björn Persson And a ridiculous number of them are being set, permanently, for admins and trusted users who couldn't spell password rotation if you tattooed one word on each hand. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Michael Catanzaro wrote: On Fri, 2015-03-06 at 19:25 -0500, Miloslav Trmač wrote: The way we deploy LUKS, a single password guess takes one second on a comparable hardware, so the fuzz factor is not actually as large as it might seem. Wow, I had no clue it was that good. OK, so making one guess at the user account password every ~three seconds would not be an unreasonable attack, once you've stolen the computer, given how slow it would be to attack LUKS. I had incorrectly assumed that the difference in speed would be orders of magnitude. Still, this is not a realistic threat for most users, and it would take forever to attack either way, so this really just convinces me that I can be safe with a much weaker disk encryption password than I had previously imagined. :) Don't forget that an attack on the disk encryption can be parallelized, while attempts to unlock the console can not. Björn Persson pgpHNKme0WuDc.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The catch is that the words must be *randomly* chosen. XKCD doesn't stress that point much, and humans are notoriously bad at choosing randomly. I suspect that many people make up some highly nonrandom four-word passphrase and think they have a correct horse battery staple-quality passphrase. Björn Persson pgp10lWlTGRHZ.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass- phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. The catch is that the words must be *randomly* chosen. XKCD doesn't stress that point much, and humans are notoriously bad at choosing randomly. I suspect that many people make up some highly nonrandom four-word passphrase and think they have a correct horse battery staple-quality passphrase. I don't think randomness matters at all, only whether the words are in the word list(s) used by the attacker. In the Ars Technica article, one attacker was using multiple lists, one of which included 111 million words. Another attacker limited himself to a list of 14 million words -- which were real-world passwords that were exposed in an SQL-injection hack several years ago. Note that these words are simply strings -- some might be recognizable as words in a spoken or written language, while others are just character strings (e.g., momof3g or 8kids) that the attacker has culled from one source or another. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 6 March 2015 at 22:58, Mike Pinkerton pseli...@mindspring.com wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html You are missing the sarcasm that Adam was meaning that such an easy and simple password should be flagged for multiple reasons but isn't. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, Mar 6, 2015 at 2:00 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 6 Mar 2015 10:52:34 -0500 David Cantrell dcantr...@redhat.com wrote: From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. I think there were technical arguments, but they were hard to find in a bunch of heated rhetoric in many cases. From my view: * Making this change in isolation now and then having to change it again to match a policy seems like a waste. If we revert enough of it now so we have time to make a policy we can just change it hopefully once. * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. It will, Some of them will simply change it manually, with a manually run 'passwd' command, or by publishing an already encrypted password of arbitrary simplicity with a system management tool or shell script as part of pickstart '%post' process if they know how. If the page had a pointer I'll point out two old documents that point out some of the problems with this let me outsmart people and force my concepts on them in hardcoded software approach. The first is an old XKCD aobut password strength, pointing out just how silly many modern password checkers are: http://xkcd.com/936/ The other is Eric Raymond's Luxury of Ignorance essay, about why so many open source interfaces are so horrible. http://www.catb.org/esr/writings/cups-horror.html In this case, anaconda enforcing a confusing and unclear password strength algorithm with no visible information aoubt how a password is judged 'strong enough would violate Eric's guidelines 1, 2, 3, 4, and 6. It also violates one of my guidelines that he added to that recipe, the one about Are there settings you can do from the command line or hand-editing config files that cannot be done from the GUI? * There's lots of questions around libpwquality and how well it works and what values it should be set at when. * There's lots of UI questions. Currently anaconda says That password is bad but it doesn't say why, or how to choose a good one, leading to some folks getting frustrated because they don't know the rules,etc. I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. I'd LOVE a security policy to give you, but there's pretty much no way we could have such a policy before F22 Alpha, so I think it's reasonable to ask for a (partial) revert so we can try and gather time and people and come up with something for F23. Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. ok. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Absolutely it should. kevin How very sensible! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 7 Mar 2015, at 15:52, Stephen John Smoogen wrote: On 7 March 2015 at 11:53, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass-phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. They limit it to 1-2 words because it takes a LONG time to crack SHA512crypt passwords. You can do on average 32k - 128k hash crypt checks per second per password. A two word dictionary of diceware would have 2^25.85 passwords in it. A single system is going to take 256 seconds on 2 words. Add in 3 words (2^38.775) and it is 24 days. Add in a 4th word and it is 544 years. Add in a 5th word and it is 4.5 million years. Apparently Diceware's creator is not as confident as you -- he nows recommends more than 5 words. http://arstechnica.com/information-technology/2014/03/diceware- passwords-now-need-six-random-words-to-thwart-hackers/ Perhaps improvements in graphics cards have changed the calculus in recent years. While writing this up I went and checked that the whole thing is outlined point for point in wikipedia http://en.wikipedia.org/wiki/Password_strength To estimate the time just do the following: $15,000 computer - 128k/sec = 2^17. Lets assume moore's law comes in and we have 2^20 by 2020. Take the possible entropy and subtract the 2^17 and that will give you the worst case. I believe it may be 1/4 of that so make it subtract 2^19 currently for one system and 2^29 for a cluster of 1024 computers (so 15 million dollars). 2 words is going to be (25.85-19) 115 seconds for one system and 0.1 for big ass cluster. 3 words is going to be (38.78-19) 236 hours ). 1 day for big ass cluster 4 words is going to be (51.70-19) 221 years). 1 year 5 words is going to be (64.63-19) 1.7 million years) 1700 years. (or 1.7 years for a 15 billion dollar investment). To get equivalent strength from say an all lower case password you are going to need 14 [a-z] characters. Now here is the funny thing. All that speed to get 128k is if the password is less than around 12 characters for most cracking software due to the way the hardware and algorithms have been optimized. If the string is longer than that the hardware drops in speed by orders of magnitude. So correctstaple is actually going to take longer than I said. In fact all the numbers I put for 3+ words is probably going to be 10-100 times longer. All of this assumes that the attacker is trying to brute force the entire string -- character by character. In the Ars Technica article I linked to in my previous message, the attackers did not try to brute force anything over 6 characters. Instead, they used other strategies, including the combinator strategy that would have broken correcthorse. There are 2 caveats. 1) Once again, Adam was being sarcastic. He knows the password isn't any good because well he TOLD everyone what it was. He was making fun of the fact that libpwquality does not blacklist it.. which means that correctstaple is the new password of choice (when the old one might have been 123456) I saw your first note that Adam was being sarcastic -- although it probably doesn't matter what password he is using for offline testing of Anaconda and release candidates. I was responding to Björn Persson's suggestion that, in discussions of password quality, correcthorsebatterystaple would be an example of a safe password. My point is that, if attackers are using strategies other than brute forcing, which the Ars Technica article suggests is the case, then constructing long passwords out of known words is probably not a safe strategy.
Re: FESCO request to revert password confirmation change in F22
On 7 March 2015 at 11:53, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass-phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. They limit it to 1-2 words because it takes a LONG time to crack SHA512crypt passwords. You can do on average 32k - 128k hash crypt checks per second per password. A two word dictionary of diceware would have 2^25.85 passwords in it. A single system is going to take 256 seconds on 2 words. Add in 3 words (2^38.775) and it is 24 days. Add in a 4th word and it is 544 years. Add in a 5th word and it is 4.5 million years. While writing this up I went and checked that the whole thing is outlined point for point in wikipedia http://en.wikipedia.org/wiki/Password_strength To estimate the time just do the following: $15,000 computer - 128k/sec = 2^17. Lets assume moore's law comes in and we have 2^20 by 2020. Take the possible entropy and subtract the 2^17 and that will give you the worst case. I believe it may be 1/4 of that so make it subtract 2^19 currently for one system and 2^29 for a cluster of 1024 computers (so 15 million dollars). 2 words is going to be (25.85-19) 115 seconds for one system and 0.1 for big ass cluster. 3 words is going to be (38.78-19) 236 hours ). 1 day for big ass cluster 4 words is going to be (51.70-19) 221 years). 1 year 5 words is going to be (64.63-19) 1.7 million years) 1700 years. (or 1.7 years for a 15 billion dollar investment). To get equivalent strength from say an all lower case password you are going to need 14 [a-z] characters. Now here is the funny thing. All that speed to get 128k is if the password is less than around 12 characters for most cracking software due to the way the hardware and algorithms have been optimized. If the string is longer than that the hardware drops in speed by orders of magnitude. So correctstaple is actually going to take longer than I said. In fact all the numbers I put for 3+ words is probably going to be 10-100 times longer. There are 2 caveats. 1) Once again, Adam was being sarcastic. He knows the password isn't any good because well he TOLD everyone what it was. He was making fun of the fact that libpwquality does not blacklist it.. which means that correctstaple is the new password of choice (when the old one might have been 123456) 2) This is always true http://xkcd.com/538/ And finally. If one were to take the top 1 million known passwords as the dictionary.. then each word would have about 20 bits of entropy. A password generator that outputted stuff like 123456 password trustn01 letmein1 would take 256 or more longer to brute force crack than using diceware. Actually that sounds like a nice project to add to my EN_RN translation project. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 7 March 2015 at 15:33, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 15:52, Stephen John Smoogen wrote: On 7 March 2015 at 11:53, Mike Pinkerton pseli...@mindspring.com wrote: On 7 Mar 2015, at 10:41, Björn Persson wrote: Mike Pinkerton wrote: On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html It's not entirely clear, but I guess you mean that a two-word combination like correct horse won't stand up. That appears to be true. A four-word phrase is an entirely different matter. Each additional word increases the complexity exponentially, so doubling the number of words squares the number of possible combinations. The combinator attack that is described in the Ars Technica article that Bruce Schneier quotes in the above link appears to be an attack that tries combinations of multiple words from one or more of the attacker's word lists. Certainly adding more words to the pass-phrase would make that more difficult. As I don't know the current state of the art in password cracking, I don't know whether attackers typically limit their attacks to only two words, or extend to three or more words. They limit it to 1-2 words because it takes a LONG time to crack SHA512crypt passwords. You can do on average 32k - 128k hash crypt checks per second per password. A two word dictionary of diceware would have 2^25.85 passwords in it. A single system is going to take 256 seconds on 2 words. Add in 3 words (2^38.775) and it is 24 days. Add in a 4th word and it is 544 years. Add in a 5th word and it is 4.5 million years. Apparently Diceware's creator is not as confident as you -- he nows recommends more than 5 words. http://arstechnica.com/information-technology/2014/ 03/diceware-passwords-now-need-six-random-words-to-thwart-hackers/ Perhaps improvements in graphics cards have changed the calculus in recent years. Yes and no. 1) He has always wanted to make sure that an attack was going to take billions of years for the US government on. Thus his level of threat is the 100 billion dollar cluster... Which yes 6 or 7 words would be needed if not 8. Your password of completely random characters will also need to be a lot longer. 2) He is also aware that most of the hacks out there have not been SHA512crypt but MD5sum/SHAsum/NT password breaches. If you are lucky they used md5crypt or the original sha1crypt. Those are formats that yes millions of attacks per second can be done in an offline attempt. If you have no control over how the password is stored then using 4 or 5 words is not enough. 3) Yes graphic cards improve with more cores but they do not increase word size as often because there really isn't much need other than cracking large passwords (bitcoin which is the primary use for video cards doesn't get faster with a larger word so it isn't something people will pay for.) Without a larger word size the various code for doing a SHA512crypt gets slow. Neither of the first two items are things which are going to be general users of Linux are needing to deal with. If you are having to worry about that sort of attack then you are going to need a lot more work than a 100+ bit entropy password. While writing this up I went and checked that the whole thing is outlined point for point in wikipedia http://en.wikipedia.org/wiki/Password_strength To estimate the time just do the following: $15,000 computer - 128k/sec = 2^17. Lets assume moore's law comes in and we have 2^20 by 2020. Take the possible entropy and subtract the 2^17 and that will give you the worst case. I believe it may be 1/4 of that so make it subtract 2^19 currently for one system and 2^29 for a cluster of 1024 computers (so 15 million dollars). 2 words is going to be (25.85-19) 115 seconds for one system and 0.1 for big ass cluster. 3 words is going to be (38.78-19) 236 hours ). 1 day for big ass cluster 4 words is going to be (51.70-19) 221 years). 1 year 5 words is going to be (64.63-19) 1.7 million years) 1700 years. (or 1.7 years for a 15 billion dollar investment). To get equivalent strength from say an all lower case password you are going to need 14 [a-z] characters. Now here is the funny thing. All that speed to get 128k is if the password is less than around 12 characters for most cracking software due to the way the hardware and algorithms have been optimized. If the string is longer than that the hardware drops in speed by orders of magnitude. So correctstaple is actually going to take
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 19:25 -0500, Miloslav Trmač wrote: The way we deploy LUKS, a single password guess takes one second on a comparable hardware, so the fuzz factor is not actually as large as it might seem. Wow, I had no clue it was that good. OK, so making one guess at the user account password every ~three seconds would not be an unreasonable attack, once you've stolen the computer, given how slow it would be to attack LUKS. I had incorrectly assumed that the difference in speed would be orders of magnitude. Still, this is not a realistic threat for most users, and it would take forever to attack either way, so this really just convinces me that I can be safe with a much weaker disk encryption password than I had previously imagined. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: * Case 1: The attacker has physical access to your computer. The user account password is no protection: I think pretty much all of us know how to boot a live image and copy files off the disk that way. A BIOS password would actually help somewhat, to delay the attacker as long as it takes the attacker to drain your battery to reset it. A disk encryption password would be real security. No, the real security is actually the minimum of (disk encryption password)*fuzz, (user account/screen lock password); with a fuzz factor accounting for the fact that disk encryption password can be broken off-line, at full speed, farming it out to thousands of machines, but a screen lock password needs to be typed (or perhaps brute-forced using a keyboard-mimicking USB device, still slower than full speed, and restricted to one guess at a time). The way we deploy LUKS, a single password guess takes one second on a comparable hardware, so the fuzz factor is not actually as large as it might seem. The screen lock password still matters, though it does not need to be as strong as the disk encryption password. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Hi! On Fri, 2015-03-06 at 23:01 +0100, Björn Persson wrote: or if the attacker snuck into your room when you left it to fetch some coffee, and needs to unlock your console, implant a backdoor and sneak back out before you return, or otherwise can't reboot your computer because you would notice it, Well... yes, I suppose if you've left your computer on and locked, and the attacker wants to make sure you do not notice the reboot, or wants to get a RAM dump that would be lost when shut down (e.g. for my gnome-keyring passwords), then there is some benefit, but to a quite limited extent IMO: the attacker is still limited by the speed at which PAM and gdm allow you to try logging in. Every guess takes something like three seconds. So I think a weak password suffices. In the previous paragraph you wrote that it does matter. It seems that what you're actually arguing is that the threshold should be very low. Personally, I'd be fine with the password strength check if the threshold was very low, but my proposed threshold is *way* lower than libpwquality can be configured to accept. Different thresholds could make sense for different products. Obviously many other folks want it completely gone. Changing libpwquality would be quite desirable so we can close the upstream bugs in gnome-control-center and gnome-initial-setup. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Hello, On Fri, Mar 06, 2015 at 09:43:33AM -0500, Adam Jackson wrote: As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that anaconda revert a password behaviour change in the UI from F22, restoring the double-click to confirm weak password behaviour from F21 and earlier. From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. There were quite a few use cases that just don’t warrant that strong a password, and where the insistence on a strong password is only annoying. Even if we completely discounted the Fedora testers, there are personal VMs, and there is Workstation with disabled ssh. Are these not “technical arguments against the change”? Sure, they are disconnected and don’t come packaged in a neat distribution-wide policy, but then neither does the anaconda change. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 19:35 -0500, Miloslav Trmač wrote: There is another very important case where this falls down: the computer is enrolled into AD/IPA and the password is used throughout the organization. Just looking at a local machine does not necessarily tell you what the needed password strength is. This is of course not an argument in favor of making the policy stricter, but it does mean that _every_ way to change the password should respect the system-wide libpwsafe configuration. If the site administrator, along with enrolling into IPA/AD, sets up libpwquality to set up password strength restriction they deem appropriate, _all_ of Workstation should enforce these restrictions. Now perhaps the right default is to _have_ no restrictions but they need to be enforced the moment someone sets them up. I doubt anyone will argue against this. :) Um, “we can’t do $this so we need to leave other parts of the system insecure” is really not sound logic. At the very least we have the option of giving up on VNC instead. And I don’t really see why it would be impossible to add a password strength check for VNC at all; in the worst case we could just store the libpwquality score when the password is set / changed somewhere, and use this stored score to decide whether to warn the user before enabling VNC (storing the scores like this, and telling the attacker which accounts are weak, would be bad on multi-user desktops, but those are rare nowadays and the admin wouldn’t want individual users to go enabling services on such machines anyway). What am I missing? Eh, well by my logic they are both so closely-related that it's nonsense to treat them differently... but that comment was more a wishful somebody please fix VNC or rewrite history than anything. I have no clue why VNC passwords are limited/truncated to eight characters, but it seems like that limitation makes the protocol not worth supporting at all, let alone worth promoting in System Settings. I wonder how well FreeRDP is coming along -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
I have no clue why VNC passwords are limited/truncated to eight characters, but it seems like that limitation makes the protocol not worth supporting at all, let alone worth promoting in System Settings. The only VNC authentication mechanism standardized in RFC 6143 uses the password as a DES key, which limits it to 8 (7-bit) bytes. The VNC protocol can, however, support several different kinds of authentication, and several have been defined as vendor extensions. See e.g. http://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst#security-types . Restricting to non-standard authentication types, would, of course, impact interoperability. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Hello, On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: * Case 1: The attacker has physical access to your computer. * Case 2: The attacker doesn't have physical access to your computer. The user account password is irrelevant. My argument in Case 2 does fall down if the user enables SSH in the Sharing panel of System Settings. That's indeed disabled by default, though. It also falls down if the user enables VNC in the Sharing panel, but that is an orthogonal issue as that's not your user account password, and it's limited to eight characters regardless. There is another very important case where this falls down: the computer is enrolled into AD/IPA and the password is used throughout the organization. Just looking at a local machine does not necessarily tell you what the needed password strength is. This is of course not an argument in favor of making the policy stricter, but it does mean that _every_ way to change the password should respect the system-wide libpwsafe configuration. If the site administrator, along with enrolling into IPA/AD, sets up libpwquality to set up password strength restriction they deem appropriate, _all_ of Workstation should enforce these restrictions. Now perhaps the right default is to _have_ no restrictions but they need to be enforced the moment someone sets them up. I mention it because I hesitate to add a password strength check when enabling SSH unless we do so for VNC as well, which would be impossible. Um, “we can’t do $this so we need to leave other parts of the system insecure” is really not sound logic. At the very least we have the option of giving up on VNC instead. And I don’t really see why it would be impossible to add a password strength check for VNC at all; in the worst case we could just store the libpwquality score when the password is set / changed somewhere, and use this stored score to decide whether to warn the user before enabling VNC (storing the scores like this, and telling the attacker which accounts are weak, would be bad on multi-user desktops, but those are rare nowadays and the admin wouldn’t want individual users to go enabling services on such machines anyway). What am I missing? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 6 March 2015 at 19:13, Michael Catanzaro mcatanz...@gnome.org wrote: On Fri, 2015-03-06 at 19:35 -0500, Miloslav Trmač wrote: Eh, well by my logic they are both so closely-related that it's nonsense to treat them differently... but that comment was more a wishful somebody please fix VNC or rewrite history than anything. I have no clue why VNC passwords are limited/truncated to eight characters, but it seems like that limitation makes the protocol not worth supporting at all, let alone worth promoting in System Settings. I wonder how well FreeRDP is coming along Wasn't http://www.spice-space.org/ a solution to be looked at also? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
David Cantrell wrote: From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. [...] Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. In other words, you want to give in only temporarily for one release and we will have to fight this nonsense again at every single release? Why can't you just take a no as a no? It is not Anaconda's job to reject perfectly valid passwords just because it doesn't like them. Even the empty string is a valid password. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FESCO request to revert password confirmation change in F22
As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that anaconda revert a password behaviour change in the UI from F22, restoring the double-click to confirm weak password behaviour from F21 and earlier. As for how that's realized: I'm not picky. If it makes more sense from a development or maintenance perspective to keep the revert in fedora package git rather than rhinstaller upstream, that's fine; if it makes more sense to revert upstream as well, that's fine too. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. For FESCO, - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 10:52 -0500, David Cantrell wrote: I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. Speaking only for myself: yeah, I didn't like it either. I voted against it (asking for a revert) in the 28 February meeting because I was hoping the engineering teams actually involved would be willing to work with each other. That appears not to have happened, which I consider deeply disappointing all around. There wasn't _no_ technical discussion. Plenty of people were willing to point out that pwquality being overzealous was making it reject passwords that would otherwise have passed on F21, or would be expected to be sufficiently strong according to whatever metric. Plenty of people were willing to point out the ways policy might vary here depending on the deployment scenario. But nobody was willing to make those ideas manifest in, you know, code. So the technical consideration (I felt) we were left with was not regressing relative to F21. That is a stunningly weak justification, given that what we're regressing from wasn't especially well-defined and that we change plenty of things in every release, but here we are. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Indeed. I'll bring this back to fesco to find someone to head this up. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, Mar 06, 2015 at 09:43:33AM -0500, Adam Jackson wrote: As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that anaconda revert a password behaviour change in the UI from F22, restoring the double-click to confirm weak password behaviour from F21 and earlier. From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. As for how that's realized: I'm not picky. If it makes more sense from a development or maintenance perspective to keep the revert in fedora package git rather than rhinstaller upstream, that's fine; if it makes more sense to revert upstream as well, that's fine too. Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Thanks, -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 6 Mar 2015 10:52:34 -0500 David Cantrell dcantr...@redhat.com wrote: From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. I think there were technical arguments, but they were hard to find in a bunch of heated rhetoric in many cases. From my view: * Making this change in isolation now and then having to change it again to match a policy seems like a waste. If we revert enough of it now so we have time to make a policy we can just change it hopefully once. * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. * There's lots of questions around libpwquality and how well it works and what values it should be set at when. * There's lots of UI questions. Currently anaconda says That password is bad but it doesn't say why, or how to choose a good one, leading to some folks getting frustrated because they don't know the rules,etc. I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. I'd LOVE a security policy to give you, but there's pretty much no way we could have such a policy before F22 Alpha, so I think it's reasonable to ask for a (partial) revert so we can try and gather time and people and come up with something for F23. Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. ok. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Absolutely it should. kevin pgpLnYYTxzjio.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: * Case 1: The attacker has physical access to your computer. The user account password is no protection: I think pretty much all of us know how to boot a live image and copy files off the disk that way. A BIOS password would actually help somewhat, to delay the attacker as long as it takes the attacker to drain your battery to reset it. A disk encryption password would be real security. * Case 2: The attacker doesn't have physical access to your computer. The user account password is irrelevant. --- This is a pretty simple argument, can anyone point out a flaw? --- My argument in Case 2 does fall down if the user enables SSH in the Sharing panel of System Settings. That's indeed disabled by default, though. It also falls down if the user enables VNC in the Sharing panel, but that is an orthogonal issue as that's not your user account password, and it's limited to eight characters regardless. I mention it because I hesitate to add a password strength check when enabling SSH unless we do so for VNC as well, which would be impossible. Maybe someone else has a good idea here. What if the attacker is not after any files on your computer, but just your password so that he can reuse it somewhere else? In that case, password strength still doesn't matter: if he can see the hash of your password in /etc/shadow to try cracking it, he has already pwned you and might as well log your keystrokes. If the attacker is unskilled and doesn't know how to boot a live image, and the password is *exceedingly* bad (123, alice, mcatanzaro etc.), then it would matter if the attacker could guess it. I personally see little harm in taking the ball away from those who'd use passwords like those. Possibly there is something I have missed -- if someone can set me straight as to a safety issue I am missing, that'd be dandy -- but I for one have yet to see an argument that the strength of the password matters at all! Now, enforcing a strong *disk encryption password* and turning on disk encryption by default (at least for laptops): that would be some actual security. :) Michael signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 15:14 -0600, Michael Catanzaro wrote: On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: I don't care of have a password strength, maybe like 8 characters and one being a number, should be enough. But they made it so strong, and no information at all on what the problem was, nor info on minimum it took to create one. That and, guess I missed those millions of emails that complained on passwords getting cracked and stolen from all the linux computers in the world, that had to all of a sudden cause a panic to strengthen passwords in the installer. -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: Adam Jackson wrote: FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Indeed. I'll bring this back to fesco to find someone to head this up. I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Michael Catanzaro wrote: If the attacker is unskilled and doesn't know how to boot a live image, or if the attacker snuck into your room when you left it to fetch some coffee, and needs to unlock your console, implant a backdoor and sneak back out before you return, or otherwise can't reboot your computer because you would notice it, and the password is *exceedingly* bad (123, alice, mcatanzaro etc.), then it would matter if the attacker could guess it. I personally see little harm in taking the ball away from those who'd use passwords like those. Possibly there is something I have missed -- if someone can set me straight as to a safety issue I am missing, that'd be dandy -- but I for one have yet to see an argument that the strength of the password matters at all! In the previous paragraph you wrote that it does matter. It seems that what you're actually arguing is that the threshold should be very low. Björn Persson pgpGQzcIqmkbn.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
Adam Jackson wrote: FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Indeed. I'll bring this back to fesco to find someone to head this up. I hope https://xkcd.com/936/ will be among the inputs to that discussion. Björn Persson pgpV5os4uho4_.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
