On 01/03/2017 15:37, Bob Sneidar via use-livecode wrote:
Hi Peter. Very informative thank you. In the example,

[protected form] = [salt] + protect([protection func], [salt] +
[credential]);

It looks like they are saying to prepent the salt prior to the
protect function (in the case of LC that would be encrypt) but if
someone got access to the SQL database, wouldn't that give part of
the secret away? Isn't the salt value a way to further obscure the
credential, making something like a hash table more difficult?

I use a salt value that only I know, and I password protect the stack
that uses it. Seems to me that prepending the salt to the protected
form is like giving someone my user name but not my password. The
other team is starting on the 50 yard line (in American sports
vernacular).

The idea of a password storage scheme is to make it extremely costly for
an attacker to recover the original passwords, even given _total_ information about the scheme. When evaluating a scheme, you should always assume that if someone has got access to your password database, they have also got access to anything else on that server or any server connected to it -- potentially including your secret salt.

By appending the salt to the front of the protected form, you can use a
different salt for every single password in your database. Even if someone knows a password already (e.g. because they have an account on your server), they gain no information about any of the other passwords in the database.

Password storage schemes like Argon2 go one step further and put all of the parameters for the protected form into the protected string. This allows the parameters to be modified for newly-stored passwords while still being able to verify old passwords. They are also tuned to ensure that it takes a long time to compute the protected form (usually around 0.1 to 0.5 ms). That's long enough that knowing _all_ the parameters still makes it infeasible to figure out what the original password was.

In summary: salt values shouldn't need to be secret.

                                       Peter

--
Dr Peter Brett <peter.br...@livecode.com>
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to