Hi again, I thought I'd chip in with another path to hashing bliss. Rewriting AuthComponent for your purposes envolves modifying a single line of code. So anyone wanting non-hashed passwords by default can achieve that in a few seconds by making a copy of the file in the core and placing it in the app.
For CakePHP 1.2.8004 cake/libs/controllers/components/auth.php line 277 --- $this->data = $controller->data = $this->hashPasswords($controller- >data); +++ $this->data = $controller->data; // = $this->hashPasswords($controller- >data); No more automagic hashing. What you loose is of-course future updates to the file. I have a feeling it has very few, if any, bugs left but it is worth mentioning. An alternative is to use $this->Auth->authenticate and point if to an object with a hashPasswords function that does nothing. I use this when I need a different hashing in an app. Like when I need to comply with an existing database of users. /Martin On Feb 5, 11:44 am, Martin Westin <[email protected]> wrote: > Hi Aidan, > Sorry, but automatic hashing was not a stumbling block for me. I has a > whole set of other issues when first implementing AuthComponent. But > that is hardly relevant. I see lots of questions about authentication > and passwords, too. > > There is a simple and exceedingly common was to eliminate (work > around) the things you see as problems. All of them, except the part > about magic, I think. > > On the Cookbook-page you linked to it is called "password_confirm": > That other field that almost every registration (and change password) > form has. This field will never be magically hashed and can be used > for any validation you like. It can be passed back to the view, > replacing the hashed password if you like (I don't like sending > passwords back and forth in the clear but that is just me). All you > have to do is to compare a hashed version of it to the "real" > password. But that has to e done either way so that shouldn't be a > problem. > > Personally, I think CakePHP would (and should) receive a lot more > criticism if the internal component responsible for authentication did > not hash passwords. I use the internal AuthComponent because I trust > the core team more than myself when it comes to not making a logical > mistake with the details of security. Hashing passwords is pretty > vital and certainly for the 99% of requests that are logins and not > registrations. The same is true for the Models where the setup works > great for 99% of the database-queries I make. > > But I do understand that a lot of people have problems getting their > head around how Auth works and the documentation could probably be > modified to make things even clearer. > > On Feb 5, 9:17 am, Aidan Lister <[email protected]> wrote: > > > Hi Bakers, > > > Can we have a discussion about rewriting the Auth component to remove > > the numerous issues involved with automatic hashing? > > > Although forcing users to automatically hash their users password is a > > nice idea, the current implementation a major stumbling block for > > every single person that uses this component, and I don't use "every > > single person" lightly. > > > Let's have a look at the things automatic hashing breaks: > > > 1. Validation > > You can't validate the users password. You can't check whether it > > contains certain characters, or whether it's too long or too short. > > > A simple notEmpty check will always return true because the salt is > > hashed - meaning a blank password appears to be 40 characters long. > > > There are numerous ways to override this behaviour [1], however most > > users appear to be simply renaming their password field to "passwd". > > This directly eliminates any benefits of automatic hashing anyway. > > > 2. Registration > > We shouldn't need a section in the manual [2] about common problems > > the user will encounter trying to do simple tasks. We should fix the > > common problems. > > > 3. Users > > Why punish the user for making an unrelated mistake during a > > registration process? Auth either sends the user back his hashed > > password (meaning the user has to clear the input and retype his > > password) or blanks the password. Stop punishing the user! > > > 4. Magic > > I don't want to have to spend unnecessary brain effort thinking about > > how naming my fields will affect my application. I expect password as > > a fieldname to behave the same way any other field behaves. Magic is > > rarely good, and frequently confusing. > > > It is said that magic_quotes was the biggest mistake the PHP > > Development team ever made, and automatic hashing reeks of the same > > mentality. Our developers aren't stupid - they can hash their own > > passwords. > > > [1]http://teknoid.wordpress.com/2008/10/08/demystifying-auth-features-in... > > [2]http://book.cakephp.org/view/565/Troubleshooting-Auth-Problems --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
