Password hashing is different in 2.2+

Linc

FYI, we updated our password hashing in 2.2 to be more secure / standard depending on what libraries are available on your server. Therefore, it's entirely possible the passwords in a 2.2 / master branch install of Vanilla may not be compatible with a 2.1 install - i.e. they would all need to be reset in a downgrade. Just a word of warning / info to the community since I just saw it come up in a support request for someone exiting cloud hosting.

x00

but the other would should be fine as you could upgrade their hash dynamically/individually if necessary.

Linc

@x00 said:
but the other would should be fine as you could upgrade their hash dynamically/individually if necessary.

Do you mean the other way should be fine? Yes, the upgrade process is seamless. It's just not reversible.

x00

yes sorry.

x00

BTW have you considered using native hmac algos where available for session cookies? It might be a bit faster than the hand-rolled solution you have.

Bleistivt

Was this already commited?

Because i recently overwrote a test installation (master) with 2.1.1 and I can still log in.

Linc

@Bleistivt said:
Was this already commited?

Yes, it was committed. As I said, it depends on the libraries available on your server. We prefer a different one now, but if it's unavailable, we fallback to older methods that are still compatible.

Linc

@x00 said:
BTW have you considered using native hmac algos where available for session cookies? It might be a bit faster than the hand-rolled solution you have.

I don't know; I'll mention @Todd to see if he has an opinion about it.

Todd

I'm about to do a rewrite of our cookie hash to include proper hmac, but also encryption. The cookies will get bigger, but I think it's ultimately better to provide an encryption layer in the cookie.

x00

@Todd said:
I'm about to do a rewrite of our cookie hash to include proper hmac, but also encryption. The cookies will get bigger, but I think it's ultimately better to provide an encryption layer in the cookie.

Encryption for the data used the comparison (or the entire thing)? I think this would add overhead, I don't really see much benefit tbh

The data used in the comparison isn't really privileged anyway. The security is in what you don't transport. If you are really worried about that a transient look up would be better, substituting a key. Just don't store the hash.

I believe the native php hmac algos are safe but an implementation in Java's anti-timing algos were flawed, so it is always worth checking for php bugs.

Todd

@x00 you can have a look at the cookie algorithm here: https://tools.ietf.org/html/rfc6896. This will give you an idea of the type of thing we are getting at.

x00

@Todd said:
x00 you can have a look at the cookie algorithm here: https://tools.ietf.org/html/rfc6896. This will give you an idea of the type of thing we are getting at.

Interesing thanks.

Bleistivt

I'm kind of relying on this snippet in a few places:

https://gist.github.com/lincolnwebs/700805

Could you give some hints on how to make it work again, once the new cookie encryption is in place?