11:44 a.m.
Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Summary:
All existing users of the Fedora Account System (FAS) at
https://admin.fedoraproject.org/accounts are required to change their
password and upload a NEW ssh public key before 2011-11-30.
Failure to do so may result in your account being marked inactive.
Passwords changed and NEW ssh public keys uploaded after 2011-10-10
will meet this requirement.
Backgound and reasoning:
This change event has NOT been triggered by any specific compromise or
vulnerability in Fedora Infrastructure. Rather, we believe, due to the
large number of high profile sites with security breaches in recent
months, that this is a great time for all Fedora contributors and users
to review their security settings and move to "best practices" on their
machines. Additionally, we are putting in place new rules for passwords
to make them harder to guess.
New Password Rules:
* Nine or more characters with lower and upper case letters, digits and
punctuation marks.
* Ten or more characters with lower and upper case letters and digits.
* Twelve or more characters with lower case letters and digits
* Twenty or more characters with all lower case letters.
* No maximum length.
Some Do's and Don'ts:
* NEVER store your ssh private key on a shared or public system.
* ALWAYS use a strong passphrase on your ssh key.
* If you must store passwords, use an application specifically for this
purpose like revelation, gnome-keyring, seahorse, or keepassx.
* Regularly apply your operating system's security related updates.
* Only use ssh agent forwarding when needed ( .ssh/config:
"ForwardAgent no")
* DO verify ssh host keys via dnssec protected dns. ( .ssh/config:
"VerifyHostKeyDNS yes")
* DO consider a seperate ssh key for Fedora Infrastructure.
* Work with and use security features like SELinux and iptables.
* Review the Community Standard Infrastructure security document (link
below)
Q&A:
Q: My password and ssh private key are fine and secure!
Can't I just skip this change?
No. We believe the new guidelines above provide an added measure of
security compared to the previous requirements. We want all users of
our infrastructure to follow the new guidelines to improve one aspect
of security across the systems they share. Awareness is also an
aspect of good security. By requiring these changes, we also hope to
maintain and improve awareness of the process for changing passwords
and keys.
Q: Can I just change my password and re-upload my same ssh public key?
Or upload a bogus ssh public key and then re-upload my old one?
A: No. We've installed safeguards to ensure that your new ssh public
key is different from your old one. Additionally, some of our
contributors may have had accounts on compromised high profile Linux
sites recently, and we want to make sure no ssh private keys or
passwords used in Fedora Infrastructure were obtained via those
incidents.
Q: This is a hassle. How often is this going to happen?
A: The last mass password change in Fedora was more than 3 years ago.
Absent a triggering event, these mass changes will be infrequent.
Q: The new password length requirements/rules are too strict.
How will I remember passwords that are that long?
A: You can employ a password storage application (see above), or
use a method like diceware (see below), or construct a memorable
sentence or phrase.
Q: How do I generate a new ssh key? How do I use it for just Fedora
hosts?
A: See http://fedoraproject.org/wiki/Cryptography and use a
~/.ssh/config file to match fedoraproject.org hosts for that key.
Q: I never uploaded a ssh key to the Fedora Account System, nor am I
in a group that needs one, do I still have to upload a new one?
A: No. If you don't have a ssh public key uploaded or desire to do so,
you can just change your password.
More reading:
http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-si...
https://fedoraproject.org/wiki/Infrastructure_mass_password_update
http://xkcd.com/936/
http://www.iusmentis.com/security/passphrasefaq/
http://world.std.com/~reinhold/diceware.html
http://fedoraproject.org/wiki/Cryptography
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
12:41 p.m.
On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
All existing users of the Fedora Account System (FAS) at
https://admin.fedoraproject.org/accounts are required to change their
password and upload a NEW ssh public key before 2011-11-30.
I have to upload a *new* public key? Why should I have two sets of keys?
* Nine or more characters with lower and upper case letters, digits
and
punctuation marks.
* Ten or more characters with lower and upper case letters and digits.
* Twelve or more characters with lower case letters and digits
* Twenty or more characters with all lower case letters.
This is just insane. My existing password is 8 digits and
alphanumeric, and given that I have to enter it over and over again
(and prove "I'm human", another WTF) when creating updates I'm really
wondering if I want to bother.
Talk about putting up barriers.
Richard.
12:51 p.m.
On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> All existing users of the Fedora Account System (FAS) at
> https://admin.fedoraproject.org/accounts are required to change their
> password and upload a NEW ssh public key before 2011-11-30.
I have to upload a *new* public key? Why should I have two sets of keys?
Meant 'replacement'. You can only have one key in FAS, afaict.
> * Nine or more characters with lower and upper case letters,
digits and
> punctuation marks.
> * Ten or more characters with lower and upper case letters and digits.
> * Twelve or more characters with lower case letters and digits
> * Twenty or more characters with all lower case letters.
This is just insane. My existing password is 8 digits and
alphanumeric, and given that I have to enter it over and over again
(and prove "I'm human", another WTF) when creating updates I'm really
wondering if I want to bother.
Talk about putting up barriers.
I can think of no reason why everyone shouldn't use a password manager.
It's just hands down a better way to do things in every respect. Eight
characters alphanumeric is not actually a very strong password; the
numbers on how long it'd take to brute force with e.g. EC2 are quite
tiny. And an account like yours certainly counts as high-value.
This is clearly not a theoretical threat: kernel.org _was compromised_.
mysql _was compromised_. winehq _was compromised_. There are actual
real-world attackers out there right now going after open source project
systems, precisely using attacks on weak and shared credentials. This is
not some stupid 'best practice' thing, this is a practical attempt to
prevent us falling victim to specific and very obviously real threats.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:53 p.m.
On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > All existing users of the Fedora Account System (FAS) at
> > https://admin.fedoraproject.org/accounts are required to change their
> > password and upload a NEW ssh public key before 2011-11-30.
>
> I have to upload a *new* public key? Why should I have two sets of keys?
Meant 'replacement'. You can only have one key in FAS, afaict.
You can have more than one. Just paste them in place all together.
And we're verifying key changes by checking the fingerprint of the
pubkeys vs your prior ones.
-sv
12:58 p.m.
On Wed, 2011-10-12 at 13:53 -0400, seth vidal wrote:
On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > > All existing users of the Fedora Account System (FAS) at
> > > https://admin.fedoraproject.org/accounts are required to change their
> > > password and upload a NEW ssh public key before 2011-11-30.
> >
> > I have to upload a *new* public key? Why should I have two sets of keys?
>
> Meant 'replacement'. You can only have one key in FAS, afaict.
You can have more than one. Just paste them in place all together.
And we're verifying key changes by checking the fingerprint of the
pubkeys vs your prior ones.
ah, k. I think what Richard was thinking, though, is that by 'new ssh
public key' you meant 'add a new key alongside your existing one', which
is why I clarified that the requirement was to _replace_ your existing
one.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:04 p.m.
On Wed, 2011-10-12 at 10:58 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 13:53 -0400, seth vidal wrote:
> On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
> > On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> > > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > > > All existing users of the Fedora Account System (FAS) at
> > > > https://admin.fedoraproject.org/accounts are required to change
their
> > > > password and upload a NEW ssh public key before 2011-11-30.
> > >
> > > I have to upload a *new* public key? Why should I have two sets of keys?
> >
> > Meant 'replacement'. You can only have one key in FAS, afaict.
>
>
> You can have more than one. Just paste them in place all together.
>
>
> And we're verifying key changes by checking the fingerprint of the
> pubkeys vs your prior ones.
ah, k. I think what Richard was thinking, though, is that by 'new ssh
public key' you meant 'add a new key alongside your existing one', which
is why I clarified that the requirement was to _replace_ your existing
one.
I see. Sorry. I must have misunderstood.
-sv
1:06 p.m.
On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > > All existing users of the Fedora Account System (FAS) at
> > > https://admin.fedoraproject.org/accounts are required to change
> their
> > > password and upload a NEW ssh public key before 2011-11-30.
> >
> > I have to upload a *new* public key? Why should I have two sets of
> keys?
>
> Meant 'replacement'. You can only have one key in FAS, afaict.
You can have more than one. Just paste them in place all together.
And we're verifying key changes by checking the fingerprint of the
pubkeys vs your prior ones.
It's really not a huge hassle. I've already done it. I configured the
.ssh/config files where I needed to, and it doesn't conflict with any
other keys I have. I don't get what the big deal is. The disruption is,
like, five minutes of work. The potential benefit is unknown, but
certainly not zero.
Why wait for a breach to do this? This is a perfect time. Doing it
after the 2008 breach was wise. This is better.
-J
-sv
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
1:20 p.m.
On Wed, 2011-10-12 at 13:06 -0500, Jon Ciesla wrote:
> On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
>> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
>> > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
>> > > All existing users of the Fedora Account System (FAS) at
>> > > https://admin.fedoraproject.org/accounts are required to change
>> their
>> > > password and upload a NEW ssh public key before 2011-11-30.
>> >
>> > I have to upload a *new* public key? Why should I have two sets of
>> keys?
>>
>> Meant 'replacement'. You can only have one key in FAS, afaict.
>
>
> You can have more than one. Just paste them in place all together.
>
>
> And we're verifying key changes by checking the fingerprint of the
> pubkeys vs your prior ones.
It's really not a huge hassle. I've already done it. I configured the
.ssh/config files where I needed to, and it doesn't conflict with any
other keys I have. I don't get what the big deal is. The disruption is,
like, five minutes of work. The potential benefit is unknown, but
certainly not zero.
Why wait for a breach to do this? This is a perfect time. Doing it
after the 2008 breach was wise. This is better.
A breach won't compromise my actual keys even if it happened now or a
year ago.
Plus there are limitations on how many keys (and passpharases I can
remember, especially for stuff I use less often).
Plus there are limitation about how many keys ssh/ssh-agent can use
before failing to log you in no matter what.
Compound all this.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:25 p.m.
On Wed, 2011-10-12 at 13:06 -0500, Jon Ciesla wrote:
> > On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
> >> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> >> > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> >> > > All existing users of the Fedora Account System (FAS) at
> >> > > https://admin.fedoraproject.org/accounts are required to change
> >> their
> >> > > password and upload a NEW ssh public key before 2011-11-30.
> >> >
> >> > I have to upload a *new* public key? Why should I have two sets of
> >> keys?
> >>
> >> Meant 'replacement'. You can only have one key in FAS, afaict.
> >
> >
> > You can have more than one. Just paste them in place all together.
> >
> >
> > And we're verifying key changes by checking the fingerprint of the
> > pubkeys vs your prior ones.
>
> It's really not a huge hassle. I've already done it. I configured the
> .ssh/config files where I needed to, and it doesn't conflict with any
> other keys I have. I don't get what the big deal is. The disruption
> is,
> like, five minutes of work. The potential benefit is unknown, but
> certainly not zero.
>
> Why wait for a breach to do this? This is a perfect time. Doing it
> after the 2008 breach was wise. This is better.
A breach won't compromise my actual keys even if it happened now or a
year ago.
Unless the breach alters a package that gets pushed to your machine and
snarfs your keys. </devilsadvocate>
Plus there are limitations on how many keys (and passpharases I can
remember, especially for stuff I use less often).
keepassx.
Plus there are limitation about how many keys ssh/ssh-agent can use
before failing to log you in no matter what.
If your client config knows what key to use for what host, and you know
the password, I fail to see the problem. Plus, you could have multiple
keys, all with the same passphrase, for different things, should you so
desire.
Compound all this.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
1:40 p.m.
On Wed, 2011-10-12 at 13:25 -0500, Jon Ciesla wrote:
> On Wed, 2011-10-12 at 13:06 -0500, Jon Ciesla wrote:
>> > On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
>> >> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
>> >> > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com>
wrote:
>> >> > > All existing users of the Fedora Account System (FAS) at
>> >> > > https://admin.fedoraproject.org/accounts are required to
change
>> >> their
>> >> > > password and upload a NEW ssh public key before 2011-11-30.
>> >> >
>> >> > I have to upload a *new* public key? Why should I have two sets
of
>> >> keys?
>> >>
>> >> Meant 'replacement'. You can only have one key in FAS, afaict.
>> >
>> >
>> > You can have more than one. Just paste them in place all together.
>> >
>> >
>> > And we're verifying key changes by checking the fingerprint of the
>> > pubkeys vs your prior ones.
>>
>> It's really not a huge hassle. I've already done it. I configured the
>> .ssh/config files where I needed to, and it doesn't conflict with any
>> other keys I have. I don't get what the big deal is. The disruption
>> is,
>> like, five minutes of work. The potential benefit is unknown, but
>> certainly not zero.
>>
>> Why wait for a breach to do this? This is a perfect time. Doing it
>> after the 2008 breach was wise. This is better.
>
> A breach won't compromise my actual keys even if it happened now or a
> year ago.
Unless the breach alters a package that gets pushed to your machine and
snarfs your keys. </devilsadvocate>
That's possible, at which point I will have to change all my keys.
But unless the machine is reinstalled first, it will make no difference,
new keys will be snarfed again as soon as they are created.
> Plus there are limitations on how many keys (and passpharases I
can
> remember, especially for stuff I use less often).
keepassx.
By rule ssh and gpg keys passphrases exist only in my memory.
No chance of writing them down.
> Plus there are limitation about how many keys ssh/ssh-agent can
use
> before failing to log you in no matter what.
If your client config knows what key to use for what host, and you know
the password, I fail to see the problem. Plus, you could have multiple
keys, all with the same passphrase, for different things, should you so
desire.
Using the same passphrase for different keys is the same as using the
same password for different websites. If I am protecting the keys the
same way I can as well use the same keys everywhere, unless projects set
up insane rules about how to handle my own keys.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:57 p.m.
On Wed, 2011-10-12 at 13:25 -0500, Jon Ciesla wrote:
> > On Wed, 2011-10-12 at 13:06 -0500, Jon Ciesla wrote:
> >> > On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote:
> >> >> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> >> >> > On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> >> >> > > All existing users of the Fedora Account System (FAS) at
> >> >> > > https://admin.fedoraproject.org/accounts are required to
> change
> >> >> their
> >> >> > > password and upload a NEW ssh public key before
2011-11-30.
> >> >> >
> >> >> > I have to upload a *new* public key? Why should I have two
sets
> of
> >> >> keys?
> >> >>
> >> >> Meant 'replacement'. You can only have one key in FAS,
afaict.
> >> >
> >> >
> >> > You can have more than one. Just paste them in place all together.
> >> >
> >> >
> >> > And we're verifying key changes by checking the fingerprint of the
> >> > pubkeys vs your prior ones.
> >>
> >> It's really not a huge hassle. I've already done it. I configured
> the
> >> .ssh/config files where I needed to, and it doesn't conflict with any
> >> other keys I have. I don't get what the big deal is. The disruption
> >> is,
> >> like, five minutes of work. The potential benefit is unknown, but
> >> certainly not zero.
> >>
> >> Why wait for a breach to do this? This is a perfect time. Doing it
> >> after the 2008 breach was wise. This is better.
> >
> > A breach won't compromise my actual keys even if it happened now or a
> > year ago.
>
> Unless the breach alters a package that gets pushed to your machine and
> snarfs your keys. </devilsadvocate>
That's possible, at which point I will have to change all my keys.
But unless the machine is reinstalled first, it will make no difference,
new keys will be snarfed again as soon as they are created.
> > Plus there are limitations on how many keys (and passpharases I can
> > remember, especially for stuff I use less often).
>
> keepassx.
By rule ssh and gpg keys passphrases exist only in my memory.
No chance of writing them down.
> > Plus there are limitation about how many keys ssh/ssh-agent can use
> > before failing to log you in no matter what.
>
> If your client config knows what key to use for what host, and you know
> the password, I fail to see the problem. Plus, you could have multiple
> keys, all with the same passphrase, for different things, should you so
> desire.
Using the same passphrase for different keys is the same as using the
same password for different websites. If I am protecting the keys the
same way I can as well use the same keys everywhere, unless projects set
up insane rules about how to handle my own keys.
I wasn't suggesting it was a good idea, I was suggesting that it was a
tradeoff one could make in favor of convenience. I don't, personally.
-J
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
2:20 p.m.
ons 2011-10-12 klockan 13:25 -0500 skrev Jon Ciesla:
Plus, you could have multiple
keys, all with the same passphrase, for different things, should you so
desire.
That's effectively one shared key for all. If one of them are
compromized them most likely all of them are, as the attacker clearly
gained access to both
- The storage locaiton where the keys were stored
- The encryption key (passphrase)
And if an attacker managed to gain access to this combination for any of
your keys it's likely he also gains access to the others.
Regards
Henrik
2:22 p.m.
ons 2011-10-12 klockan 13:25 -0500 skrev Jon Ciesla:
> Plus, you could have multiple
> keys, all with the same passphrase, for different things, should you so
> desire.
That's effectively one shared key for all. If one of them are
compromized them most likely all of them are, as the attacker clearly
gained access to both
- The storage locaiton where the keys were stored
- The encryption key (passphrase)
And if an attacker managed to gain access to this combination for any of
your keys it's likely he also gains access to the others.
Agreed, it's a bad idea. I was just throwing it out there as one nod to
convenience. I don't do it.
-J
Regards
Henrik
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
2:40 p.m.
Jon Ciesla <limb(a)jcomserv.net> wrote:
[...]
It's really not a huge hassle. I've already done it. I
configured the
.ssh/config files where I needed to, and it doesn't conflict with any
other keys I have. I don't get what the big deal is. The disruption is,
like, five minutes of work. The potential benefit is unknown, but
certainly not zero.
Nodz.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
1:10 p.m.
On Wed, Oct 12, 2011 at 6:51 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
> On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > All existing users of the Fedora Account System (FAS) at
> > https://admin.fedoraproject.org/accounts are required to change their
> > password and upload a NEW ssh public key before 2011-11-30.
>
> I have to upload a *new* public key? Why should I have two sets of keys?
Meant 'replacement'. You can only have one key in FAS, afaict.
> > * Nine or more characters with lower and upper case letters, digits and
> > punctuation marks.
> > * Ten or more characters with lower and upper case letters and digits.
> > * Twelve or more characters with lower case letters and digits
> > * Twenty or more characters with all lower case letters.
>
> This is just insane. My existing password is 8 digits and
> alphanumeric, and given that I have to enter it over and over again
> (and prove "I'm human", another WTF) when creating updates I'm
really
> wondering if I want to bother.
>
> Talk about putting up barriers.
I can think of no reason why everyone shouldn't use a password manager.
It's just hands down a better way to do things in every respect. Eight
characters alphanumeric is not actually a very strong password; the
numbers on how long it'd take to brute force with e.g. EC2 are quite
tiny. And an account like yours certainly counts as high-value.
In fact there are rainbow tables out there easily available of all 8
alpha numeric combinations where you wouldn't even need EC2 to crack a
lot of them. I know of a couple DBs where they have Terabytes of pre
calculated password hashes and its just a simple string match.
Peter
1:12 p.m.
On 10/12/2011 02:10 PM, Peter Robinson wrote:
On Wed, Oct 12, 2011 at 6:51 PM, Adam
Williamson<awilliam(a)redhat.com> wrote:
> On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote:
>> On 12 October 2011 17:44, Kevin Fenzi<kevin(a)scrye.com> wrote:
>>> All existing users of the Fedora Account System (FAS) at
>>> https://admin.fedoraproject.org/accounts are required to change their
>>> password and upload a NEW ssh public key before 2011-11-30.
>>
>> I have to upload a *new* public key? Why should I have two sets of keys?
>
> Meant 'replacement'. You can only have one key in FAS, afaict.
>
>>> * Nine or more characters with lower and upper case letters, digits and
>>> punctuation marks.
>>> * Ten or more characters with lower and upper case letters and digits.
>>> * Twelve or more characters with lower case letters and digits
>>> * Twenty or more characters with all lower case letters.
>>
>> This is just insane. My existing password is 8 digits and
>> alphanumeric, and given that I have to enter it over and over again
>> (and prove "I'm human", another WTF) when creating updates I'm
really
>> wondering if I want to bother.
>>
>> Talk about putting up barriers.
>
> I can think of no reason why everyone shouldn't use a password manager.
> It's just hands down a better way to do things in every respect. Eight
> characters alphanumeric is not actually a very strong password; the
> numbers on how long it'd take to brute force with e.g. EC2 are quite
> tiny. And an account like yours certainly counts as high-value.
In fact there are rainbow tables out there easily available of all 8
alpha numeric combinations where you wouldn't even need EC2 to crack a
lot of them. I know of a couple DBs where they have Terabytes of pre
calculated password hashes and its just a simple string match.
Peter
If FAS uses salts, and the DB hasn't been compromised, then rainbow
tables are useless. If re-encryption is used, then brute force will be
much slower.
Eight char passwords are not ideal, but they are also not trivially
compromised if the system uses relatively basic/simple precautions.
Again, baring a lead of the DB/salts therein.
--
Digimer
E-Mail: digimer(a)alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"At what point did we forget that the Space Shuttle was, essentially,
a program that strapped human beings to an explosion and tried to stab
through the sky with fire and math?"
1:37 p.m.
On 10/12/2011 01:41 PM, Richard Hughes wrote:
On 12 October 2011 17:44, Kevin Fenzi<kevin(a)scrye.com> wrote:
> * Nine or more characters with lower and upper case letters, digits and
> punctuation marks.
> * Ten or more characters with lower and upper case letters and digits.
> * Twelve or more characters with lower case letters and digits
> * Twenty or more characters with all lower case letters.
This is just insane. My existing password is 8 digits and
alphanumeric, and given that I have to enter it over and over again
(and prove "I'm human", another WTF) when creating updates I'm really
wondering if I want to bother.
Length beats out larger character set, which is nicely illustrated by
the XKCD cartoon
http://imgs.xkcd.com/comics/password_strength.png
Considering that it's hard to type a wide character set (I probably
touch-type '&' correctly about 70% of the time), I actually like long
alpha passwords.
It is strange though that the complexity of the new requirements varies
so much:
(24+24+10+12)^9 or 4.0354e+16
(24+24+10)^10 or 4.3080e+17
(24+24)^12 or 1.4959e+20
(24)^20 or 4.0200e+27
except, of course, the alphabetic strings aren't likely to be purely
random but rather dictionary words, which would reduce the complexity
spread.
Richard's complexity is (24+24+10)^8, or 1.2806e+14 which is not that
much worse than the low end. We all know that he'll just add '1' to his
existing password :)
except, of course, the alphabetic strings aren't going to be purely
random but rather dictionary words, which would reduce the complexity
spread.
2:45 a.m.
On Wed, Oct 12, 2011 at 1:37 PM, Przemek Klosowski
<przemek.klosowski(a)nist.gov> wrote:
Length beats out larger character set, which is nicely illustrated
by
the XKCD cartoon
http://imgs.xkcd.com/comics/password_strength.png
Be careful, that xkcd strip glosses over how that phrase was actually
generated. If you just pick words or sentences out of your head, you
could actually have dangerously little actual entropy in your
passphrase. Do NOT actually use spaces in your passphrase, the space
bar typically makes a distinctive sound so an eavesdropper can
potentially figure out how many words are in your passphrase, and the
length of each word, narrowing their search window...
He's assigning 11 bits of entropy to each word, 2^11 = a word list
2048 words long, which corresponds with S/KEY:
http://en.wikipedia.org/wiki/S/KEY
There's also:
http://en.wikipedia.org/wiki/Diceware
http://en.wikipedia.org/wiki/Bubble_Babble
http://en.wikipedia.org/wiki/Biometric_word_list
Cryptographic security is all in the details, doing it even slightly
wrong can completely destroy your security. Make sure to follow a
proven strategy if you're going the passphrase route.
Personally I've been generating passwords with "pwgen -s 12 1", or for
really important stuff (like online banking), "pwgen -s 12 1". A
different password for absolutely everything, all passwords are stored
in a Revelation database protected by a REALLY long passphrase. I find
its not that hard to remember a completely obscure 12-char password,
after a day or two of frequent use, if you force yourself to actually
type it in by hand rather than just cut-and-pasting from Revelation.
Try just memorizing 2-4 chars at a time until you remember it all. I
find I end up just consciously remembering the first 4 chars and
muscle memory completes the rest...
Also see:
http://www.wired.com/politics/security/commentary/securitymatters/2007/01...
6:03 a.m.
On 10/13/2011 09:45 AM, Callum Lerwick wrote:
On Wed, Oct 12, 2011 at 1:37 PM, Przemek Klosowski
<przemek.klosowski(a)nist.gov> wrote:
> Length beats out larger character set, which is nicely illustrated by
> the XKCD cartoon
>
> http://imgs.xkcd.com/comics/password_strength.png
Be careful, that xkcd strip glosses over how that phrase was actually
generated. If you just pick words or sentences out of your head, you
could actually have dangerously little actual entropy in your
passphrase. Do NOT actually use spaces in your passphrase, the space
bar typically makes a distinctive sound so an eavesdropper can
potentially figure out how many words are in your passphrase, and the
length of each word, narrowing their search window...
- well, to me "correct horse battery staple" seems random enough, but
I'd like to ask everyone to not use it, because it's what I use as my
password on every machine I have access to...
Regards,
Jirka
He's assigning 11 bits of entropy to each word, 2^11 = a word
list
2048 words long, which corresponds with S/KEY:
http://en.wikipedia.org/wiki/S/KEY
There's also:
http://en.wikipedia.org/wiki/Diceware
http://en.wikipedia.org/wiki/Bubble_Babble
http://en.wikipedia.org/wiki/Biometric_word_list
Cryptographic security is all in the details, doing it even slightly
wrong can completely destroy your security. Make sure to follow a
proven strategy if you're going the passphrase route.
Personally I've been generating passwords with "pwgen -s 12 1", or for
really important stuff (like online banking), "pwgen -s 12 1". A
different password for absolutely everything, all passwords are stored
in a Revelation database protected by a REALLY long passphrase. I find
its not that hard to remember a completely obscure 12-char password,
after a day or two of frequent use, if you force yourself to actually
type it in by hand rather than just cut-and-pasting from Revelation.
Try just memorizing 2-4 chars at a time until you remember it all. I
find I end up just consciously remembering the first 4 chars and
muscle memory completes the rest...
Also see:
http://www.wired.com/politics/security/commentary/securitymatters/2007/01...
3:50 p.m.
On Thu, Oct 13, 2011 at 2:45 AM, Callum Lerwick <seg(a)haxxed.com> wrote:
Personally I've been generating passwords with "pwgen -s 12
1", or for
really important stuff (like online banking), "pwgen -s 12 1".
Erk, that should be "pwgen -s -y 12" for the important stuff.
Cut-and-paste fail. :(
A fully random 12 char alpha-numeric (with fully random caps) password
is about ~71 bits of entropy.
A fully random 12 char password using all 94 printable ASCII
characters (not including space) is ~78 bits of entropy.
Remember, bits multiply exponentially. Each additional bit doubles
your search space. If I did my math right, this is exceeding a four
word S/KEY passphrase (~44 bits) by about 8-10 orders of magnitude.
You need to go to 7 (!) S/KEY words to get to ~77 bits of entropy.
See:
http://en.wikipedia.org/wiki/Password_strength
Also of interest:
http://www.schneier.com/blog/archives/2005/06/write_down_your.html
As computers become faster, depending purely on human memory for
security only becomes more and more impractical. As time goes on, OTP
devices are necessary for any real security:
http://fedoraproject.org/wiki/Infrastruture/Yubikey
http://code.google.com/p/google-authenticator/
http://us.blizzard.com/support/article.xml?locale=en_US&articleId=24660
(IIRC, World of Warcraft is the #1 target for cracking, phishing, and
fraud in the world today. Its big business! But I can't find any
references offhand...)
7:19 a.m.
On Wed, 2011-10-12 at 14:37 -0400, Przemek Klosowski wrote:
On 10/12/2011 01:41 PM, Richard Hughes wrote:
> On 12 October 2011 17:44, Kevin Fenzi<kevin(a)scrye.com> wrote:
>> * Nine or more characters with lower and upper case letters, digits and
>> punctuation marks.
>> * Ten or more characters with lower and upper case letters and digits.
>> * Twelve or more characters with lower case letters and digits
>> * Twenty or more characters with all lower case letters.
>
> This is just insane. My existing password is 8 digits and
> alphanumeric, and given that I have to enter it over and over again
> (and prove "I'm human", another WTF) when creating updates I'm
really
> wondering if I want to bother.
Length beats out larger character set, which is nicely illustrated by
the XKCD cartoon
http://imgs.xkcd.com/comics/password_strength.png
Considering that it's hard to type a wide character set (I probably
touch-type '&' correctly about 70% of the time), I actually like long
alpha passwords.
It is strange though that the complexity of the new requirements varies
so much:
(24+24+10+12)^9 or 4.0354e+16
(24+24+10)^10 or 4.3080e+17
(24+24)^12 or 1.4959e+20
(24)^20 or 4.0200e+27
except, of course, the alphabetic strings aren't likely to be purely
random but rather dictionary words, which would reduce the complexity
spread.
This rules are very restricting.
If I want to use _random_ lower case letters, I have to remember 20
random characters and have marginally more secure password compared to
people who use lower case, upper case and digits?
Even just 14 random lower case letters have bigger complexity than the
other cases.
I can use 12 characters long random lower case password, or
"aaaaaaaaaaaaaaaaaaaa". I will not be remembering 20 random letters.
Please change the rules to have at least similar complexity.
Richard's complexity is (24+24+10)^8, or 1.2806e+14 which is not that
much worse than the low end. We all know that he'll just add '1' to his
existing password :)
except, of course, the alphabetic strings aren't going to be purely
random but rather dictionary words, which would reduce the complexity
spread.
--
Martin Gracik <mgracik(a)redhat.com>
9:26 p.m.
Richard Hughes wrote:
On 12 October 2011 17:44, Kevin Fenzi <kevin(a)scrye.com> wrote:
> All existing users of the Fedora Account System (FAS) at
> https://admin.fedoraproject.org/accounts are required to change their
> password and upload a NEW ssh public key before 2011-11-30.
I have to upload a *new* public key? Why should I have two sets of keys?
(or upload a new key to all the other f***ing servers I'm using)
+1
> * Nine or more characters with lower and upper case letters,
digits and
> punctuation marks.
> * Ten or more characters with lower and upper case letters and digits.
> * Twelve or more characters with lower case letters and digits
> * Twenty or more characters with all lower case letters.
This is just insane. My existing password is 8 digits and
alphanumeric, and given that I have to enter it over and over again
(and prove "I'm human", another WTF) when creating updates I'm really
wondering if I want to bother.
Talk about putting up barriers.
+1 again!
This stupid security paranoia really needs to stop! There is NO concrete
reason why we're being forced to change the password and the SSH key, plus
the new password requirements are too strict. It's bad enough that we have
to generate a new Koji client certificate every 6 months for no reason. (The
expiration time on these should be infinite, only explicitly revoked certs
should be rejected.)
Now after the whole FPCA stuff (which was enforced really radically, with a
tight deadline, mass orphaning of packages and no deadline extension even
though many people hadn't complied by the posted deadline, when the old ICLA
had served us well for years (so why the rush?)), we're going to once again
lose many contributors, and packages with them, due to stupid, unnecessary
and inflexible bureaucratic policies being enforced in an automated and
draconian way.
And once again we're going another step further from TRUSTING our
contributors (to either keep their credentials secure or replace/revoke
them, in this case).
What will come next? Will you start taking our (actual, biometric)
fingerprints? Iris scans? Will we only be able to log into Fedora
infrastructure in the presence of armed security guards? It's time to stop
the nonsense!
Kevin Kofler
12:53 p.m.
On 10/12/2011 12:44 PM, Kevin Fenzi wrote:
Subject: IMPORTANT: Mandatory password and ssh key change by
2011-11-30
Summary:
All existing users of the Fedora Account System (FAS) at
https://admin.fedoraproject.org/accounts are required to change their
password and upload a NEW ssh public key before 2011-11-30.
Failure to do so may result in your account being marked inactive.
Passwords changed and NEW ssh public keys uploaded after 2011-10-10
will meet this requirement.
I'd like to add my voice to the concern about requiring new public keys.
I can appreciate the desire for security, but forcing new SSH keys
accomplishes nothing of practical use. Quite the contrary; It induces a
fair hardship of those of us with keys configured on many other systems.
The idea of maintaining a second set of keys for Fedora (and again for
any other projects that follow suit) is, I'd argue, unreasonably burdensome.
--
Digimer
E-Mail: digimer(a)alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"At what point did we forget that the Space Shuttle was, essentially,
a program that strapped human beings to an explosion and tried to stab
through the sky with fire and math?"
2:44 p.m.
On Wed, 12 Oct 2011 13:53:34 -0400
Digimer <linux(a)alteeve.com> wrote:
On 10/12/2011 12:44 PM, Kevin Fenzi wrote:
> Subject: IMPORTANT: Mandatory password and ssh key change by
> 2011-11-30
>
> Summary:
>
> All existing users of the Fedora Account System (FAS) at
> https://admin.fedoraproject.org/accounts are required to change
> their password and upload a NEW ssh public key before 2011-11-30.
> Failure to do so may result in your account being marked inactive.
> Passwords changed and NEW ssh public keys uploaded after 2011-10-10
> will meet this requirement.
I'd like to add my voice to the concern about requiring new public
keys. I can appreciate the desire for security, but forcing new SSH
keys accomplishes nothing of practical use. Quite the contrary; It
induces a fair hardship of those of us with keys configured on many
other systems.
I'm sorry it's causing you hassle. It does accomplish some practical
gain, IMHO.
You can use a separate key for Fedora machines if that makes things
easier for you. Or you could document and determine now when you aren't
in a hurry (the deadline is 1.5 months away) what hosts you need to
change and that your private key wasn't accidentally backed up to them.
The idea of maintaining a second set of keys for Fedora (and again
for any other projects that follow suit) is, I'd argue, unreasonably
burdensome.
I'm sorry you think so. You don't have to take that tack if you don't
like.
kevin
2:56 p.m.
Digimer <linux(a)alteeve.com> wrote:
[...]
The idea of maintaining a second set of keys for Fedora (and again
for
any other projects that follow suit) is, I'd argue, unreasonably burdensome.
Oh, come on. It was less than 5 minutes (and I learnt a bit while at it
too). From now on, it will be handled automagically by my machine here.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
1:19 p.m.
The password change is understandable, but why force an SSH key change
with such short notice?
And what if the SSH key is a hard token (smartcard) which can not be
copied or trivially changed? Switching to a soft key would be mostly
counter-productive from a security point of view. Now I were not
currently using my hard token smartcard key for Fedora for other reasons
but I would had been quite annoyed by this change requirement if I were.
And why is so much of the Fedora inftrastructure relying on plain text
password exchanges (within SSL, but still plain text at the Fedora
servers) when there is both HTTP digest authentication (no plaintext
seen by Fedora servers) and SSL certificates and SSH keys which all
three serves a much better identification method?
And you forgot the one most important DON'T in the list. Never use the
same password for two different systems. Do not use the same password
for Fedora account as you use for Hotmal / GMail / At Work / Facebook /
Whatever.
But even then, the security of Fedora accounts is no stronger than the
security of the email associated with an account. Quite pointless to try
to bolster the security very high when all that is needed to take over a
standard Fedora account is to have access to the email (account or
traffic) of the Fedora account. Sure, a full account takeover is more
likely to get noticed than a stolen password, but it still sets the
level of expected security.
Regards
Henrik
1:22 p.m.
2011/10/12 Henrik Nordström <henrik(a)henriknordstrom.net>:
The password change is understandable, but why force an SSH key
change
with such short notice?
And what if the SSH key is a hard token (smartcard) which can not be
copied or trivially changed? Switching to a soft key would be mostly
counter-productive from a security point of view. Now I were not
currently using my hard token smartcard key for Fedora for other reasons
but I would had been quite annoyed by this change requirement if I were.
If your using a hard token you should be using a subkeys I believe and
not the root key, not sure if that's gpg or ssh or both.
Peter
2:30 p.m.
ons 2011-10-12 klockan 19:22 +0100 skrev Peter Robinson:
If your using a hard token you should be using a subkeys I believe
and
not the root key, not sure if that's gpg or ssh or both.
subkeys is not relevant to the SSH world. That's a OpenPGP thing where
the main key should only be used for the chain of trust and stored
separately off line, and subkeys for the day to dya usage
(identification, encryption), as chaning the chain of trust key is a
real pain.
The hard tokein I normally use is a OpenPGP card, and as far as I know
it only have one free slot for the SSH key. The card have three RSA keys
in total, Signing, Encryption, Authentication(SSH).
Regards
Henrik
2:49 p.m.
On Wed, 12 Oct 2011 20:19:27 +0200
Henrik Nordström <henrik(a)henriknordstrom.net> wrote:
The password change is understandable, but why force an SSH key
change
with such short notice?
Short? 1.5 months?
How long would you like?
And what if the SSH key is a hard token (smartcard) which can not be
copied or trivially changed? Switching to a soft key would be mostly
counter-productive from a security point of view. Now I were not
currently using my hard token smartcard key for Fedora for other
reasons but I would had been quite annoyed by this change requirement
if I were.
If you can't change your token, then I would posit you have a problem.
What if you KNEW your private key was compromised? Surely there is a
way to generate a new one...
And why is so much of the Fedora inftrastructure relying on plain
text
password exchanges (within SSL, but still plain text at the Fedora
servers) when there is both HTTP digest authentication (no plaintext
seen by Fedora servers) and SSL certificates and SSH keys which all
three serves a much better identification method?
Please feel free to jump in and help code such changes. :)
We are a open source infrastructure and I'm sure patches and ideas even
would be welcome.
And you forgot the one most important DON'T in the list. Never
use the
same password for two different systems. Do not use the same password
for Fedora account as you use for Hotmal / GMail / At Work /
Facebook / Whatever.
Yeah, I kept adding things, but the email was already really long. ;(
But even then, the security of Fedora accounts is no stronger than
the
security of the email associated with an account. Quite pointless to
try to bolster the security very high when all that is needed to take
over a standard Fedora account is to have access to the email
(account or traffic) of the Fedora account. Sure, a full account
takeover is more likely to get noticed than a stolen password, but it
still sets the level of expected security.
Yeah, ideally we would do more here with gpg.
kevin
3:12 p.m.
ons 2011-10-12 klockan 13:49 -0600 skrev Kevin Fenzi:
If you can't change your token, then I would posit you have a
problem.
What if you KNEW your private key was compromised? Surely there is a
way to generate a new one...
I can change it, but it means changing it for all sytems I access using
that SSH token, not only Fedora. And as hard token keys is not easily
compromised without the token as such being stolen it's not something
you normally do.
A compromise of the hard token key without the token as such being
stolen together with the access code would require a bruteforce of the
RSA key in question.
Please feel free to jump in and help code such changes. :)
We are a open source infrastructure and I'm sure patches and ideas even
would be welcome.
Point taken. And something I been considering many times but not gotten
the whole way to doing. Getting there is quite far away for someone not
already woring on the infrastructure.
The tools needed already esists. The question is how to get the
infrastructure to use them.
> But even then, the security of Fedora accounts is no stronger
than the
> security of the email associated with an account. Quite pointless to
> try to bolster the security very high when all that is needed to take
> over a standard Fedora account is to have access to the email
> (account or traffic) of the Fedora account. Sure, a full account
> takeover is more likely to get noticed than a stolen password, but it
> still sets the level of expected security.
Yeah, ideally we would do more here with gpg.
Yes. Once there is a GPG or SSH key installed in the FAS account then
those should take preference over the email as "account owner key", and
resetting the account should not be possible with a plain text email
alone. If the GPG and SSH keys is both lost then administrator action
should be needed to reset the account and verifying credibility of the
account owner.
Regards
Henrik
3:15 p.m.
ons 2011-10-12 klockan 13:49 -0600 skrev Kevin Fenzi:
> If you can't change your token, then I would posit you have a problem.
> What if you KNEW your private key was compromised? Surely there is a
> way to generate a new one...
I can change it, but it means changing it for all sytems I access using
that SSH token, not only Fedora. And as hard token keys is not easily
compromised without the token as such being stolen it's not something
you normally do.
Well, no, actually it just means you just need to use a different key for
Fedora. There's no reason you can't keep using that key everywhere else
you're using it.
-J
A compromise of the hard token key without the token as such being
stolen together with the access code would require a bruteforce of the
RSA key in question.
> Please feel free to jump in and help code such changes. :)
> We are a open source infrastructure and I'm sure patches and ideas even
> would be welcome.
Point taken. And something I been considering many times but not gotten
the whole way to doing. Getting there is quite far away for someone not
already woring on the infrastructure.
The tools needed already esists. The question is how to get the
infrastructure to use them.
> > But even then, the security of Fedora accounts is no stronger than the
> > security of the email associated with an account. Quite pointless to
> > try to bolster the security very high when all that is needed to take
> > over a standard Fedora account is to have access to the email
> > (account or traffic) of the Fedora account. Sure, a full account
> > takeover is more likely to get noticed than a stolen password, but it
> > still sets the level of expected security.
>
> Yeah, ideally we would do more here with gpg.
Yes. Once there is a GPG or SSH key installed in the FAS account then
those should take preference over the email as "account owner key", and
resetting the account should not be possible with a plain text email
alone. If the GPG and SSH keys is both lost then administrator action
should be needed to reset the account and verifying credibility of the
account owner.
Regards
Henrik
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
4:59 p.m.
ons 2011-10-12 klockan 15:15 -0500 skrev Jon Ciesla:
Well, no, actually it just means you just need to use a different key
for
Fedora. There's no reason you can't keep using that key everywhere else
you're using it.
Sure I could buy another token just for fedora, just don't see what it
would add other than one more gadget to very careflully keep track of.
Regards
Henrik
3:24 p.m.
On Wed, 2011-10-12 at 13:49 -0600, Kevin Fenzi wrote:
On Wed, 12 Oct 2011 20:19:27 +0200
Henrik Nordström <henrik(a)henriknordstrom.net> wrote:
> The password change is understandable, but why force an SSH key change
> with such short notice?
Short? 1.5 months?
How long would you like?
> And what if the SSH key is a hard token (smartcard) which can not be
> copied or trivially changed? Switching to a soft key would be mostly
> counter-productive from a security point of view. Now I were not
> currently using my hard token smartcard key for Fedora for other
> reasons but I would had been quite annoyed by this change requirement
> if I were.
If you can't change your token, then I would posit you have a problem.
What if you KNEW your private key was compromised? Surely there is a
way to generate a new one...
If your token has been compromised you throw it away. Or it will be
compromised again evidently because there is a way to extract keys (keep
in mind HW tokens like that are tamper-proof).
> But even then, the security of Fedora accounts is no stronger
than the
> security of the email associated with an account. Quite pointless to
> try to bolster the security very high when all that is needed to take
> over a standard Fedora account is to have access to the email
> (account or traffic) of the Fedora account. Sure, a full account
> takeover is more likely to get noticed than a stolen password, but it
> still sets the level of expected security.
Yeah, ideally we would do more here with gpg.
Sure so next time you also force me to change my gpg key and throw away
years of web of trust ? No thanks!
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:33 p.m.
On Wed, Oct 12, 2011 at 08:19:27PM +0200, Henrik Nordström wrote:
And why is so much of the Fedora inftrastructure relying on plain text
password exchanges (within SSL, but still plain text at the Fedora
servers) when there is both HTTP digest authentication (no plaintext
seen by Fedora servers) and SSL certificates and SSH keys which all
three serves a much better identification method?
Don't know about hte others but we've actually looked at SSL certificates
several times. Unfortunately, they have the client side tooling around SSL
certificates makes them less attractive than they could be. It seems that
what we need is the equivalent to an ssh-agent for SSL certificates to bring
that end of things up to par.
-Toshio
2:43 p.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011, Kevin Fenzi wrote:
* DO verify ssh host keys via dnssec protected dns. ( .ssh/config:
"VerifyHostKeyDNS yes")
https://bugzilla.redhat.com/show_bug.cgi?id=180277
https://bugzilla.redhat.com/show_bug.cgi?id=730558
You can't tell us to use this while at the same time refusing to make
that security setting not the system default....
I asked for this back in 2006 ........
See the bug entry for my elaborate example showing you that DNS without DNSSEC
does NOT lead to automatically connecting to servers you were never on before
without prompting.
Paul
2:47 p.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011 15:43:42 -0400 (EDT)
Paul Wouters <paul(a)xelerance.com> wrote:
On Wed, 12 Oct 2011, Kevin Fenzi wrote:
> * DO verify ssh host keys via dnssec protected dns. ( .ssh/config:
> "VerifyHostKeyDNS yes")
https://bugzilla.redhat.com/show_bug.cgi?id=180277
https://bugzilla.redhat.com/show_bug.cgi?id=730558
You can't tell us to use this while at the same time refusing to make
that security setting not the system default....
I asked for this back in 2006 ........
If the 'you' you are talking to here is me, which is what it reads
like: I am not the openssh maintainer. ;)
See the bug entry for my elaborate example showing you that DNS
without DNSSEC does NOT lead to automatically connecting to servers
you were never on before without prompting.
I completely agree with your reasoning and would love to have this
default in openssh.
kevin
2:51 p.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 15:43 -0400, Paul Wouters wrote:
On Wed, 12 Oct 2011, Kevin Fenzi wrote:
> * DO verify ssh host keys via dnssec protected dns. ( .ssh/config:
> "VerifyHostKeyDNS yes")
https://bugzilla.redhat.com/show_bug.cgi?id=180277
https://bugzilla.redhat.com/show_bug.cgi?id=730558
You can't tell us to use this while at the same time refusing to make
that security setting not the system default....
I asked for this back in 2006 ........
See the bug entry for my elaborate example showing you that DNS without DNSSEC
does NOT lead to automatically connecting to servers you were never on before
without prompting.
Except nobody says or said that DNS without DNSSEC leads to the
automatic connection with such setting. The objection (upstream one that
is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend
on the DNSSEC security for your SSH connection security and that is
something we will never make default if upstream does not.
Setting it to 'VerifyHostKeyDNS ask' by default is another matter and I
am OK with that.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
5:17 p.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011, Tomas Mraz wrote:
Except nobody says or said that DNS without DNSSEC leads to the
automatic connection with such setting.
I answered that multiple times, including today with a vast amount of screen pasting
into https://bugzilla.redhat.com/show_bug.cgi?id=180277 to show you that
DNS without DNSSEC does NOT lead to automatic connection in ANY case other then
you already having the key in known_hosts, which is the same behaviour as without
any SSHFP record in DNS.
The objection (upstream one that
is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend
on the DNSSEC security for your SSH connection security
It does not add any new dependancies. If there is no DNSSEC, you are told the SSHFP
is in the DNS, shown the fingerprint like there is no SSHFP record, and asked if
you really want to continue. If there is DNSSEC, no entries to known_hosts are added
so whenever DNSSEC is not there, you fall back to exactly what you have now.
Also, ssh already "depends" on DNSSEC to get a trustworth A/AAAA record with an
RRSIG
from DNSSEC. The dependancy is there whether upstream likes it or not.
and that is
something we will never make default if upstream does not.
If upstream deems this so bad, why does upstream offer the option? I don't see them
offering 1des or rot13 cipher either. Apparently, upstream is somewhat divided?
Setting it to 'VerifyHostKeyDNS ask' by default is another
matter and I
am OK with that.
Thank you, it's good enough for me and a happy end of a 5 year old bug.
Paul
5:37 p.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 18:17 -0400, Paul Wouters wrote:
On Wed, 12 Oct 2011, Tomas Mraz wrote:
> Except nobody says or said that DNS without DNSSEC leads to the
> automatic connection with such setting.
I answered that multiple times, including today with a vast amount of screen pasting
into https://bugzilla.redhat.com/show_bug.cgi?id=180277 to show you that
DNS without DNSSEC does NOT lead to automatic connection in ANY case other then
you already having the key in known_hosts, which is the same behaviour as without
any SSHFP record in DNS.
You seem to not understand that NEVER said that DNS without DNSSEC leads
to automatic connection with the setting. That is not and never was the
problem. You're just repeating things I know and knew at that time very
well.
> The objection (upstream one that
> is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend
> on the DNSSEC security for your SSH connection security
It does not add any new dependancies. If there is no DNSSEC, you are told the SSHFP
is in the DNS, shown the fingerprint like there is no SSHFP record, and asked if
you really want to continue. If there is DNSSEC, no entries to known_hosts are added
so whenever DNSSEC is not there, you fall back to exactly what you have now.
Also, ssh already "depends" on DNSSEC to get a trustworth A/AAAA record with an
RRSIG
from DNSSEC. The dependancy is there whether upstream likes it or not.
Nope, you do not understand what the dependency is. Of course you depend
on the DNS to not be compromised to get the IP address of the host but
you still can verify the fingerprint on the first connection if you got
it by other means. And in case you already have it in known_hosts it
will explicitly disallow connection if the DNS gives you false answer
and you'll connect to a different host. With 'VerifyHostKeyDNS yes' if
there is a malicious DNS administrator, you will not have a chance to
verify the fingerprint, you will be directly connected to a false server
immediately compromising your password if password auth is used. And if
this malicious DNS administrator controls the caching nameserver you're
using for DNS queries, he can present you ANY data even 'valid' fake
DNSSEC data.
> and that is
> something we will never make default if upstream does not.
If upstream deems this so bad, why does upstream offer the option? I don't see them
offering 1des or rot13 cipher either. Apparently, upstream is somewhat divided?
> Setting it to 'VerifyHostKeyDNS ask' by default is another matter and I
> am OK with that.
Thank you, it's good enough for me and a happy end of a 5 year old bug.
Feature
request that is. And a change that is not to be taken lightly.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
3:29 a.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Tomas Mraz <tmraz(a)redhat.com> writes:
And if this malicious DNS administrator controls the caching
nameserver you're using for DNS queries, he can present you ANY data
even 'valid' fake DNSSEC data.
This is not generally true. Resolver libraries can (and should, IMHO)
verify DNSSEC themselves. Otherwise DNSSEC is somewhat pointless,
because it is precisely when you are stuck behind an untrusted Wifi
gateway that you need DNSSEC the most.
/Benny
3:51 a.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 2011-10-13 at 10:29 +0200, Benny Amorsen wrote:
Tomas Mraz <tmraz(a)redhat.com> writes:
> And if this malicious DNS administrator controls the caching
> nameserver you're using for DNS queries, he can present you ANY data
> even 'valid' fake DNSSEC data.
This is not generally true. Resolver libraries can (and should, IMHO)
verify DNSSEC themselves. Otherwise DNSSEC is somewhat pointless,
because it is precisely when you are stuck behind an untrusted Wifi
gateway that you need DNSSEC the most.
Yes, they can and should. But they
don't.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
9:21 a.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 13 Oct 2011, Tomas Mraz wrote:
>
>> And if this malicious DNS administrator controls the caching
>> nameserver you're using for DNS queries, he can present you ANY data
>> even 'valid' fake DNSSEC data.
>
> This is not generally true. Resolver libraries can (and should, IMHO)
> verify DNSSEC themselves. Otherwise DNSSEC is somewhat pointless,
> because it is precisely when you are stuck behind an untrusted Wifi
> gateway that you need DNSSEC the most.
Yes, they can and should. But they don't.
We're testing ftp://ftp.xelerance.com/dnssec-trigger/ and I hope it can
get integrated into Fedora.
It means running dnssec aware resolvers on the endnode, with as much use
as possible od dhcp obtained dns server caches.
Paul
9:46 a.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 13 Oct 2011, Tomas Mraz wrote:
Nope, you do not understand what the dependency is. Of course you
depend
on the DNS to not be compromised to get the IP address of the host but
you still can verify the fingerprint on the first connection if you got
it by other means.
That scales as well as all those firefox plugins that warn you when a cert
changes.... but yes, a very few individuals with pick up the phone, and good
for them!
and you'll connect to a different host. With
'VerifyHostKeyDNS yes' if
there is a malicious DNS administrator, you will not have a chance to
verify the fingerprint, you will be directly connected to a false server
immediately compromising your password if password auth is used.
That's a very good argument - but against password ssh authentication, not
against fingerprints in dnssec.
1) the infrastructure is already compromised by an inside DNS admin
2) the user apparently typing in a password into a machine they never
contacted before.
You should use "ssh-keyscan remotehost" to a machine you never connected to
before where you depend on password authentication to avoid this.
The only scenario where I can see trusting machines I never logged into before
is one where the cluster is trusted by the same admin, using the same usernames
and shared homedirs, in which case I would alwas have my authorized_keys,
and would immediately hit ctrl-c when a password prompt would happen.
And if
this malicious DNS administrator controls the caching nameserver you're
using for DNS queries, he can present you ANY data even 'valid' fake
DNSSEC data.
I have no idea what " 'valid' fake DNSSEC data" is supposed to mean. I
am assuming you mean something silly as "trust random dhcp obtained dns
server's AD bit". If you do that, you already lost before even getting
an ssh login on a new server. Any security aware fedora user is running
a local DNSSEC caching server. If not, then ssh will prompt them with
the host key!
Also, trusted the AD bit without trusting the last mile violates the RFC 3655
Section 3
3. Interpretation of the AD bit
A response containing data marked Insecure in the answer or authority
section MUST never have the AD bit set. In this case, the resolver
SHOULD treat the data as Insecure whether or not SIG records are
present.
A resolver MUST NOT blindly trust the AD bit unless it communicates
with a recursive nameserver over a secure transport mechanism or
using a message authentication such as TSIG [RFC2845] or SIG(0)
[RFC2931] and is explicitly configured to trust this recursive name
server.
If the ssh client grabs non-localhost resolver entries and trusts the AD
bit, then that is a bug and should be reported upstream.
Paul
1:15 p.m.
New subject: VerifyHostKeyDNS, was Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
>>>> On Thu, 13 Oct 2011 10:46:01 -0400 (EDT), Paul
Wouters <paul(a)xelerance.com> said:
PW> Also, trusted the AD bit without trusting the last mile violates the
PW> RFC 3655 Section 3
[snip]
PW> If the ssh client grabs non-localhost resolver entries and trusts the AD
PW> bit, then that is a bug and should be reported upstream.
The other option is to do in-application validation which gets all the
way to the end-system.
We actually have some instrumented openssh RPMs that are based on the
Fedora RPM with an additional patch to support in-application DNSSEC
validation.
https://www.dnssec-tools.org/wiki/index.php/OpenSSH
https://www.dnssec-tools.org/download/
The implementation does a number of nice things, which includes
auto-accepting SSHFP keys that were verified via DNSSEC.
--
Wes Hardaker
My Pictures: http://capturedonearth.com/
My Thoughts: http://pontifications.hardakers.net/
4:41 p.m.
Kevin Fenzi writes:
New Password Rules:
* Nine or more characters with lower and upper case letters, digits and
punctuation marks.
* Ten or more characters with lower and upper case letters and digits.
* Twelve or more characters with lower case letters and digits
* Twenty or more characters with all lower case letters.
* No maximum length.
Pop quiz, folks:
Guess how many people will have their password set to
"abcdefghijklmnopqrstuvwxyz".
It meets the new criteria.
5:01 p.m.
On Wed, 2011-10-12 at 17:41 -0400, Sam Varshavchik wrote:
Kevin Fenzi writes:
> New Password Rules:
>
> * Nine or more characters with lower and upper case letters, digits and
> punctuation marks.
> * Ten or more characters with lower and upper case letters and digits.
> * Twelve or more characters with lower case letters and digits
> * Twenty or more characters with all lower case letters.
> * No maximum length.
Pop quiz, folks:
Guess how many people will have their password set to
"abcdefghijklmnopqrstuvwxyz".
It meets the new criteria.
This is much easier to type and also passes:
12qwertyuiop
:)
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
7:12 p.m.
On 10/12/2011 10:44 AM, Kevin Fenzi wrote:
Q: How do I generate a new ssh key? How do I use it for just Fedora
hosts?
A: See http://fedoraproject.org/wiki/Cryptography and use a
~/.ssh/config file to match fedoraproject.org hosts for that key.
So just a message to say, thanks for the instructions. My key was
changed very quickly. I especially like the part about using multiple
keys as described above. I had no idea it was possible so thanks for the
learning! This will come in useful very shortly in a project I am
involved with.
Such a great example.
Thanks for working to keep everything as secure as possible.
--
Nathanael
7:30 p.m.
Once upon a time, Orcan Ogetbil <oget.fedora(a)gmail.com> said:
On Wed, Oct 12, 2011 at 12:44 PM, Kevin Fenzi wrote:
> New Password Rules:
...
> * No maximum length.
I thought about this for a while. Is this ever possible? What kind of
storage do we use?
Yeah, I saw that too. A literal "no maximum length" is a denial of
service waiting to happen. I'm sure the passwords are hashed, so it
isn't a matter of storage, but the input buffer is not unlimited, and
neither are the hash iterations to process the input.
What is the actual limit? 256 characters? 512?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:31 p.m.
On Wed, 12 Oct 2011 20:23:55 -0400
Orcan Ogetbil <oget.fedora(a)gmail.com> wrote:
On Wed, Oct 12, 2011 at 12:44 PM, Kevin Fenzi wrote:
>
> New Password Rules:
...
> * No maximum length.
>
I thought about this for a while. Is this ever possible? What kind of
storage do we use?
Yeah, in practice there's a limit... likely limited by the post trying
to send it timing out before it can finish.
Should be quite large in practice however.
kevin
1:40 a.m.
On 10/12/2011 07:44 PM, Kevin Fenzi wrote:
Q&A:
Q: I never uploaded a ssh key to the Fedora Account System, nor am I
in a group that needs one, do I still have to upload a new one?
A: No. If you don't have a ssh public key uploaded or desire to do so,
you can just change your password.
Please add to the FAQ:
Q: I determined I don't really need keys to access Fedora infrastructure
and want to move to password-only, can I just remove my key from the FAS?
--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
1:32 p.m.
On Thu, 13 Oct 2011 09:40:59 +0300
Nicu Buculei <nicu_fedora(a)nicubunu.ro> wrote:
On 10/12/2011 07:44 PM, Kevin Fenzi wrote:
>
> Q&A:
>
>
> Q: I never uploaded a ssh key to the Fedora Account System, nor am I
> in a group that needs one, do I still have to upload a new one?
>
> A: No. If you don't have a ssh public key uploaded or desire to do
> so, you can just change your password.
Please add to the FAQ:
Q: I determined I don't really need keys to access Fedora
infrastructure and want to move to password-only, can I just remove
my key from the FAS?
Currently there's not a way to do this, but there really should be.
https://fedorahosted.org/fedora-infrastructure/ticket/2977
kevin
4:13 p.m.
tor 2011-10-13 klockan 12:32 -0600 skrev Kevin Fenzi:
Currently there's not a way to do this, but there really should
be.
https://fedorahosted.org/fedora-infrastructure/ticket/2977
Not even uploading an empty key file?
4:40 p.m.
On Fri, Oct 14, 2011 at 11:13:08PM +0200, Henrik Nordström wrote:
tor 2011-10-13 klockan 12:32 -0600 skrev Kevin Fenzi:
> Currently there's not a way to do this, but there really should be.
>
> https://fedorahosted.org/fedora-infrastructure/ticket/2977
t
Not even uploading an empty key file?
I believe the empty key file would be saved, so it should have the desired
effect. I haven't tried to make sure though.
-Toshio
12:26 p.m.
On Fri, 14 Oct 2011 14:40:20 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Fri, Oct 14, 2011 at 11:13:08PM +0200, Henrik Nordström wrote:
> tor 2011-10-13 klockan 12:32 -0600 skrev Kevin Fenzi:
>
> > Currently there's not a way to do this, but there really should
> > be.
> >
> > https://fedorahosted.org/fedora-infrastructure/ticket/2977
> t
> Not even uploading an empty key file?
>
I believe the empty key file would be saved, so it should have the
desired effect. I haven't tried to make sure though.
Sadly, I just tested this out and it's not the case. ;(
If you try and upload a 0 length file it takes it, but it doesn't
change your key any. If you upload something thats not a valid key, it
rejects it.
Hopefully we will get the above ticket fixed up here soon so that folks
who don't need a ssh key in fas can easily clear it.
kevin
4577
days inactive
4580
days old
55 comments
26 participants
participants (26)
-
Adam Williamson -
Benny Amorsen -
Callum Lerwick -
Chris Adams -
Digimer -
Henrik Nordström -
Horst H. von Brand -
Jiri Moskovcak -
Jon Ciesla -
Kevin Fenzi -
Kevin Kofler -
Martin Gracik -
Nathanael D. Noblet -
Nicu Buculei -
Orcan Ogetbil -
Paul Wouters -
Peter Robinson -
Przemek Klosowski -
Richard Hughes -
Sam Varshavchik -
Seth Vidal -
Simo Sorce -
Sven Lankes -
Tomas Mraz -
Toshio Kuratomi -
Wes Hardaker