All this business about the problems with MD5 reminded me... that a lot of
people
who `password protect' their SSH keys may not be getting the protection that
they
think they are. See:
http://www.tedunangst.com/flak/post/new-openssh-key-format-and-bcrypt-pbkdf
It turns out that OpenSSH client-side tools started supporting a newer, better
password-protection mechanism for your private keys just over 2 years ago
(so maybe everyone already knows this?). For the Debian users on the list,
this wasn't released in time to make it into Debian 7 ("wheezy", which was
originally released ~7 months prior to SSH 6.5), but it did make it into
the _current_ stable Debian release ("jessie", AKA Debian 8), and is also
available for Debian 7/wheezy via the "wheezy-backports" section.
I have no idea about other distributions. But this is about the point
at which people running other distributions usually jump and and say
"yeah, you Debian guys are so old and crusty--we all got the new version
*years ago*!" (except for maybe the people running Red Hat Enterprise
or CentOS, or some home-grown distro)....
Once you have OpenSSH >= 6.5, you just need to run "ssh-keygen -po"
(the "-o" part is the new part!) to upgrade the security on your
private key (and since private keys are client-side only,
there's nothing to worry about on the server side).
Why should you worry about this?
Basically, the way ssh-keygen `password encrypts' your private key is
by setting it up so that you're `unencrypted' key is *generated* by performing
an MD5 hash of your password. In one single, efficient hash operation.
And the problem with this is basically that... MD5 is *too efficient*
to be a really secure password-hash.
The point of password-protecting your private key--which (ideally)
nobody else is supposed to get access to--is that, in case someone else
_does_ somehow get access to your private key, the password-protection
buys you some time to find out about the compromise and mitigate damage
by changing all of your locks.
The password-protection is supposed to buy you time by making
the ne'er-do-wells have to actually crack your password by brute force.
But if there's one thing you _don't_ want offline password-cracking to be,
you _don't_ want offline-password-cracking to be _efficient_.
As if there weren't enough ways or reasons to deprecate MD5....
If you're interested in a deeper, more technical description
of what's going on here, Martin Kleppmann wrote a pretty good one--
including what appears to be a workaround for using harder-to-crack
password-protection schemes with older versions of the OpenSSH client-side
tools (prior to version 6.5), if for some reason you're in a situation
where you want to upgrade your security but can't upgrade your tools:
https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html
--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
On 02/24/2016 05:52 PM, Joshua Judson Rosen wrote:
> On 02/21/2016 06:49 PM, Ted Roche wrote:
>> According to
>>
>> http://fossforce.com/2016/02/linux-mint-hacked-iso-for-17-3-cinnamon-edition-modified/
>>
>> Original web site posting here:
>>
>> http://blog.linuxmint.com/?p=2994
>>
>> Be careful out there.
>
> And he says "check its MD5 signature".... So many things wrong with that.
>
> But I notice that there are also sha256sum files, alongside the md5sum files--
> and those sha256sum files also have OpenPGP signatures that can be checked
> with GnuPG to actually verify their source. I'd say it's advisable to actually
> *ignore the MD5 checksums*, check the sha256sums instead, and actually
> verify *the authenticity of the sha256sums* by checking the OpenPGP
> signatures.
>
>
> MD5 has been broken for over a decade now..., though I guess MD5 is maybe
> still
> kinda-sorta OK-ish for stuff like this (since the known pre-image attacks are
> still
> kind-of expensive)..., assuming you don't try to `skim' through verifying the
> checksum
> visually (because... <http://www.finnie.org/software/vanityhash/>)....
>
> And assuming that you can actually trust the MD5 checksum. Because MD5 is a
> checksum,
> *not a signature*.
>
> Can we trust the checksums (at least the ones given in the blog post)
> haven't been compromised? Who knows? It's actually a little scary to see
> a blog-post that says `someone broke into my server and changed stuff,
> but this web page is still trustworthy'. Looks like they are actually
> different servers, at least.
>
> Using actual *signatures* should let us bypass pretty much all of these
> uncertainties.
>
> At least, it would if he was using strong signing key with a strong signing
> hash.... He's actually using an old DSA key with SHA-1. D'oh.
>
> I guess it could be a lot worse, e.g.:
>
>
> http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/
>
>
> If you're ever in a position to use hashes/checksums in your own project,
> check out the "Lifetimes of popular cryptographic hashes" chart first:
>
> http://valerieaurora.org/hash.html
>
> And then check back regularly :)
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
