Re: Default password hash, redux

[John-Mark Gurney]

> 
> I believe that there are patches/review for making the default password
> hash algorithm configurable via login.conf or something similar.. so some
> of the work has already been done..
> 
> > I'd also like to see us to pull in scrypt if cperciva doesn't have any 
> > objections. It's good to have options.
> 
> Yes, pulling in scrypt and/or argon2 is a great idea...
> 
> -- 
>   John-Mark GurneyVoice: +1 415 225 5579
> 
>  "All that I will do, has been done, All that I have, has not."
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Dag-Erling Smrgrav wrote this message on Thu, May 31, 2018 at 00:38 +0200:
> John-Mark Gurney  writes:
> > I believe that there are patches/review for making the default password
> > hash algorithm configurable via login.conf or something similar...
> 
> You mean like r64918?

No, I don't.

Sorry, I wasn't specific enough in my comment, but you also dropped the
context of that statment:

John-Mark Gurney wrote this message on Sun, May 27, 2018 at 16:14 -0700:
> Mark Felder wrote this message on Wed, May 23, 2018 at 16:40 -0500:
> > In light of this new article[2] I would like to rehash (pun intended) this 
> > conversation and also mention a bug report[3] we've been sitting on in some 
> > form for 12 years[4] with usable code that would make working with password 
> > hashing algorithms easier and the rounds configurable by the admin.
> 
> I'd like to see it set where we set a time, say 50ms or so, and on each
> boot, we set the rounds based upon this.  (obviously configurable), w/ a
> minimum maybe for slower systems...  This allows us to autoscale to faster
> cpu systems...

r64918 does not allow you to set default number of rounds...  there is
a patch in bugzilla or phabricator that allows you to set this..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash, redux

[Dag-Erling Smørgrav]

John-Mark Gurney  writes:
> I believe that there are patches/review for making the default password
> hash algorithm configurable via login.conf or something similar...

You mean like r64918?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash, redux

[John-Mark Gurney]

Mark Felder wrote this message on Wed, May 23, 2018 at 16:40 -0500:
> Around 2012[1] we made the brave switch from md5crypt to sha512. Some people 
> were asking for bcrypt to be default, and others were hoping we would see 
> pbkdf2 support. We went with compatible. Additionally, making password 
> hashing more
> 
> In light of this new article[2] I would like to rehash (pun intended) this 
> conversation and also mention a bug report[3] we've been sitting on in some 
> form for 12 years[4] with usable code that would make working with password 
> hashing algorithms easier and the rounds configurable by the admin.

I'd like to see it set where we set a time, say 50ms or so, and on each
boot, we set the rounds based upon this.  (obviously configurable), w/ a
minimum maybe for slower systems...  This allows us to autoscale to faster
cpu systems...

I believe that there are patches/review for making the default password
hash algorithm configurable via login.conf or something similar.. so some
of the work has already been done..

> I'd also like to see us to pull in scrypt if cperciva doesn't have any 
> objections. It's good to have options.

Yes, pulling in scrypt and/or argon2 is a great idea...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash, redux

[Derek (freebsd lists)]

On 18-05-23 05:40 PM, Mark Felder wrote:

In light of this new article[2] I would like to rehash (pun intended) this 
conversation and also mention a bug report[3] we've been sitting on in some 
form for 12 years[4] with usable code that would make working with password 
hashing algorithms easier and the rounds configurable by the admin.

[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182518


I'd also like to add relevant reference to the public discussion 
regarding this patch:


https://lists.freebsd.org/pipermail/freebsd-security/2015-February/008175.html

(which also links to previous discussion on -current)

as some additional context at this time.

Derek
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash, redux

[Benjamin Kaduk]

On Wed, May 23, 2018 at 05:50:04PM -0400, Yonas Yanfa wrote:
> I recommend adding support for Argon2.
> 
> https://en.wikipedia.org/wiki/Argon2

Yes, Argon2 seems like a no-brainer at this point.

-Ben
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash, redux

[Mark Felder]

On Wed, May 23, 2018, at 16:40, Mark Felder wrote:
> Additionally, making password hashing more
> 

Mailman came to the door and my barking dog interrupted my train of thought :-)

I believe what I was going for was in reference to the bugzilla report, so I'll 
try again:

Additionally, making password hashing more configurable/pluggable gives us more 
room to experiment with implementing new hashes and makes it easier to solve 
these problems. It appears that the patch languishing in bugzilla would help 
alleviate this issue.

-- 
  Mark Felder
  ports-secteam & portmgr member
  f...@freebsd.org
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash, redux

[Yonas Yanfa]

I recommend adding support for Argon2.

https://en.wikipedia.org/wiki/Argon2

On Wed, May 23, 2018, 5:42 PM Mark Felder,  wrote:

> Around 2012[1] we made the brave switch from md5crypt to sha512. Some
> people were asking for bcrypt to be default, and others were hoping we
> would see pbkdf2 support. We went with compatible. Additionally, making
> password hashing more
>
> In light of this new article[2] I would like to rehash (pun intended) this
> conversation and also mention a bug report[3] we've been sitting on in some
> form for 12 years[4] with usable code that would make working with password
> hashing algorithms easier and the rounds configurable by the admin.
>
> I'd also like to see us to pull in scrypt if cperciva doesn't have any
> objections. It's good to have options.
>
> PS: Why does "compatibility" matter for a default algorithm? Having a
> default different than Linux or Solaris isn't a bad thing as long as we
> implement the industry's common hashes which would permit any management
> tools twiddling the master.passwd manually to still be able to insert the
> password hashes in a common format...
>
> [1]
> https://lists.freebsd.org/pipermail/freebsd-security/2012-June/006271.html
> [2]
> https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/
> [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182518
> [4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=75934 is the
> original report about the issue
>
> --
>   Mark Felder
>   ports-secteam & portmgr member
>   f...@freebsd.org
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org
> "
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Default password hash, redux

[Mark Felder]

Around 2012[1] we made the brave switch from md5crypt to sha512. Some people 
were asking for bcrypt to be default, and others were hoping we would see 
pbkdf2 support. We went with compatible. Additionally, making password hashing 
more

In light of this new article[2] I would like to rehash (pun intended) this 
conversation and also mention a bug report[3] we've been sitting on in some 
form for 12 years[4] with usable code that would make working with password 
hashing algorithms easier and the rounds configurable by the admin.

I'd also like to see us to pull in scrypt if cperciva doesn't have any 
objections. It's good to have options.

PS: Why does "compatibility" matter for a default algorithm? Having a default 
different than Linux or Solaris isn't a bad thing as long as we implement the 
industry's common hashes which would permit any management tools twiddling the 
master.passwd manually to still be able to insert the password hashes in a 
common format...

[1] https://lists.freebsd.org/pipermail/freebsd-security/2012-June/006271.html
[2] 
https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182518
[4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=75934 is the original 
report about the issue

-- 
  Mark Felder
  ports-secteam & portmgr member
  f...@freebsd.org
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Default password hash

[Dag-Erling Smørgrav]

The attached patch backports support for sha256 and sha512 hashes to
stable/7.  It is not an exact MFH because the sha code in head uses
stpncpy(), which is not present in stable/7's libc.

DES
-- 
Dag-Erling Smørgrav - d...@des.no

Index: lib/libcrypt
===
--- lib/libcrypt	(revision 236892)
+++ lib/libcrypt	(working copy)

Property changes on: lib/libcrypt
___
Added: svn:mergeinfo
   Merged /head/gnu/libcrypt:r183242
   Merged /head/lib/libcrypt:r179308,183242,213738,213814,213903,216591,220497-220498,221142,221471,227006,234132
Index: lib/libcrypt/crypt.c
===
--- lib/libcrypt/crypt.c	(revision 236892)
+++ lib/libcrypt/crypt.c	(working copy)
@@ -63,6 +63,16 @@
 		$3$
 	},
 	{
+		sha256,
+		crypt_sha256,
+		$5$
+	},
+	{
+		sha512,
+		crypt_sha512,
+		$6$
+	},
+	{
 		NULL,
 		NULL,
 		NULL
Index: lib/libcrypt/crypt-sha512.c
===
--- lib/libcrypt/crypt-sha512.c	(working copy)
+++ lib/libcrypt/crypt-sha512.c	(working copy)
@@ -60,7 +60,7 @@
 #define ROUNDS_MAX 9
 
 static char *
-sha512_crypt_r(const char *key, const char *salt, char *buffer, int buflen)
+crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen)
 {
 	u_long srounds;
 	int n;
@@ -210,7 +210,9 @@
 
 	/* Now we can construct the result string. It consists of three
 	 * parts. */
-	cp = stpncpy(buffer, sha512_salt_prefix, MAX(0, buflen));
+	cp = buffer;
+	strncpy(buffer, sha512_salt_prefix, MAX(0, buflen));
+	cp += sizeof(sha512_salt_prefix) - 1;
 	buflen -= sizeof(sha512_salt_prefix) - 1;
 
 	if (rounds_custom) {
@@ -221,7 +223,8 @@
 		buflen -= n;
 	}
 
-	cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	cp += MIN((size_t)MAX(0, buflen), salt_len);
 	buflen -= MIN((size_t)MAX(0, buflen), salt_len);
 
 	if (buflen  0) {
@@ -280,12 +283,12 @@
 
 /* This entry point is equivalent to crypt(3). */
 char *
-sha512_crypt(const char *key, const char *salt)
+crypt_sha512(const char *key, const char *salt)
 {
 	/* We don't want to have an arbitrary limit in the size of the
 	 * password. We can compute an upper bound for the size of the
 	 * result in advance and so we can prepare the buffer we pass to
-	 * `sha512_crypt_r'. */
+	 * `crypt_sha512_r'. */
 	static char *buffer;
 	static int buflen;
 	int needed;
@@ -305,7 +308,7 @@
 		buflen = needed;
 	}
 
-	return sha512_crypt_r(key, salt, buffer, buflen);
+	return crypt_sha512_r(key, salt, buffer, buflen);
 }
 
 #ifdef TEST
@@ -482,7 +485,7 @@
 	}
 
 	for (cnt = 0; cnt  ntests2; ++cnt) {
-		char *cp = sha512_crypt(tests2[cnt].input, tests2[cnt].salt);
+		char *cp = crypt_sha512(tests2[cnt].input, tests2[cnt].salt);
 
 		if (strcmp(cp, tests2[cnt].expected) != 0) {
 			printf(test %d: expected \%s\, got \%s\\n,
Index: lib/libcrypt/crypt.h
===
--- lib/libcrypt/crypt.h	(revision 236892)
+++ lib/libcrypt/crypt.h	(working copy)
@@ -36,5 +36,8 @@
 char *crypt_md5(const char *pw, const char *salt);
 char *crypt_nthash(const char *pw, const char *salt);
 char *crypt_blowfish(const char *pw, const char *salt);
+char *crypt_sha256 (const char *pw, const char *salt);
+char *crypt_sha512 (const char *pw, const char *salt);
 
 extern void _crypt_to64(char *s, u_long v, int n);
+extern void b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int *buflen, char **cp);
Index: lib/libcrypt/crypt-sha256.c
===
--- lib/libcrypt/crypt-sha256.c	(working copy)
+++ lib/libcrypt/crypt-sha256.c	(working copy)
@@ -60,7 +60,7 @@
 #define ROUNDS_MAX 9
 
 static char *
-sha256_crypt_r(const char *key, const char *salt, char *buffer, int buflen)
+crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen)
 {
 	u_long srounds;
 	int n;
@@ -210,7 +210,9 @@
 
 	/* Now we can construct the result string. It consists of three
 	 * parts. */
-	cp = stpncpy(buffer, sha256_salt_prefix, MAX(0, buflen));
+	cp = buffer;
+	strncpy(buffer, sha256_salt_prefix, MAX(0, buflen));
+	cp += sizeof(sha256_salt_prefix) - 1;
 	buflen -= sizeof(sha256_salt_prefix) - 1;
 
 	if (rounds_custom) {
@@ -221,7 +223,8 @@
 		buflen -= n;
 	}
 
-	cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	cp += MIN((size_t)MAX(0, buflen), salt_len);
 	buflen -= MIN((size_t)MAX(0, buflen), salt_len);
 
 	if (buflen  0) {
@@ -268,12 +271,12 @@
 
 /* This entry point is equivalent to crypt(3). */
 char *
-sha256_crypt(const char *key, const char *salt)
+crypt_sha256(const char *key, const char *salt)
 {
 	/* We don't want to have an arbitrary limit in the size of the
 	 * password. We can compute an 

Re: Default password hash

[Dag-Erling Smørgrav]

The attached patch backports support for sha256 and sha512 hashes to
stable/7.  It is not an exact MFH because the sha code in head uses
stpncpy(), which is not present in stable/7's libc.

DES
-- 
Dag-Erling Smørgrav - d...@des.no

Index: lib/libcrypt
===
--- lib/libcrypt	(revision 236892)
+++ lib/libcrypt	(working copy)

Property changes on: lib/libcrypt
___
Added: svn:mergeinfo
   Merged /head/gnu/libcrypt:r183242
   Merged /head/lib/libcrypt:r179308,183242,213738,213814,213903,216591,220497-220498,221142,221471,227006,234132
Index: lib/libcrypt/crypt.c
===
--- lib/libcrypt/crypt.c	(revision 236892)
+++ lib/libcrypt/crypt.c	(working copy)
@@ -63,6 +63,16 @@
 		$3$
 	},
 	{
+		sha256,
+		crypt_sha256,
+		$5$
+	},
+	{
+		sha512,
+		crypt_sha512,
+		$6$
+	},
+	{
 		NULL,
 		NULL,
 		NULL
Index: lib/libcrypt/crypt-sha512.c
===
--- lib/libcrypt/crypt-sha512.c	(working copy)
+++ lib/libcrypt/crypt-sha512.c	(working copy)
@@ -60,7 +60,7 @@
 #define ROUNDS_MAX 9
 
 static char *
-sha512_crypt_r(const char *key, const char *salt, char *buffer, int buflen)
+crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen)
 {
 	u_long srounds;
 	int n;
@@ -210,7 +210,9 @@
 
 	/* Now we can construct the result string. It consists of three
 	 * parts. */
-	cp = stpncpy(buffer, sha512_salt_prefix, MAX(0, buflen));
+	cp = buffer;
+	strncpy(buffer, sha512_salt_prefix, MAX(0, buflen));
+	cp += sizeof(sha512_salt_prefix) - 1;
 	buflen -= sizeof(sha512_salt_prefix) - 1;
 
 	if (rounds_custom) {
@@ -221,7 +223,8 @@
 		buflen -= n;
 	}
 
-	cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	cp += MIN((size_t)MAX(0, buflen), salt_len);
 	buflen -= MIN((size_t)MAX(0, buflen), salt_len);
 
 	if (buflen  0) {
@@ -280,12 +283,12 @@
 
 /* This entry point is equivalent to crypt(3). */
 char *
-sha512_crypt(const char *key, const char *salt)
+crypt_sha512(const char *key, const char *salt)
 {
 	/* We don't want to have an arbitrary limit in the size of the
 	 * password. We can compute an upper bound for the size of the
 	 * result in advance and so we can prepare the buffer we pass to
-	 * `sha512_crypt_r'. */
+	 * `crypt_sha512_r'. */
 	static char *buffer;
 	static int buflen;
 	int needed;
@@ -305,7 +308,7 @@
 		buflen = needed;
 	}
 
-	return sha512_crypt_r(key, salt, buffer, buflen);
+	return crypt_sha512_r(key, salt, buffer, buflen);
 }
 
 #ifdef TEST
@@ -482,7 +485,7 @@
 	}
 
 	for (cnt = 0; cnt  ntests2; ++cnt) {
-		char *cp = sha512_crypt(tests2[cnt].input, tests2[cnt].salt);
+		char *cp = crypt_sha512(tests2[cnt].input, tests2[cnt].salt);
 
 		if (strcmp(cp, tests2[cnt].expected) != 0) {
 			printf(test %d: expected \%s\, got \%s\\n,
Index: lib/libcrypt/crypt.h
===
--- lib/libcrypt/crypt.h	(revision 236892)
+++ lib/libcrypt/crypt.h	(working copy)
@@ -36,5 +36,8 @@
 char *crypt_md5(const char *pw, const char *salt);
 char *crypt_nthash(const char *pw, const char *salt);
 char *crypt_blowfish(const char *pw, const char *salt);
+char *crypt_sha256 (const char *pw, const char *salt);
+char *crypt_sha512 (const char *pw, const char *salt);
 
 extern void _crypt_to64(char *s, u_long v, int n);
+extern void b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int *buflen, char **cp);
Index: lib/libcrypt/crypt-sha256.c
===
--- lib/libcrypt/crypt-sha256.c	(working copy)
+++ lib/libcrypt/crypt-sha256.c	(working copy)
@@ -60,7 +60,7 @@
 #define ROUNDS_MAX 9
 
 static char *
-sha256_crypt_r(const char *key, const char *salt, char *buffer, int buflen)
+crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen)
 {
 	u_long srounds;
 	int n;
@@ -210,7 +210,9 @@
 
 	/* Now we can construct the result string. It consists of three
 	 * parts. */
-	cp = stpncpy(buffer, sha256_salt_prefix, MAX(0, buflen));
+	cp = buffer;
+	strncpy(buffer, sha256_salt_prefix, MAX(0, buflen));
+	cp += sizeof(sha256_salt_prefix) - 1;
 	buflen -= sizeof(sha256_salt_prefix) - 1;
 
 	if (rounds_custom) {
@@ -221,7 +223,8 @@
 		buflen -= n;
 	}
 
-	cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len));
+	cp += MIN((size_t)MAX(0, buflen), salt_len);
 	buflen -= MIN((size_t)MAX(0, buflen), salt_len);
 
 	if (buflen  0) {
@@ -268,12 +271,12 @@
 
 /* This entry point is equivalent to crypt(3). */
 char *
-sha256_crypt(const char *key, const char *salt)
+crypt_sha256(const char *key, const char *salt)
 {
 	/* We don't want to have an arbitrary limit in the size of the
 	 * password. We can compute an 

Re: Default password hash

[Dag-Erling Smørgrav]

Mike Tancsa m...@sentex.net writes:
 Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
 currently not there.

not there as in not supported by crypt(3)?

 http://phk.freebsd.dk/sagas/md5crypt_eol.html

That blog entry is (partly) why I suggested this change.  I think phk is
being overly pessimistic, but there is no reason not to switch to sha512
when a) it's indubitably stronger and b) that's what the rest of the
world uses.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Dag-Erling Smørgrav]

Lars Engels lars.eng...@0x20.net writes:
 BTW Solaris 10 and 11 support our Blowfish algorithm, Solaris 10 = 10/08
 supports SHA256 and SHA512 and SHA256 was mad the default algorithm in
 Solaris 11.
 Some Linux variants support Blowfish and from glibc 2.7 on they have
 support for SHA256 and SHA512.

 So the least common denominator if we want to use a compatible format is
 SHA256/SHA512.

SHA512 is the default in RedHat, Fedora, Debian and Ubuntu.  I believe
SUSE uses Blowfish, but I'm not sure.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Lev Serebryakov]

Hello, Simon.
You wrote 10 июня 2012 г., 14:02:50:

SLBN Has anyone looked at how long the SHA512 password hashing
SLBN actually takes on modern computers?
 Modern  computers  are  not what should you afraid. Modern GPUs are.
And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2.

 Modern key-derivation schemes must be RAM-heavy, not CPU-heavy.

 And   I   don't   understand,   why  should  we  use  our  home-grown
strengthening algorithms instead of standard choices: PBKDF2[1],
bcrypt[2] and (my favorite) scrypt[3].

[1] http://tools.ietf.org/html/rfc2898
[2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.html
[3] http://www.tarsnap.com/scrypt.html

-- 
// Black Lion AKA Lev Serebryakov l...@freebsd.org

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Mike Tancsa]

On 6/11/2012 4:48 AM, Dag-Erling Smørgrav wrote:
 Mike Tancsa m...@sentex.net writes:
 Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
 currently not there.
 
 not there as in not supported by crypt(3)?

If you put in sha256|sha512 in passwd_format, the passwd that gets
chosen is DES, as in Data Encryption Standard, not Dag-Erling Smørgrav ;-)

---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Lars Engels]

On Mon, Jun 11, 2012 at 10:51:45AM +0200, Dag-Erling Smørgrav wrote:
 Damian Weber dwe...@htw-saarland.de writes:
  *collision* attacks are relatively easy these days, but against 1 MD5, 
  not against 1000 times MD5
 
 I'm not talking about collision attacks, I'm talking about brute-forcing
 hashes.
 
  there is a NIST hash competition running, the winner will soon be announced
  (and it won't be SHA256 or SHA512 ;-)
  http://csrc.nist.gov/groups/ST/hash/timeline.html
  so my suggestion would be to use all of the finalists - especially
  the winner - for password hashing
  * BLAKE
  * Grøstl 
  * JH
  * Keccak
  * Skein
  see, for example, http://www.nist.gov/itl/csd/sha3_010511.cfm
 
 There's a world of difference between switching the default to an
 algorithm we already support and which is widely used by other operating
 systems, and switching to a completely knew and untested algorithm.

BTW Solaris 10 and 11 support our Blowfish algorithm, Solaris 10 = 10/08
supports SHA256 and SHA512 and SHA256 was mad the default algorithm in
Solaris 11.
Some Linux variants support Blowfish and from glibc 2.7 on they have
support for SHA256 and SHA512.

So the least common denominator if we want to use a compatible format is
SHA256/SHA512.


pgpwbHE2hL5Qm.pgp
Description: PGP signature

Re: Default password hash

[Simon L. B. Nielsen]

On Sun, Jun 10, 2012 at 3:53 PM, Gleb Kurtsou gleb.kurt...@gmail.com wrote:
 On (10/06/2012 11:02), Simon L. B. Nielsen wrote:

 On 8 Jun 2012, at 13:51, Dag-Erling Smørgrav wrote:

  We still have MD5 as our default password hash, even though known-hash
  attacks against MD5 are relatively easy these days.  We've supported
  SHA256 and SHA512 for many years now, so how about making SHA512 the
  default instead of MD5, like on most Linux distributions?

 Has anyone looked at how long the SHA512 password hashing actually takes on 
 modern computers?

 The real solution for people who care significantly about this seems 
 something like the algorithm pjd implemented (I think he did it at least) 
 for GELI, where the number of rounds is variable and calculated so it takes 
 X/0.X seconds on the specific hardware used. That's of course a lot more 
 complicated, and I'm not sure if it would work with the crypt() API.

 Do you mean pkcs5v2_calculate from geli? It seems to have a drawback

Correct.

 that results produced depend on actual CPU load.

That's not the drawback, but the whole point (well, at least a point).
While it can of course produce fewer rounds on different systems,
especially on fast systems you will likely end up with a lot more
rounds than whatever the default is.

 % ./pkcs5v-test [*]
 541491
 539568
 542352
 540376
 388285 -- start several instances of pkcs5v-test in parallel
 303071
 284793
 281110

 It would be awesome to provide user with options to configure minimal
 and maximal iteration count and randomly choose iteration count within
 the range for each new password. Such trivial change should considerably
 complicate mass password bruteforce cracking.

That's also an option. I'm not sure how well that would work in practice.

 Variable number of rounds for a password would also require changing
 crypt() interface.

Exactly, so probably not actually a working solution for normal case,
and possibly just not worth the trouble at all due to compatibility.

 Why does nobody mention scrypt? It looks very attractive in longer
 perspective.

It's not in the base system yet, last I checked anyway, so I assume
that either Colin still don't find it ready for general use, or he has
just been too busy.

-- 
Simon
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Simon L. B. Nielsen]

On Mon, Jun 11, 2012 at 11:44 AM, Lev Serebryakov l...@freebsd.org wrote:
 Hello, Simon.
 You wrote 10 июня 2012 г., 14:02:50:

 SLBN Has anyone looked at how long the SHA512 password hashing
 SLBN actually takes on modern computers?
  Modern  computers  are  not what should you afraid. Modern GPUs are.
 And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2.

  Modern key-derivation schemes must be RAM-heavy, not CPU-heavy.

But the modern CPU's will limit the number of rounds you can use for a
hash (if you use same system as md5crypt), as you can't let users wait
10+ seconds to check their password.

  And   I   don't   understand,   why  should  we  use  our  home-grown
 strengthening algorithms instead of standard choices: PBKDF2[1],
 bcrypt[2] and (my favorite) scrypt[3].

Recall that FreeBSD's MD5 strengthening probably predates most of the
other systems by a while (I'm too lazy to look it up).

That said, I generally agree we should go with something standard or
existing unless there is a very good reason not to.

PBKDF2 / RFC2898 is what GELI uses (which I mentioned previously).

 [1] http://tools.ietf.org/html/rfc2898
 [2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.html
 [3] http://www.tarsnap.com/scrypt.html

-- 
Simon
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Mike Tancsa]

On 6/11/2012 10:00 AM, Dag-Erling Smørgrav wrote:
 Mike Tancsa m...@sentex.net writes:
 Dag-Erling Smørgrav d...@des.no writes:
 Mike Tancsa m...@sentex.net writes:
 Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
 currently not there.
 not there as in not supported by crypt(3)?
 If you put in sha256|sha512 in passwd_format, the passwd that gets
 chosen is DES, as in Data Encryption Standard, not Dag-Erling Smørgrav
 ;-)
 
 This is non-trivial to fix, as the code that would need to be MFCed
 depends on libc changes.  I'm worried about collateral damage from
 MFCing those changes.
 
 It may be possible to backport the sha2 code.

Locally, we still have a need to share some passwd files between a
couple of RELENG_8 and RELENG_7 boxes.  But it might be better to just
upgrade the new boxes to 8 if need be.  If not, is Blowfish as its
currently implemented on RELENG_7 considered strong enough ? There has
been some discussion suggesting its not and some that it is.


---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Dag-Erling Smørgrav]

O. Hartmann ohart...@zedat.fu-berlin.de writes:
 You should also file a PR for change-requets, so it is not only in the
 email list.

I have no idea what you mean by that...

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Gleb Kurtsou]

On (11/06/2012 12:51), Simon L. B. Nielsen wrote:
 On Mon, Jun 11, 2012 at 11:44 AM, Lev Serebryakov l...@freebsd.org wrote:
  Hello, Simon.
  You wrote 10 июня 2012 г., 14:02:50:
 
  SLBN Has anyone looked at how long the SHA512 password hashing
  SLBN actually takes on modern computers?
   Modern  computers  are  not what should you afraid. Modern GPUs are.
  And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2.
 
   Modern key-derivation schemes must be RAM-heavy, not CPU-heavy.
 
 But the modern CPU's will limit the number of rounds you can use for a
 hash (if you use same system as md5crypt), as you can't let users wait
 10+ seconds to check their password.
 
   And   I   don't   understand,   why  should  we  use  our  home-grown
  strengthening algorithms instead of standard choices: PBKDF2[1],
  bcrypt[2] and (my favorite) scrypt[3].
 
 Recall that FreeBSD's MD5 strengthening probably predates most of the
 other systems by a while (I'm too lazy to look it up).
 
 That said, I generally agree we should go with something standard or
 existing unless there is a very good reason not to.
 
 PBKDF2 / RFC2898 is what GELI uses (which I mentioned previously).

PBKDF2 as a key derivation function is a bit different from a key
stretching concept. KDF's *main* goal is to produce cryptographically
good keys, but not to make bruteforce attacks hard on GPU/FPGA/etc.

As already mentioned, nowadays good key stretching algorithms are
supposed to be GPU-unfriendly. That is the case with crypto_blowfush,
crypt_md5 and crypt_sha* thanks to data dependent branching, but it's
not true for PBKDF2.

I suppose everybody reading this thread has already seen recent
presentation by Solar Designer on password security (video should also
be available online):
http://www.openwall.com/presentations/PHDays2012-Password-Security/

What particularly interesting is the following slide, comparing
crypt_sha512/crypt_blowfish GPU-friendliness and performance:
http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00037.html

In other words, currently there is no benefit in switch default
algorithm to relatively new crypt_sha512 vs 256-iterations
crypt_blowfish supported on RELENG_7.

crypt-md5.c except:
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);
}

  [1] http://tools.ietf.org/html/rfc2898
  [2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.html
  [3] http://www.tarsnap.com/scrypt.html
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Dag-Erling Smørgrav]

Gleb Kurtsou gleb.kurt...@gmail.com writes:
 In other words, currently there is no benefit in switch default
 algorithm to relatively new crypt_sha512 vs 256-iterations
 crypt_blowfish supported on RELENG_7.

From a cryptographic point of view, perhaps, but they are both better
than the current default (md5), and all else being equal, I favor the
option that maximises compatibility, i.e. sha512.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/09/12 04:34, Mike Tancsa wrote:
 On 6/8/2012 8:51 AM, Dag-Erling Smørgrav wrote:
 We still have MD5 as our default password hash, even though
 known-hash attacks against MD5 are relatively easy these days.
 We've supported SHA256 and SHA512 for many years now, so how
 about making SHA512 the default instead of MD5, like on most
 Linux distributions?
 
 Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its 
 currently not there.

Ping me next Friday if nobody else would volunteer.

 RELENG_7 is supported until 2013
 
 Sort of a security issue considering this assessment of MD5
 
 http://phk.freebsd.dk/sagas/md5crypt_eol.html
 
 
 ---Mike
 
 
 
 
 Index: etc/login.conf 
 ===

 
- --- etc/login.conf  (revision 236616)
 +++ etc/login.conf  (working copy) @@ -23,7 +23,7 @@ # AND
 SEMANTICS'' section of getcap(3) for more escape sequences).
 
 default:\ -   :passwd_format=md5:\ +
 :passwd_format=sha512:\ :copyright=/etc/COPYRIGHT:\ 
 :welcome=/etc/motd:\ 
 :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
 
 DES
 
 


- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJP1ETFAAoJEG80Jeu8UPuzRWAH/3XDen0pxNpYDqRxfAiTKJjI
A0JqyNrVMMA3/ncenceODJs+7BugXRWnC5jyAzfxC5KulL1ZcBZCfYApdWgJ+Lun
yHnv/JryEK2InzGwuDX/P3Tt1TZVKtr5drs7yJuZnRaW5SWRRaPRvLqgGZ1PdNxb
/cHIXL+DPxHUXhwBcInhWWImNDJU3xEcvFQSpW4C8iqGqviFLE0WlhKTGVvnwiMO
lXTnyyadQMrMQW8XIgcgyNZ5b3asiTAC1TOXtaTWiFR2QPgfxZSvEoaxu/AMmep3
HegMWA0qXXCvj7E0xUECRs3tXG6hbxhaRJima8FdPeCLWcNtd12PC44xj+EuufQ=
=7wMd
-END PGP SIGNATURE-
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Gleb Kurtsou]

On (10/06/2012 11:02), Simon L. B. Nielsen wrote:
 
 On 8 Jun 2012, at 13:51, Dag-Erling Smørgrav wrote:
 
  We still have MD5 as our default password hash, even though known-hash
  attacks against MD5 are relatively easy these days.  We've supported
  SHA256 and SHA512 for many years now, so how about making SHA512 the
  default instead of MD5, like on most Linux distributions?
 
 Has anyone looked at how long the SHA512 password hashing actually takes on 
 modern computers?
 
 The real solution for people who care significantly about this seems 
 something like the algorithm pjd implemented (I think he did it at least) for 
 GELI, where the number of rounds is variable and calculated so it takes X/0.X 
 seconds on the specific hardware used. That's of course a lot more 
 complicated, and I'm not sure if it would work with the crypt() API.

Do you mean pkcs5v2_calculate from geli? It seems to have a drawback
that results produced depend on actual CPU load.

% ./pkcs5v-test [*]
541491
539568
542352
540376
388285 -- start several instances of pkcs5v-test in parallel
303071
284793
281110

It would be awesome to provide user with options to configure minimal
and maximal iteration count and randomly choose iteration count within
the range for each new password. Such trivial change should considerably
complicate mass password bruteforce cracking.

Variable number of rounds for a password would also require changing
crypt() interface.

 Also, does anyone know if our SHA512 is compatible with the format used by 
 Linux, other BSD's etc?

It's supposed to be compatible with Linux. DragonFly invented something
on their own with a nasty bug in it. They could have changed to
standard crypt on top of sha-2 after bug was discovered.
http://www.openwall.com/lists/oss-security/2012/01/16/2

Why does nobody mention scrypt? It looks very attractive in longer
perspective.

Thanks,
Gleb.


* pkcs5v-test.c:
#include crypto/pkcs5v2/pkcs5v2.h

int
main(int argc, char **argv)
{
int i, usec;

for (i = 0; i  10; i++) {
usec = pkcs5v2_calculate(200, 512 / 8, 4);
printf(%d\n, usec);
}

return (0);
}

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Damian Weber]

 On 8 Jun 2012, at 13:51, Dag-Erling Smørgrav wrote:
 
  We still have MD5 as our default password hash, even though known-hash
  attacks against MD5 are relatively easy these days. 

*collision* attacks are relatively easy these days, but against 1 MD5, 
not against 1000 times MD5

w.r.t. password hashes, a successful preimage attack would be threatening,
which publications are you referring to?

I found one preimage attack on reduced MD5, but it's theoretical (2^96 steps)
Preimage Attacks on 3-Pass HAVAL and Step-Reduced MD5*
eprint.iacr.org/2008/183.pdf


  We've supported
  SHA256 and SHA512 for many years now, so how about making SHA512 the
  default instead of MD5, like on most Linux distributions?

there is a NIST hash competition running, the winner will soon be announced
(and it won't be SHA256 or SHA512 ;-)
http://csrc.nist.gov/groups/ST/hash/timeline.html
so my suggestion would be to use all of the finalists - especially
the winner - for password hashing
* BLAKE
* Grøstl 
* JH
* Keccak
* Skein
see, for example, http://www.nist.gov/itl/csd/sha3_010511.cfm

--
Damian Weber, http://www-crypto.htw-saarland.de___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Matt Piechota]

On 06/10/2012 06:02 AM, Simon L. B. Nielsen wrote:
Has anyone looked at how long the SHA512 password hashing actually 
takes on modern computers? The real solution for people who care 
significantly about this seems something like the algorithm pjd 
implemented (I think he did it at least) for GELI, where the number of 
rounds is variable and calculated so it takes X/0.X seconds on the 
specific hardware used. That's of course a lot more complicated, and 
I'm not sure if it would work with the crypt() API. 


I'm kinda curious about this: I take it you'd encode the number of 
rounds in the string somehow? Otherwise, the hash wouldn't be portable 
to another machine (or even if you upgrade the current machine).


--
Matt Piechota

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

[Re: Default password hash]

[Oliver Pinter]

On 6/8/12, Dag-Erling Smørgrav d...@des.no wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?

 Index: etc/login.conf
 ===
 --- etc/login.conf  (revision 236616)
 +++ etc/login.conf  (working copy)
 @@ -23,7 +23,7 @@
  # AND SEMANTICS'' section of getcap(3) for more escape sequences).

  default:\
 -   :passwd_format=md5:\
 +   :passwd_format=sha512:\
 :copyright=/etc/COPYRIGHT:\
 :welcome=/etc/motd:\
 :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

 DES
 --
 Dag-Erling Smørgrav - d...@des.no
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash]

[RW]

On Mon, 11 Jun 2012 00:37:30 +0200
Oliver Pinter wrote:


 16 rounds in 2012? It is not to weak?!

It's hard to say. Remember that blowfish was designed as a cipher not
a hash. It's designed to be fast, but to still resist known plaintext
attacks at the beginning of the ciphertext. It was also designed to
work directly with a passphrase because there was a history of
programmers abusing DES by using simple ascii passwords as keys. 

For these reasons initialization is deliberately expensive,
effectively it already contains an element of passphrase hashing. 
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash]

[Oliver Pinter]

On 6/11/12, RW rwmailli...@googlemail.com wrote:
 On Mon, 11 Jun 2012 00:37:30 +0200
 Oliver Pinter wrote:


 16 rounds in 2012? It is not to weak?!

 It's hard to say. Remember that blowfish was designed as a cipher not
 a hash. It's designed to be fast, but to still resist known plaintext
 attacks at the beginning of the ciphertext. It was also designed to
 work directly with a passphrase because there was a history of
 programmers abusing DES by using simple ascii passwords as keys.

 For these reasons initialization is deliberately expensive,
 effectively it already contains an element of passphrase hashing.

Yes, I know that the blowfish is a cipher and not hash, but I think 16
round today is too small. I checked this in a freshly installed
openbsd, and they used 256 round ($2a$08$...) .




 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash]

[emu]

On 2012-06-10 19:24, RW wrote:

On Mon, 11 Jun 2012 00:37:30 +0200
Oliver Pinter wrote:



16 rounds in 2012? It is not to weak?!


It's hard to say. Remember that blowfish was designed as a cipher not
a hash. It's designed to be fast, but to still resist known plaintext
attacks at the beginning of the ciphertext. It was also designed to
work directly with a passphrase because there was a history of
programmers abusing DES by using simple ascii passwords as keys.

For these reasons initialization is deliberately expensive,
effectively it already contains an element of passphrase hashing.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to 
freebsd-security-unsubscr...@freebsd.org

how long are we going to go on about this
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[O. Hartmann]

On 06/08/12 14:51, Dag-Erling Smørgrav wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?
 
 Index: etc/login.conf
 ===
 --- etc/login.conf  (revision 236616)
 +++ etc/login.conf  (working copy)
 @@ -23,7 +23,7 @@
  # AND SEMANTICS'' section of getcap(3) for more escape sequences).
 
  default:\
 -   :passwd_format=md5:\
 +   :passwd_format=sha512:\
 :copyright=/etc/COPYRIGHT:\
 :welcome=/etc/motd:\
 :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
 
 DES

You should also file a PR for change-requets, so it is not only in the
email list. I second a change, since I use blf since 2009 without
(obvious) problems.

The manpage for login.conf also needs an update. I checked this morning
and found that thye manpage doesn't even mention hashes apart from des,
md5 and blf.

Oliver



signature.asc
Description: OpenPGP digital signature

Re: Default password hash

[O. Hartmann]

On 06/09/12 11:28, Dimitry Andric wrote:
 On 2012-06-09 09:43, O. Hartmann wrote:
 On 06/08/12 14:51, Dag-Erling Smørgrav wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?
 ...
 The manpage for login.conf also needs an update. I checked this morning
 and found that thye manpage doesn't even mention hashes apart from des,
 md5 and blf.
 
 Dag-Erling fixed this just yesterday :)
 
 http://svn.freebsd.org/changeset/base/236751

Great and thank you all ... :-)



signature.asc
Description: OpenPGP digital signature

Re: Default password hash

[emu]

On 2012-06-09 00:01, Robert Simmons wrote:
On Fri, Jun 8, 2012 at 9:06 AM, Maxim Khitrov m...@mxcrypt.com 
wrote:
On Fri, Jun 8, 2012 at 8:51 AM, Dag-Erling Smørgrav d...@des.no 
wrote:
We still have MD5 as our default password hash, even though 
known-hash
attacks against MD5 are relatively easy these days.  We've 
supported
SHA256 and SHA512 for many years now, so how about making SHA512 
the

default instead of MD5, like on most Linux distributions?


If SHA-2 hashes have been supported for many years, why haven't the
man pages been updated? login.conf(5) on 9.0-RELEASE still only 
lists

des, md5, and blf. I've been using the latter on my systems.


Yes, I think at least listing all the supported algorithms in the
login.conf man page is of utmost importance.  I've been using 
blowfish

since it was introduced to FreeBSD over 12 years ago, but I had no
idea that any other algorithms were possible/available until now.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to 
freebsd-security-unsubscr...@freebsd.org
it was listed with 9.0, change /etc/login.conf from md5 to sha512 and 
then cap_mkdb /etc/login.conf and then passwd root/users for effect. as 
a previous post im not sure the /etc/auth.conf is necessary.

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Dimitry Andric]

On 2012-06-09 09:43, O. Hartmann wrote:
 On 06/08/12 14:51, Dag-Erling Smørgrav wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?
...
 The manpage for login.conf also needs an update. I checked this morning
 and found that thye manpage doesn't even mention hashes apart from des,
 md5 and blf.

Dag-Erling fixed this just yesterday :)

http://svn.freebsd.org/changeset/base/236751

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Mike Tancsa]

On 6/8/2012 8:51 AM, Dag-Erling Smørgrav wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?

Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
currently not there.

RELENG_7 is supported until 2013

Sort of a security issue considering this assessment of MD5

http://phk.freebsd.dk/sagas/md5crypt_eol.html


---Mike



 
 Index: etc/login.conf
 ===
 --- etc/login.conf  (revision 236616)
 +++ etc/login.conf  (working copy)
 @@ -23,7 +23,7 @@
  # AND SEMANTICS'' section of getcap(3) for more escape sequences).
 
  default:\
 -   :passwd_format=md5:\
 +   :passwd_format=sha512:\
 :copyright=/etc/COPYRIGHT:\
 :welcome=/etc/motd:\
 :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
 
 DES


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Mike Tancsa]

On 6/9/2012 9:19 AM, someone wrote:
 hi,
 
 what is needed to change from md5 to sha512 ? As all old passwd are md5, I 
 imagine there is a
 sequence of steps not to lock me out of the box. is there any place that 
 documents this ?

You need a relatively recent RELENG_8, not sure the exact date.  To
change the pass format, edit the file login.conf
cd /etc

vi /etc/login.conf

where it shows

default:\
:passwd_format=md5:\

change it to

default:\
:passwd_format=sha512:\

Regenerate the db file
cap_mkdb login.conf

The old passwd hash thats MD5 based will look something like

0(cage2)# grep testuser /etc/master.passwd
testuser:$1$0lfvk63d$WPD8y7w6o2CAU8V4kTgqR1:1004:1004::0:0:User
:/home/testuser:/bin/sh
0(cage2)#

note the $1$

change the users passwd to something new, or just use the old passwd,
but re-enter it

1(cage2)# grep testuser /etc/master.passwd
testuser:$1$0lfvk63d$WPD8y7w6o2CAU8V4kTgqR1:1004:1004::0:0:User
:/home/testuser:/bin/sh
0(cage2)# passwd testuser
Changing local password for testuser
New Password:
Retype New Password:
0(cage2)# grep testuser /etc/master.passwd
testuser:$6$AvBQXRlaKNv/YkM8$WhrcMomrs7mXgHAvFpETPT.T21jH9rYtsK8KKEFVOOYCm6noIHKI3JqQw67Vc/cYwTkGxnFY1zWrddiVUmk2p0:1004:1004::0:0:User
:/home/testuser:/bin/sh
0(cage2)#


Note the $6$ in the hash, and its now super long.

If your FreeBSD version does not support sha512, Blowfish might be a
better alternative.  Note sure, perhaps others here know how safe it is

again, change the same file to

default:\
:passwd_format=blf:\

and do a cap_mkdb login.conf

0(cage2)# passwd testuser
Changing local password for testuser
New Password:
Retype New Password:
0(cage2)# grep testuser /etc/master.passwd
testuser:$2a$04$veZKfUGwqsrxWZOb/wbes.RdgQhLL.kfqyQ8Cv044rjJdFI0nSVXy:1004:1004::0:0:User
:/home/testuser:/bin/sh
0(cage2)#

Note the $2a$

Other place to do it is in auth.conf, but I usually do it in login.conf
as shown above.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/crypt.html



---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Nenhum_de_Nos]

On Sat, June 9, 2012 10:34, Mike Tancsa wrote:
 On 6/9/2012 9:19 AM, someone wrote:
 hi,

 what is needed to change from md5 to sha512 ? As all old passwd are md5, I 
 imagine there is a
 sequence of steps not to lock me out of the box. is there any place that 
 documents this ?

 You need a relatively recent RELENG_8, not sure the exact date.  To
 change the pass format, edit the file login.conf
 cd /etc

 vi /etc/login.conf

 where it shows

 default:\
 :passwd_format=md5:\

 change it to

 default:\
 :passwd_format=sha512:\

 Regenerate the db file
 cap_mkdb login.conf

 The old passwd hash thats MD5 based will look something like

 0(cage2)# grep testuser /etc/master.passwd
 testuser:$1$0lfvk63d$WPD8y7w6o2CAU8V4kTgqR1:1004:1004::0:0:User
 :/home/testuser:/bin/sh
 0(cage2)#

 note the $1$

 change the users passwd to something new, or just use the old passwd,
 but re-enter it

 1(cage2)# grep testuser /etc/master.passwd
 testuser:$1$0lfvk63d$WPD8y7w6o2CAU8V4kTgqR1:1004:1004::0:0:User
 :/home/testuser:/bin/sh
 0(cage2)# passwd testuser
 Changing local password for testuser
 New Password:
 Retype New Password:
 0(cage2)# grep testuser /etc/master.passwd
 testuser:$6$AvBQXRlaKNv/YkM8$WhrcMomrs7mXgHAvFpETPT.T21jH9rYtsK8KKEFVOOYCm6noIHKI3JqQw67Vc/cYwTkGxnFY1zWrddiVUmk2p0:1004:1004::0:0:User
 :/home/testuser:/bin/sh
 0(cage2)#


 Note the $6$ in the hash, and its now super long.

 If your FreeBSD version does not support sha512, Blowfish might be a
 better alternative.  Note sure, perhaps others here know how safe it is

 again, change the same file to

 default:\
 :passwd_format=blf:\

 and do a cap_mkdb login.conf

 0(cage2)# passwd testuser
 Changing local password for testuser
 New Password:
 Retype New Password:
 0(cage2)# grep testuser /etc/master.passwd
 testuser:$2a$04$veZKfUGwqsrxWZOb/wbes.RdgQhLL.kfqyQ8Cv044rjJdFI0nSVXy:1004:1004::0:0:User
 :/home/testuser:/bin/sh
 0(cage2)#

 Note the $2a$

 Other place to do it is in auth.conf, but I usually do it in login.conf
 as shown above.

 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/crypt.html

thanks Mike. I plan to change this on 9.0R. I have 8.1 but I think I'll have to 
update.

thanks,

matheus

-- 
We will call you Cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Bryan Drewery]

On 6/9/2012 6:34 AM, Mike Tancsa wrote:
 Sort of a security issue considering this assessment of MD5

You can use blf (blowfish) as well.

Regards,
Bryan Drewery

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Jason Hellenthal]

On Sat, Jun 09, 2012 at 12:04:25AM -0400, emu wrote:
 On 2012-06-09 00:01, Robert Simmons wrote:
  On Fri, Jun 8, 2012 at 9:06 AM, Maxim Khitrov m...@mxcrypt.com 
  wrote:
  On Fri, Jun 8, 2012 at 8:51 AM, Dag-Erling Smørgrav d...@des.no 
  wrote:
  We still have MD5 as our default password hash, even though 
  known-hash
  attacks against MD5 are relatively easy these days.  We've 
  supported
  SHA256 and SHA512 for many years now, so how about making SHA512 
  the
  default instead of MD5, like on most Linux distributions?
 
  If SHA-2 hashes have been supported for many years, why haven't the
  man pages been updated? login.conf(5) on 9.0-RELEASE still only 
  lists
  des, md5, and blf. I've been using the latter on my systems.
 
  Yes, I think at least listing all the supported algorithms in the
  login.conf man page is of utmost importance.  I've been using 
  blowfish
  since it was introduced to FreeBSD over 12 years ago, but I had no
  idea that any other algorithms were possible/available until now.

 it was listed with 9.0, change /etc/login.conf from md5 to sha512 and 
 then cap_mkdb /etc/login.conf and then passwd root/users for effect. as 
 a previous post im not sure the /etc/auth.conf is necessary.

AFAILR auth.conf was being deprecated and there was only one real user
of that left to eliminate. Whether that has been eliminated is beyond me
as I never tracked it... unimportant.

-- 

 - (2^(N-1))
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[RW]

On Sat, 09 Jun 2012 07:34:22 -0400
Mike Tancsa wrote:

 On 6/8/2012 8:51 AM, Dag-Erling Smørgrav wrote:
  We still have MD5 as our default password hash, even though
  known-hash attacks against MD5 are relatively easy these days.
  We've supported SHA256 and SHA512 for many years now, so how about
  making SHA512 the default instead of MD5, like on most Linux
  distributions?
 
 Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ?  Its
 currently not there.
 
 RELENG_7 is supported until 2013
 
 Sort of a security issue 

Lets not forget that this is an attack against insecure passwords
performed after an attacker has already gained root or physical access.


 considering this assessment of MD5
 
 http://phk.freebsd.dk/sagas/md5crypt_eol.html

In the context of that all the existing algorithms are pretty insecure.
The people that are doing this are brute forcing passwords; the
cryptographic merits of the underlying hash are immaterial, except in
as far as they slow things down. 

I would estimate that md5crypt vs sha512crypt is roughly:

2.5 * (5000rounds/1000rounds) *  (512bits/128bits) = 50

to put that in context, going from simple md5 to md5crypt is factor of
~1024.

50 is equivalent to less than 6bits of password entropy. In some cases
it may make little difference to the percentage of passwords cracked.



 

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Robert Simmons]

On Sat, Jun 9, 2012 at 9:34 AM, Mike Tancsa m...@sentex.net wrote:
 On 6/9/2012 9:19 AM, someone wrote:
 hi,

 what is needed to change from md5 to sha512 ? As all old passwd are md5, I 
 imagine there is a
 sequence of steps not to lock me out of the box. is there any place that 
 documents this ?
 change the users passwd to something new, or just use the old passwd,
 but re-enter it

Bad idea.  Never reuse an old password.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Eitan Adler]

On 9 June 2012 13:16, Robert Simmons rsimmo...@gmail.com wrote:
 On Sat, Jun 9, 2012 at 9:34 AM, Mike Tancsa m...@sentex.net wrote:
 On 6/9/2012 9:19 AM, someone wrote:
 hi,

 what is needed to change from md5 to sha512 ? As all old passwd are md5, I 
 imagine there is a
 sequence of steps not to lock me out of the box. is there any place that 
 documents this ?
 change the users passwd to something new, or just use the old passwd,
 but re-enter it

change the default format and run passwd. The password will
transparently change.


-- 
Eitan Adler
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Default password hash

[Dag-Erling Smørgrav]

We still have MD5 as our default password hash, even though known-hash
attacks against MD5 are relatively easy these days.  We've supported
SHA256 and SHA512 for many years now, so how about making SHA512 the
default instead of MD5, like on most Linux distributions?

Index: etc/login.conf
===
--- etc/login.conf  (revision 236616)
+++ etc/login.conf  (working copy)
@@ -23,7 +23,7 @@
 # AND SEMANTICS'' section of getcap(3) for more escape sequences).

 default:\
-   :passwd_format=md5:\
+   :passwd_format=sha512:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Maxim Khitrov]

On Fri, Jun 8, 2012 at 8:51 AM, Dag-Erling Smørgrav d...@des.no wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?

If SHA-2 hashes have been supported for many years, why haven't the
man pages been updated? login.conf(5) on 9.0-RELEASE still only lists
des, md5, and blf. I've been using the latter on my systems.

- Max
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Hartmann, O.]

On 06/08/12 15:06, Maxim Khitrov wrote:
 On Fri, Jun 8, 2012 at 8:51 AM, Dag-Erling Smørgrav d...@des.no wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?
 
 If SHA-2 hashes have been supported for many years, why haven't the
 man pages been updated? login.conf(5) on 9.0-RELEASE still only lists
 des, md5, and blf. I've been using the latter on my systems.
 
 - Max
 ___
 freebsd-security@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-security
 To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org


I asked similar things once:

http://lists.freebsd.org/pipermail/freebsd-security/2009-January/005072.html

I use blf since then. I hear the first time FreeBSD is supporting
SHA256 and SHA512.


Oliver
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Mark Felder]

On Fri, 08 Jun 2012 07:51:55 -0500, Dag-Erling Smørgrav d...@des.no wrote:


We still have MD5 as our default password hash, even though known-hash
attacks against MD5 are relatively easy these days.  We've supported
SHA256 and SHA512 for many years now, so how about making SHA512 the
default instead of MD5, like on most Linux distributions?

Index: etc/login.conf
===
--- etc/login.conf  (revision 236616)
+++ etc/login.conf  (working copy)
@@ -23,7 +23,7 @@
 # AND SEMANTICS'' section of getcap(3) for more escape sequences).

 default:\
-   :passwd_format=md5:\
+   :passwd_format=sha512:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

DES



I strongly support this -- using either SHA-2 or Blowfish would be a great  
step forward. You'll also want to change the defuault for auth.conf so  
adduser picks it up.



#
# $FreeBSD: releng/9.0/etc/auth.conf 118103 2003-07-28 02:28:51Z rwatson $
#
# Configure some authentication-related defaults.  This file is being
# gradually subsumed by user class and PAM configuration.
#

# crypt_default =   md5 des
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[RW]

On Fri, 08 Jun 2012 14:51:55 +0200
Dag-Erling Smørgrav wrote:

 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  

Are any of those attacks relevant to salted passwords even with a
single MD5 hash, let alone FreeBSD's complicated iterative algorithm? 
 
  We've supported SHA256 and SHA512 for many years now, so how about
 making SHA512 the default instead of MD5, like on most Linux
 distributions?

I think the most important consideration is which is most resistant to
brute force dictionary attack with GPUs. From a quick look at the code
SHA512 looks to have 5000 rounds compared to MD5's 1000, but it's not
so easy to compare with Blowfish. 
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Ruud Althuizen]

On Fri 08 Jun 2012 05:47 PM, RW wrote:
 On Fri, 08 Jun 2012 14:51:55 +0200
 Dag-Erling Smørgrav wrote:
 
  We still have MD5 as our default password hash, even though known-hash
  attacks against MD5 are relatively easy these days.  
 
 Are any of those attacks relevant to salted passwords even with a
 single MD5 hash, let alone FreeBSD's complicated iterative algorithm? 
Complication isn't your friend when considering cryptography.

-- 
With kind regards,
Ruud Althuizen


pgprSKXCr282x.pgp
Description: PGP signature

Re: Default password hash

[Poul-Henning Kamp]

In message 20120608172857.ge2...@stack.nl, Ruud Althuizen writes:

Complication isn't your friend when considering cryptography.

Sorry, it's a one way relationship, and its the other way around:

If it is cryptography, it is complicated.

But it can be complicated without being cryptography.

-- 
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.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Brett Glass]

One thing to consider -- given the nature of the recent attack on LinkedIn --
is to provide a setting that allows one to increase the size of the salt.
The main danger, when a file of hashed passwords is stolen (as was the case
with LinkedIn), is that an attacker can use a pre-computed dictionary to
break accounts with weak or commonly used passwords. The larger the salt,
the more impractical it becomes to prepare or store such a dictionary.
This can matter more than the strength or computational burden of the
hashing algorithm.

--Brett Glass

At 06:51 AM 6/8/2012, Dag-Erling Smørgrav wrote:


We still have MD5 as our default password hash, even though known-hash
attacks against MD5 are relatively easy these days.  We've supported
SHA256 and SHA512 for many years now, so how about making SHA512 the
default instead of MD5, like on most Linux distributions?

Index: etc/login.conf
===
--- etc/login.conf  (revision 236616)
+++ etc/login.conf  (working copy)
@@ -23,7 +23,7 @@
 # AND SEMANTICS'' section of getcap(3) for more escape sequences).

 default:\
-   :passwd_format=md5:\
+   :passwd_format=sha512:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2433/5055 - Release Date: 06/07/12


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: Default password hash

[Robert Simmons]

On Fri, Jun 8, 2012 at 9:06 AM, Maxim Khitrov m...@mxcrypt.com wrote:
 On Fri, Jun 8, 2012 at 8:51 AM, Dag-Erling Smørgrav d...@des.no wrote:
 We still have MD5 as our default password hash, even though known-hash
 attacks against MD5 are relatively easy these days.  We've supported
 SHA256 and SHA512 for many years now, so how about making SHA512 the
 default instead of MD5, like on most Linux distributions?

 If SHA-2 hashes have been supported for many years, why haven't the
 man pages been updated? login.conf(5) on 9.0-RELEASE still only lists
 des, md5, and blf. I've been using the latter on my systems.

Yes, I think at least listing all the supported algorithms in the
login.conf man page is of utmost importance.  I've been using blowfish
since it was introduced to FreeBSD over 12 years ago, but I had no
idea that any other algorithms were possible/available until now.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org