Subject: [OAUTH-WG] Request for proposals on bootstrapping usernames

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 00:55:53 -0700

The reason why I got interested in bringing this work to the IETF to begin with was to try and use it to solve the problems with HTTP Basic auth. It is clear that at this point Digest is not likely to win wide adoption and the simplicity of Basic trumps most other considerations. I am looking for a way to allow clients to use existing usernames and password, by defining a token class that uses these credentials to bootstrap and provide clients with a set of token credentials they already have.

I was (easily) convinced that using passwords as HMAC keys is a bad idea because it will require servers to store passwords in the clear which even Basic does not require them. However, I think it is worth trying to find ideas on how to use existing usernames with the new token scheme that will replace Basic auth in the most common use cases.

This is currently not an explicit item of the WG, but we are allowed to include such a token class in our '2-legged' proposal.

Comments?

EHL

---

From: Ethan Jewett <[email-masked]>
Date: Sun, 6 Dec 2009 12:18:54 -0600

I would like to understand what advantages this approach has over
Basic with a secure connection.

I think the major downside to providing this type of bootstrapping
method is that there is no way for a user to verify that the client is
behaving well with regards to their username/password combination.
Once you give your username/password to a client that is a bad actor,
the game is up. A lot of work has been done trying to eradicate the
so-called "password anti-pattern" and there is a lot of work left to
do. It seems that this approach would be going backwards.

That said, there are always tradeoffs, so outlining the pluses and
minuses should probably be done thoroughly before coming to a
decision.

Ethan

On Sun, Dec 6, 2009 at 1:55 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 11:43:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ethan Jewett
> Sent: Sunday, December 06, 2009 10:19 AM
> To: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping
> usernames
> 
> I would like to understand what advantages this approach has over Basic with
> a secure connection.

First, it doesn't require a secure connection. But a secure connection doesn't solve phishing and other problems. If there was a way for me to give my credentials to an application I trust (like my browser) which will then authenticate me without sending my password, but still use my password to authenticate, authenticating against attackers will not help them much beyond being able to make that one request on their own.

EHL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 6 Dec 2009 13:44:45 -0500

The problem with solving Basic Auth is that patent trolls are sitting
on the technologies you would want to use instead.

I absolutely disagree with the idea that storing the password en-clair
makes Digest less satisfactory than Basic. Intercepting passwords on
the wire is a trivial issue, if the attacker can compromise the
password database on a server then they can bypass any other access
control and get whatever they want in any case. This argument was dead
and burried in the early 1990s when crack came out and even the most
ideological UNIX fanboy had to finally admit that shadow passwords
were essential.

I know the arguments made in the UNIX manual. THEY ARE WRONG. They
were somewhat accurate when they were written forty years ago. At this
point the argument about the salt and so on are utterly ridiculous,
wrong and dangerous. The fact is that well over 95% of passwords will
be found in a dictionary of a million passwords. Forcing users to add
non-alphabetic characters or to use capitalization results in a
trivial increase in the work factor.

The problem with DIGEST is that there is not enough ergodicity in the
proof of possession blob passed over the wire. So DIGEST is now
vulnerable to all the same attacks that can be performed against a
password file.

There is no way to fix that without using public key cryptography.
DIGEST was designed to give the best security possible without using
encumbered technology.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 12:12:29 -0700

It's very likely that this goal is overreaching and impractical within the scope of this WG. I just want to give it a brief consideration.

EHL

> From: Ethan Jewett [mailto:[email-masked]]
> Sent: Sunday, December 06, 2009 11:10 AM
> To: Eran Hammer-Lahav
> In that case, I think I misunderstand the proposal. I'll wait for the discussion
> to fill out before I comment further.
> 
> Thanks,
> Ethan
> 
> On Sun, Dec 6, 2009 at 12:43 PM, Eran Hammer-Lahav
> <[email-masked]> wrote:
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Ethan Jewett
> > First, it doesn't require a secure connection. But a secure connection
> doesn't solve phishing and other problems. If there was a way for me to give
> my credentials to an application I trust (like my browser) which will then
> authenticate me without sending my password, but still use my password to
> authenticate, authenticating against attackers will not help them much
> beyond being able to make that one request on their own.
> >
> > EHL
> >
> >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 6 Dec 2009 15:14:30 -0500

That was the original objective of DIGEST, even if there is a phishing
attack the password itself is not disclosed, only a hash of the
password.

I did warn people at the time that BASIC was a bad idea.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 6 Dec 2009 13:29:44 -0700

The main implementation issue I hear about DIGEST is the multi-request requirement. Because OAuth 1.0 flipped that (by making the client issue the nonce, etc.) it is more appealing to developers. I don't know if trying to directly fix Basic is a practical/good idea. People seem to have very strong feeling about it.

EHL

> From: Phillip Hallam-Baker [mailto:[email-masked]]
> Sent: Sunday, December 06, 2009 12:15 PM
> To: Eran Hammer-Lahav
> Cc: Ethan Jewett; OAuth WG ([email-masked])
> That was the original objective of DIGEST, even if there is a phishing attack
> the password itself is not disclosed, only a hash of the password.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Dec 2009 10:35:19 +0000

> on the technologies you would want to use instead.

So I wonder if anyone would be interested in an EKE based scheme?
I mean interested enough that it'd get deployed. The timing might
be good for that now.

S.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 8 Dec 2009 00:19:11 +1100

> I mean interested enough that it'd get deployed. The timing might

SRP (Secure Remote Password) has been specified to work with TLS in RFC 5054 [note: no client or server certificates required].
This classifies as an EKE based scheme doesn't it?

SRP in TLS secures a connection using a password. It uses a handshake consisting of a few round trips to work. It is not suitable for protecting a standalone request.

For protecting a standalone request, without any challenge from the server, the best you can do it run a password-based key derivation function (PBKDF) (running a hash algorithm for many thousands of iterations) then use the resulting key to calculate a MAC over the request.

I think the password-protection feature in the latest versions of Microsoft Office do about as good a job as is possible for the standalone request scenario (which is basically the same scenario as protecting a standalone file). I can't remember exactly which PBKDF they use or how many iterations -- but was many, many orders of magnitude better than earlier (2003?) versions.

-- 
James Manger

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 07 Dec 2009 10:15:28 -0500

Well, I was about to propose this, but Stephen beat me!

Yes, I think that EKE is one way of getting there, and I wanted to add 
for a consideration a protocol from the same family, PAK, that has been 
deployed (as part of Inferno and Plan 9 operating systems in Open 
Source) and standardized by 3GPP2 and ITU-T.  We have described it in 
the IETF RFC RFC 5683 (which was supposed to be published, but is 
waiting for some bureaucratic stamp beyond the IETF and RFC Editor 
reach). The final text is in 
http://tools.ietf.org/html/draft-brusilovsky-pak-10.

PAK  is using a password to 1) authenticate the D-H and 2) create a 
session key, based on the password.

Igor

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Dec 2009 15:56:18 +0000

> http://tools.ietf.org/html/draft-brusilovsky-pak-10.

...which references https://datatracker.ietf.org/ipr/1179/

Doing exactly EKE [1] (and no more) on the other hand may be
cleaner.

However, James' points are relevant - these protocols are not
really single shot, though might still fit a bunch of OAuth
use-cases for token acquisition since that will often involve
a couple of exchanges.

S.

[1] http://www.freepatentsonline.com/5241599.html

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Dec 2009 09:15:36 -0700

Any replacement to Basic auth we may consider for inclusion in the Token scheme must be a single request, and must be at a similar complexity level as the current Token proposal.

EHL

> Of Stephen Farrell
> Sent: Monday, December 07, 2009 7:56 AM
> To: [email-masked]
> Cc: Phillip Hallam-Baker; OAuth WG ([email-masked])
> > for a consideration a protocol from the same family, PAK, that has
> > been deployed (as part of Inferno and Plan 9 operating systems in Open
> Doing exactly EKE [1] (and no more) on the other hand may be cleaner.
> 
> However, James' points are relevant - these protocols are not really single
> shot, though might still fit a bunch of OAuth use-cases for token acquisition
> since that will often involve a couple of exchanges.
> 
> S.
> 
> >>> The problem with solving Basic Auth is that patent trolls are
> >>> sitting on the technologies you would want to use instead.
> >>>
> >>
> >> I mean interested enough that it'd get deployed. The timing might be
> >> good for that now.
> >>
> >> S.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Dec 2009 09:18:25 -0700

> Of Manger, James H
> Sent: Monday, December 07, 2009 5:19 AM

> For protecting a standalone request, without any challenge from the server,
> the best you can do it run a password-based key derivation function (PBKDF)
> (running a hash algorithm for many thousands of iterations) then use the
> resulting key to calculate a MAC over the request.

Is there a spec to reference for this? Also, does this require storing passwords in the clear on the server?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Dec 2009 16:38:34 -0700

This means servers using a salt/hash today to store their users' passwords will have to provide that to the client in order to make this work (which takes away the ability to make this work without a challenge).

So while this looks like an interesting idea, it won't work to bootstrap existing credentials in most servers.

EHL

> From: Manger, James H [mailto:[email-masked]]
> Sent: Monday, December 07, 2009 3:29 PM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: RE: [OAUTH-WG] Request for proposals on bootstrapping
> usernames
> 
> > Is there a spec to reference for this?
> 
> PBKDF2 (password-based key derivation function, version 2) is specified in
> PKCS #5 v2.0 and in RFC 2898 (same content, different format).
> Start at http://en.wikipedia.org/wiki/PBKDF2.
> It even defines a password-based MAC (PBMAC1).
> 
> I cannot remember (and cannot find) where password-based protection in
> Microsoft Office is detailed.
> 
> 
> > Also, does this require storing passwords in the clear on the server?
> 
> No. The server can always encrypted any of its own data however it wants.
> Decryption (with a key on the server) will reveal the passwords in the clear.
> 
> If you need to avoid any round trip (ie want a standalone authentic request)
> then I think it is fundamentally impossible for the server not to have access
> to the "password" in the clear.
> 
> Of course the server can store a hash of the password (& username), and the
> client can use the same hash as the shared secret. DIGEST does this
> (including the realm as well). The password is not in the clear, but the hash is
> in the clear and an attacker only needs the hash to masquerade as the client.
> This is worth doing (an attacker cannot reuse the hash at another site where
> the user uses the same password), but doesn't really improve the security of
> the site itself.
> 
> 
> --
> James Manger

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 07 Dec 2009 17:05:03 -0800

On Sun, 2009-12-06 at 00:55 -0700, Eran Hammer-Lahav wrote:

> The reason why I got interested in bringing this work to the IETF to
> begin with was to try and use it to solve the problems with HTTP Basic
> auth. It is clear that at this point Digest is not likely to win wide
> adoption and the simplicity of Basic trumps most other considerations.
> I am looking for a way to allow clients to use existing usernames and
> password, by defining a token class that uses these credentials to
> bootstrap and provide clients with a set of token credentials they
> already have.
> 
> I was (easily) convinced that using passwords as HMAC keys is a bad
> idea because it will require servers to store passwords in the clear
> which even Basic does not require them. However, I think it is worth
> trying to find ideas on how to use existing usernames with the new
> token scheme that will replace Basic auth in the most common use
> cases.
> 
> This is currently not an explicit item of the WG, but we are allowed
> to include such a token class in our '2-legged' proposal.
> 
> Comments?

Whatever is proposed, I presume needs to cope with the way passwords are
stored on the server; usually not in cleartext. I think this is one of
the significant factors in the lack of adoption in Digest
authentication, as most servers don't/can't store H(A1) in their
databases.

So if my logic stands, to meet the objective, I think boils down to
either the password being sent in the clear (HTTP Basic) or being
encrypted using a symmetric key that's negotiated between server and
client (or asymmetric key, identified, certified and validated somehow).

If work is put into negotiating a symmetric key to use to transmit
passwords, it seems on the same order of effort to simply authenticate
and receive a token in return. In other words, doesn't "2-legged" OAuth
meet this objective?

Paul

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 8 Dec 2009 14:30:59 +1100

> This means servers using a salt/hash today to store their users'
> passwords will have to provide that to the client in order to make this
> work (which takes away the ability to make this work without a
> challenge).
> 
> So while this looks like an interesting idea, it won't work to
> bootstrap existing credentials in most servers.

I think what you are asking for is theoretically impossible. Given a user-id & password:
1. Authenticate a standalone request (with no real-time data from the server first);
2. Don't send the password in the clear;
3. The server can use an existing password database that stores salted password hashes.

If you don't drop 3, either the salt has to be sent to the client (violating #1), or the password has to be sent in the clear so the server can redo the hash to compare (violating #2).

If you drop 1, you can use password-authenticated key agreement schemes (such as EKE, SRP, PAK...; see http://en.wikipedia.org/wiki/Password-authenticated_key_agreement). These are the ultimate password-based protocols (in practise and in theory). An attacker can only make 1 password guess per run of the protocol -- they cannot perform an off-line dictionary attack. These algorithms use the maths of public-key crypto. Patent issues have often clouded the use of these algorithms [I know nothing about the patent issues]. A TLS-layer spec exists [RFC 5054]. I guess an HTTP-layer version could be defined, but I am not sure it could adds enough value over the TLS-layer spec.

If you drop 2, you have BASIC.

If you drop 3, you can use PBKDF2 with a nonce/timestamp chosen by client as a salt (probably adding the user-id, algorithm names etc into the salt as well), a huge number of iterations of a hash algorithm (eg chosen so the computation takes ~1 second), then use the result as a MAC key. The "password" input to PBKDF2 can actually be hash(password||userid). The server needs access to this hash in the clear. An attacker compromising the server's account database can use hash(password||userid) to login as the user (without knowing the password).

P.S. The following blog post (and various other posts in the same blog) has details about the password-based security in Office 2007 (and updates).
It uses a slight variation on PBKDF1: with 100,000 iterations of SHA-1 by default.
http://blogs.msdn.com/david_leblanc/archive/2008/12/04/new-improved-office-crypto.aspx 

-- 
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 8 Dec 2009 10:29:17 +1100

I cannot remember (and cannot find) where password-based protection in Microsoft Office is detailed.

If you need to avoid any round trip (ie want a standalone authentic request) then I think it is fundamentally impossible for the server not to have access to the "password" in the clear.

Of course the server can store a hash of the password (& username), and the client can use the same hash as the shared secret. DIGEST does this (including the realm as well). The password is not in the clear, but the hash is in the clear and an attacker only needs the hash to masquerade as the client. This is worth doing (an attacker cannot reuse the hash at another site where the user uses the same password), but doesn't really improve the security of the site itself.

-- 
James Manger

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Dec 2009 08:42:06 +0000

> If you drop 3, you can use PBKDF2 with a nonce/timestamp chosen by client as a salt (probably adding the user-id, algorithm names etc into the salt as well), a huge number of iterations of a hash a…

What about a Schnorr signature?

Use it to sign a timestamp+nonce. If the server and client are
synchronised (ish), you can do it in one round trip. If they are not,
the server responds with an error and a time offset, the client tries
again, and we're done.

That gives you 1, 2 and 3, and also the better property that new
passwords can be stored as g^x at the server instead of x, and so the
server doesn't have a password equivalent.

Replays are possible for a short time, if the server doesn't want to
(or can't) store used timestamps+nonces. If it does want to, then no
replay is possible.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 9 Dec 2009 23:25:38 +1100

> > 1. Authenticate a standalone request
> >    (with no real-time data from the server first);
...
> > If you drop 3, you can use PBKDF2... than a MAC

> ...

I don't know much about Schnorr signatures.

I am sure they cannot satisfy #3: ie you have an existing DB of hashed salted passwords (used to, say, verify web-form logins), then try to deploy Schnorr signatures.

It looks like a server could create a DB without password equivalents when passwords are established, which is an advantage.

I believe an eavesdropper can perform an off-line dictionary attack if they see a Schnorr signature. Hence, it does not provide the security benefits of a password-authenticated key agreement scheme.

Presumably you still need to run, say, PBKDF2 to (slowly) convert a password to a key used in the Schnorr signature.

I would be reluctant to replace a MAC (eg HMAC) with a Schnorr signature as I have seen so much more use of the former than the latter. 

-- 
James Manger

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Dec 2009 15:51:50 +0000

> I am sure they cannot satisfy #3: ie you have an existing DB of hashed salted passwords (used to, say, verify web-form logins), then try to deploy Schnorr signatures.

Why are you sure of that? Seems easy to me (x is the hashed password,
server can derive g^x from it).

> I believe an eavesdropper can perform an off-line dictionary attack if they see a Schnorr signature. Hence, it does not provide the security benefits of a password-authenticated key agreement schem…

I think you are wrong - I believe the attacker would have to know g^x
to perform an offline attack. Although this is described as a public
key, there's no need to make it public.

> I would be reluctant to replace a MAC (eg HMAC) with a Schnorr signature as I have seen so much more use of the former than the latter.

Presumably because Schnorr signatures only recently came out of patent.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 09 Dec 2009 08:31:48 -0800

> server can derive g^x from it).

For my own edification:

If x (private key) is just the existing salted hash in the database and
y (public key) is simply g^x, presumably:

a) The client needs to (somehow) be supplied y by the server—it can't be
derived from the password because the client doesn't know what hashing
algorithm the server used (nor the salt) to represent it the database.
If true, doesn't this violate point 1 above?

b) I'm wondering whether it would be acceptable to expose y (even if
just to the client who would presumably already know the password in
plaintext), given that x can easily be derived from it? This may be just
more paranoia on my part than realistic concern.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Dec 2009 16:35:05 +0000

> If true, doesn't this violate point 1 above?

The client would need to be supplied the hashing algorithm, not y
(being supplied y wouldn't help, anyway).

> more paranoia on my part than realistic concern.

x cannot be easily derived from it, this is the discrete log problem,
which is assumed hard.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 09 Dec 2009 08:39:54 -0800

> (being supplied y wouldn't help, anyway).

Okay, sorry, I had the parties reversed, right client doesn't need y. It
needs x.

So, to have x, client would need to know: what hashing algorithm server
used to store it in the database, and what salt was used?

This still doesn't seem to avoid violating point 1.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Dec 2009 16:45:16 +0000

> This still doesn't seem to avoid violating point 1.

You are right, you have to violate either 1 or 3, still. Not sure why
3 is a requirement, though (or, at least, why one can't violate 1 in
order to support 3 for transition, so long as after the transition 1
is not violated).

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 10 Dec 2009 12:18:24 +1100

James said:
>> I believe an eavesdropper can perform an off-line dictionary attack
>> if they see a Schnorr signature. Hence, it does not provide the
>> security benefits of a password-authenticated key agreement scheme.

> key, there's no need to make it public.

g is public (same for all users).
x is either:
- a password - which the attacker can guess;
- PBKDF2(password) - which the attacker can calc from a password guess;
- H(salt|password) - which the attacker can calc from a password guess as the salt was sent from the server to the client in the clear.

Hence an attacker trying a dictionary of passwords, can calculate x for each password guess, then use that to try to verify a Schnorr signature -- all off-line.
Isn't there a fundamental reason why SRP, PAKE, J-PAKE etc all need more round-trips to avoid off-line attacks?

The one advantage of PBKDF2+Schnorr over PBKDF2+MAC seems to be that the server can avoid storing a password equivalent.
A disadvantage is that the client needs to know the common parameters (g and q) that the server uses, plus the PBKDF2 per-user parameters (iteration count, salt) -- not just the algorithms. Perhaps the PBKDF2 parameters could be per-server, but that compromises its benefits.

Neither this advantage nor disadvantage is crucial (eg they are not as important as eliminating off-line dictionary attacks, for instance).

My gut feeling is that PBKDF2+MAC is better in practise. It supports client-chosen PBKDF2 salt and iteration count values (that can vary by device and CPU power) to make off-line dictionary attacks awkward, without requiring user-specific knowledge from the server.

--
James Manger

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Dec 2009 09:48:54 +0000

> Isn't there a fundamental reason why SRP, PAKE, J-PAKE etc all need more round-trips to avoid off-line attacks?

Yeah. I should try to get over jetlag before I think about crypto :-)

> My gut feeling is that PBKDF2+MAC is better in practise. It supports client-chosen PBKDF2 salt and iteration count values (that can vary by device and CPU power) to make off-line dictionary attacks…

Neither of these are different to PBKDF2+Schnorr, AFAICS, so why is it better?

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 14 Dec 2009 11:40:31 +1100

I said:
> > The one advantage of PBKDF2+Schnorr over PBKDF2+MAC seems to be that
> > the server can avoid storing a password equivalent.
> >
> > A disadvantage is that the client needs to know the common parameters
> > (g and q) that the server uses, plus the PBKDF2 per-user parameters
> > (iteration count, salt) -- not just the algorithms.
> > Perhaps the PBKDF2 parameters could be per-server,
> > but that compromises its benefits.
> >
> > Neither this advantage nor disadvantage is crucial (eg they are
> > not as important as eliminating off-line dictionary attacks, for instance).
> >
> > My gut feeling is that PBKDF2+MAC is better in practise.
> > It supports client-chosen PBKDF2 salt and iteration count values
> > (that can vary by device and CPU power)
> > to make off-line dictionary attacks awkward,
> > without requiring user-specific knowledge from the server.

> Neither of these are different to PBKDF2+Schnorr, AFAICS, so why is it

A client cannot choose an iteration count of 8000 one day, and 9000 the next day if the server has stored g^PKBDF2(password,salt,iterations) to avoid having a password equivalent. The salt and iteration count are fixed for a given password verifier.

If instead a server stores the password in the clear, then a client gets the security advantage of choosing a random salt and dynamically choosing an iteration count in each login for PBKDF2+MAC or PBKDF2+Schnorr.

The only reason MAC is better than Schnorr in this case is that I am more familiar with MACs (eg there are more implementations, APIs, security analysis etc). In this case Schnorr offers no advantages so I would prefer to avoid its use of public key crypto. I have never heard of using PBKDF2 with Schnorr before this thread so I am not totally confident it is as secure as I assume.

--
James Manger

---

From: Ben Laurie <[email-masked]>
Date: Thu, 17 Dec 2009 16:27:07 +0000

On Mon, Dec 14, 2009 at 12:40 AM, Manger, James H <
[email-masked]> wrote:

> A client cannot choose an iteration count of 8000 one day, and 9000 the
> next day if the server has stored g^PKBDF2(password,salt,iterations) to
> avoid having a password equivalent. The salt and iteration count are fixed
> for a given password verifier.
>
> If instead a server stores the password in the clear, then a client gets
> the security advantage of choosing a random salt and dynamically choosing an
> iteration count in each login for PBKDF2+MAC or PBKDF2+Schnorr.
>
> The only reason MAC is better than Schnorr in this case is that I am more
> familiar with MACs (eg there are more implementations, APIs, security
> analysis etc). In this case Schnorr offers no advantages so I would prefer
> to avoid its use of public key crypto. I have never heard of using PBKDF2
> with Schnorr before this thread so I am not totally confident it is as
> secure as I assume.
>

If you have as a design requirement that the server should store a password
in the clear, then indeed there's no advantage to Schnorr. I thought no-one
wanted to store passwords in the clear anymore, though.

---

From: Chris Messina <[email-masked]>
Date: Fri, 18 Dec 2009 18:00:56 -0800

> wanted to store passwords in the clear anymore, though.
...and yet apparently they still do:

http://www.techcrunch.com/2009/12/14/rockyou-hack-security-myspace-facebook-passwords/

Sigh.

-- 
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private