Hi,
First some background:
Anaconda 22.17+ has started to enforce the following: +- Don't allow weak LUKS passwords either (bcl) +- Don't allow weak passwords (text mode). (sbueno+anaconda) +- Remove the press done twice to exit text (bcl) +- Don't allow weak user passwords (bcl)
test@ list 1st announcement of change, and the ensuing 91 (and counting) email thread which you're welcome to skip as I'll attempt to cover the salient points in this email: https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html
The impetus behind the change are the two scope bullets in this rejected change: https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
A FESCO ticket has been opened asking for review: https://fedorahosted.org/fesco/ticket/1412
And then some points:
- I think it'll make users angry. The test@ list is overwhelmingly against the change, and I expect they're more tolerant and understanding compared to the wider community.
- On Windows and OS X server variants, remote access (in-bound) services are disabled by default. It's expected to use an OOB method to initially connect to a server (or even VM) and enable the desired services.
- libpwquality is what's being used to "grade" the quality of the passwords used in anaconda. This has been referred to as having capricious behavior in the test@ thread. In a 2 day old build of boot.iso which contains the current version of libpwquality and anaconda 22.17, I'm finding the following:
The gibberish password that an infamous xkcd comic strip railed against # pwscore Tr0ub4dor&3 67 ##anaconda=good
8 actually random lowercase latin characters. # pwscore liampres 4 # pwscore amptiato 4 # pwscore tempeadj 1 # pwscore clungerm 1
8 random characters mixed case, numbers, specials. # pwscore CHYtU$W3 27 # pwscore ja#P2etw 27 # pwscore 6*T!MsjD 21
Portions of widely published phrases, lowercase latin characters. # pwscore correcthorse 41 ##anaconda=fair # pwscore batterystaple 55 # pwscore correcthorsebatterystaple 100 # pwscore onceuponatimetherewasa 100 # pwscore itwasthebestoftimes 100 # pwscore lookbeforeyouleap 90 # pwscore dropdeadgorgeous 75
I don't have an easy way to prove this, but in a millions+ attempt brute force attack, I find it difficult to believe that correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted. I had recently read that up to 100 character dictionary only word based passwords were routinely attempted in brute force attacks.
I think the change improperly shifts burden to all users without respect to their use case, in a manner inconsistent with the device control they've come to expect: no password requirements at all on mobile devices, and very minimalist ones on Windows and OS X. I don't see how being an outliar in this area, even among Linux distros, helps.
Conclusion: I think the concerning services need to be disabled by default, and use OOB management to enable those services, since it's a long standing practice elsewhere. If we can do better than this, fine, but not by shifting the security burden.
Thanks,
On Thursday 12 February 2015 17:09:56 Chris Murphy wrote:
I don't have an easy way to prove this, but in a millions+ attempt brute force attack, I find it difficult to believe that correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted. I had recently read that up to 100 character dictionary only word based passwords were routinely attempted in brute force attacks.
yes, it's rather well known that there are... deficiencies in the way libpwquality scores passwords: https://bugzilla.redhat.com/show_bug.cgi?id=983187 https://bugzilla.redhat.com/show_bug.cgi?id=985463 https://bugzilla.redhat.com/show_bug.cgi?id=970222 https://bugzilla.redhat.com/show_bug.cgi?id=985411 https://bugzilla.redhat.com/show_bug.cgi?id=1005313 https://bugzilla.redhat.com/show_bug.cgi?id=985356 https://bugzilla.redhat.com/show_bug.cgi?id=985364 https://bugzilla.redhat.com/show_bug.cgi?id=1005276
and then cracklib (which is used for the dictionary part of check) has few bugs still: https://bugzilla.redhat.com/show_bug.cgi?id=963769 https://bugzilla.redhat.com/show_bug.cgi?id=986400 https://bugzilla.redhat.com/show_bug.cgi?id=985378 https://bugzilla.redhat.com/show_bug.cgi?id=1146814
I'm all for the change in question (no bad passwords accepted by Anaconda), but for that we *first* need: - libpwquality that has at least a 0.1% rate of false positives, if not lower - generator for good passwords that will pass the above checks and are easy to remember (something that generates "horse battery"-like passwords) and presents them to the user if he or she has problem entering the password
What many people forget is that NIST SP 800-63-1 *doesn't* specify that passwords have to be 6 or 8 character long with such-and-such character classes. It says that passwords have to have 10 or 14 bits of *entropy*. It also *requires* rate limiting for the logons. Current password checkers can't even approximate that, let alone check properly.
On Fri, Feb 13, 2015 at 4:00 AM, Hubert Kario hkario@redhat.com wrote:
On Thursday 12 February 2015 17:09:56 Chris Murphy wrote:
I don't have an easy way to prove this, but in a millions+ attempt brute force attack, I find it difficult to believe that correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted. I had recently read that up to 100 character dictionary only word based passwords were routinely attempted in brute force attacks.
yes, it's rather well known that there are... deficiencies in the way libpwquality scores passwords: https://bugzilla.redhat.com/show_bug.cgi?id=983187 https://bugzilla.redhat.com/show_bug.cgi?id=985463 https://bugzilla.redhat.com/show_bug.cgi?id=970222 https://bugzilla.redhat.com/show_bug.cgi?id=985411 https://bugzilla.redhat.com/show_bug.cgi?id=1005313 https://bugzilla.redhat.com/show_bug.cgi?id=985356 https://bugzilla.redhat.com/show_bug.cgi?id=985364 https://bugzilla.redhat.com/show_bug.cgi?id=1005276
and then cracklib (which is used for the dictionary part of check) has few bugs still: https://bugzilla.redhat.com/show_bug.cgi?id=963769 https://bugzilla.redhat.com/show_bug.cgi?id=986400 https://bugzilla.redhat.com/show_bug.cgi?id=985378 https://bugzilla.redhat.com/show_bug.cgi?id=1146814
I'm all for the change in question (no bad passwords accepted by Anaconda), but for that we *first* need:
- libpwquality that has at least a 0.1% rate of false positives, if not lower
- generator for good passwords that will pass the above checks and are easy to remember (something that generates "horse battery"-like passwords) and presents them to the user if he or she has problem entering the password
Aside from the ethical problem of using coercion instead of innovative persuasion, is the consequence of a premature attempt to close this perceived weakness. Trust is hugely important in this area. I think implementing this change further damages trust by the user in Fedora decision making, and there's a recent incident of password policy change happening in the installer:
https://bugzilla.redhat.com/show_bug.cgi?id=958608 https://lists.fedoraproject.org/pipermail/devel/2013-May/thread.html#182196
While I agree the minimum barrier is for the software to not behave capriciously, and for actual guidelines to appear in the UI so the user can set a minimally compliant password in a single attempt, I still don't agree it can be made compulsory without very negative consequences. The context isn't a service, it's the user's own device. Upon what line of reasoning is this power usurped from the user to the Fedora installer? Thus far it sounds like an ends justifies the means argument.
Seemingly a more reasonable stick and carrot approach, is a UI that ties services to passworth strength. For example, the UI conveys sshd is disabled by default, and cannot be enabled (in the installer) until a minimum strength password is supplied. This suggests a lesser quality password is acceptable when services that raise vulnerability are disabled. But before such services can be enabled (in the installer), a stronger password is needed.
Right now there is only stick. That's trust damaging, not enhancing.
What many people forget is that NIST SP 800-63-1 *doesn't* specify that passwords have to be 6 or 8 character long with such-and-such character classes. It says that passwords have to have 10 or 14 bits of *entropy*. It also *requires* rate limiting for the logons. Current password checkers can't even approximate that, let alone check properly.
There's more than one paper floating around challenging the usefulness password entropy concept in NIST SP800-63. Actually this one uses stronger wording:
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpb...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, Feb 12, 2015 at 05:09:56PM -0700, Chris Murphy wrote:
I don't have an easy way to prove this, but in a millions+ attempt brute force attack, I find it difficult to believe that correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted. I had recently read that up to 100 character dictionary only word based passwords were routinely attempted in brute force attacks.
I have a really awesome white paper sitting on a hard drive around here somewhere that explains this perfectly. It comes down to the math involved. Assuming all characters are available, letters (upper case and lower), numbers, and symbols, creates a good number of available choices for each password character. It turns out, however, that using more characters in your password, assuming just letters, is far better than using a shorter password with everything. Combine both of these, long password with all available character sets, and you get a really difficult password to break.
The other problem is the use of dictionary words. With the rainbow tables available out there most brute force attacks start as dictionary attacks. So using a word from the dictionary can really be bad. I used to run John on highly secured enterprise systems only to break a high percentage of the passwords in less than 90 seconds (looking directly at the password hashes, not trying to gain entry to the system which is a bit harder.
I think the change improperly shifts burden to all users without respect to their use case, in a manner inconsistent with the device control they've come to expect: no password requirements at all on mobile devices, and very minimalist ones on Windows and OS X. I don't see how being an outliar in this area, even among Linux distros, helps.
Yeah, but users are dumb. They think their use case is a computer sitting in their house and that with this they are fine. And this works great until their house is broken into or they leave their backpack, with their computer inside, on the subway and only then do they realize (or maybe they don't) that their security could have been better.
Never never never look to Windows or OS X as a way to show how things should be. These operating systems are horrible. From my experience, Linux users typically see Linux as more secure because we have better code and we don't allow dumb things (or we used to not do dumb things anyway). Sometimes you just have to lead by example instead of looking around and trying to built other people's bad ideas into your product.
Oh, I said above that live attacks are more difficult than ones specifically looking at password hashes. I'll explain this part a bit as I think it shows where we can balance user and backend burden. When I have a hash table I can pour over it, almost indefinitely, to try to break a password. I generally cannot do this on a properly configured system because of rate limiting and maximum retries. If a system only allows for three tries before the account is locked I will likely not be able to break the password using brute force but would rather require some intelligence information (and I always start with sports team names).
In the end, passwords are all rubbish and should be done away with. What are the other options, though? I suspect most people aren't using smartcards to log into their systems (or any other kind of multi-factor authentication). Until these options become more in use we need to raise the bar for password use. People are carrying around more sensitive infromation with them in their pockets and on their backs and by not properly securing their system they are just asking for trouble.
Conclusion: I think the concerning services need to be disabled by default, and use OOB management to enable those services, since it's a long standing practice elsewhere. If we can do better than this, fine, but not by shifting the security burden.
I really hate it when people say to disable security features by default. It's just really short sighted. People don't want to have to go through their system changing switches and adding configuration just to have a secure system. Users expect their system to be secure by default. If it's too much work to secure their systems properly they will either lose interest or forget to check a box and then get into trouble later. It's much easier to remove a security feature someone feels strongly about instead of trying to implement everything with the potential of forgetting something or the inability to properly test a particular functionality.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Fri, Feb 13, 2015 at 7:57 AM, Eric H. Christensen sparks@fedoraproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, Feb 12, 2015 at 05:09:56PM -0700, Chris Murphy wrote:
I don't have an easy way to prove this, but in a millions+ attempt brute force attack, I find it difficult to believe that correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted. I had recently read that up to 100 character dictionary only word based passwords were routinely attempted in brute force attacks.
I have a really awesome white paper sitting on a hard drive around here somewhere that explains this perfectly. It comes down to the math involved. Assuming all characters are available, letters (upper case and lower), numbers, and symbols, creates a good number of available choices for each password character. It turns out, however, that using more characters in your password, assuming just letters, is far better than using a shorter password with everything. Combine both of these, long password with all available character sets, and you get a really difficult password to break.
The goal of the brute force attack is to gain access, quickly. So the strategy is always changing on both sides. What's true a few years ago isn't necessarily true today.
http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-cha...
I think it's much more likely a user has a 2, 3, or possibly a 4 word password based on dictionary words, than truly random 8 using all available ASCII characters. I'd expect at least 2 word combinations from a dictionary to be attempted before random 8, and probably 3 word combinations are.
Diceware is recommending 5 word passphrases as the minimum. I just don't see that being accepted by users for a device. Sure for Twitter but the context and consequences are totally different.
Yeah, but users are dumb. They think their use case is a computer sitting in their house and that with this they are fine. And this works great until their house is broken into or they leave their backpack, with their computer inside, on the subway and only then do they realize (or maybe they don't) that their security could have been better.
a. The contra argument is that software engineers are dumb, they should design this stuff better instead of dumping more complexity onto the user. Ergo, be careful with flinging ad hominem attacks. Once they're in bounds, the monkey on the other side of the debate is just as full of crap.
b. Your example are bad ones. The installer doesn't mandate encrypted volumes, and only encrypted volumes protect against your examples. A stronger user or root password does exactly nothing. It doesn't alter the time it takes me to own your data by even 1 second.
Never never never look to Windows or OS X as a way to show how things should be. These operating systems are horrible. From my experience, Linux users typically see Linux as more secure because we have better code and we don't allow dumb things (or we used to not do dumb things anyway). Sometimes you just have to lead by example instead of looking around and trying to built other people's bad ideas into your product.
Or you can lead by example with your own bad ideas into your product. I have examples of this in Fedora if you ask.
But your style of debate above is sloppy, it contains no facts, it's hand waiving and glittering generalities. I'll take on your disk encryption non-suggestion from earlier since that's still peripherally on topic:
OS X simply does it loads better than anyone. It can be opted into at any time, post-install. Click two buttons and conversion begins. The system can continue to be used, put to sleep, or even rebooted. The user login is tied to unlocking the volume. This makes it more likely the user will use disk encryption, only one password to know. It also means the singular location for changing user password means disk unlocking password is updated at the same time, the old password will not unlock the volume. Further it means adding users causes no change in UI from a non-encrypted system.
Linux: Well, we know how it works, it it's not like this. It's viciously user hostile in comparison. It's in strictly in the realm for sysadmin, esoteric level knowledge to manage this at all.
So give up the cave man style debate tactic. "Windows bad! UGHH! Mac bad! UGHH!" isn't exactly convincing to any of my house plants, or me.
Oh, I said above that live attacks are more difficult than ones specifically looking at password hashes. I'll explain this part a bit as I think it shows where we can balance user and backend burden. When I have a hash table I can pour over it, almost indefinitely, to try to break a password. I generally cannot do this on a properly configured system because of rate limiting and maximum retries. If a system only allows for three tries before the account is locked I will likely not be able to break the password using brute force but would rather require some intelligence information (and I always start with sports team names).
In the end, passwords are all rubbish and should be done away with. What are the other options, though? I suspect most people aren't using smartcards to log into their systems (or any other kind of multi-factor authentication). Until these options become more in use we need to raise the bar for password use. People are carrying around more sensitive infromation with them in their pockets and on their backs and by not properly securing their system they are just asking for trouble.
Do you not see how your password policy defend hinges on grandiose assumptions? I have many devices lying around without any information on them, they're used strictly for testing, so there isn't anything but an OS and some cache files for ycombinator and cnn, BFD. Oh but I need to use strong passwords because someone ELSE might be an idiot and have sensitive information on their laptop. So you are drawing me into becoming responsible for other people's behavior too. Everyone is baby sitting users who don't give a crap.
But let's say you're right, you thus far haven't argued for mandatory disk encryption, which is really the only way to solve the problems you keep using as examples. And yet it's a good thing you aren't arguing for mandatory disk encryption because that UX is such complete utter shit on Linux right now it is a Do Not Pass Go scenario. It could never happen.
Meanwhile over on OS X, Apple is quite well situated for the next version of the OS to default to disk encryption enabled, and the user's workflow won't be impacted at all.
But I agree passwords are rubbish and solving that problem is one of the Holy Grails. But this doesn't mean forcing users is better than getting their compliance voluntarily.
Do you really think it'll go over well that Fedora *forces* users to do something other platforms don't? I don't think there's an award for this waiting.
Conclusion: I think the concerning services need to be disabled by default, and use OOB management to enable those services, since it's a long standing practice elsewhere. If we can do better than this, fine, but not by shifting the security burden.
I really hate it when people say to disable security features by default. It's just really short sighted.
I really hate it when people say to enable security features by default. It's just really short sighted.
See how two can play that game? Do better.
First, sshd is not a security feature, it's a remote connection service and increases the attack surface. Disable that. It has a lower burden on more people, and it's also an expected burden for anyone come from other enterprise cultures. The idea a Windows Server would have remote services enabled by default? I think most any hard core Windows sysadmin who also doesn't make bad excuses for Microsoft would admit this could be a liability lawsuit waiting to happen if they were to do that. That's how bad an idea it is.
And stronger password requirements is not a security feature, it's an imposition.
People don't want to have to go through their system changing switches and adding configuration just to have a secure system.
I honestly have no idea what you're talking about. Users can have stronger passwords if they want to opt into this, at any time. Force is not required. Flipping switches not required.
Users expect their system to be secure by default. If it's too much work to secure their systems properly they will either lose interest or forget to check a box and then get into trouble later. It's much easier to remove a security feature someone feels strongly about instead of trying to implement everything with the potential of forgetting something or the inability to properly test a particular functionality.
Users expect their system to be secure by default, meanwhile sshd is enabled by default on Fedora 21 Server. Can you honestly not connect the dots here? The very thing that's enabled by default is the very thing being held up as the #1 reason why stronger passwords are needed by default. If that service is disabled, a massive bulk of the argument for stronger login passwords at install time is reduced.
Further, weak passwords are immediately, visually communicated in the installer UI. The user always has this information available to them.
Meanwhile, the fact sshd is enabled is not ever communicated in the installer UI. The user lacks this information.
But what you're saying is, it's the user that's the problem? The user has perfect information of the former, not the later, yet it's the former that needs enhancement? What?
Even if I accept the absurdity of full disclosure needing more enhancement vs no disclosure, it means you don't trust the user. If you trusted the user, simply informing them would be enough. But informing them isn't enough, you have to force them. Therefore it's clear they aren't trusted. If they aren't trusted, then why do you trust they know the risk behind sshd enabled by default?
On Friday 13 February 2015 14:42:09 Chris Murphy wrote:
Do you not see how your password policy defend hinges on grandiose assumptions? I have many devices lying around without any information on them, they're used strictly for testing, so there isn't anything but an OS and some cache files for ycombinator and cnn, BFD. Oh but I need to use strong passwords because someone ELSE might be an idiot and have sensitive information on their laptop. So you are drawing me into becoming responsible for other people's behavior too. Everyone is baby sitting users who don't give a crap.
you should take a look at traffic laws, they all are about "someone ELSE might be an idiot"
If you know you will be using the device for testing then just change the password post-install to something simple.
The vast majority of people won't be using the installations just for testing.
First, sshd is not a security feature, it's a remote connection service and increases the attack surface. Disable that. It has a lower burden on more people, and it's also an expected burden for anyone come from other enterprise cultures. The idea a Windows Server would have remote services enabled by default? I think most any hard core Windows sysadmin who also doesn't make bad excuses for Microsoft would admit this could be a liability lawsuit waiting to happen if they were to do that. That's how bad an idea it is.
but they do
you can certainly run commands remotely on a Windows Server system as soon as you connect it to a domain, just because the remote GUI login is disabled doesn't make remote services and administration disabled
On Mon, Feb 16, 2015 at 10:22 AM, Hubert Kario hkario@redhat.com wrote:
On Friday 13 February 2015 14:42:09 Chris Murphy wrote:
Do you not see how your password policy defend hinges on grandiose assumptions? I have many devices lying around without any information on them, they're used strictly for testing, so there isn't anything but an OS and some cache files for ycombinator and cnn, BFD. Oh but I need to use strong passwords because someone ELSE might be an idiot and have sensitive information on their laptop. So you are drawing me into becoming responsible for other people's behavior too. Everyone is baby sitting users who don't give a crap.
you should take a look at traffic laws, they all are about "someone ELSE might be an idiot"
No there are numerous logical fallacies here. There are threats of fines and jail time, there is no active "pre-crime" coercion that somehow compels incompetents to alter decision making. Idiots still break the law, they run red lights, there are still traffic accidents. Traffic laws are about normalization, in effect they're a spec so that users have expectations and trust in a transit system that would otherwise be chaotic.
You should take a look at collective punishment.
If you know you will be using the device for testing then just change the password post-install to something simple
The vast majority of people won't be using the installations just for testing.
Your work around belies the change itself and results in equivocation.
This is what I hear: inconveniencing testers is unfortunate but ultimately it's OK because it's a small group. One small set of helpful and responsible users will in effect be collectively punished, over and over again (some testers do dozens of new installs per week, even per day) in order to coddle the emotional state of a handful of control minded types who are completely out of ideas (or time) to convince a 3rd group of users to stop using weak passwords voluntarily, therefore have decided coerce them into capitulation along with the ensuing collateral affects. But it's OK because better security is always better. Pissing people off is not the goal, but it's an acceptable trade off in this case.
It's more likely I'll stop testing the installer, so far I haven't since the change appeared in the 22.17 build. The burden is too high, and philosophically I'm diametrically opposed. I think the change is unethical. My password policy is mine. It is not yours, it is not Fedora's. The device is mine, it's not yours or Fedora's. The change is a misplaced appropriation to the point I consider it misfeasance.
First, sshd is not a security feature, it's a remote connection service and increases the attack surface. Disable that. It has a lower burden on more people, and it's also an expected burden for anyone come from other enterprise cultures. The idea a Windows Server would have remote services enabled by default? I think most any hard core Windows sysadmin who also doesn't make bad excuses for Microsoft would admit this could be a liability lawsuit waiting to happen if they were to do that. That's how bad an idea it is.
but they do
you can certainly run commands remotely on a Windows Server system as soon as you connect it to a domain, just because the remote GUI login is disabled doesn't make remote services and administration disabled
Powershell might be enabled by default in more recent versions but then there's also execution policies in place. The scope of the risk is still apparently low enough that not even Microsoft, with its history of security issues, bothers to insist on an installer mandating long or complex passwords.
All of these attempts to change the policy, and individual one-line patches, show there is a fairly high perceived need to do “something”; our default setup just isn’t so good that we can confidently leave it unchanged.
And, we actually _could_ improve both the security and usability of the system, with some work.
We could detect whether a system being installed is a VM. (And someone smarter than me could maybe figure out a way to test whether a VM is behind local NAT, i.e. a personal or testing machine, or bridged to a larger network.)
We could disable ssh on interactive installations (if you are installing interactively you will also run firstboot interactively and can log in interactively and enable ssh interactively) and enable it on kickstart installations (while still having interactive installations record a kickstart that disables ssh).
We could figure out a reasonable rate limiting policy for ssh, and depend on it to allow weaker passwords.
Ultimately, we could fix the LUKS/system login dual password situation.
And I’m sure there are many other possible improvements.
All of this just takes a willingness to look at a dozen components at a time instead of at a single one, and a willingness to write patches that sum up to thousand lines instead of a single five-line patch. Now only if there were anyone able and willing to take this on; I will ask around but so far I don’t know of anyone with too much free time on their hands. Mirek
On Mon, Feb 16, 2015 at 9:18 AM, Miloslav Trmač mitr@redhat.com wrote:
All of these attempts to change the policy, and individual one-line patches, show there is a fairly high perceived need to do “something”; our default setup just isn’t so good that we can confidently leave it unchanged.
And, we actually _could_ improve both the security and usability of the system, with some work.
We could detect whether a system being installed is a VM. (And someone smarter than me could maybe figure out a way to test whether a VM is behind local NAT, i.e. a personal or testing machine, or bridged to a larger network.)
We could disable ssh on interactive installations (if you are installing interactively you will also run firstboot interactively and can log in interactively and enable ssh interactively) and enable it on kickstart installations (while still having interactive installations record a kickstart that disables ssh).
We could figure out a reasonable rate limiting policy for ssh, and depend on it to allow weaker passwords.
Ultimately, we could fix the LUKS/system login dual password situation.
And I’m sure there are many other possible improvements.
All of this just takes a willingness to look at a dozen components at a time instead of at a single one, and a willingness to write patches that sum up to thousand lines instead of a single five-line patch. Now only if there were anyone able and willing to take this on; I will ask around but so far I don’t know of anyone with too much free time on their hands.
This is exactly the more important issue that the password change distracts from. And my objection is, this state of affair hasn't been presented to the wider community along with the commensurate request for a change in password policy as a necessary consequence.
In the meantime, there's this distracting resistance to the pw quality change. Workstation WG has expressed a desire to opt out of this change. And before the change was announced, in a recent Server SIG meeting one person suggested longer passwords might be acceptable but not more complex ones. Therefore it's plausible two product WG's will express dislike for the change and may even opt out of it. And then what? What's next?
Assuming admonishing and coercing is ever OK, I'd sooner do it in favor of cooperation and cohesiveness in Fedora as an OS, rather than against a scant number of stubborn users who can't take a hint (literally) about their password quality. The former is a boulder, the latter is a pebble, but moving that boulder is the real deal by which eventually we could move mountains. Moving a pebble? It's a aggravation for essentially zero gain. I think it's silly (and annoying).
I'm noticing that Fedora depends on the user passworld, plus a salt, and the glibc sha512-crypt.c default of 5000 rounds through SHA512, to create the hash found in /etc/shadow.
- Could the security team provide some guidance on the work needed, the time frame required, to increase the number of rounds? And also how many rounds should it be set to? I think this can be done by modifying /etc/pam.d/passwd. And if there's consensus on this, or any other alternative, if it could be noted in this FESCo ticket, I think that would be helpful. https://fedorahosted.org/fesco/ticket/1412
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy. I think such a policy needs to involve the security team, and possibly some work that there just isn't time for before Fedora 22 although I could be wrong about that part. Changing the number of rounds used to arrive at the password hash gives breathing room both security wise, and time wise for a better and stronger strategy.
Among other burdens to overcome mentioned in that FESCo ticket, I think it's a significant practical problem to have a complex password policy without a guideline for the user by which they can create a minimally compliant password in a single attempt. Right now, it's a guessing game. Since we're very nearly at feature freeze, no guidelines draft exists, no translations done, I think it's difficult (for me at least) to imagine the current behavior being foisted on users. Shooting in the dark to achieve almost no meaningful change in security I think is what will actually make more users mad than any philosophical complaint.
So since I expect this to be reverted, I think Fedora security minded folks and experts need to chime in with an alternative that can mitigate brute force attack concerns that doesn't require a password quality change.
- A minor point, just a note. It looks like anaconda uses authconfig, not passwd, and the resulting /etc/shadow contains a 16 character salt. Meanwhile, passwd uses an 8 character salt. I'm not sure how significant this is, but I filed a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1195110
---- http://www.tarsnap.com/scrypt/scrypt.pdf
Table 1 (The paper includes caveats about the table on the previous page; actual costs today would be different, however relative costs are probably about the same).
Noteworthy is the weakness of 40 character test passphrases (column 5) compared to 10 random characters, let alone 8 random characters. I really think the user passphrase cat is out of the bag, there's just no possible way to get that under control on the user side without *significantly* increasing the requirement well beyond what Anaconda proposes. And therefore all the more reason to look at other ways to mitigate the concerns.
All the more reason to look at increasing the number of SHA512 rounds we're using today; and hopefully by Fedora 23 or Fedora 24, some kind of KDF can be decided upon to make such attacks even more expensive. Possibly a standardized one, which is supposedly due sometime in the 2nd quarter this year.
https://password-hashing.net/timeline.html https://password-hashing.net/index.html
----
OK and a bit of hopefully skillful trolling. I found this for 32 month old OS X 10.8 (two major releases ago) https://hashcat.net/trac/ticket/75
The relevant parts: SALTED-SHA512-PBKDF2 Iteration count varies based on check done at hash generation time.
OS X 10.10 has been out some months and hashcat doesn't have OS X 10.10 support yet, and they distinguish between each major OS X version 10.4 through 10.9. Clearly Apple changes there hashing method between each OS X release.
Chris Murphy
On 22 February 2015 at 22:48, Chris Murphy lists@colorremedies.com wrote:
I'm noticing that Fedora depends on the user passworld, plus a salt, and the glibc sha512-crypt.c default of 5000 rounds through SHA512, to create the hash found in /etc/shadow.
The main issue that occurs when you change the 5000 rounds is running into mixed environments. You quickly find that while the password format has a format which allows for you to set the number of rounds.. a lot of places assume that 5000 is what is being used. You then have the "I can't login to X" where X is some addon to the Oracle/SAP/etc system and you can't do your vacation time. To deal with that is a larger issue than just the security team in that you need to say "We realize that the product change is going to affect usage in non-Fedora-only environment.
OS X 10.10 has been out some months and hashcat doesn't have OS X 10.10 support yet, and they distinguish between each major OS X version 10.4 through 10.9. Clearly Apple changes there hashing method between each OS X release.
Sometimes they do.. sometimes they don't. The main issue is where the password is stored and the format it is stored in versus the method. [They used the same method for a couple but changed how it looked.] They can't change it too much because they have to deal with the fact that user X has a MacOS-X 10.9 and 10.10 box and may need to work in an environment where box A and B are using the same password.
On Mon, Feb 23, 2015 at 10:01 AM, Stephen John Smoogen smooge@gmail.com wrote:
The main issue that occurs when you change the 5000 rounds is running into mixed environments. You quickly find that while the password format has a format which allows for you to set the number of rounds.. a lot of places assume that 5000 is what is being used. You then have the "I can't login to X" where X is some addon to the Oracle/SAP/etc system and you can't do your vacation time. To deal with that is a larger issue than just the security team in that you need to say "We realize that the product change is going to affect usage in non-Fedora-only environment.
Thanks for the response. I don't understand how software ignores the rounds value specified in /etc/shadow but honors the salt specified in same. Assuming should only happen if /etc/shadow omits $rounds=.
OS X 10.10 has been out some months and hashcat doesn't have OS X 10.10 support yet, and they distinguish between each major OS X version 10.4 through 10.9. Clearly Apple changes there hashing method between each OS X release.
Sometimes they do.. sometimes they don't. The main issue is where the password is stored and the format it is stored in versus the method. [They used the same method for a couple but changed how it looked.] They can't change it too much because they have to deal with the fact that user X has a MacOS-X 10.9 and 10.10 box and may need to work in an environment where box A and B are using the same password.
The context is the local shadow file in both the Fedora (above) and OS X cases.
If the environment is using directory services (Active/Open Directory, LDAP) then I could even be using an OS X 10.6 system for this, using the same password. And all such setups are kerberized and hence standardized.
Hello,
I'm noticing that Fedora depends on the user passworld, plus a salt, and the glibc sha512-crypt.c default of 5000 rounds through SHA512, to create the hash found in /etc/shadow.
- Could the security team provide some guidance on the work needed,
the time frame required, to increase the number of rounds? And also how many rounds should it be set to? I think this can be done by modifying /etc/pam.d/passwd. And if there's consensus on this, or any other alternative, if it could be noted in this FESCo ticket, I think that would be helpful. https://fedorahosted.org/fesco/ticket/1412
I really don’t see the number of rounds having any effect on that ticket. The anaconda policy change was AFAICT primarily driven by wanting to make ssh attacks more difficult, and making offline attacks more difficult is not relevant at all.
Sure, increasing the number of iterations would also slow down the ssh guessing process, but that would hardly be noticeable. The CPU time needed to perform a password check is hardly a binding constraint in the SSH bruteforcing scenario: assuming a round-trip time of ~10 ms, and therefore session setup time on the order of 50 ms, the current time to check a password (a few ms) is almost invisible in the whole process, and even a plausible iteration increase to require 50 ms per password check would at best halve the number of possible attempts. OTOH real rate-limiting (to, say, 2 guesses per second) could easily decrease the guessing rate by thousands or higher multiples.
(And, in general, strong protection against off-line attacks seems fairly low on the list of things that are worth improving. If an attacker collects any sizable number of passwords, the goal is not to crack them all but to just find a few weak passwords, and for that the limiting factor is the position of the weakest password on the top-N list (is it 100 guesses? 1000 guesses? Very likely not millions) rather than time needed for brute-forcing password hashes of any complexity.)
*shrug* To get back on topic, the usual UI guidelines point towards targeting a maximum budget on the order of 50 ms for changing or verifying a single password. And my current computer (i7) benchmarks at about 3 ms using the default number of rounds.
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years. Mirek
On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač mitr@redhat.com wrote:
Hello,
I'm noticing that Fedora depends on the user passworld, plus a salt, and the glibc sha512-crypt.c default of 5000 rounds through SHA512, to create the hash found in /etc/shadow.
- Could the security team provide some guidance on the work needed,
the time frame required, to increase the number of rounds? And also how many rounds should it be set to? I think this can be done by modifying /etc/pam.d/passwd. And if there's consensus on this, or any other alternative, if it could be noted in this FESCo ticket, I think that would be helpful. https://fedorahosted.org/fesco/ticket/1412
I really don’t see the number of rounds having any effect on that ticket. The anaconda policy change was AFAICT primarily driven by wanting to make ssh attacks more difficult, and making offline attacks more difficult is not relevant at all.
Sure, increasing the number of iterations would also slow down the ssh guessing process, but that would hardly be noticeable. The CPU time needed to perform a password check is hardly a binding constraint in the SSH bruteforcing scenario: assuming a round-trip time of ~10 ms, and therefore session setup time on the order of 50 ms, the current time to check a password (a few ms) is almost invisible in the whole process, and even a plausible iteration increase to require 50 ms per password check would at best halve the number of possible attempts. OTOH real rate-limiting (to, say, 2 guesses per second) could easily decrease the guessing rate by thousands or higher multiples.
OK so to do the slow down via more SHA512 iterations is essentially pointless. And to make it actually slow things down meaningfully necessitates adding some kind of KDF (like scrypt or PBKDF2) supporting to the authentication path. Are those correct?
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.
Right. In that category of new code, is a guideline (instructions) integrated into each UI that's going to significantly increase enforced higher quality passwords. But this work is omitted from the current installer behavior, and likewise doesn't exist in Gnome Users or in Gnome-Initial-Setup or in the KDE, Mate, etc equivalents. Instead the proposal expects the user to either iterate, or magically choose a sufficiently long or strong enough password as their first choice. The latter might be a majority case, I don't know, hopefully that's true. But instances of the former will at least be in the significant minority, and that's likely to result in enough resistance to warrant an alternative plan.
On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač mitr@redhat.com wrote:
Hello,
I'm noticing that Fedora depends on the user passworld, plus a salt, and the glibc sha512-crypt.c default of 5000 rounds through SHA512, to create the hash found in /etc/shadow.
- Could the security team provide some guidance on the work needed,
the time frame required, to increase the number of rounds? And also how many rounds should it be set to? I think this can be done by modifying /etc/pam.d/passwd. And if there's consensus on this, or any other alternative, if it could be noted in this FESCo ticket, I think that would be helpful. https://fedorahosted.org/fesco/ticket/1412
I really don’t see the number of rounds having any effect on that ticket. The anaconda policy change was AFAICT primarily driven by wanting to make ssh attacks more difficult, and making offline attacks more difficult is not relevant at all.
Sure, increasing the number of iterations would also slow down the ssh guessing process, but that would hardly be noticeable. The CPU time needed to perform a password check is hardly a binding constraint in the SSH bruteforcing scenario: assuming a round-trip time of ~10 ms, and therefore session setup time on the order of 50 ms, the current time to check a password (a few ms) is almost invisible in the whole process, and even a plausible iteration increase to require 50 ms per password check would at best halve the number of possible attempts. OTOH real rate-limiting (to, say, 2 guesses per second) could easily decrease the guessing rate by thousands or higher multiples.
OK so to do the slow down via more SHA512 iterations is essentially pointless. And to make it actually slow things down meaningfully necessitates adding some kind of KDF (like scrypt or PBKDF2) supporting to the authentication path. Are those correct?
I don’t know that the algorithm makes a difference here; any hash checking slowdown we would be reasonably willing to endure for protection against dictionary attacks will not be nearly as effective as reasonable rate limiting.
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.
Right. In that category of new code, is a guideline (instructions) integrated into each UI that's going to significantly increase enforced higher quality passwords.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks. (The off-line attacks scenario includes encryption passwords, without well-deployed TPM use at least, so it is still a problem that needs solving, OTOH.) Mirek
On Mon, Feb 23, 2015 at 4:22 PM, Miloslav Trmač mitr@redhat.com wrote:
OK so to do the slow down via more SHA512 iterations is essentially pointless. And to make it actually slow things down meaningfully necessitates adding some kind of KDF (like scrypt or PBKDF2) supporting to the authentication path. Are those correct?
I don’t know that the algorithm makes a difference here; any hash checking slowdown we would be reasonably willing to endure for protection against dictionary attacks will not be nearly as effective as reasonable rate limiting.
OK, good.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks.
This comment I think is in scope for the FESCo ticket. It'd also be useful exactly how to obtain the "not obviously stupid" check. Is this some blacklist made of the top 100,000 most common passwords used in 2014 hacks?
While I'm tickled at the idea of user interfaces literally saying "obviously stupid passwords will be rejected" just for the amusement factor, it's unlikely to happen that way. Plus, it's vague. So somehow this needs to be articulated to the user and this isn't straightforward and thus represents more work to be done.
OS X at least does allow obviously stupid passwords. I don't even get a pw quality indication by default. I can use "moon" for example, which ends up not just being a login password but also unlocks the encrypted volume (root + home). I don't present this as model to emulate. It's presented as, two giant companies who have the resources and clout to enforce something different, and have a sane UI to go with it, yet still haven't done anything. So it's presented from the point of, I'm skeptical that this is a good area to expend resources while also troubling users who have already ignored password quality check advise (in Anaconda).
On Monday 23 February 2015 18:43:39 Chris Murphy wrote:
On Mon, Feb 23, 2015 at 4:22 PM, Miloslav Trmač mitr@redhat.com wrote:
OK so to do the slow down via more SHA512 iterations is essentially pointless. And to make it actually slow things down meaningfully necessitates adding some kind of KDF (like scrypt or PBKDF2) supporting to the authentication path. Are those correct?
I don’t know that the algorithm makes a difference here; any hash checking slowdown we would be reasonably willing to endure for protection against dictionary attacks will not be nearly as effective as reasonable rate limiting.
OK, good.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks.
This comment I think is in scope for the FESCo ticket. It'd also be useful exactly how to obtain the "not obviously stupid" check. Is this some blacklist made of the top 100,000 most common passwords used in 2014 hacks?
common words *and* typical password cracker rules used
otherwise you can end up with stuff like "iloveyou" being on the list but "iloveyou1" not
On Mon, Feb 23, 2015 at 4:22 PM, Miloslav Trmač mitr@redhat.com wrote:
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks.
This comment I think is in scope for the FESCo ticket. It'd also be useful exactly how to obtain the "not obviously stupid" check. Is this some blacklist made of the top 100,000 most common passwords used in 2014 hacks?
That is not some absolute measure; it is intrinsically linked with how we rate-limit/otherwise protect passwords. For a hypothetical made-up example, suppose we decided on a goal that a Fedora box should be able to resist 7 days of continuous password guessing, _and_ had a ssh rate limiting implementation that restricted the botnet to 1 guess a minute over the 7 days. Then we only need to protect against the 10,080 possible guesses, i.e. something on the order top 20,000 most common passwords (compare that with the 479,828 entries in /usr/share/dict/words). Obviously with a different rate limiting/brute-forcing implementation, or a different goal, the password strength requirement would be different. Mirek
On Monday 23 February 2015 18:22:44 Miloslav Trmač wrote:
On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač mitr@redhat.com wrote:
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.
Right. In that category of new code, is a guideline (instructions) integrated into each UI that's going to significantly increase enforced higher quality passwords.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks. (The off-line attacks scenario includes encryption passwords, without well-deployed TPM use at least, so it is still a problem that needs solving, OTOH.) Mirek
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
On Monday 23 February 2015 18:22:44 Miloslav Trmač wrote:
On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač mitr@redhat.com wrote:
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.
Right. In that category of new code, is a guideline (instructions) integrated into each UI that's going to significantly increase enforced higher quality passwords.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks. (The off-line attacks scenario includes encryption passwords, without well-deployed TPM use at least, so it is still a problem that needs solving, OTOH.) Mirek
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
On Monday 23 February 2015 18:22:44 Miloslav Trmač wrote:
On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač mitr@redhat.com
wrote:
The point is, there should be a qualified alternative to the password policy change that Anaconda has already implemented; and also as a short term stop gap to the request by Anaconda that FESCo should come up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.
Right. In that category of new code, is a guideline (instructions) integrated into each UI that's going to significantly increase enforced higher quality passwords.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks. (The off-line attacks scenario includes encryption passwords, without well-deployed TPM use at least, so it is still a problem that needs solving, OTOH.) Mirek>
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it possible for "bored student" kind of targeted attacks. You can do low level of such an attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't be the only thing above simple dictionary check.
On Út, 2015-02-24 at 13:46 +0100, Hubert Kario wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
On Monday 23 February 2015 18:22:44 Miloslav Trmač wrote:
On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač mitr@redhat.com
wrote:
> The point is, there should be a qualified alternative to the > password > policy change that Anaconda has already implemented; and also as a > short term stop gap to the request by Anaconda that FESCo should > come > up with a distribution wide password quality policy.
Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.
Right. In that category of new code, is a guideline (instructions) integrated into each UI that's going to significantly increase enforced higher quality passwords.
AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary. With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks. (The off-line attacks scenario includes encryption passwords, without well-deployed TPM use at least, so it is still a problem that needs solving, OTOH.) Mirek>
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it possible for "bored student" kind of targeted attacks. You can do low level of such an attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't be the only thing above simple dictionary check.
Except everything above simple dictionary and length check is unacceptable for default install unless there is a possibility to override.
On 24 February 2015 at 05:46, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
rate limiting and denyhosts have no impact what so ever when the
attacker
has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it possible for "bored student" kind of targeted attacks. You can do low level of such an attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't be the only thing above simple dictionary check.
That matches what I am seeing with a couple of random servers I have out there. The number of attacks where IP address one is doing
apple:apple apple:123456 apple:trustn01 apple:... bob:bob bob:123456 bob:trustn01 bob:password
where if box A is blocked a new ip address starts up exactly where the first one stopped is much more common now than it was say 2 years ago and it will keep going until 50-60 boxes are rotated through.
On Tue, Feb 24, 2015 at 8:45 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 24 February 2015 at 05:46, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it possible for "bored student" kind of targeted attacks. You can do low level of such an attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't be the only thing above simple dictionary check.
That matches what I am seeing with a couple of random servers I have out there. The number of attacks where IP address one is doing
apple:apple apple:123456 apple:trustn01 apple:... bob:bob bob:123456 bob:trustn01 bob:password
Half of these will be allowed with the current installer behavior: # pwscore apple:123456 55 # pwscore apple:trustn01 84 # pwscore bob:trustn01 55 # pwscore bob:password 58
On Tuesday 24 February 2015 08:53:04 Chris Murphy wrote:
On Tue, Feb 24, 2015 at 8:45 AM, Stephen John Smoogen smooge@gmail.com
wrote:
On 24 February 2015 at 05:46, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it possible for "bored student" kind of targeted attacks. You can do low level of such an attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't be the only thing above simple dictionary check.
That matches what I am seeing with a couple of random servers I have out there. The number of attacks where IP address one is doing
apple:apple apple:123456 apple:trustn01 apple:... bob:bob bob:123456 bob:trustn01 bob:password
Half of these will be allowed with the current installer behavior: # pwscore apple:123456 55 # pwscore apple:trustn01 84 # pwscore bob:trustn01 55 # pwscore bob:password 58
I think that Stephen meant: for user name 'apple' the attacker tries 'apple', '123456', 'trustn01', etc. for user name 'bob'...
But yes, 'trustn01' is accepted, with score of 1
though if trustn01 is really a third password tested it's rather surprising, it is on 83823 position (tied with 3493 other passwords) in the RockYou list
On 24 February 2015 at 08:59, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 08:53:04 Chris Murphy wrote:
On Tue, Feb 24, 2015 at 8:45 AM, Stephen John Smoogen smooge@gmail.com
wrote:
On 24 February 2015 at 05:46, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we
can
prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a
public
IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it
possible
for "bored student" kind of targeted attacks. You can do low level of
such an
attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't
be
the only thing above simple dictionary check.
That matches what I am seeing with a couple of random servers I have
out
there. The number of attacks where IP address one is doing
apple:apple apple:123456 apple:trustn01 apple:... bob:bob bob:123456 bob:trustn01 bob:password
Half of these will be allowed with the current installer behavior: # pwscore apple:123456 55 # pwscore apple:trustn01 84 # pwscore bob:trustn01 55 # pwscore bob:password 58
I think that Stephen meant: for user name 'apple' the attacker tries 'apple', '123456', 'trustn01', etc. for user name 'bob'...
But yes, 'trustn01' is accepted, with score of 1
though if trustn01 is really a third password tested it's rather surprising, it is on 83823 position (tied with 3493 other passwords) in the RockYou list
That was just me remembering what passwords that I saw coming in versus actual statistics. I apologize for misleading you in that way.
On Tuesday 24 February 2015 09:01:23 Stephen John Smoogen wrote:
On 24 February 2015 at 08:59, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 08:53:04 Chris Murphy wrote:
On Tue, Feb 24, 2015 at 8:45 AM, Stephen John Smoogen smooge@gmail.com
wrote:
On 24 February 2015 at 05:46, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote: > rate limiting and denyhosts have no impact what so ever when the > attacker > has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we
can
prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a
public
IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it
possible
for "bored student" kind of targeted attacks. You can do low level of
such an
attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't
be
the only thing above simple dictionary check.
That matches what I am seeing with a couple of random servers I have
out
there. The number of attacks where IP address one is doing
apple:apple apple:123456 apple:trustn01 apple:... bob:bob bob:123456 bob:trustn01 bob:password
Half of these will be allowed with the current installer behavior: # pwscore apple:123456 55 # pwscore apple:trustn01 84 # pwscore bob:trustn01 55 # pwscore bob:password 58
I think that Stephen meant: for user name 'apple' the attacker tries 'apple', '123456', 'trustn01', etc. for user name 'bob'...
But yes, 'trustn01' is accepted, with score of 1
though if trustn01 is really a third password tested it's rather surprising, it is on 83823 position (tied with 3493 other passwords) in the RockYou list
That was just me remembering what passwords that I saw coming in versus actual statistics. I apologize for misleading you in that way.
no problem
thing is, that even if it just comes up once that means that the attackers either use full publicly available word lists or not entirely trivial password modification rules ("trustno1" is on 1001th position in RockYou list)
either means that a simple dictionary check won't protect against such opportunistic attackers
note to self: get password list from honeypots
On Tue, Feb 24, 2015 at 9:10 AM, Hubert Kario hkario@redhat.com wrote:
thing is, that even if it just comes up once that means that the attackers either use full publicly available word lists or not entirely trivial password modification rules ("trustno1" is on 1001th position in RockYou list)
either means that a simple dictionary check won't protect against such opportunistic attackers
note to self: get password list from honeypots
In the UI for setting a password, how does the guideline read for such enforcement?
"Your password must contain at least 8 characters and must contain at least one letter and one numeric or punctuation character" is obviously not going to work.
On Tuesday 24 February 2015 09:24:36 Chris Murphy wrote:
On Tue, Feb 24, 2015 at 9:10 AM, Hubert Kario hkario@redhat.com wrote:
thing is, that even if it just comes up once that means that the attackers either use full publicly available word lists or not entirely trivial password modification rules ("trustno1" is on 1001th position in RockYou list)
either means that a simple dictionary check won't protect against such opportunistic attackers
note to self: get password list from honeypots
In the UI for setting a password, how does the guideline read for such enforcement?
"Your password must contain at least 8 characters and must contain at least one letter and one numeric or punctuation character" is obviously not going to work.
I would consider the following to be good interaction:
For a password like: Troubadour1&
""" Your password failed a complexity check, estimated entropy: 17 bits, password pattern detected: dictionary word with simple modifications (capitalise, suffix-1, suffix-symbol). This system requires passwords with at least 20 bits of entropy.
Please try a different password.
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using """
And then when the user enters the "red mist" password, I'd expect it to say:
""" Estimated password entropy: 20 bits. Low complexity, acceptable. """ Possibly with a tooltip that says "Password pattern detected: 2 random dictionary words"
(switch "entropy" with "score" if we want to be user-friendly and not scare users with technicalities)
So not only say "your password is bad", but also say _why_ it is bad and provide ready to use passwords that will match the requirement.
On St, 2015-02-25 at 14:32 +0100, Hubert Kario wrote:
On Tuesday 24 February 2015 09:24:36 Chris Murphy wrote:
On Tue, Feb 24, 2015 at 9:10 AM, Hubert Kario hkario@redhat.com wrote:
thing is, that even if it just comes up once that means that the attackers either use full publicly available word lists or not entirely trivial password modification rules ("trustno1" is on 1001th position in RockYou list)
either means that a simple dictionary check won't protect against such opportunistic attackers
note to self: get password list from honeypots
In the UI for setting a password, how does the guideline read for such enforcement?
"Your password must contain at least 8 characters and must contain at least one letter and one numeric or punctuation character" is obviously not going to work.
I would consider the following to be good interaction:
For a password like: Troubadour1&
""" Your password failed a complexity check, estimated entropy: 17 bits, password pattern detected: dictionary word with simple modifications (capitalise, suffix-1, suffix-symbol). This system requires passwords with at least 20 bits of entropy.
Please try a different password.
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using
I do not think that two random words password from not too big dictionary would be sufficiently strong. You have to understand that the attacker will know which dictionary was used to generate it. And a big dictionary means that the words will be so obscure that people will not be able to memorize them much more easily than randomized single word.
"""
And then when the user enters the "red mist" password, I'd expect it to say:
""" Estimated password entropy: 20 bits. Low complexity, acceptable. """ Possibly with a tooltip that says "Password pattern detected: 2 random dictionary words"
(switch "entropy" with "score" if we want to be user-friendly and not scare users with technicalities)
I am not too confident with the password entropy scoring as presented by the NIST standard.
So not only say "your password is bad", but also say _why_ it is bad and provide ready to use passwords that will match the requirement.
All in all yes, this is good proposal, except nobody is working on the code that would implement it. At least I do not see it as a high priority for me.
On Wednesday 25 February 2015 14:47:57 Tomas Mraz wrote:
On St, 2015-02-25 at 14:32 +0100, Hubert Kario wrote:
On Tuesday 24 February 2015 09:24:36 Chris Murphy wrote:
On Tue, Feb 24, 2015 at 9:10 AM, Hubert Kario hkario@redhat.com wrote:
thing is, that even if it just comes up once that means that the attackers either use full publicly available word lists or not entirely trivial password modification rules ("trustno1" is on 1001th position in RockYou list)
either means that a simple dictionary check won't protect against such opportunistic attackers
note to self: get password list from honeypots
In the UI for setting a password, how does the guideline read for such enforcement?
"Your password must contain at least 8 characters and must contain at least one letter and one numeric or punctuation character" is obviously not going to work.
I would consider the following to be good interaction:
For a password like: Troubadour1&
""" Your password failed a complexity check, estimated entropy: 17 bits, password pattern detected: dictionary word with simple modifications (capitalise, suffix-1, suffix-symbol). This system requires passwords with at least 20 bits of entropy.
Please try a different password.
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using
I do not think that two random words password from not too big dictionary would be sufficiently strong. You have to understand that the attacker will know which dictionary was used to generate it. And a big dictionary means that the words will be so obscure that people will not be able to memorize them much more easily than randomized single word.
2 "symbols" selected at random from 1024 large symbol list give 20 bit entropy, no matter how you look at it. Make the dictionary 2048 large and you have the room to spare for occasional situations where the selected word from two dictionaries is the same and you throw away such picks.
With rate limiting that does meet NIST SP 800-63-1 with plenty of room to spare.
"""
And then when the user enters the "red mist" password, I'd expect it to say:
""" Estimated password entropy: 20 bits. Low complexity, acceptable. """ Possibly with a tooltip that says "Password pattern detected: 2 random dictionary words"
(switch "entropy" with "score" if we want to be user-friendly and not scare users with technicalities)
I am not too confident with the password entropy scoring as presented by the NIST standard.
The standard doesn't define a way to estimate entropy, it just specifies the lower bound of it and a _suggested_ way to do that (which was shown to be greatly inadequate by multiple researchers).
So not only say "your password is bad", but also say _why_ it is bad and provide ready to use passwords that will match the requirement.
All in all yes, this is good proposal, except nobody is working on the code that would implement it. At least I do not see it as a high priority for me.
Unfortunately my time situation is similar, I will gladly help with such project, but I don't have time to lead the project myself.
On 25 February 2015 at 06:47, Tomas Mraz tmraz@redhat.com wrote:
On St, 2015-02-25 at 14:32 +0100, Hubert Kario wrote:
If nobody else is looking at your screen, you can use one of the
following
random passwords: red mist second wanted degree however ready respect using
I do not think that two random words password from not too big dictionary would be sufficiently strong. You have to understand that the attacker will know which dictionary was used to generate it. And a big dictionary means that the words will be so obscure that people will not be able to memorize them much more easily than randomized single word.
Could we drop back from the weeds and go back to a core part. How many bits of entropy are we wanting to encourage towards passwords? Hubert is saying 20 bits, you have another but not expressed. Are we looking for 40 to be minimal? 90? 400?
(switch "entropy" with "score" if we want to be user-friendly and not scare
users with technicalities)
I am not too confident with the password entropy scoring as presented by the NIST standard.
The NIST standard is meant for passwords which are limited in length and was designed to be used from the days when passwords were limited to 7 or 8 characters. So trying to apply its scoring in unlimited length passwords is definitely suspect.
However unless we can agree to some sort of measurement system then every thing we 'impose' is going to be no better than throwing salt over our shoulder and turning 3 times windershin.
On Wed, Feb 25, 2015 at 10:42 AM, Stephen John Smoogen smooge@gmail.com wrote:
However unless we can agree to some sort of measurement system then every thing we 'impose' is going to be no better than throwing salt over our shoulder and turning 3 times windershin.
Feynman's Freshman Class problem... I don't think this is well enough understood to put this in front of users. And by this, I mean, concepts like entropy or even a score.
It also doesn't actively give advice in advance, it only disqualifies (or admonishes) after the fact, so it's negative (re)enforcement, rather than being positive. And I can't agree this is the right direction to go in.
On Wednesday 25 February 2015 18:55:29 Chris Murphy wrote:
On Wed, Feb 25, 2015 at 10:42 AM, Stephen John Smoogen smooge@gmail.com
wrote:
However unless we can agree to some sort of measurement system then every thing we 'impose' is going to be no better than throwing salt over our shoulder and turning 3 times windershin.
Feynman's Freshman Class problem... I don't think this is well enough understood to put this in front of users. And by this, I mean, concepts like entropy or even a score.
That's why I proposed to also show a minimum entropy/score needed.
If I provide something that gets score of 10 while the requirement is for 20, then I know that I need something much more complex.
on the other hand, if I get 19 and the requirement is for 20, I know I need just simple modification to push it over the threshold.
Users already are rather familiar with password quality meters.
But the minimum entropy *depends directly* on rate limiting and password ageing settings.
It also doesn't actively give advice in advance, it only disqualifies (or admonishes) after the fact, so it's negative (re)enforcement, rather than being positive. And I can't agree this is the right direction to go in.
What I had in mind, was that the password evaluation (and example passwords) is done after the user stops writing (0.5s of inactivity?) or moves to the re- entry field. So it's during the act, not after.
It's also rather hard to tell the user he can't have the password he or she likes before knowing it...
On Wednesday 25 February 2015 10:42:51 Stephen John Smoogen wrote:
On 25 February 2015 at 06:47, Tomas Mraz tmraz@redhat.com wrote:
On St, 2015-02-25 at 14:32 +0100, Hubert Kario wrote:
If nobody else is looking at your screen, you can use one of the
following
random passwords: red mist second wanted degree however ready respect using
I do not think that two random words password from not too big dictionary would be sufficiently strong. You have to understand that the attacker will know which dictionary was used to generate it. And a big dictionary means that the words will be so obscure that people will not be able to memorize them much more easily than randomized single word.
Could we drop back from the weeds and go back to a core part. How many bits of entropy are we wanting to encourage towards passwords? Hubert is saying 20 bits, you have another but not expressed. Are we looking for 40 to be minimal? 90? 400?
Talking about entropy without talking about how severe will be the rate limiting or password lifetimes will also lead us nowhere.
I chose 20 only to show that passwords that look complex aren't while the ones that don't look complex are much more secure.
If we use the NIST recommendation of 100 unsuccessful login attempts to lockout account and 30 day password rotation, then we may be fine with just 10 bit entropy - that of a random 4 digit PIN or single dictionary password.
If we want to increase the amount of allowed login attempts or password lifetime, then we need to increase the amount of required entropy in passwords to retain security level.
(switch "entropy" with "score" if we want to be user-friendly and not scare users with technicalities)
I am not too confident with the password entropy scoring as presented by the NIST standard.
The NIST standard is meant for passwords which are limited in length and was designed to be used from the days when passwords were limited to 7 or 8 characters. So trying to apply its scoring in unlimited length passwords is definitely suspect.
No, it didn't say anything about the max length of "Memorized Secret Token". It said that if the system requires better protection than an "7 or 8 character password" (14 bits of entropy) can provide, the system *can't use* passwords for authentication in the first place.
However unless we can agree to some sort of measurement system then every thing we 'impose' is going to be no better than throwing salt over our shoulder and turning 3 times windershin.
I think the rules for Level 1 and Level 2 are quite reasonable: The probability that an attacker guesses a password during password life time is 1% and 0.1% respectively for Level 1 and Level 2.
On Thu, Feb 26, 2015 at 3:30 AM, Hubert Kario hkario@redhat.com wrote:
Talking about entropy without talking about how severe will be the rate limiting or password lifetimes will also lead us nowhere.
OK, so the password lifetime thing: I just fired my ISP for having 3 month mandatory password changes. I think it's a bad idea that actually makes us less safe.
https://www.schneier.com/blog/archives/2010/11/changing_passwo.html
If we use the NIST recommendation of 100 unsuccessful login attempts to lockout account and 30 day password rotation, then we may be fine with just 10 bit entropy - that of a random 4 digit PIN or single dictionary password.
OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's been the same for 8+ years.
I strongly advise when considering what work needs to be done, you consider what sort of work will be resoundly rejected. Overwhelmingly users will reject both password quality enforcement and expirations. So if they're totally off the table, now what? What's your next design idea for harding? Because *that* is the one that probably has the best bang for the buck.
To put a finer point on this: some of you probably assume the human primate is much more agreeable than they really are. The thing is, as soon as they get to a certain threshold of frustration, they go bezerk. They scream, they throw things, they create uproar, make all sorts of off topic rants and insults – incredible amounts of irrational behavior. And there's a reason for this. It's a successful sociological behavior. If the uproar is just wide spread enough, if enough peripheral individuals who otherwise would say nothing see a fellow primate flipping out then they feels like it's socially acceptable to complain also (rationally or irrationally) when they otherwise wouldn't; people will be sucked into a vortex of manufactured controversy explicitly (though unconsciously) designed for the minority to veto a change. The entire point is to be disruptive.
And this has happened before on this very issue the last time Anaconda folks changed the password behavior. And I think the current behavior in the installer (the change) is more controversial than that one.
Now maybe our fellow primates get riled up and worn out about some other controversy first. And somehow the password change sneaks in under the radar. I seriously doubt it, and I think expecting it will is very high risk. I think we're better off assuming the worst, not the best, and trying to leave the unpredictable user out of the equation entirely until absolutely necessary.
So for any of you who don't like verbal fist fights? You're not serious. You don't take these changes seriously enough if you're not willing to argue vehemently, angrily, in favor of them. You have to demonstrate to your fellow primates that this is serious business and we have no alternatives right now than to shift the burden to the user. If you can't do that and stick with it, give it up. Instead, consider the alternatives that don't require user cooperation.
On 26 February 2015 at 11:25, Chris Murphy lists@colorremedies.com wrote:
So for any of you who don't like verbal fist fights? You're not serious. You don't take these changes seriously enough if you're not willing to argue vehemently, angrily, in favor of them. You have to demonstrate to your fellow primates that this is serious business and we have no alternatives right now than to shift the burden to the user. If you can't do that and stick with it, give it up. Instead, consider the alternatives that don't require user cooperation.
Sorry, but I find any call for violence even verbal violence to be counter-productive. I may agree with some of your points but I will not be party to reenacting the Dawn of Time from 2001.
On Thu, Feb 26, 2015 at 11:37 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 26 February 2015 at 11:25, Chris Murphy lists@colorremedies.com wrote:
So for any of you who don't like verbal fist fights? You're not serious. You don't take these changes seriously enough if you're not willing to argue vehemently, angrily, in favor of them. You have to demonstrate to your fellow primates that this is serious business and we have no alternatives right now than to shift the burden to the user. If you can't do that and stick with it, give it up. Instead, consider the alternatives that don't require user cooperation.
Sorry, but I find any call for violence even verbal violence to be counter-productive. I may agree with some of your points but I will not be party to reenacting the Dawn of Time from 2001.
It's strictly a metaphor. If you're not willing to strenuously argue your points, then you're acknowledging your position isn't really worth it *to you*, and your fellow person will see that you're not that committed and that incentivizes them to remain unconvinced. That's the point.
I'm definitely not recommending this approach because I think by now I've argued the trust capital simply isn't there. This exact same thing happened almost two years ago, it turned into a devel@ sh|tshow, and it was at best distressing and disruptive. As a result:
a. Distrust in Anaconda when it comes to any change being well vetted in advance, but especially on the matter of security and passwords. b. Distrust in Fedora process that this was possible: reminder, the change happened silently, it abruptly appeared in Fedora 18 Beta TC2. c. The ensuing uproar successfully resulted in a reversion. d. There was no contrition or acknowledgement how the process could be improved to have avoided the kerfuffle in the first place.
Now, if there's any possible way to Do This Wrong™ it would be do make a password policy change silently without consulting anyone again. And it has less to do with the merit or scope of the change, but rather on trying to rebuild trust. The sociologically right thing to do would be to be contrite, to try and rebuild trust, by voluntarily going through the change process, and vetting this idea with security folks. Yet none of that was done, instead we have a repeat of history, and thus more damaged trust. And it's a peripherally damaging thing, when trust is lost people don't just lose it on a single target, it has ripple effects and the consequences are broad in scope.
So I pretty much guarantee (and hey if I'm wrong and have egg on my face and end up eating crow for breakfast then that's a spectacularly benign outcome) this change is not going to go over well once it hits devel@. It is trust damaging, not trust building.
If the security minded folks aren't so in love with this change that they're willing to get defend it tooth and nail, then I suggest they side with the user against the change, even if it's maybe contrary to better judgement. Because siding with the user will engender trust, it will de-escalate the controversy, should it materialize. And this earned trust can be used for recruitment on future needed work, it can be used for when you really really really need the user to change their behavior. Which is probably not now, nor in this fashion.
And you don't have to criticize the Anaconda team to do that, you can leave that to jerks like me who eat crow for breakfast. All you have to do is say something like, hey we think this change is not worth the security enhancement compared to the usability impact and we are working on better defaults and hardening that don't require the user to change their behavior, while making it easier to opt in to better behaviors that have big impact, and we really need help and involvement from the community to realize all of that, please join us at our next meeting (or something like that).
On Thursday 26 February 2015 11:25:59 Chris Murphy wrote:
On Thu, Feb 26, 2015 at 3:30 AM, Hubert Kario hkario@redhat.com wrote:
Talking about entropy without talking about how severe will be the rate limiting or password lifetimes will also lead us nowhere.
OK, so the password lifetime thing: I just fired my ISP for having 3 month mandatory password changes. I think it's a bad idea that actually makes us less safe.
https://www.schneier.com/blog/archives/2010/11/changing_passwo.html
and I agree, blanket requirement of changing the password every 30 days is bad
but if we say "password never expires" we need to assume (for purposes of calculation) a sufficiently long password life-time - like 100 years
we could go the route of - give me a good enough password and you won't be required to change it in next x-months or x-years
but every calculation of security level of a password needs to include: - amount of tries the attacker can perform per unit of time - how long the password is useful - how hard is the password to guess (entropy)
If the "amount of tries" is "5 million per second", the "how long" is "10 years" then the password needs to be really complex to keep "1% chance to be guessed".
But if you enter "100 tries per 30 days", "30 days" and "10 bits of entropy" you get "1% chance for the password to be guessed".
We can tune any value we like, but some other value will change too, otherwise we will not end up with a system that is as secure as we would like/expect.
If we use the NIST recommendation of 100 unsuccessful login attempts to lockout account and 30 day password rotation, then we may be fine with just 10 bit entropy - that of a random 4 digit PIN or single dictionary password.
OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's been the same for 8+ years.
it's also locked out after 3 unsuccessful attempts and requires possession of hardware token, not a favourable comparison
On Thu, Feb 26, 2015 at 12:12 PM, Hubert Kario hkario@redhat.com wrote:
and I agree, blanket requirement of changing the password every 30 days is bad
but if we say "password never expires" we need to assume (for purposes of calculation) a sufficiently long password life-time - like 100 years
we could go the route of - give me a good enough password and you won't be required to change it in next x-months or x-years
but every calculation of security level of a password needs to include:
- amount of tries the attacker can perform per unit of time
- how long the password is useful
- how hard is the password to guess (entropy)
If the "amount of tries" is "5 million per second", the "how long" is "10 years" then the password needs to be really complex to keep "1% chance to be guessed".
But if you enter "100 tries per 30 days", "30 days" and "10 bits of entropy" you get "1% chance for the password to be guessed".
We can tune any value we like, but some other value will change too, otherwise we will not end up with a system that is as secure as we would like/expect.
I just don't see this being even remotely tenable in an OS installer. There are no examples of this being successfully foisted on users yet either. I think the burden is high both for user and development. I think this GUI application needs to be standalone, with no dependency on the installer for now.
If we use the NIST recommendation of 100 unsuccessful login attempts to lockout account and 30 day password rotation, then we may be fine with just 10 bit entropy - that of a random 4 digit PIN or single dictionary password.
OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's been the same for 8+ years.
it's also locked out after 3 unsuccessful attempts and requires possession of hardware token, not a favourable comparison
Perhaps not favorable, but it's quite useless and relevant because it's exactly what any ordinary user wonders when they're burdened with disproportionate password requirements. Why? It's the mitigating factors. So how do you create mitigating factors that don't affect the user at all? I've never run into the 3 attempt limit of a bank card, I had no idea the limit was that low, because I've never gotten it wrong three times in a row.
Sorry, I really need to proof read before I hit send...
On Thu, Feb 26, 2015 at 1:01 PM, Chris Murphy lists@colorremedies.com wrote:
There are no examples of this being successfully foisted on users yet either.
i.e. no examples of such a password matrix UI on any distro or platform. Usability impact is totally unknown.
OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's been the same for 8+ years.
it's also locked out after 3 unsuccessful attempts and requires possession of hardware token, not a favourable comparison
Perhaps not favorable, but it's quite useless and relevant because it's exactly what any ordinary user wonders when they're burdened with disproportionate password requirements.
Not favorable, but useful and relevant...
and I agree, blanket requirement of changing the password every 30 days is bad
but if we say "password never expires" we need to assume (for purposes of calculation) a sufficiently long password life-time - like 100 years
“Sufficiently long”, yes. 100 years, no—other time limits will become binding much earlier:
* Can a botnet survive over 100 years? Something between 3 and 10 years seems a better guess. * Will a deployed system stay around for 100 years? The usual hardware warranty is around 3 years, even small businesses tend to upgrade around every 10 years (and change ISPs, i.e. IP addresses, even more frequently). * Will a botnet continue to hammer a single system after 99 years of failures, or give up and move on to an easier target?
For an untargeted attack, I would expect the last factor to dominate—resiliency for 1–7 days of continuous password guessing intuitively seems like quite sufficient (though this depends not as much on what Fedora does as what OS vendors of other possible targets do).
For a targeted attack from a nation state, I don’t know; passwords tend to get reused over a long time and a nation state may have the resources, interest and means to keep following and attacking the same person/company over their various computing systems for a decade or more easily enough. The folk wisdom is that any targeted attack like this will eventually succeed, so I’m really not sure where to put the line between “worthwhile effort to protect our users” and “eh, you are screwed anyway, let’s not annoy those who are not targets like you”.
If we use the NIST recommendation of 100 unsuccessful login attempts to lockout account and 30 day password rotation, then we may be fine with just 10 bit entropy - that of a random 4 digit PIN or single dictionary password.
OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's been the same for 8+ years.
it's also locked out after 3 unsuccessful attempts and requires possession of hardware token, not a favourable comparison
(FWIW the locking out after 3 tries is not universal; I know of several banks where 3 bad attempts will just cause the current transaction to be aborted and allow you to try elsewhere again immediately (not even locking you out for 24 hours). But then banks never speak about their internal rate limiting and alarm and automated / manual blocking rules, so we will not know the full picture.) Mirek
On Friday 27 February 2015 14:17:29 Miloslav Trmač wrote:
and I agree, blanket requirement of changing the password every 30 days is bad
but if we say "password never expires" we need to assume (for purposes of calculation) a sufficiently long password life-time - like 100 years
“Sufficiently long”, yes. 100 years, no—other time limits will become binding much earlier:
- Can a botnet survive over 100 years? Something between 3 and 10 years
seems a better guess.
- Will a deployed system stay around for 100 years?
100? *probably* not, but 10 years? certainly (I've had e-mail addresses longer), 50 years is still very likely (banking systems), and even desktops/laptops have very long rotation periods now (5 years is not uncommon)
the difference between 50 and 100 years is 1 extra bit of entropy needed, between 10 and 100 is 3 bits, I think we can have this much safety margin (that's a difference of "<password/>" and "<password/>1" or "<password/>" and "<password/>4" respectively)
The usual hardware warranty is around 3 years, even small businesses tend to upgrade around every 10 years (and change ISPs, i.e. IP addresses, even more frequently).
and systems don't get migrated over? Don't get connected to a stable LDAP hierarchy that gets migrated over and over?
- Will a botnet continue to hammer a single system after
99 years of failures, or give up and move on to an easier target?
doesn't matter if it's a single botnet or multiple uncoordinated ones, the main point is that the system may remain under attack for whole operational lifetime
and sure, the different botnets may try the same set of passwords over and over, but you *can't* be certain of it
assume the worst
For an untargeted attack, I would expect the last factor to dominate—resiliency for 1–7 days of continuous password guessing intuitively seems like quite sufficient (though this depends not as much on what Fedora does as what OS vendors of other possible targets do).
doesn't matter if it's targeted or not, by sheer luck the uncoordinated attacks may end up with very little overlap of tried passwords
and you have to make sure the lowest hanging fruit hangs high enough that they won't snatch it and gain access to system
and even if we go your route, of "7 days of continuous password guessing", how many such attacks should a systems with 10 year operational period be able to resist? 'cause I'm sure it's more that 1
For a targeted attack from a nation state, I don’t know; passwords tend to get reused over a long time and a nation state may have the resources, interest and means to keep following and attacking the same person/company over their various computing systems for a decade or more easily enough.
password reuse is something we have no control over, just as we have no control over administrator inadvertently posting his shadow file on the http server or the user just providing the password in phishing attack
those are problems we can't fix using technical means
we can make them less common by making SSO easier to deploy and supporting OAuth or similar, but those are external things to the password policy
The folk wisdom is that any targeted attack like this will eventually succeed, so I’m really not sure where to put the line between “worthwhile effort to protect our users” and “eh, you are screwed anyway, let’s not annoy those who are not targets like you”.
unless we start installing fail2ban or similar software by default it doesn't matter, and if we do that, it automatically introduces hard limits for password guessing
this doesn't change the equation, just the needed entropy in passwords
And I'm not saying *how* we should introduce rate limiting, I'm saying we need *some* rate limiting.
If we use the NIST recommendation of 100 unsuccessful login attempts to lockout account and 30 day password rotation, then we may be fine with just 10 bit entropy - that of a random 4 digit PIN or single dictionary password.
OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's been the same for 8+ years.
it's also locked out after 3 unsuccessful attempts and requires possession of hardware token, not a favourable comparison
(FWIW the locking out after 3 tries is not universal; I know of several banks where 3 bad attempts will just cause the current transaction to be aborted and allow you to try elsewhere again immediately (not even locking you out for 24 hours). But then banks never speak about their internal rate limiting and alarm and automated / manual blocking rules, so we will not know the full picture.) Mirek
it's still "highly limited", something that won't fly for an online system as it will make for easy DoS attacks
Hello,
On Friday 27 February 2015 14:17:29 Miloslav Trmač wrote:
and I agree, blanket requirement of changing the password every 30 days is bad
but if we say "password never expires" we need to assume (for purposes of calculation) a sufficiently long password life-time - like 100 years
“Sufficiently long”, yes. 100 years, no—other time limits will become binding much earlier:
- Can a botnet survive over 100 years? Something between 3 and 10 years
seems a better guess.
- Will a deployed system stay around for 100 years?
100? *probably* not, but 10 years? certainly (I've had e-mail addresses longer), 50 years is still very likely (banking systems), and even desktops/laptops have very long rotation periods now (5 years is not uncommon)
the difference between 50 and 100 years is 1 extra bit of entropy needed, between 10 and 100 is 3 bits, I think we can have this much safety margin (that's a difference of "<password/>" and "<password/>1" or "<password/>" and "<password/>4" respectively)
Sure, we can have 3 bits of a safety margin ☺ But if we end up adding 3 bits of safety margin to every variable we consider in the calculation, we will not get anywhere.
- Will a botnet continue to hammer a single system after
99 years of failures, or give up and move on to an easier target?
doesn't matter if it's a single botnet or multiple uncoordinated ones, the main point is that the system may remain under attack for whole operational lifetime
and sure, the different botnets may try the same set of passwords over and over, but you *can't* be certain of it
assume the worst
Certainly not! The worst possibility is that a first guess will flawlessly guess a high-entropy, completely random, password. (And AFAICT that single-attempt password guess would be _more_ likely than 10 or more independent and independently managed botnets that end up up guessing the passwords using different sets and progressing difficulty as if under a common control¹.)
We are necessarily in the business of engineering for plausible/implausible/likely/unlikely attack scenarios and weighing them against various costs of mitigation and various entities bearing these costs.
(Building the password policy is, though, a game theory situation, where the more botnets try the same set of passwords, the more likely are OSes to allow passwords just outside of this set, and the more likely is a new botnet to try a different set of passwords. So we do need _some_ margin.)
For an untargeted attack, I would expect the last factor to dominate—resiliency for 1–7 days of continuous password guessing intuitively seems like quite sufficient (though this depends not as much on what Fedora does as what OS vendors of other possible targets do).
doesn't matter if it's targeted or not, by sheer luck the uncoordinated attacks may end up with very little overlap of tried passwords
I don't think the botnets are likely to guess randomly enough for that to happen, it would be too inefficient for them. The password distribution is very skewed and the botnet wants to take advantage of this (to get results quickly, to not trip too many alarms, and because the botnet either has been rented and its time costs money—or there is an opportunity cost if it is guessing instead of being rented out.)
and even if we go your route, of "7 days of continuous password guessing", how many such attacks should a systems with 10 year operational period be able to resist? 'cause I'm sure it's more that 1
We don’t know the precise set of guessed passwords so we need some margin over the 7 days in any case just to account for modeling error, but the needed margin certainly does not grow anywhere close to linearly with the number of attacks.
(The 7 days are an example; I think it is a plausible value both as the ultimate decision and as an example for these discussions, but I am really not insisting on that specific value.)
For a targeted attack from a nation state, I don’t know; passwords tend to get reused over a long time and a nation state may have the resources, interest and means to keep following and attacking the same person/company over their various computing systems for a decade or more easily enough.
password reuse is something we have no control over,
We sort of do, by prohibiting low-complexity passwords, making reuse impossible when it is be dangerous (and letting password reuse stay irrelevant when the password is strong enough.)
this doesn't change the equation, just the needed entropy in passwords
Sure; it's good that we don’t need two different equations ☺ Now how to arrive at reasonable inputs to the equation for targeted attack.
And I'm not saying *how* we should introduce rate limiting, I'm saying we need *some* rate limiting.
Absolutely. Mirek
¹ The reply to “same set of passwords over and over” with “botnets randomly behaving as if under a single control” is, I admit, unfair, but I thought the probability comparison is interesting.
I would consider the following to be good interaction:
For a password like: Troubadour1&
""" Your password failed a complexity check, estimated entropy: 17 bits, password pattern detected: dictionary word with simple modifications (capitalise, suffix-1, suffix-symbol). This system requires passwords with at least 20 bits of entropy.
That ends up saying “too bad, try something else” like we already do, except there are more scary words ☺ Showing the pattern that was detected does nothing to show _other_ patterns that will also not be allowed.
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using """
Now this is an useful idea. We should have this. (The required never-ending nowhere-leading discussion about what the recommendations should look like notwithstanding.) Mirek
On Wed, Feb 25, 2015 at 12:24 PM, Miloslav Trmač mitr@redhat.com wrote:
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using """
Now this is an useful idea. We should have this. (The required never-ending nowhere-leading discussion about what the recommendations should look like notwithstanding.)
OK well at least there's acknowledgement, at least on this list, that there need to be visible recommendations in the UI rather than the user given a text fail whale. I don't know if there's consensus on this point.
What about a "pronounceable" password creator, one that explicitly doesn't use dictionary words? Based on the aforementioned 2009 estimated cost to brute force attack passwords, it still looks like passwords like "however ready respect using" can't possibly be all that safe against a voluminous attack. If you want to go to all this work building such a thing and translating it, why not help the user create completely non-dictionary passphrases that have some change of being memorable by virtue of being pronounceable. Plus, the proposal should be nonsense in any language, which seems less Amero/Anglocentric.
anguleatimplesc nitypeyrosentra mideakeremicamo spenhutendempis
And so on. I got these from Lastpass which lets me choose 'make pronounceable' as an advanced option, and I can pick any length. The argument against is that chances are the user has to write these down at least temporarily until memorized. *shrug* But that could be true for four word passphrases too.
Chris Murphy
On St, 2015-02-25 at 22:54 -0700, Chris Murphy wrote:
On Wed, Feb 25, 2015 at 12:24 PM, Miloslav Trmač mitr@redhat.com wrote:
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using """
Now this is an useful idea. We should have this. (The required never-ending nowhere-leading discussion about what the recommendations should look like notwithstanding.)
OK well at least there's acknowledgement, at least on this list, that there need to be visible recommendations in the UI rather than the user given a text fail whale. I don't know if there's consensus on this point.
What about a "pronounceable" password creator, one that explicitly doesn't use dictionary words? Based on the aforementioned 2009 estimated cost to brute force attack passwords, it still looks like passwords like "however ready respect using" can't possibly be all that safe against a voluminous attack. If you want to go to all this work building such a thing and translating it, why not help the user create completely non-dictionary passphrases that have some change of being memorable by virtue of being pronounceable. Plus, the proposal should be nonsense in any language, which seems less Amero/Anglocentric.
anguleatimplesc nitypeyrosentra mideakeremicamo spenhutendempis
And so on. I got these from Lastpass which lets me choose 'make pronounceable' as an advanced option, and I can pick any length. The argument against is that chances are the user has to write these down at least temporarily until memorized. *shrug* But that could be true for four word passphrases too.
Note that there is already pronounceable password generator in the libpwquality library. You can test it with the pwmake command. The generated passwords contain also some numbers and special characters so that they can be shorter with the same entropy. The lowest entropy passwords that are possible to generate have 56 bits which might be a little bit too much though for cases where online attacks are rate-limited. Examples: owt4NYt=AtYg uj-iMuhIh5Im HYk@qziL4fmE aHaRiP=yccUp
On Thu, 2015-02-26 at 10:50 +0100, Tomas Mraz wrote:
And so on. I got these from Lastpass which lets me choose 'make pronounceable' as an advanced option, and I can pick any length. The argument against is that chances are the user has to write these down at least temporarily until memorized. *shrug* But that could be true for four word passphrases too.
Note that there is already pronounceable password generator in the libpwquality library. You can test it with the pwmake command. The generated passwords contain also some numbers and special characters so that they can be shorter with the same entropy. The lowest entropy passwords that are possible to generate have 56 bits which might be a little bit too much though for cases where online attacks are rate-limited.
For the generation of passwords to memorize I find apg convenient because of the added spelling.
$ apg -a 0 -m 15 -t jortedfavwievTo (jort-ed-fav-wiev-To) PryFlydkibBojfi (Pry-Flyd-kib-Boj-fi) )WrernyanwamNia (RIGHT_PARENTHESIS-Wrern-yan-wam-Nia) inHinReexHookot (in-Hin-Reex-Hook-ot) 6wrowgAmFaypErm (SIX-wrowg-Am-Fayp-Erm) HaQuisyaggUfes6 (Ha-Quis-yagg-Uf-es-SIX)
On Wednesday 25 February 2015 22:54:18 Chris Murphy wrote:
On Wed, Feb 25, 2015 at 12:24 PM, Miloslav Trmač mitr@redhat.com wrote:
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using """
Now this is an useful idea. We should have this. (The required never-ending nowhere-leading discussion about what the recommendations should look like notwithstanding.)
OK well at least there's acknowledgement, at least on this list, that there need to be visible recommendations in the UI rather than the user given a text fail whale. I don't know if there's consensus on this point.
What about a "pronounceable" password creator, one that explicitly doesn't use dictionary words?
I have used this method before and didn't find pronounceable gibberish to be easy to remember, words are much more so.
But I don't have anything against providing few different style passwords to the user - one with random words, other with random syllables and even one with completely random characters. But all the presented passwords must pass the later check and.
Based on the aforementioned 2009 estimated cost to brute force attack passwords, it still looks like passwords like "however ready respect using" can't possibly be all that safe against a voluminous attack.
The NIST recommendation are for on-line systems where the password is used (and as such, is useful) for a limited amount of time and you have complete control over amount of tries the attacker can perform.
The bruteforce you're talking about is for offline attacks where the attacker has access to password hashes - useful for guidelines for disk encryption or private key encryption, not so much for regular login password.
If you want to go to all this work building such a thing and translating it, why not help the user create completely non-dictionary passphrases that have some change of being memorable by virtue of being pronounceable. Plus, the proposal should be nonsense in any language, which seems less Amero/Anglocentric.
anguleatimplesc nitypeyrosentra mideakeremicamo spenhutendempis
Diceware already has word lists in many languages, don't see why we couldn't have different random passwords (from different dictionaries) if the user selected different installer language.
And what you consider pronounceable really depends on the language you speak... For example this is completely valid Czech sentence: Strč prst skrz krk
Yes, it doesn't contain a single vowel :)
On Thu, Feb 26, 2015 at 3:58 AM, Hubert Kario hkario@redhat.com wrote:
Diceware already has word lists in many languages, don't see why we couldn't have different random passwords (from different dictionaries) if the user selected different installer language.
I like diceware better than the pronounceable passphrases. Thing is I often am too lazy to go find the dice, so if this were made easier, or even for some contributing an external random source like a dice roll (hey there are rng concerns floating about) might encourage more buy in. I definitely think it's appropriate to consider i18n aspect, and not being overly English centric.
And what you consider pronounceable really depends on the language you speak... For example this is completely valid Czech sentence: Strč prst skrz krk
Yes, it doesn't contain a single vowel :)
Hieratic, Arabic and Hebrew also.
On Wednesday 25 February 2015 14:24:37 Miloslav Trmač wrote:
I would consider the following to be good interaction:
For a password like: Troubadour1&
""" Your password failed a complexity check, estimated entropy: 17 bits, password pattern detected: dictionary word with simple modifications (capitalise, suffix-1, suffix-symbol). This system requires passwords with at least 20 bits of entropy.
That ends up saying “too bad, try something else” like we already do, except there are more scary words ☺ Showing the pattern that was detected does nothing to show _other_ patterns that will also not be allowed.
Well, every kind of rule that results in rejection can be summed up as "too bad, try something else".
The point of it is to learn users *not* to use "clever" tricks they have been using to get past password filters, like appending "1!" and capitalising the word to pass the "4 character classes" rule. Same tricks crackers have been using for decades now to guess the passwords.
And it does actually _show_ you what will be accepted right below: plain english words.
If nobody else is looking at your screen, you can use one of the following random passwords: red mist second wanted degree however ready respect using """
Now this is an useful idea. We should have this. (The required never-ending nowhere-leading discussion about what the recommendations should look like notwithstanding.) Mirek
On Tue, Feb 24, 2015 at 8:59 AM, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 08:53:04 Chris Murphy wrote:
Half of these will be allowed with the current installer behavior: # pwscore apple:123456 55 # pwscore apple:trustn01 84 # pwscore bob:trustn01 55 # pwscore bob:password 58
I think that Stephen meant: for user name 'apple' the attacker tries 'apple', '123456', 'trustn01', etc. for user name 'bob'...
OK.
But yes, 'trustn01' is accepted, with score of 1
Anaconda's threshold is somewhere around 40-50.
On 24 February 2015 at 08:53, Chris Murphy lists@colorremedies.com wrote:
On Tue, Feb 24, 2015 at 8:45 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 24 February 2015 at 05:46, Hubert Kario hkario@redhat.com wrote:
On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal
Large botnet means that the attack is targeted. I do not think we can prevent targeted attack against weak password in the default configuration. What we should aim at is prevention of non-targeted attacks such as attacks you can see when you open ssh port on a public IP almost immediately. These attacks usually come from single IP address.
Not necessarily, I've seen both - where an IP did try just 2 or 3 password/user combinations and ones that did try dozens.
Having access to botnet is not uncommon or expensive, making it possible for "bored student" kind of targeted attacks. You can do low level of such
an
attack with just EC2.
I'm not saying that we shouldn't have rate limiting, but it shouldn't be the only thing above simple dictionary check.
That matches what I am seeing with a couple of random servers I have out there. The number of attacks where IP address one is doing
apple:apple apple:123456 apple:trustn01 apple:... bob:bob bob:123456 bob:trustn01 bob:password
Half of these will be allowed with the current installer behavior: # pwscore apple:123456 55 # pwscore apple:trustn01 84 # pwscore bob:trustn01 55 # pwscore bob:password 58
Uhm that was meant to be account name : password so you should only test what is after the :
security@lists.fedoraproject.org
-
Chris Murphy -
Eric Christensen -
Hubert Kario -
Miloslav Trmač -
Nikos Mavrogiannopoulos -
Stephen John Smoogen -
Tomas Mraz