These values have not marched forward with the progress of time.  For 
perspective, the last increase in bcrypt rounds was around the time we 
considered Monica Lewinsky a big scandal.

If processing power really doubles every 2 years, we should 
increase by 6, but that means 5 second root logins even on a fast 
machine.  I know I know, no pain no gain, but let's build up our atrophied 
muscles slowly.  Increasing by 3 also means root goes to 11.

Slow machines will, of course, get slower, but:
	1.  You don't have to upgrade to the new numbers
	2.  You can dial down the pain if necessary
	3.  We can call the added delay "The Gawker Memorial Second"

Index: login.conf.in
===================================================================
RCS file: /home/tedu/cvs/src/etc/login.conf.in,v
retrieving revision 1.2
diff -u -r1.2 login.conf.in
--- login.conf.in	9 Jan 2007 10:20:12 -0000	1.2
+++ login.conf.in	16 Dec 2010 03:21:23 -0000
@@ -46,7 +46,7 @@
 	:maxproc-cur=@DEF_MAXPROC_CUR@:\
 	:openfiles-cur=@DEF_OPENFILES_CUR@:\
 	:stacksize-cur=4M:\
-	:localcipher=blowfish,6:\
+	:localcipher=blowfish,9:\
 	:ypcipher=old:\
 	:tc=auth-defaults:\
 	:tc=auth-ftp-defaults:
@@ -62,7 +62,7 @@
 	:maxproc=infinity:\
 	:openfiles-cur=128:\
 	:stacksize-cur=8M:\
-	:localcipher=blowfish,8:\
+	:localcipher=blowfish,11:\
 	:tc=default:
 
 #

[ message continues ]

OK, so let's table what the right values and just make the values 
configurable.  Then we can discuss moving up (or even down).

Index: login.conf.in
===================================================================
RCS file: /home/tedu/cvs/src/etc/login.conf.in,v
retrieving revision 1.2
diff -u -r1.2 login.conf.in
--- login.conf.in	9 Jan 2007 10:20:12 -0000	1.2
+++ login.conf.in	16 Dec 2010 04:28:42 -0000
@@ -46,7 +46,7 @@
 	:maxproc-cur=@DEF_MAXPROC_CUR@:\
 	:openfiles-cur=@DEF_OPENFILES_CUR@:\
 	:stacksize-cur=4M:\
-	:localcipher=blowfish,6:\
+	:localcipher=blowfish,@DEF_BLOWFISH_RNDS@:\
 	:ypcipher=old:\
 	:tc=auth-defaults:\
 	:tc=auth-ftp-defaults:
@@ -62,7 +62,7 @@
 	:maxproc=infinity:\
 	:openfiles-cur=128:\
 	:stacksize-cur=8M:\
-	:localcipher=blowfish,8:\
+	:localcipher=blowfish,@ROOT_BLOWFISH_RNDS@:\
 	:tc=default:
 
 #
Index: mklogin.conf
===================================================================
RCS file: /home/tedu/cvs/src/etc/mklogin.conf,v
retrieving revision 1.4
diff -u -r1.4 mklogin.conf
--- mklogin.conf	24 Mar 2009 20:34:51 -0000	1.4
+++ mklogin.conf	16 Dec 2010 04:30:28 -0000
@@ -19,6 +19,8 @@
 	values["STAFF_MAXPROC_MAX"]="512"
 	values["STAFF_MAXPROC_CUR"]="128"
 	values["STAFF_OPENFILES_CUR"]="128"
+	values["DEF_BLOWFISH_RNDS"]="6"
+	values["ROOT_BLOWFISH_RNDS"]="8"
 
 	# Optional overrides
 	if (ARGC > 1) {

[ message continues ]

I don't mind this if the eventual goal is to think about diddling with
it per arch..

I certainly do NOT want a 2^11 blowfish password when logging into my sparc



[ message continues ]

Why not? An attacker can, after all, brute-force your password on a
machine of his choice. Silently decreasing the number of rounds on older
architectures surprises the user in a way that can lead to password
compromise ("My password was brute-forced because I used it on a sparc?!
I would have been fine on amd64? Huh? What happened to 'secure by
default'?!")

One *could* consider using a memory- instead of CPU-bound function to
calculate the password hash. Since, historically, memory access times
have increased less than effective CPU speeds, this may give decent
security without penalizing old machines quite as much.

Colin Percival (FreeBSD security officer) has proposed scrypt
(security/scrypt; BSD license), which is supposed to be both memory- and
CPU-bound. Perhaps you could do some test runs on your sparc to see if
the above theory actually holds up? (Leaving open the question of
whether OpenBSD should switch - bcrypt *is* more battle-tested.)

FWIW, I've used 2^10 rounds for years and never had any problems. Then
again, I've only used machines made in the last 10 years...

		Joachim

[ message continues ]

On Thu, Dec 16, 2010 at 4:35 AM, Joachim Schipper

At some point, you won't be able to compute the hash before the login
timeout of 5 minutes expires.  Hopefully, the people using old
machines are using them for fun, not in a setting where master.passwd
is likely to be stolen.

That's really what it's about.  Is your machine likely to have the
passwd file stolen and are the accounts and passwords in that file
worth cracking?

[ message continues ]

And that is exactly my point.  By your logic let's switch you to a
2^25 round blowfish on you dumbass. you'd be incredibly secure.

Show me colin percivals' peer reviewed paper about this new scheme,
and where it has been compared to bcrypt.  then go read neil's paper
on the subject please.

[ message continues ]

My message was too emotional, and for that I apologize. Sorry.

I share your concern for the newness of scrypt, and in fact I edited out
a sentence to that effect. With respect to the paper: are you talking
about "A Future-Adaptable Password Scheme" by Niels Provos and David
Mazihres? If not, my Google-fu failed me and I would, honestly,
appreciate a pointer to said paper.

		Joachim

[ message continues ]

Curse you gmail.  CC tech this time


[ message continues ]

I was about to do the same and do some measurements to back my
words up, but got distracted.  I'm strongly in a favor of
increasing number of rounds at least to 2^8.  Solar Designer
uses this number of rounds in Openwall for quite some time now.


[ message continues ]

I don't have a problem with doing this for modern arch's  doing it at
the expense of the old stuff is silly.

and the old stuff is important. it finds bugs that keep you all secure.

[ message continues ]