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 -~----------~----~----~----~------~----~------~--~---
