Securing a users 'role' as well as 'password'
Posted: Tue Jul 20, 2010 10:18 am
Hey all,
I'm just after some guidance on what the best way to approach my situation would be.
I've currently got my user database set up much like this password hashing thread. A static site salt and a per-user salt in the user table. It jumps through a few hoops to create the final hash (breaking the salts down and doing things before the final hash run, etc.) but the outcome seems pretty satisfactory.
Now I'm trying to give an authorization level to each user (member, contributor, admin, etc), but it seems to me that protecting the password is a bit pointless if someone can just come along (well, having compromised the database) and just change their status. Now I could change the values to numbers or some other system, but it seems that it would still be pretty obvious what options there were, and a test of each one would soon uncover the admin role.
So my first thought was to include the role in the users password hash routine, but then I started thinking about what happens when I want to change a users role. I'd have to re-issue a new password, though it also occurs to me that I could just trigger the change on next login, so that I can use the plain text password to authenticate and regenerate the stored hash. But then it also occurs to me that a clever person, having got this far, would realize that they could just use the sites 'lost password' function to get their password regenerated after changing their role to whatever they chose.
So then I thought that perhaps I could use the salt to hash the role and store both in the table. That way, when a user logs on, their role is rehashed and checked against the stored value in much the same way as the password is currently, thus in theory protecting the role from tampering.
The latter seems to be winning, but then I started thinking about brute force attacks. I mean, doesn't it somewhat weaken my security to provide the answer next to the hash. Kind of like showing someone a lock that takes 3 keys and then giving them two (user salt and role). Or am I being overly cautious here? I've worked on a few similar projects when coding with others and they have ALL without fail left the role as plain text, where you can change a persons role by hand just by updating the column. As bad as it seems, or just common practice?
I've been thinking about this too long and it's quite late. Just wanted to throw this out there and see if any of you have any advice on this one before I go off the rails and think up a way to complicate this even further.
Cheers
I'm just after some guidance on what the best way to approach my situation would be.
I've currently got my user database set up much like this password hashing thread. A static site salt and a per-user salt in the user table. It jumps through a few hoops to create the final hash (breaking the salts down and doing things before the final hash run, etc.) but the outcome seems pretty satisfactory.
Now I'm trying to give an authorization level to each user (member, contributor, admin, etc), but it seems to me that protecting the password is a bit pointless if someone can just come along (well, having compromised the database) and just change their status. Now I could change the values to numbers or some other system, but it seems that it would still be pretty obvious what options there were, and a test of each one would soon uncover the admin role.
So my first thought was to include the role in the users password hash routine, but then I started thinking about what happens when I want to change a users role. I'd have to re-issue a new password, though it also occurs to me that I could just trigger the change on next login, so that I can use the plain text password to authenticate and regenerate the stored hash. But then it also occurs to me that a clever person, having got this far, would realize that they could just use the sites 'lost password' function to get their password regenerated after changing their role to whatever they chose.
So then I thought that perhaps I could use the salt to hash the role and store both in the table. That way, when a user logs on, their role is rehashed and checked against the stored value in much the same way as the password is currently, thus in theory protecting the role from tampering.
The latter seems to be winning, but then I started thinking about brute force attacks. I mean, doesn't it somewhat weaken my security to provide the answer next to the hash. Kind of like showing someone a lock that takes 3 keys and then giving them two (user salt and role). Or am I being overly cautious here? I've worked on a few similar projects when coding with others and they have ALL without fail left the role as plain text, where you can change a persons role by hand just by updating the column. As bad as it seems, or just common practice?
I've been thinking about this too long and it's quite late. Just wanted to throw this out there and see if any of you have any advice on this one before I go off the rails and think up a way to complicate this even further.
Cheers