Subject: [http-auth] HTTP Digest - A1 with Salted Hash

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 26 Mar 2015 16:02:13 -0500

Hi,

The TRAM WG is working on a new document to update the Session Traversal
Utilities for NAT (STUN) protocol.

The STUNbis document is looking to align with what's in the HTTP Digest
draft
but interested in having the ability to add a salt to the calculation of A1.

Questions:
1. Is this covered by the current charter?
2. Can we update the current HTTP Digest draft to cover this request?
3. If the answer to question 2 is that it is too late, can this be done by
   a new draft that updates the HTTP Digest draft?

Hopefully we can get a minute or two to talk about this during the HTTPAuth
meeting later today.

Regards,
 Rifaat

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Mar 2015 19:39:31 -0500

Hi

Having talked this over with Rifaat and Yaron after the meeting, I think I understand the use case. Digest as it is today requires the password database to be in the clear.

We’ve been telling people for years to salt and hash the password database at rest, but if the server has access to a salted and hashed database, the protocol must convey the cleartext password, the way Basic does. By adding a salted hash to Digest, we allow the client to pre-process the password to what the server is holding, and then perform the digest processing.

The benefit to security is not in making Digest more secure, but in eliminating the choice between the relatively secure Digest and a salted and hashed database. With this there is no longer a downside to salting and hashing the database.

Yoav

> On Mar 26, 2015, at 4:02 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> Hi,
> 
> The STUNbis document is looking to align with what's in the HTTP Digest draft

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 27 Mar 2015 13:05:47 +0900

Dear Yoav and Rifaat,

I assume that the Rifaat's proposal intends to announce the
server-local salt in the protocol exchange, so that
clients can compute the proper value of salted A1. Is this true?

To my understanding, unfortunately, the server salt gives not
such a big difference in the usual user authentication setting
as Yoav mentioned in the mail thread.

The current Digest needs only A1 values for
both clients and servers to authenticate themselves.
The plain password ("passwd" in the spec) is not needed on either side.
The passwd in A1 is (in some sense) already _salted_ with the realm and the
username, so that the admins can not easily _look_ the password from the DB.
In fact, Apache already stores a A1 value, instead of the plain passwd,
in the server-side password database.

Unfortunately, this means that when the server leaks the A1 value by
an accident, the client can use that value for authentication,
even not knowing the plain passwd itself.  In this sense, A1 is
"password-equivalent" in the protocol.

By adding the random server salt to A1, the value will still serves as the
"password-equivalent" in the protocol level, unfortunately.
If the randomly-salted A1 is leaked, it can be used by attackers
to successfully log in to the server.

The small difference is when the attacker want to know the "plain passwd"
to be used in another situation (such as Basic authentication).
Now, the attacker must know the realm and the password along with A1.
If salt added, it must also know the salt value, which will be
easily acquired on-line during the authentication process.

In general, to gain the benefit of "salting with the random value",
the value of salt must be contained within the servers and
not told to the client side.  This is not the case for usual hash-based
authentication like Digest.

On 2015/03/27 9:39, Yoav Nir wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
-- 
Yutaka OIWA, Ph.D.
           Senior Researcher, Research Institute for Secure Systems (RISEC)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Sophie Bremer <[email-masked]>
Date: Fri, 27 Mar 2015 07:24:17 +0100

Hello,

we have only the hashed A1 in our database (AES protected) and I only see the requirement for plain passwords, if you change realm or username without user interaction or user notification.
If the user changes the username or realm, you are be able to request the plain password in the form and use it for the new A1.

Like Yutaka I do not see the value in an other salt, because it does not add significant value to security or ease.

Regards,
Sophie

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 27 Mar 2015 06:21:13 -0500

The motivation for this is to minimize the impact on the system in the case
of database compromise.

With the current model, if the database is compromised, the system must
changes all user passwords *and* it must changes the realm(s) in the
system, which impacts many network elements.

With the added salt and in the case of a database compromise the system can
keep using the existing realm(s) but only change the salt.

Regards,
 Rifaat

On Fri, Mar 27, 2015 at 1:24 AM, Sophie Bremer <[email-masked]
> wrote:

> Hello,
>
> we have only the hashed A1 in our database (AES protected) and I only see
> the requirement for plain passwords, if you change realm or username
> without user interaction or user notification.
> If the user changes the username or realm, you are be able to request the
> plain password in the form and use it for the new A1.
>
> Like Yutaka I do not see the value in an other salt, because it does not
> add significant value to security or ease.
>
> Regards,
> Sophie
>
> >> Having talked this over with Rifaat and Yaron after the meeting, I
> think I understand the use case. Digest as it is today requires the
> password database to be in the clear.
> >>
> >> We've been telling people for years to salt and hash the password
> database at rest, but if the server has access to a salted and hashed
> database, the protocol must convey the cleartext password, the way Basic
> does. By adding a salted hash to Digest, we allow the client to pre-process
> the password to what the server is holding, and then perform the digest
> processing.
> >>
> >> The benefit to security is not in making Digest more secure, but in
> eliminating the choice between the relatively secure Digest and a salted
> and hashed database. With this there is no longer a downside to salting and
> hashing the database.
> >>
> >> Yoav
> >>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 27 Mar 2015 10:43:39 -0500

I'm still not sure about the exact use case here. Are we talking about a 
"standard" password database, where passwords are stored salted and 
hashed by a PKKDF2 (or similar) process, with a per-user random salt? Is 
there an additional step of salting by public values?

Regardless, at a higher level, I think we have our threat model wrong. 
HTTP Digest, with or without salt, is vulnerable to a dictionary attack 
on the wire. This is arguably a higher risk than compromise of the 
entire password database. We need to get rid of Digest and replace it by 
an augmented PAKE, instead of trying to harden it.

And by the way, this can get complex quick. Are we using PBKDF2, Scrypt? 
What is the hash function? How is the salt encoded? These details are 
usually private to the implementation, and now will need to be encoded 
in the protocol for the client to use.

Thanks,
	Yaron

On 03/27/2015 06:21 AM, Rifaat Shekh-Yusef wrote:
> The motivation for this is to minimize the impact on the system in the
> case of database compromise.
>
> With the added salt and in the case of a database compromise the system
> can keep using the existing realm(s) but only change the salt.
>
> Regards,
>   Rifaat
>
>
> On Fri, Mar 27, 2015 at 1:24 AM, Sophie Bremer
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     we have only the hashed A1 in our database (AES protected) and I
>     only see the requirement for plain passwords, if you change realm or
>     username without user interaction or user notification.
>     If the user changes the username or realm, you are be able to
>     request the plain password in the form and use it for the new A1.
>
>     Like Yutaka I do not see the value in an other salt, because it does
>     not add significant value to security or ease.
>
>     Regards,
>     Sophie
>
>      >> Having talked this over with Rifaat and Yaron after the meeting,
>     I think I understand the use case. Digest as it is today requires
>     the password database to be in the clear.
>      >>
>      >> We’ve been telling people for years to salt and hash the
>     password database at rest, but if the server has access to a salted
>     and hashed database, the protocol must convey the cleartext
>     password, the way Basic does. By adding a salted hash to Digest, we
>     allow the client to pre-process the password to what the server is
>     holding, and then perform the digest processing.
>      >>
>      >> The benefit to security is not in making Digest more secure, but
>     in eliminating the choice between the relatively secure Digest and a
>     salted and hashed database. With this there is no longer a downside
>     to salting and hashing the database.
>      >>
>      >> Yoav
>      >>
>      >>> On Mar 26, 2015, at 4:02 PM, Rifaat Shekh-Yusef
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>>
>      >>> Hi,
>      >>>
>      >> [email-masked] <mailto:[email-masked]>
>      >                      Mail addresses: <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 27 Mar 2015 11:06:18 -0500

Yaron,

While I agree with you that we need a PAKE-based solution, as per our
discussion yesterday :), the proposal here is very simple and is trying to
address the database compromise case.

Today, the server stores the HA1 for the user, which is calculated as
follows: H(username:realm:password).
The new proposal is calling for calculating HA1 as follows:
H(username:realm:password:salt); the salt is per domain, not per user.
No PBKDF2, No Scrypt, ...

This is not trying to address security threats, but instead, as I mentioned
in my previous email, is trying to minimize the impact on the system in the
case of a database compromise.

Hope this better clarifies the proposal.

Regards,
 Rifaat

On Fri, Mar 27, 2015 at 10:43 AM, Yaron Sheffer <[email-masked]>
wrote:

> "standard" password database, where passwords are stored salted and hashed
> by a PKKDF2 (or similar) process, with a per-user random salt? Is there an
> additional step of salting by public values?
>
> HTTP Digest, with or without salt, is vulnerable to a dictionary attack on
> the wire. This is arguably a higher risk than compromise of the entire
> password database. We need to get rid of Digest and replace it by an
> augmented PAKE, instead of trying to harden it.
>
> usually private to the implementation, and now will need to be encoded in
> the protocol for the client to use.
>
> Thanks,
>         Yaron
>
>>      >> We've been telling people for years to salt and hash the

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 28 Mar 2015 03:01:25 +0900

Dear Rifaat and Yaron,

In my personal impression,

 * In general Web-based settings, this proposed technology
   does not give significant improvements on both security and
   usability. For browser users, it IS better to change the
   realm string upon DB compromise, so that clients will
   notice the incompatibility of credentials.

 * If the no-change of realm is important in regard to a
   specific use case (such as STUN), it should be
   expressed in the draft with the specific scenario.
   Given a specific non-Web scenario shown, we might be
   convinced of its usefulness in the real case.

 * However, if all users will change their passwords
   upon re-registration after DB compromise, we would not
   need salt to be changed. So, the effectiveness of adding
   salt is under assumption that users tend to
   re-register the accounts with the same plaintext password.

   In this case, it is strictly REQUIRED that
   the plain password is so complex that it cannot be
   recovered from the stolen A1 value by
   dictionary-based hash-reversal attacks.
   If it cannot be ensured in the operation,
   changing of the salt will not prevent DB-stealing attackers
   (having old A1 value) to compute new A1 value.

On 2015/03/28 1:06, Rifaat Shekh-Yusef wrote:
> Yaron,
> 
> While I agree with you that we need a PAKE-based solution, as per our discussion
> yesterday :), the proposal here is very simple and is trying to address the
> database compromise case.
> 
> Today, the server stores the HA1 for the user, which is calculated as follows:
> H(username:realm:password).
> This is not trying to address security threats, but instead, as I mentioned in
> my previous email, is trying to minimize the impact on the system in the case of
> a database compromise.
> 
> On Fri, Mar 27, 2015 at 10:43 AM, Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Regardless, at a higher level, I think we have our threat model wrong. HTTP
>     Digest, with or without salt, is vulnerable to a dictionary attack on the
>     wire. This is arguably a higher risk than compromise of the entire password
>     database. We need to get rid of Digest and replace it by an augmented PAKE,
>     instead of trying to harden it.
> 
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>             Hello,
> 
>             <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__> wrote:
>              >>>
>              >>> Hi,
>              >>>
>              >> _________________________________________________
>              >> http-auth mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>              >> https://www.ietf.org/mailman/__listinfo/http-auth
>         <https://www.ietf.org/mailman/listinfo/http-auth>
>              >>
>              > --
>              > Yutaka OIWA, Ph.D.
>         <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>,
>         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>              > _________________________________________________
>              > http-auth mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>              > https://www.ietf.org/mailman/__listinfo/http-auth
>         <https://www.ietf.org/mailman/listinfo/http-auth>
> 
> 
> 
> 
>         _________________________________________________
>         http-auth mailing list
>         https://www.ietf.org/mailman/__listinfo/http-auth
>         <https://www.ietf.org/mailman/listinfo/http-auth>
> 
> 
> 
>

---

From: Sophie Bremer <[email-masked]>
Date: Fri, 27 Mar 2015 19:06:33 +0100

Rifaat,

I still do not see the value in it. The salt per domain is not state of the art.
If you use salted passwords, you have to use a salt per entry to protect the plain password these days - and this is the case for A1 only. 

SHA2(password:salt) is cheap enough to break it with brute force in weeks, if the salt is not unique.
The problem with unique salts for passwords is, that you have to change Digest in a big way to support this.

So in the end "username:realm:password" is always more secure than "password:domainsalt", because the username is unique.

Regards,
Sophie

Am 27.03.2015 um 17:06 schrieb Rifaat Shekh-Yusef:

> Yaron,
> 
> While I agree with you that we need a PAKE-based solution, as per our discussion yesterday :), the proposal here is very simple and is trying to address the database compromise case.
> 
> Today, the server stores the HA1 for the user, which is calculated as follows: H(username:realm:password).
> The new proposal is calling for calculating HA1 as follows: H(username:realm:password:salt); the salt is per domain, not per user.
> This is not trying to address security threats, but instead, as I mentioned in my previous email, is trying to minimize the impact on the system in the case of a database compromise.
> 
> On Fri, Mar 27, 2015 at 10:43 AM, Yaron Sheffer <[email-masked]> wrote:
> I'm still not sure about the exact use case here. Are we talking about a "standard" password database, where passwords are stored salted and hashed by a PKKDF2 (or similar) process, with a per-user random salt? Is there an additional step of salting by public values?
> 
> Regardless, at a higher level, I think we have our threat model wrong. HTTP Digest, with or without salt, is vulnerable to a dictionary attack on the wire. This is arguably a higher risk than compromise of the entire password database. We need to get rid of Digest and replace it by an augmented PAKE, instead of trying to harden it.
> 
> And by the way, this can get complex quick. Are we using PBKDF2, Scrypt? What is the hash function? How is the salt encoded? These details are usually private to the implementation, and now will need to be encoded in the protocol for the client to use.
> 
> Thanks,
>         Yaron
>

---

From: Sophie Bremer <[email-masked]>
Date: Fri, 27 Mar 2015 19:19:13 +0100

Sorry, I have misunderstood the problem. Now I am neutral.

Regards,
Sophie

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 27 Mar 2015 15:57:09 -0500

Hi Rifaat,

Now I understand the scheme - thank you.

I still think we should not enhance Digest to support this type of 
databases. Both Digest itself and this hashing method are way behind the 
times, and we should push the industry forward instead of codifying 
insecure authentication methods.

Thanks,
	Yaron

On 03/27/2015 11:06 AM, Rifaat Shekh-Yusef wrote:
> discussion yesterday :), the proposal here is very simple and is trying
> to address the database compromise case.
>
> This is not trying to address security threats, but instead, as I
> mentioned in my previous email, is trying to minimize the impact on the
> system in the case of a database compromise.
>
>     I'm still not sure about the exact use case here. Are we talking
>     about a "standard" password database, where passwords are stored
>     salted and hashed by a PKKDF2 (or similar) process, with a per-user
>     random salt? Is there an additional step of salting by public values?
>
>     Regardless, at a higher level, I think we have our threat model
>     wrong. HTTP Digest, with or without salt, is vulnerable to a
>     dictionary attack on the wire. This is arguably a higher risk than
>     compromise of the entire password database. We need to get rid of
>     Digest and replace it by an augmented PAKE, instead of trying to
>     harden it.
>
>     And by the way, this can get complex quick. Are we using PBKDF2,
>     Scrypt? What is the hash function? How is the salt encoded? These
>     details are usually private to the implementation, and now will need
>     to be encoded in the protocol for the client to use.
>
>     Thanks,
>              Yaron
>
>               > The plain password ("passwd" in the spec) is not needed
>         on either
>              side.
>               > The passwd in A1 is (in some sense) already _salted_
>         with the
>              realm and the
>               > username, so that the admins can not easily _look_ the
>         password
>              from the DB.
>               > In fact, Apache already stores a A1 value, instead of
>         the plain
>              passwd,
>               > The small difference is when the attacker want to know
>         the "plain
>              passwd"
>               >>> The TRAM WG is working on a new document to update the
>         Session
>              Traversal
>               >>> The STUNbis document is looking to align with what's
>         in the
>              HTTP Digest draft
>               >>> 2. Can we update the current HTTP Digest draft to
>         cover this
>              request?
>               >>> 3. If the answer to question 2 is that it is too late,
>         can this
>              be done by
>               >>> Hopefully we can get a minute or two to talk about
>         this during
>              the HTTPAuth
>               >>> meeting later today.
>               >>
>               >>
>               > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139
>         8677 9BD2
>              4405 46B5]
>               >

---

From: Sophie Bremer <[email-masked]>
Date: Sat, 28 Mar 2015 07:20:19 +0100

Am 27.03.2015 um 20:56 schrieb Yoav Nir:

> Cool! Can you explain it on-list, because I’m not sure that I understand...

Okay. If we assume that all users are lazy and we like to support there ease, we may have a problem, if A1 gets public.

A1 = H(username:realm:password)

If A1 gets public, you have to change it, to prevent foreign logins.
For the sake of ease you can not change username or password.
So only the realm can be changed, but server or client may depend on the realm.
You have now to options:

a) Dissolve the dependency from realm with the help of a new digest parameter or header option.

b) Introduce a new digest parameter and fourth value for A1, that can be changed. A1 = H(username:realm:password:anonce)

Regards,
Sophie

---

From: Yoav Nir <[email-masked]>
Date: Sat, 28 Mar 2015 14:12:33 +0300

Ah. Now I understand. Thanks.

Regards,

Yoav

Sent from my Windows Phone 

-----Original Message-----
From: "Sophie Bremer" <[email-masked]>
Sent: ‎3/‎28/‎2015 9:18
To: "Yoav Nir" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [http-auth] HTTP Digest - A1 with Salted Hash

Regards,
Sophie

---

From: Yoav Nir <[email-masked]>
Date: Sat, 28 Mar 2015 23:49:08 +0300

> On Mar 28, 2015, at 9:20 AM, Sophie Bremer <[email-masked]> wrote:
> 

And now that I understand the proposal, I think we should not accept it.

If the stored values are A1 = H(username:realm:password:anonce), then a legacy client sending H(username:realm:password) doesn’t help the server authenticate it.

This can only work if both the client and server are updated, and if we’re already updating both client and server, we might as well upgrade them to something better, such as MutualAuth.

This is different from userhash, where a legacy client will send the username in the clear, and the server can hash it if needed.

Yoav

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 30 Mar 2015 10:54:32 -0400

Hi Sophie,

I am not sure that I understand your comment.
If the database is compromised, the password must be changed regardless of
what is in the A1.
The only difference between the salted and non-salted version of A1 is that
with the salted version you do not need to change the realm(s), only the
salt.

Regards,
 Rifaat

On Sat, Mar 28, 2015 at 2:20 AM, Sophie Bremer <[email-masked]

> > Cool! Can you explain it on-list, because I'm not sure that I
> understand...
>
> Okay. If we assume that all users are lazy and we like to support there
> ease, we may have a problem, if A1 gets public.
>
> b) Introduce a new digest parameter and fourth value for A1, that can be
> changed. A1 = H(username:realm:password:anonce)
>
> Regards,
> Sophie

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 30 Mar 2015 11:01:35 -0400

Yoav,

This would be addressed by indicating that the algorithms in the registry
might have a salted variant, similar to the -sess variant.
Existing clients will always select non-salted variants, while new clients
should be able to select salted variants if they support it.

Regards,
 Rifaat

On Sat, Mar 28, 2015 at 4:49 PM, Yoav Nir <[email-masked]> wrote:

> If the stored values are A1 = H(username:realm:password:anonce), then a
> legacy client sending H(username:realm:password) doesn't help the server
> authenticate it.
>
> This can only work if both the client and server are updated, and if we're
> already updating both client and server, we might as well upgrade them to
> something better, such as MutualAuth.
>
> This is different from userhash, where a legacy client will send the
> username in the clear, and the server can hash it if needed.
>
> Yoav
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 20:15:52 +0300

> On Mar 30, 2015, at 6:01 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> Yoav,
> 
> This would be addressed by indicating that the algorithms in the registry might have a salted variant, similar to the -sess variant.
> Existing clients will always select non-salted variants, while new clients should be able to select salted variants if they support it.

Sure, but -sess variants have been there since forever. “-salt” would require a new client and a new server, and a server can’t support both “-salt” and non-“-salt” (because if the database is salted, you can do Basic, but you can’t do regular Digest).

So if the database requires a new client and new software on the server, we might as well choose something more modern than Digest.

Yoav

---

From: Sophie Bremer <[email-masked]>
Date: Tue, 31 Mar 2015 18:49:49 +0200

Hi Rifaat,

okay, but users do not like to change passwords, so I expect there no change for the majority.
Even if you force them to change the password, you will lose.
They will change to a new password and then change back to the old one.

Regards,
Sophie

Am 30.03.2015 um 16:54 schrieb Rifaat Shekh-Yusef:

> If the database is compromised, the password must be changed regardless of what is in the A1.
> The only difference between the salted and non-salted version of A1 is that with the salted version you do not need to change the realm(s), only the salt.
> 
> Regards,
>  Rifaat
> 
> 
> On Sat, Mar 28, 2015 at 2:20 AM, Sophie Bremer <[email-masked]> wrote:

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 31 Mar 2015 14:27:43 -0400

Yoav,

To take advantage of any of the new functionalities defined in this draft
you need new software in the client and the server.
How is salted hash any different?

Regards,
 Rifaat

On Mon, Mar 30, 2015 at 1:15 PM, Yoav Nir <[email-masked]> wrote:

> > This would be addressed by indicating that the algorithms in the
> registry might have a salted variant, similar to the -sess variant.
> > Existing clients will always select non-salted variants, while new
> clients should be able to select salted variants if they support it.
>
> Sure, but -sess variants have been there since forever. "-salt" would
> require a new client and a new server, and a server can't support both
> "-salt" and non-"-salt" (because if the database is salted, you can do
> Basic, but you can't do regular Digest).
>
> So if the database requires a new client and new software on the server,
> we might as well choose something more modern than Digest.
>
> Yoav
>
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 31 Mar 2015 14:37:59 -0400

Sophie,

There are ways to address that concern.
I have seen many systems that require the user to change his password every
once in a while and prevent the user from using an identical password to
his last few passwords.

In any case, I do not think that this issue is related to the salted hash
proposal.

Regards,
 Rifaat

On Tue, Mar 31, 2015 at 12:49 PM, Sophie Bremer <
[email-masked]> wrote:

> The only difference between the salted and non-salted version of A1 is
> that with the salted version you do not need to change the realm(s), only
> the salt.
>
> Regards,
>  Rifaat
>
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 Mar 2015 22:54:58 +0300

The difference is that to use a salted hash, you need a salted database. Once the database is salted, you can’t use plain digest. This means that your server cannot support both old and new clients. It’s either a salted database and new clients, or an unsalted database and both kinds of clients, but no salt. There is no smooth transition.

Yoav

> On Mar 31, 2015, at 9:27 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> Yoav,
> 
> To take advantage of any of the new functionalities defined in this draft you need new software in the client and the server.
> On Mon, Mar 30, 2015 at 1:15 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Mar 30, 2015, at 6:01 PM, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Yoav,
> >