PHK's MD5 might not be slow enough anymore
Chris Palmer
/*
* and now, just to make sure things don't run too fast
* On a 60 Mhz Pentium this takes 34 msec, so you would
* need 30 seconds to build a 1000 entry dictionary...
*/
for(i = 0; i < 1000; i++) {
MD5Init(&ctx1);
if(i & 1)
MD5Update(&ctx1, (const u_char *)pw, strlen(pw));
else
MD5Update(&ctx1, (const u_char *)final, MD5_SIZE);
if(i % 3)
MD5Update(&ctx1, (const u_char *)sp, (u_int)sl);
if(i % 7)
MD5Update(&ctx1, (const u_char *)pw, strlen(pw));
if(i & 1)
MD5Update(&ctx1, (const u_char *)final, MD5_SIZE);
else
MD5Update(&ctx1, (const u_char *)pw, strlen(pw));
MD5Final(final, &ctx1);
}
This algorithm is still the default on FreeBSD 8. (Blowfish is available --
but has it been tuned for slowness either? I have not checked.) The purpose
of these functions is to be slow, but the above has not been slow for years.
Hence this patch:
--- crypt.h.orig 2010-01-28 10:14:50.000000000 -0800
+++ crypt.h 2010-01-28 10:17:49.000000000 -0800
@@ -32,6 +32,9 @@
#define MD4_SIZE 16
#define MD5_SIZE 16
+/* As processors get faster, increase this. 1000 was good on a Pentium 60. */
+#define MD5_SLOW 100000
+
char *crypt_des(const char *pw, const char *salt);
char *crypt_md5(const char *pw, const char *salt);
char *crypt_nthash(const char *pw, const char *salt);
--- crypt-md5.c.orig 2010-01-28 10:18:03.000000000 -0800
+++ crypt-md5.c 2010-01-28 10:19:00.000000000 -0800
@@ -107,10 +107,10 @@
/*
* and now, just to make sure things don't run too fast
- * On a 60 Mhz Pentium this takes 34 msec, so you would
+ * On a 60 Mhz Pentium MD5_SLOW = 1000 takes 34 msec, so you would
* need 30 seconds to build a 1000 entry dictionary...
*/
- for(i = 0; i < 1000; i++) {
+ for(i = 0; i < MD5_SLOW; i++) {
MD5Init(&ctx1);
if(i & 1)
MD5Update(&ctx1, (const u_char *)pw, strlen(pw));
Bill Moran
I'm sure someone will correct me if I'm wrong, but you can't do this
without establishing this as an entirely new algorithm. The hashes
generated after your patch will not be compatible with existing password
files, thus anyone who applies this will be unable to log in. Have you
tried it?
In response to Chris Palmer <ch...@noncombatant.org>:
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmo...@collaborativefusion.com
Phone: 412-422-3463x4023
****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************
Chris Palmer
> I'm sure someone will correct me if I'm wrong, but you can't do this
> without establishing this as an entirely new algorithm. The hashes
> generated after your patch will not be compatible with existing password
> files, thus anyone who applies this will be unable to log in. Have you
> tried it?
Yes, which is why I reset my passwords after doing "make install", which
worked fine. I suppose I should have mentioned that in the first message. :)
People installing the OS fresh won't need to take this step.
Note that 1,000 is simply too low -- the security value of PHK's scheme is
lost as computers increase in speed. Therefore, taking a minute to update my
passwords is acceptable to me. Since there is 0 cost for people installing
fresh, there is no reason not to do it.
The blowfish algorithm should also be similarly tuned.
Xin LI
Hash: SHA1
Hi, Chris,
On 2010/01/28 10:24, Chris Palmer wrote:
> See your copy of /usr/src/lib/libcrypt/crypt-md5.c:
I'd appreciate your effort put into this but I feel necessary to say
something on this topic.
The slowness was useful at the time when the code was written, but I
don't think it would buy us as much nowadays, expect the slowness be
halved from time to time, not to mention the use of distributed
techniques to accelerate the build of dictionaries.
Second, recent research has shown MD5 to be vulnerable to collision
attacks [1] by the end of 2008.
It's time to switch to some better algorithm, maybe something like
Skein, etc...
[1] http://www.kb.cert.org/vuls/id/836068
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLYeveAAoJEATO+BI/yjfBWzkH/icNHpEr5w/ulBlKe/fr/4Uo
+ZrGj7SixbL4g6yLPd79JKoJpFZEdMlY9AnLTr3QT0/OwKyySwVXg7Fh+7LA3r+4
DqE4N2pZfIqD6maS7ccF6Yp+2JAN9BJG7O73W6fEhm0mRTPkdLWMnB1gMx6DymQh
NQvx41QADmiN3jq6DapFJhQRDwFcxFzCsyg3eZ0nIwaCP+72HBPCEKEPro1JtLSF
sm0uf0TIyaGTgMe4xcjtwdlRtMmNA0V5yZwGHOcW09cuxxt3n79BA2RrPVz/+6Tr
KIa6LhNzoF1Eb4wfCSrSu2c4a6nM6+FSGT5fdpx/jkfr125W7sQYZuEVNzPWuxU=
=LuLY
-----END PGP SIGNATURE-----
Flemming Jacobsen
> Second, recent research has shown MD5 to be vulnerable to collision
> attacks [1] by the end of 2008.
Uhmm. That is totally irrelevant in this context.
Regards,
Flemming
--
Flemming Jacobsen Email: f...@batmule.dk
"The chief obstacle to the progress of the human race is the human
race." -- Don Marquis
Bill Moran
> Bill Moran writes:
>
> > I'm sure someone will correct me if I'm wrong, but you can't do this
> > without establishing this as an entirely new algorithm. The hashes
> > generated after your patch will not be compatible with existing password
> > files, thus anyone who applies this will be unable to log in. Have you
> > tried it?
<snip>
> Since there is 0 cost for people installing
> fresh, there is no reason not to do it.
Are you volunteering to handle all the complaints from all the
people who want to upgrade their systems without reinstalling?
This would also introduce a complete incompatibility between systems.
I, for one, frequently copy password files from one system to another.
I expect $1$ to be compatible on all systems.
If a new algorithm is to be used, why even start with md5? Why not
start with something that's inherently stronger and more CPU intensive?
>From there, assign it a new algorithm number. See the "Modular Crypt"
section of crypt(3). Then compatibility is maintained.
Chris Palmer
> The slowness was useful at the time when the code was written, but I don't
> think it would buy us as much nowadays, expect the slowness be halved from
> time to time, not to mention the use of distributed techniques to
> accelerate the build of dictionaries.
The goal is to make the attacker *have* to use distributed techniques and to
buy more gear, rather than simply be able to brute them all in a few minutes
on a single cheap PC. MD5_SLOW is the factor by which you increase the
attacker's cost; it is easy for the defender to go very high here because
checking any one password is still fast. Distributed attacks existed when
PHK wrote the code originally, too -- I don't think anything has
fundamentally changed since then. Attackers use arrays of GPUs now? Ok,
increase MD5_SLOW some more.
> Second, recent research has shown MD5 to be vulnerable to collision
> attacks [1] by the end of 2008.
I'm not sure that attack against MD5 is relevant here, because we're not
using it in a way where collisions hurt. (Someone correct me if I'm wrong.)
In fact, moving to a modern hash would weaken the defense, because e.g.
Skein is brilliantly fast -- the opposite of our goal.
See also:
"""The major advantage of adaptive hashing is that you get to tune it. As
computers get faster, the same block of code continues to produce passwords
that are hard to crack."""
Chuck Swiger
On Jan 28, 2010, at 12:10 PM, Bill Moran wrote:
> This would also introduce a complete incompatibility between systems.
> I, for one, frequently copy password files from one system to another.
> I expect $1$ to be compatible on all systems.
Exactly. Just like classic DES passwords were portable to all platforms.
> If a new algorithm is to be used, why even start with md5? Why not
> start with something that's inherently stronger and more CPU intensive?
>>
> From there, assign it a new algorithm number. See the "Modular Crypt"
> section of crypt(3). Then compatibility is maintained.
+1. We're probably fine with MD5 password hashes against all but extreme measures for some time to come, but adding SHA-1 and being ready for whatever algorithm(s) might be chosen by NIST for SHA-3 would be a fine thing to do.
Regards,
--
-Chuck
Chris Palmer
prefix every time we re-tune the algorithm, or using a new notation to say
how many times this password was hashed? For example: $1.1000$, $1.100000$,
et c.?
I prefer the latter. It can work with Blowfish, too, and anything else
people come up with in the future.
Xin LI
Hash: SHA1
On 2010/01/28 12:18, Chris Palmer wrote:
> For backwards compatibility, which do people prefer: Creating a new $N$
> prefix every time we re-tune the algorithm, or using a new notation to say
> how many times this password was hashed? For example: $1.1000$, $1.100000$,
> et c.?
I'd vote for $1.nnnn$, as a good side effect it would be tunable by the
administrators who want to fine tune the round number as need.
Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLYfz/AAoJEATO+BI/yjfBEXsIAIr2qzcNDVFDoZ2OWr6tAeZh
5Ew0LcrGKwMnbhwhn1lpOopJks/43JnX85YScPgpcCuDDyG8mev8kjwnuXpl0iOr
fTMTgznuzIkHT6DcPfQYc2jcaMjR3TzSy8bTFOilrnkuQr0kPHAiQNrnrUtAKyxz
Ss0JBjYboSVqtOG58fltkPB0XVoXwBSy8Y4eG+jwStn0qDPmASlZ1TaDvxQWkp9/
4X7zCK9NCQa/VH94VnbX4uFn3uiLH+IXrUISQcgd9QUkOrswSpdyjSGwV9xkQXWn
oiEQP0eVMPWWpesFjhcppSq+2gvsRRow8IpPUSgH2aZDVleZxe9/pEPyyl+bNCk=
=rEMy
-----END PGP SIGNATURE-----
Xin LI
Hash: SHA1
On 2010/01/28 12:11, Chris Palmer wrote:
> Xin LI writes:
>
>> The slowness was useful at the time when the code was written, but I don't
>> think it would buy us as much nowadays, expect the slowness be halved from
>> time to time, not to mention the use of distributed techniques to
>> accelerate the build of dictionaries.
>
> The goal is to make the attacker *have* to use distributed techniques and to
> buy more gear, rather than simply be able to brute them all in a few minutes
> on a single cheap PC. MD5_SLOW is the factor by which you increase the
> attacker's cost; it is easy for the defender to go very high here because
> checking any one password is still fast. Distributed attacks existed when
> PHK wrote the code originally, too -- I don't think anything has
> fundamentally changed since then. Attackers use arrays of GPUs now? Ok,
> increase MD5_SLOW some more.
Isn't it a losing battle, if we increase something linearly to defeat
something growing in geometric order?
Defenders must carefully protect all weak points, while the attacker
simply go the weakest chain of the whole system.
>> Second, recent research has shown MD5 to be vulnerable to collision
>> attacks [1] by the end of 2008.
>
> I'm not sure that attack against MD5 is relevant here, because we're not
> using it in a way where collisions hurt. (Someone correct me if I'm wrong.)
Yes and no.
Collision attacks themselves would do nothing against our scenario. The
design in crypt-md5.c not only "slow down" the computation, but also
introduced additional protection by using intermediate hashes when doing
the computation, like OPIE, which makes collision harder to use.
> In fact, moving to a modern hash would weaken the defense, because e.g.
> Skein is brilliantly fast -- the opposite of our goal.
Modern hash algorithms are fast, but fast by itself is not anything wrong.
Another benefit newer hash algorithms usually give is much more output
bits, and every bit in the output, doubles the space needed to store the
dictionary needed by the attacker, as well as the numbers of samples
they presumably need to compute, while halving the chance they generate
a collision for one given round.
Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLYfw8AAoJEATO+BI/yjfBTkIIAIp7NzGUdxqoRw7MbK/TzfOH
Rx2cQzn/ld0eVTdPLHWBCShPgajcWiH99j3XPU7nj+JSl+B3qitmEu+Am/zT5GhZ
wv8B9Vp+0aHrsOTdVEGw4yYHtE93VDEAzkdJ1PZndVJl/TSAWoxvIfkIkuLUJMp8
9zO53dSkM1EzIveTk5lCbDErYL8AlN+A1tIeycRTaFUhEbbRWzvcRzZ9iqCfUoB9
3WvHMykbFYfLHHEbT0dwQ3M1JzDDl51sBqxGUEUYlMkvfgrBa29r+LpvxO6+8ZiY
aHrXZFU5O5RGNlJSRbbT0CkFKkpVWmLkyvJ2zhDEoIQx9Hpn8YRta6JqushEW8o=
=ZB3V
-----END PGP SIGNATURE-----
Antoine Brodin
> For backwards compatibility, which do people prefer: Creating a new $N$
> prefix every time we re-tune the algorithm, or using a new notation to say
> how many times this password was hashed? For example: $1.1000$, $1.100000$,
> et c.?
You may want to have a look at
http://people.redhat.com/drepper/SHA-crypt.txt and freebsd PR 124164.
Cheers,
Antoine
Roger
increase the amount of time needed to check the next password after a
failure.
In other words, check the first one fast, the second try it will be
slower, then the third even slower and then the forth even slower etc.
Is this how it is currently implemented? (Sorry I did not read the
code).
-r
Garance A Drosihn
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 2010/01/28 12:18, Chris Palmer wrote:
>> For backwards compatibility, which do people prefer: Creating a new $N$
>> prefix every time we re-tune the algorithm, or using a new notation to say
>> how many times this password was hashed? For example: $1.1000$, $1.100000$,
>> et c.?
>
>I'd vote for $1.nnnn$, as a good side effect it would be tunable by the
>administrators who want to fine tune the round number as need.
Might want to make it something like $1.nnn.bbb$, so the admin can specify
the number of bits as well as the number of rounds. And then pick some
algorithm where those two values make sense. :-)
By going for something tunable, users don't HAVE to change their password
the moment the sysadmin decides that it's time for better protection. The
sysadmin can change the numbers used when the user changes their password,
and then gradually transition everyone to the stronger encryption.
It also means that users could decide to use stronger encryption if they
are willing to wait for it, without the sysadmin needing to do anything.
--
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
Chuck Swiger
On Jan 28, 2010, at 1:56 PM, Garance A Drosihn wrote:
>> On 2010/01/28 12:18, Chris Palmer wrote:
>>> For backwards compatibility, which do people prefer: Creating a new $N$
>>> prefix every time we re-tune the algorithm, or using a new notation to say
>>> how many times this password was hashed? For example: $1.1000$, $1.100000$,
>>> et c.?
>>
>> I'd vote for $1.nnnn$, as a good side effect it would be tunable by the
>> administrators who want to fine tune the round number as need.
>
> Might want to make it something like $1.nnn.bbb$, so the admin can specify
> the number of bits as well as the number of rounds. And then pick some
> algorithm where those two values make sense. :-)
As Antoine points out in the link mentioned:
> The integration into existing systems is easy if those systems already
> support the MD5-based solution. Ever since the introduction of the
> MD5-based method an extended password format is in used:
>
> $<ID>$<SALT>$<PWD>
>>
>
[ ... ]
> For the SHA-based methods the SALT string can be a simple string of
> which up to 16 characters are used. The MD5-based implementation used
> up to eight characters.. It was decided to allow one extension which
> follows an invention Sun implemented in their pluggable crypt
> implementation. If the SALT strings starts with
>
> rounds=<N>$
>
> where N is an unsigned decimal number the numeric value of N is used
> to modify the algorithm used. As will be explained later, the
> SHA-based algorithm contains a loop which can be run an arbitrary
> number of times. The more rounds are performed the higher the CPU
> requirements are. This is a safety mechanism which might help
> countering brute-force attacks in the face of increasing computing
> power.
>
> The default number of rounds for both algorithms is 5000. To ensure
> minimal security and stability on the other hand minimum and maximum
> values for N are enforced:
>
> minimum for N = 1,000
> maximum for N = 999,999,999
>
> Any selection of N below the minimum will cause the use of 1,000
> rounds and a value of 1 billion and higher will cause 999,999,999
> rounds to be used. In these cases the output string produced by the
> crypt function will not have the same salt as the input salt string
> since the correct, limited rounds value is used in the output.
This seems to address the suggestion being made by Chris (and +1'ed by others) in a fashion that is compatible with other implementations....
Regards,
--
-Chuck
Garance A Drosihn
>Hi--
>
>On Jan 28, 2010, at 1:56 PM, Garance A Drosihn wrote:
> >
>> Might want to make it something like $1.nnn.bbb$, so the admin can specify
>> the number of bits as well as the number of rounds. And then pick some
>> algorithm where those two values make sense. :-)
>
>As Antoine points out in the link mentioned:
>
>> The integration into existing systems is easy if those systems already
>> support the MD5-based solution. Ever since the introduction of the
>> MD5-based method an extended password format is in used:
>>
> > $<ID>$<SALT>$<PWD>
>This seems to address the suggestion being made by Chris (and +1'ed
>by others) in a fashion that is compatible with other
>implementations....
Ah, yes, this seems like a fine idea. (so please ignore the message I
sent about 45 seconds ago!)
Garance A Drosihn
>At 1:09 PM -0800 1/28/10, Xin LI wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On 2010/01/28 12:18, Chris Palmer wrote:
>>> For backwards compatibility, which do people prefer: Creating a new $N$
>>> prefix every time we re-tune the algorithm, or using a new notation to say
>>> how many times this password was hashed? For example: $1.1000$, $1.100000$,
>>> et c.?
>>
>>I'd vote for $1.nnnn$, as a good side effect it would be tunable by the
>>administrators who want to fine tune the round number as need.
>
>Might want to make it something like $1.nnn.bbb$, so the admin can specify
>the number of bits as well as the number of rounds. And then pick some
>algorithm where those two values make sense. :-)
>
>
>By going for something tunable, users don't HAVE to change their password
>the moment the sysadmin decides that it's time for better protection. The
>sysadmin can change the numbers used when the user changes their password,
>and then gradually transition everyone to the stronger encryption.
>
>It also means that users could decide to use stronger encryption if they
>are willing to wait for it, without the sysadmin needing to do anything.
Also note that we might not want the "nnn" number to be an exact count
of the number of times it was hashed. For instance, it might be that
the algorithm works best if the number is always hashed a prime-number
of times, or that it's always a power-of-2 increase. So a value of 3
for "nnn" just means "more times than 2 would do", and not necessarily
"exactly one more time than would be done for 2".
This is just meant as something we might want to consider.
Mike Andrews
The Blowfish one already has that feature.
A long time ago (like FreeBSD 6.something, maybe earlier) I changed all
my /etc/login.conf files to set "passwd_format=blf" and all my password
hashes are in the format "$2a$04$salthash" -- with the "04" being the
(default) number of rounds of Blowfish to run. I have some users where
it's set to 11 rounds, and as you'd expect, it puts a pretty big hurt on
the ability of things like John The Ripper to attack the hashes.
Just making sure we aren't suggesting reinventing a wheel here :)
Even 4 rounds of Blowfish is far slower than 1000 rounds of MD5, and
1000 rounds of MD5 is far slower than DES. And yeah, fear of MD5
collisions is totally irrelevant here.
If you're really that worried about MD5 anyway, just change
"passwd_format=md5" to "passwd_format=blf" in your login.conf's default
section and be happy :)
Poul-Henning Kamp
> /*
> * and now, just to make sure things don't run too fast
> * On a 60 Mhz Pentium this takes 34 msec, so you would
> * need 30 seconds to build a 1000 entry dictionary...
> */
A number of points:
1. I'm not sure slowing it down buys very much security, as far as
I know, brute-forcing $1$ is still out of the question, mostly
because of the wide salt.
2. Most "brute force" attacks are dictionary attacks, and slowing
the algorithm down for those is pointless: The bad guys have
grids of Nx100k machines to grind. Even making it take half a
second will not inconvenience them much.
3. Compatibility: as far as I know, we have a configurable mechanism
for choosing preferred crypt algo for new passwords, and
autodetection on old passwords.
4. Encoding #rounds: one of the OpenBSD derivatives for $1$ does that,
consider adoption, rather than NIH. Increased strength against
rainbow and dictionaries can be had by making the low bits in
#rounds a salt.
5. Cross system compat: A valid concern in some environments (See
#3) and not in others. Certainly not a valid reason to never
change algorithm again (see #6).
6. The major point behind $1$ was lost: You can change algorithm with
a frequency of twice your password expiry time. My intent back
in the middle of the nineties was not to write the "endl�sung"
for password encryption, but rather to point out that password
hashing is "kleenex-crypto" which can, and should, be swapped at
regular intervals. Every 15 years may be sufficiently regular.
7. Consider preempting the bike-shed, by asking some card-carrying
cryptographers for the correct way to employ a crypto-hash algorithm
in a way that does soak up some CPU time.
8. A number of interesting ideas was battered about back when $1$
was introduced, check mail archives and read the OpenBSD paper,
even though it is mostly plagarism.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
RW
Roger <rno...@gmail.com> wrote:
> What would be the consequence of having an algorithm that will
> increase the amount of time needed to check the next password after a
> failure.
The point of slowing down the algorithm is to protect against off-line
attack where an attacker has gained access to a copy of master.passwd.
Any hashing has to be done when the password is set, so it's fixed
thereafter.
Mike Andrews
> On 1/28/10 3:18 PM, Chris Palmer wrote:
>> For backwards compatibility, which do people prefer: Creating a new $N$
>> prefix every time we re-tune the algorithm, or using a new notation to say
>> how many times this password was hashed? For example: $1.1000$, $1.100000$,
>> et c.?
>>
>> I prefer the latter. It can work with Blowfish, too, and anything else
>> people come up with in the future.
>
> The Blowfish one already has that feature.
>
> A long time ago (like FreeBSD 6.something, maybe earlier) I changed all my
> /etc/login.conf files to set "passwd_format=blf" and all my password hashes
> are in the format "$2a$04$salthash" -- with the "04" being the (default)
> number of rounds of Blowfish to run. I have some users where it's set to 11
> rounds, and as you'd expect, it puts a pretty big hurt on the ability of
> things like John The Ripper to attack the hashes.
Actaully that's not the number of rounds, it's the log2() of the number of
rounds. So 04 is really 2^4=16 rounds (the minimum), 11 is 2^11=2048
rounds, and the maximum is 31 -- which as the source code states, oughta
scale pretty well for a while. :)
See /usr/src/secure/lib/libcrypt/crypt-blowfish.c
There is probably a login.conf knob to raise the default number of rounds
beyond 2^4.
But the point remains: look at what FreeBSD already has. :)
Roger
> The point of slowing down the algorithm is to protect against off-line
> attack where an attacker has gained access to a copy of master.passwd.
When say "off-line attack" do you refer to the attacker running a
brute force attack on his/her machine?
I'm assuming that by using a slow algorithm the attacker is forced to
use the same slow algorithm to check the passwords?
> Any hashing has to be done when the password is set, so it's fixed
> thereafter.
What do you mean by that?
Thank you very much for taking the time to answer.
-r
Matthew Dillon
network. No (non-kerberos) telnetd, rlogind, (non anonymous) ftpd, etc.
Just run sshd and put this in your sshd_config:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
Local passwords can still be used for things like a (restricted) sudo,
console root logins, and X/xdm. Disallowing remote passworded logins
removes the primary attack vector, which is over the network.
You'd probably want to adjust /etc/login.access too since for
some reason beyond my comprehension /usr/bin/login can be run from
pty's to cross-login locally (with a password).
So even if the attacker knows the password he is SOL without physical
access.
--
The problem with stolen master.passwd files is that you often don't
know the file has been stolen until the hacker actually starts using
the compromised accounts. In otherwords, the hacker has as much time
as he wants to break the file before having to worry about someone
reacting to it. This makes the concept of multiplying the analysis
cost almost completely worthless above and beyond everything else
mentioned.
Mostly these protections against stolen master.passwd files aren't
so much to protect the machine against being hacked (since it was
hacked already to get the file in the first place), but instead to
reduce the work involved when cleaning up after a hack incident.
It's best to limit the damage by making the stolen file simply not
be useful to a remote attacker.
-Matt
Matthew Dillon
<dil...@backplane.com>
Pawel Jakub Dawidek
> See your copy of /usr/src/lib/libcrypt/crypt-md5.c:
> This algorithm is still the default on FreeBSD 8. (Blowfish is available --
> but has it been tuned for slowness either? I have not checked.) The purpose
> of these functions is to be slow, but the above has not been slow for years.
> Hence this patch:
This is wrong approach. It should be done using PKCS#5v2 just like
geli(8) does it. It even calculates number of iterations so the
operation completes in reasonable amount of time on your machine
(eg. 1 second). It also uses HMAC/SHA512. On some recent CPUs (amd64)
it should be possible for 2^20 iterations to complete in reasonable
amount of time.
Even strong passwords have no more than five bits of entropy per
character (probably much less if it is something possible to remember),
so to brute-force one character you need 2^5 interations, which means
that strong eight characters password needs 2^40 iterations for full
brute-force. Adding 2^20 iterations of PKCS#5v2 makes it 2^60, which is
not bad.
Of course if we assume that 2^20 of PKCS#5v2 takes one second, then it
will take ~34865 years to fully brute-force it on one machine. Although
you can safely assume that if you really have something to hide, an
attacker will be able to use 100.000 nodes botnet, which leaves you with
only ~127 days to change your password:)
Remember that this is login password we are talking about, not password
used for encryption, so all you want to protect it against is theft of
/etc/master.passwd.
<advert>
All in all static passwords are for the weak that's why we
(Wheel Systems) believe in easy to use one-time passwords:)
</advert>
--
Pawel Jakub Dawidek http://www.wheel.pl
p...@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
Dan Lukes
>> all my password hashes are in the format "$2a$04$salthash" -- with the "04"
>> being the (default) number of rounds of Blowfish to run
> There is probably a login.conf knob to raise the default number of
> rounds beyond 2^4.
No. The standard way of password change flow trough pam_unix.c.
It call crypt(new_pass, salt) where salt is pseudo-random sequence. As
such salt doesn't start with a magic, the default algorithm is selected.
If it si blowfish, then crypt_blowfish(key, salt) is called.
As the random salt doesn't start with $2a$ magic it is not considered to
be '$2a$nn$salt'-like string. Then default number (04) is used all the
times.
Dan
RW
Roger <rno...@gmail.com> wrote:
> >
> > The point of slowing down the algorithm is to protect against
> > off-line attack where an attacker has gained access to a copy of
> > master.passwd.
>
> When say "off-line attack" do you refer to the attacker running a
> brute force attack on his/her machine?
Yes
> I'm assuming that by using a slow algorithm the attacker is forced to
> use the same slow algorithm to check the passwords?
Hopefully
> > Any hashing has to be done when the password is set, so it's fixed
> > thereafter.
>
The thread is about password hashing, which is not a mechanism to
slow-down and back-off login attempts.
Roger
of the thread.
-r
Dag-Erling Smørgrav
> Mike Andrews <mand...@bit0.com> writes:
> > There is probably a login.conf knob to raise the default number of
> > rounds beyond 2^4.
> No. The standard way of password change flow trough pam_unix.c.
>
> It call crypt(new_pass, salt) where salt is pseudo-random sequence. As
> such salt doesn't start with a magic, the default algorithm is
> selected. If it si blowfish, then crypt_blowfish(key, salt) is called.
Mike is mostly right and you are mostly wrong. The default algorithm is
indeed controlled by login.conf and auth.conf, although there is no way
to specify the number of rounds.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> Just give up and turn off tunneled plaintext passwords over the
> network. No (non-kerberos) telnetd, rlogind, (non anonymous) ftpd, etc.
> Just run sshd and put this in your sshd_config:
>
> # To disable tunneled clear text passwords, change to no here!
> PasswordAuthentication no
This does not do what you think it does. RTFM.
Matthew Dillon
:
Here's a thought, DES. Try acting like the professional you
profess to be instead of the 5-year-old you clearly are.
It looks like the defaults in FreeBSD are different, so shoot me.
Ah, I see, YOU were the one who changed the FreeBSD defaults to be
less secure. Now I understand. The OpenSSH folks give you a nice
default-secure setting and an easy way to change it in sshd_config
and your answer is to actually modify the base code in the contrib
instead and turn things all around? Shame on you.
So, FreeBSD users, it looks like you have to play russian roulette
with your sshd_config options if you want the directives to actually
work. But hey, I'm sure DES will be happy to flip you off instead
of tell you which options will work with FreeBSD. So I guess I'll have
to instead.
If you don't need PAM's extra features for your sshd access (which is
most people) then turn PAM off in your sshd_config to work around the
base code change that DES made. Then the other options will work as
intended. And, just to be safe, also turn off the challenge-response
option.
UsePAM no
ChallengeResponseAuthentication no
PasswordAuthentication no
There, all better. PAM has its advantages, but only for a very small
percentage of users. Its disadvantage is in its complexity and the
ease of which a mis-configuration can result in a security hole. If
there is no need for ssh to use it in your configuration then it
should be turned off.
-Matt
Matthew Dillon
<dil...@backplane.com>
Doug Barton
> If you don't need PAM's extra features for your sshd access (which is
> most people) then turn PAM off in your sshd_config to work around the
> base code change that DES made. Then the other options will work as
> intended. And, just to be safe, also turn off the challenge-response
> option.
>
> UsePAM no
> ChallengeResponseAuthentication no
> PasswordAuthentication no
I agree that turning PAM off whenever possible is a good thing. It
should also be noted that regardless of what appears in the default
config file those options should be uncommented so that you can be sure
they will be effective across updates.
For the old-school paranoids (like me) the following options are also of
interest "just in case":
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreRhosts yes
hth,
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
Computers are useless. They can only give you answers.
-- Pablo Picasso
Dag-Erling Smørgrav
> "Dag-Erling Smørgrav" <d...@des.no> writes:
> > Matthew Dillon <dil...@apollo.backplane.com> writes:
> > > Just run sshd and put this in your sshd_config:
> > >
> > > # To disable tunneled clear text passwords, change to no here!
> > > PasswordAuthentication no
> > This does not do what you think it does. RTFM.
Nope.
> Ah, I see, YOU were the one who changed the FreeBSD defaults to be
> less secure.
Nope.
"PasswordAuthentication no" *is* the default.
It does not disable password authentication. It disables the SSH
"password" authentication method. Password authentication is still
possible via PAM.
> Now I understand.
No, you don't, you're just making it up as you go along.
> So, FreeBSD users, it looks like you have to play russian roulette
> with your sshd_config options if you want the directives to actually
> work.
No Russian roulette, no sshd_config tweaking. All you need is a
one-line change to /etc/pam.d/sshd. See pam.conf(5) and pam_unix(8) for
further deatils.
> But hey, I'm sure DES will be happy to flip you off instead of tell
> you which options will work with FreeBSD.
I don't flip off users with valid concerns. You don't fall into that
category.
> So I guess I'll have to instead.
I'm sure users will be eternally grateful to you for giving them
incorrect information which weakens the security of their systems.
> If you don't need PAM's extra features for your sshd access (which is
> most people)
Wrong; most people *do* need PAM.
> then turn PAM off in your sshd_config to work around the base code
> change that DES made.
UsePAM is on by default in OpenSSH-portable.
Yes, I wrote the original PAM support code for OpenSSH; so shoot me. It
was necessary.
> Then the other options will work as
> intended. And, just to be safe, also turn off the challenge-response
> option.
>
> UsePAM no
> ChallengeResponseAuthentication no
> PasswordAuthentication no
>
> There, all better.
Yeah, now you turned off *all* authentication methods except keys, and
by turning off PAM, you also turned off session management, accounting,
utmpx logging, lockout of expired accounts, etc.
If you're serious about strong authentication, use time-synchronized OTP
tokens. Oh wait, you can't, because you need PAM and ChallengeResponse
to mediate between the user and the backend, which usually acts like a
Radius server. Too bad.
Matthew Dillon
:If you're serious about strong authentication, use time-synchronized OTP
:tokens. Oh wait, you can't, because you need PAM and ChallengeResponse
:to mediate between the user and the backend, which usually acts like a
:Radius server. Too bad.
:
:DES
:--
:Dag-Erling Smørgrav - d...@des.no
The default PAM setting in OpenSSH is 0. Line 138 servconf.c
in openssh-5.3p1 (that's the portable version). The default comment
in sshd_config in openssh-5.3.p1 from ftp.openssh.com and is condusive
to the state of the code, which is the reverse of what FreeBSD has done.
I didn't bother to go check earlier releases to see if it was different
in the past, but that seems to be the current state.
Frankly I'm a bit surprised that you are even trying to defend the
FreeBSD changes. They are clearly less secure. All you had to do
was adjust the default sshd_config. PAM is black-magic for most users,
the last thing you want to do is suggest that the general user base
make changes to PAM configuration files verses the far more user
friendly sshd_config.
The vast majority of BSD users don't need PAMs capabilities when it
comes to ssh. Having it disabled by default is more appropriate.
For that matter, your suggestion that all users use some esoteric
feature and mess with PAM configuration files as a solution instead
of changing the far more user-friendly sshd_config is just bad advise
to users. It seems to me that you are setting defaults for the
convenience of a minority of people when they should be set for the
convenience of the majority.
And if you are really going to insist on changing the option around
the least you could have done was uncomment the related options and
set them to a definitive 'no' value (that would be ChallengeResponse
at the very least) when you made the other changes.
The whole point of my original posting was to provide an alternative
to users concerned with password attacks on ssh and you basically
turned it into a personal attack. You need to grow up.
--
In anycase, I think Mr Barton's posting was excellent. We already
ship with PasswordAuthentication set to 'no' and, of course, PAM is
disabled by default, but I am going to make further adjustments to
our sshd_config based on Doug's suggestions plus I will also
uncomment ChallengeResponseAuthentication and set that to 'no' too
as a further safety measure.
The plain fact of the matter is that allowing short user passwords
over-the-wire for a shell login, whether in the clear or tunneled,
can no longer be considered a reasonable default in this day and age.
-Matt
Matthew Dillon
<dil...@backplane.com>
Dag-Erling Smørgrav
> The vast majority of BSD users don't need PAMs capabilities when it
> comes to ssh.
You clearly don't understand what PAM does.
> And if you are really going to insist on changing the option around
> the least you could have done was uncomment the related options and
> set them to a definitive 'no' value (that would be ChallengeResponse
> at the very least) when you made the other changes.
You clearly don't understand what the ChallengeResponse option does.
> In anycase, I think Mr Barton's posting was excellent. We already
> ship with PasswordAuthentication set to 'no' and, of course, PAM is
> disabled by default, but I am going to make further adjustments to
> our sshd_config based on Doug's suggestions plus I will also
> uncomment ChallengeResponseAuthentication and set that to 'no' too
> as a further safety measure.
...leaving your users with no other option than keys. No OPIE, no
Radius, no nothing - just keys. You do realize that users have the
option to store their keys unencrypted, and there is nothing you can do
on the server side do to prevent them? That's even *less* secure than
passwords.
Chris Palmer
> option to store their keys unencrypted, and there is nothing you can do on
> the server side do to prevent them? That's even *less* secure than
> passwords.
Less secure in certain, but not all, attack scenarios.
An attacker with code running on the client (i.e. any code author at all
with code on the client running as the user who wants to use the SSH
client... sigh) can log right in -- but that class of attacker could also
keylog the SSH key passphrase, too. (The problem is worse if you consider
local privilege escalaton vulnerabilities, and if the prevalence of those
vulnerabilities leads you believe that the fundamental guarantee of a
multi-user system cannot hold in practice.)
The true value of a passphrase is to stymie attackers who steal the key
(perhaps by stealing the laptop) but who don't have their own code running
on the client at the time the legitimate owner is using the machine. Full
disk encryption is a better, more general approach to that class of threat
anyway.
On the other hand, an attacker trying an online brute-force password guess
against the server still has no hope, without the unprotected key, even if
the key is not protected by a passphrase.
I don't disagree with any argument that more auth factors is better, of
course. But passphrase-less SSH keys are not necessarily the worst thing in
the world.