slower logins

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

slower logins

Ted Unangst-2
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:
 
 #

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Ted Unangst-2
On Wed, 15 Dec 2010, Ted Unangst wrote:

> 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.

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) {

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Bob Beck-4
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


On 15 December 2010 21:33, Ted Unangst <[hidden email]> wrote:

> On Wed, 15 Dec 2010, Ted Unangst wrote:
>
>> 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.
>
> 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) {

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Joachim Schipper-2
On Wed, Dec 15, 2010 at 09:42:52PM -0700, Bob Beck wrote:
> I don't mind [increasing the number of Blowfish rounds] 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

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

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Mike Belopuhov
In reply to this post by Bob Beck-4
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.

On Thu, Dec 16, 2010 at 5:42 AM, Bob Beck <[hidden email]> wrote:

> 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
>
>
> On 15 December 2010 21:33, Ted Unangst <[hidden email]> wrote:
>> On Wed, 15 Dec 2010, Ted Unangst wrote:
>>
>>> 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.
>>
>> OK, so let's table what the right values and just make the values
>> configurable.  Then we can discuss moving up (or even down).

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Ted Unangst-2
In reply to this post by Joachim Schipper-2
On Thu, Dec 16, 2010 at 4:35 AM, Joachim Schipper
<[hidden email]> wrote:

> On Wed, Dec 15, 2010 at 09:42:52PM -0700, Bob Beck wrote:
>> I don't mind [increasing the number of Blowfish rounds] 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
>
> 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'?!")

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?

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Bob Beck-4
In reply to this post by Joachim Schipper-2
> 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'?!")

> .. and I only use new machines...

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.

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Bob Beck-4
In reply to this post by Mike Belopuhov
On 16 December 2010 05:38, Mike Belopuhov <[hidden email]> wrote:
> 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.

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.

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Joachim Schipper-2
In reply to this post by Bob Beck-4
On Thu, Dec 16, 2010 at 08:14:06AM -0700, Bob Beck wrote:

> > 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'?!")
>
> > .. and I only use new machines...
>
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: slower logins

Ted Unangst-2
In reply to this post by Bob Beck-4
Curse you gmail.  CC tech this time

On Thu, Dec 16, 2010 at 11:39 AM, Ted Unangst <[hidden email]> wrote:

> On Thu, Dec 16, 2010 at 10:14 AM, Bob Beck <[hidden email]> wrote:
>> 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.
>
> http://www.tarsnap.com/scrypt.html
>
> It's definitely a continuation of bcrypt.  Colin is not unaware of
> prior art.  The theory behind scrypt is not crazy, but I think it's
> definite overkill for password hashes.
>
> I use scrypt to encrypt a few special files.  It's good for key
> generation when the stuff being protected is more valuable than just a
> password (like a file containing all my passwords).