how to handle salted keys? about hawk HOT 15 CLOSED

What I want to achieve is to compare a salted key with an unsalted key like this.

function saltedKey(salted,key) {
    var algo, len, salinate;

    if(!salted || !key) return null;

    /* verify salt algo $x$ */
    if(!(algo = salted.match(/^\$(\d)\$/))) 
        return key;

    if(!(algo = exports.argorithms[algo[1]])
        throw "invalid salt algorithm";

    if((len = salted.length) < 12 || salted[11] != '$')
        throw "bad salt";
    /* 8 grinds of salt */
    var salinate = salt.substr(3,11) + key;

    return exports.calculateHash(salinate,algo); 
}
if(saltedKey(salted,key) === salted) // good
else // bad

And plug that into Hawk somewhere (note: this code is an example only).

from hawk.

What are you trying to achieve by salting the key? Given that the key is a shared secret I'm unclear on what benefit salting obtains.

from hawk.

isn't the shared secret just a hashed password, or what else is it? :)
Salting protects the passwords if the database gets compromised.

from hawk.

The key is just a random set of characters. It shouldn't bear any relationship to users' actual passwords.

You need the key to calculate the MAC and authenticate each request, so you can't do anything one-way with it.

from hawk.

random set of characters that coexists on both client and server or is it negotiated somehow?
If this random set is persisted on the server then it is a hashed password, right?
It shouldn't matter if the client bundles that into some magic mac cookie. Since if someone compromises the user database and gets hold of that key they can also generate authentic mac:s. Or am I completely wrong ? :)

from hawk.

You need to read the README on the main Hawk page, especially the "Security Considerations" section. Let me know if you have any questions after that.

from hawk.

Sure will do that, I realize I need to dig deeper into the internals of hawk to understand this mac thingy.
Thanks for the effort, however I must admit I'm a little confused right now. ;)

Case closed for now.

from hawk.

"Hawk does not provide any mechanism for obtaining or transmitting the set of shared credentials required. Any mechanism used to obtain Hawk credentials must ensure that these transmissions are protected using transport-layer mechanisms such as TLS."
Oh my...

from hawk.

Yep, take a simple example:

• client app goes to http_s_://api.example.com/token/generate This request is protected by TLS and requires Basic authentication. If successful it returns a suitable set of Hawk credentials
• client app goes to http://api.example.com/resources/info. This request does not need TLS protection (it's still a good idea, but not so critical any more) and uses Hawk authentication

All further requests can use the Hawk credentials, with the caveats as per the README (and common sense). And you can manage the scope of the credentials to provide varying levels of access that you could not do with a single password.

from hawk.

So what happens if the database that holds the credentials gets compromised i.e due to a security flaw in the server?
I guess that these keys have to be short lived, like during a session ?

from hawk.

Thank you mcdee, I think I understand how to implement this now. 👍

from hawk.

What would you expect to happen? All your data is exposed anyway, and because the Hawk credentials are unique tokens you don't have to worry about then being used to access information elsewhere.

If you're extra-worried about this you can always give the tokens a limited lifetime, but as I say once the server is compromised it's pretty much game over anyway.

Again, to be clear, Hawk isn't designed to be a complete authentication system in itself and should not be relied on for this. It is very good at (partially) confirming that requests have not been tampered with in-flight, but how much you trust the keys to imply identity is up to you.

from hawk.

Yes if the database where the user data is stored also gets compromised it is game over, I agree.

from hawk.

How should we store credentials that we get from server in client (Browser app). Is it ok to store credentials in cookie or localstorage in plain texts?

from hawk.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

from hawk.