ZF-3402: Zend_Auth_Adapter_DbTable and unique salt per user

Description

Hi i have notice that i can't use unique salt on every password in the db. To increase security i propose that this get built in to the framework.

Code example. $auth = Zend_Registry::get('auth'); $db = Zend_Registry::get('db'); $authAdapter = new Zend_Auth_Adapter_DbTable($db, 'users', 'username', 'passwd'); $authAdapter->setIdentity($_POST["user"]); $authAdapter->setCredential($_POST["passwd"]); //--- $authAdapter->setSecurety(Zend_Auth_Securety::Db_Salt_PasswordString); // Or some thing. //--- $result = $auth->authenticate($authAdapter);

Db string example 1: "md5:1ff73fddc94ef96b107787b28b5a5c931b3c761b:3ca6f61224c49d95323e9bf2fcfbf296" Db string example 2: "sha1:0038f5a895ba79c8cf8277c34d8f7a71df5b294e:fa5c0b2db734baed9f94f7031f726f574a7c3e6a" Db string sudu: HashAlgorithm : Salt : Hash ( Salt + Password )

To validate a password the framework whod have to:

Select user by username from users

Split the passwd string by ":" to get algorithm, salt and the salted password hach.

Hashalgorithm( salt + $_POST["passwd"] )

compare if step 3:s result is equal to step 2 "alted password hach".

This enables dynamic salt length and random algorithms. Depending on the set password function of your application the dynamic salt length and random algorithm feature are active or not.

Paranoid? In my db the salt values is off dynamic length 128 to 255 chars and random algorithms (md5, sha1, sha512 and whirlpool). and autouppdate on passwd string on successful login the password is re salted and same or new algorithm . And a user have 4 tries to login.

Comments

Zend_Acl to Zend_Auth

I agree that a per-user salt would be a useful feature, but I don't think we need dynamic salt lengths or random hash algorithms.

The salt is useful to prevent precomputation of the possible password hashes by the attacker, so having a dynamic salt length does not increase security (he has to compute just as many salted hashes either way). Choosing the hash algorithm randomly from those 4 only increases the computational difficulty of the precomputation attack by a factor of 4. You might just as well add an extra 2 bits to your salt.

Also, 128 characters seems excessive for a salt. Unix, for example, uses 12 bits (2 chars).

I am inclined to close this issue. This use case is already possible, and is documented in the manual.

http://framework.zend.com/manual/en/…

Please explain reasoning for keeping this open, or providing some kind of idea as per an implementation that you think should be part of Zend_Auth_Adapter_DbTable.

Reason for keeping this open (from my side) is that dynamic salts are then dependent anymore, whatever kind of database system you use. I would like to use special treatment but its not possible with SHA2.

The problem is that there is no common pattern for salting a database. Ultimately, the Zend_Auth_Adapter_DbTable has been refactored to facilitate extending it so that this kind of scenario is possible. The only addition I could think that would be possible is the ability to add a setCredentialTreatmentCallback method so that you can pass in a php funciton to handle the "salting" but even then, that approach seems somewhat limited.

What do you mean by " I would like to use special treatment but its not possible with SHA2. " ?

(Also keep in mind, this adapter cannot be any one database specific .. like only for MySQL)

Sorry for being a bit unclear, here comes my explaination.

Say you want a unique per user, that is saved in the database, in a special column called 'salt', and you have a MD5 password hash (with the salt applied to the password ofcourse) in the column 'password'.

The current option is to use a function that's build in your database, thus thats some database specific thing. For example MySQL supports the MD5() function, which makes it possible to use MD5(CONCAT(salt,?)) which would apply the salt from the 'salt' column to the inputted password. So for MD5 and MySQL, things are allright.

Unfortunately a lot of hashing algorithms are not supported by MySQL and other databases. Ofcourse it's possible to get the salt from the database, apply it to the password, and then feed it to Zend_Auth, but thats not really the way to go, imho.

If I wanted to use SHA2 hashes with salts, this would be the only option. Therefore I think it should be possible to supply the hashing algorithm, or algorithm function to Zend_Auth. With that you need also to supply the database column that contains the salt (or, as Mikael suggested, salt:hash in one column), and the way the salt should be applied to the password f.e. salt + password + salt, or salt + password, or something different.

There is indeed a problem that there is no common pattern for salting a database. The solution is a bit annoying but is just to have a function which you can give as parameters the column name and a regex -or something similar- to get the salt. Then you can use a credentialTreatment-like to have a formatted string fed to Zend_Auth, which tells you where the salt should be applied to the password.

I hope this makes it a bit clear and if you have any questions or if im wrong please let me know! Thanks and keep up the good work.

Honestly, I think this sort of pattern requires a different adapter. It could certainly extend the standard DbTable adapter, but the suggestions you're making are adding a fair amount of complexity to the API that many users simply won't need or use. If they find themselves needing it, they can switch adapters.

As such, could you please create a proposal for the new adapter? From what I'm reading here, there are several potential approaches, and it would be good to get community feedback to see if additional approaches could also be captured in the requirements.

The requested feature is beyond a simple feature request for an existing component. Salting a row is possible currently and demonstrated in the manual via the databases built-in function set. Anything beyond what is currently supported should be proposed via the proposal process as it is far more complex than anything that would be covered by this jira- based feature request.

-ralph