HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Password hashing is different in 2.2+

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.

Comments

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

    grep is your friend.

  • LincLinc Detroit Admin
    edited August 2014

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

  • yes sorry.

    grep is your friend.

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

    grep is your friend.

  • Was this already commited?

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

  • LincLinc Detroit Admin
    edited August 2014

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

  • LincLinc Detroit Admin

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

  • ToddTodd Chief Product Officer Vanilla Staff

    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.

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

    grep is your friend.

  • ToddTodd Chief Product Officer Vanilla Staff

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

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

    grep is your friend.

  • BleistivtBleistivt Moderator
    edited August 2014

    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?

Sign In or Register to comment.