saving passwords

mjkulet · December 10, 2010, 2:38am

Thank you guys for your help, the password saved is now hashed!

I am amazed how fast and accurate you guys respond

Where can I tag this post as solved?

trejder · December 10, 2010, 7:01am

It’s not only you, Chris! Turning on E_STRICT error reporting in php.ini is among first things I do for each larger project!

trejder · December 10, 2010, 7:06am

We are trying to do our best! The truth is that being active member of Yii community is like using all the advantages of collective knowledge (hhhh… we’re the Borg, you will be assimilated! ). As someone (probably jacmoe! ) pointed out somewhere here, it is always a pleasure (feeling that you can help is a quite nice thing, at least for me) and this is something both sides profit from. Not only the one that asks, but also the person, who answers - as he or she may start to see things he/she would never do without help form second side.

Wow! That is completely off-topic!

Common, but not written rule is to add [Solved] at the beginning of topic title. In this forum you can change topic title with every edit or addition of a new post to it. Try it! And good luck with wonderful Yii!

mdomba · December 10, 2010, 7:18am

Some users has a habit to put [SOLVED] in the forum title… but as I see this… it’s not needed… as it happens that a solved thread gets “reopened”… for example someone with a similar problem post a question in that thread and the posting continues to solve this similar problem… in that case the [SOLVED] in the title is misleading…

and anyway… as this community is getting bigger and better every day… it’s very rare to have un-solved posts… so in the end there would be a list of posts all beginning with [SOLVED]…

trejder · December 10, 2010, 10:13am

Yes, you are right. I haven’t thought about this that way. Even if some one reopens a solved topic, there is 99% chance he or she forgot to remove [SOLVED] part from a title.

Then maybe we make common, but not written rule that to mark topic as solved, its initiator will write in a last (for that moment) post a simple thank you and short info that the problem was solved? :]

P.S.: I mislead some people. To edit thread topic, one need to edit first (not any) post in it - this way topic can be changed only by thread’s creator, not by anyone.

zaccaria · December 10, 2010, 10:33am

That’s a very strong affermation, anyway I can quote!

mdomba · December 10, 2010, 10:57am

At least there are very very few unanswered posts…

trejder · December 10, 2010, 11:56am

Well, then… why most of them are mine?

Like those:

Oracle column names case-sensitivity
ChoiceFormat and truly PHP evaluation?
Menu active state lost when using modules?

It drives me a little bit crazy, that there are no answers to those, as they are somehow key problems to my current app!

But, to be honest, as you said. I never met any other forum before, that would have that small factor of unanswered posts and where community would be so warm and helpful!

mdomba · December 10, 2010, 12:10pm

Could be that you have really specific problems that others has not encountered or even used until now

trejder · December 10, 2010, 12:35pm

I can agree with you about ChoiceFormat and truly PHP evaluation? but not with Menu active state lost when using modules? as it is (at least for me) so obvious problem, that I was kind of surprised that I did not noticed anything interesting in this matter in the forum. Don’t tell me that I’m first here, who used menu for accessing modules and submodules!

zaccaria · December 10, 2010, 12:39pm

I did it, and I had no problem

I just set active with some logic expression based on the actual controller and view, and all always worked fine.

I never used the extension you mentioned, always used bare CMenu.

Anyway, or is a ccs problem or is an expression problem, I think that there are no other options.

mdomba · December 10, 2010, 12:41pm

we are here too deep OT… I answered you on the menu topic

Edit:

I wrote “not encountered” first… only then “or even used”

trejder · December 10, 2010, 12:55pm

Yes I agree! We should end this conversation, before we get busted by Qiang or other forum members for doing off-topic chitchat!

mongoose76 · January 26, 2011, 1:28pm

Hi all,

I see the hashing happens only on new record.

What if I want to update the password? How would you do it?

Doru

Composer: requirements could not be resolved

Hi. I created a model ‘User’, which contains id,username,password. I want it to save the password hashed, so I created a public function ‘hashPassword’ for this. I created a ‘beforeSave’ public function ,in accordance to my understanding in the documentation, which will call the hashPassword before proceeding to saving. However, passwords are still saved as is.

Here are the details:
//User.php

public function hashPassword($password,$salt)

    {

        return md5($salt.$password);

    }
//UserController.php

public function beforeSave()

	{

	

	   if (parent::beforeSave())

	   {

	

	      if ($this->isNewRecord)

	      {

	         $this->password = User::hashPassword($this->password,'s0m3s@Lt');

	      }

	      

	      return true;

	

	   }

	

	}
Maybe my codes are incorrect,or I placed the functions in an incorrect file, or both…which is more likely.

I am a newbie, please make it simple for me

trejder · January 26, 2011, 1:59pm

Exactly the same way! :] Using hashPassword or directly PHP’s md5 method or any other way. You get plain inputed password, you have from form where you allow your user to change password, you hash it and store in DB in place where old, hashed password were previously stored.

Hashing is one-way operation. You can’t read (un-hash) password. You can only hash new password again and check if hash is the same as stored in DB (this way you are doing when logging user in). Therefore you always use the same function, no matter if you hash password for the first time, when inserting new record to your DB or if you hash new password again for updating existing record in DB.

zaccaria · January 26, 2011, 2:02pm

Usually for update a password I create another interface, in wich I update (ater hash) only the password.

mongoose76 · January 28, 2011, 9:08am

I did not express myself very clearly, sorry about that.

My problem was actually knowing when not to rehash an already hashed password.

My current solution is this: if the length of the password being saved is longer than a defined maximum password length then it is hashed so I do not rehash it. It just means that the user wanted to update something else in the User record. Probably zaccaria’s solution is the safest.

Anyway, thanks for the answer, if you have an even cleaner solution I am glad to hear it.

trejder · January 29, 2011, 3:09pm

Sorry, either I’m out of caffeine and urgently need a coffee or I’m not following you! :]

You don’t rehash passwords which length exceeds some fixed maximum? You detect what user want to updated (password or something else) by checking length of password? I’m not following your idea! :]

Yes, I agree that zaccaria’s solution is the best and sorry for not providing anything better (after all - he is a Master Member and I’m only an Advanced one! :]), but I got to ask you, because I got a bit lost, when reading your answer! :]

Have a nice weekend!

mongoose76 · January 31, 2011, 4:12pm

Hi,

My explanation skills are not quite good.

I wanted to handle the hashing inside the ActiveRecord. So from outside I just set a value and let the ActiveRecord handle if it hashes or not. I am doing this by overriding beforeSave.




public function beforeSave()

	{

		if (parent::beforeSave())

		{

			if (strlen($this->cod_de_acces)<=4)

			{

				$this->cod_de_acces = $this->hashPassword($this->cod_de_acces,$this->salt);

			}


			return true;

		}

	}

The problem is that at this stage I do not know if this password is a new password that needs to be hashed or it is just the old password that needs to remain the same and something else in the record was changed.

My passwords are 4 characters long, so my solution was to check for this. If the password length exceeds 4 then this password is already hashed and I do not hash it again.

But I think my design is not good and the decision to hash or not to hash needs to be moved somewhere else to be totally flexible. Probably in the controller where I can know for sure if the password was changed or not.

I hope this time I got it right

mongoose76 · January 31, 2011, 4:13pm

Come to think of it, is there something like a dirty flag for ActiveRecord attributes?

A flag that will tell me if the value of a column has changed will definitely help me.

mongoose76:

Hi,

My explanation skills are not quite good.

I wanted to handle the hashing inside the ActiveRecord. So from outside I just set a value and let the ActiveRecord handle if it hashes or not. I am doing this by overriding beforeSave.
public function beforeSave()

	{

		if (parent::beforeSave())

		{

			if (strlen($this->cod_de_acces)<=4)

			{

				$this->cod_de_acces = $this->hashPassword($this->cod_de_acces,$this->salt);

			}


			return true;

		}

	}
The problem is that at this stage I do not know if this password is a new password that needs to be hashed or it is just the old password that needs to remain the same and something else in the record was changed.

My passwords are 4 characters long, so my solution was to check for this. If the password length exceeds 4 then this password is already hashed and I do not hash it again.

But I think my design is not good and the decision to hash or not to hash needs to be moved somewhere else to be totally flexible. Probably in the controller where I can know for sure if the password was changed or not.

I hope this time I got it right