Hello teccmo I had a shot at porting "phpass" to zf2 (It would require minimum changes for zf1):
Take a look at http://pastebin.com/jZ93xt3S Is this what you are after? Note 1: I removed the Window-specific parts, as I only deploy on UNIX OSes. Note 2: Use the above code entirely at your own risk. It is not production code. Jonathan Maron On Tue, Aug 31, 2010 at 7:56 AM, Hector Virgen <djvir...@gmail.com> wrote: > Bill, do you have any concerns about hackers recovering the user's original > (raw) password to log into their other accounts such as banking? That's > where I see the salt coming in as a protective measure -- they would need > the db as well as the code to discover the password. > > -- > Hector Virgen > Sent from my Droid X > > On Aug 30, 2010 10:50 PM, "Bill Karwin" <b...@karwin.com> wrote: >> >> On Aug 30, 2010, at 10:29 PM, Ralf Eggert wrote: >> >>> interesting stuff. But where should the distinct salt per user be >>> saved? >>> It feels quite wrong to store it in the database right beside the >>> password. Or should it be combined from, lets say: user id, email >>> address and registration date? >> >> Ideally the salt should be more strongly pseudorandom. You don't need >> to use any constant or other user-related field in the calculation of >> the salt. Just make it as random as you can make it. And make sure >> you use a distinct random salt per user. >> >> If the attacker gains access to make queries against your database, >> you've lost the game anyway, so storing the salt in a column named >> "salt" in the same table with the hashed password is not significantly >> riskier than storing the salt anywhere else that the attacker gains >> access to. >> >> In other words, don't rely on security by obscurity. Don't even favor >> security by obscurity. In some ways, I think it's better *not* to >> make your code or database obscure at all, if that encourages you to >> strengthen more effective security measures to prevent attackers from >> gaining access. >> >> Regards, >> Bill Karwin >
