Is it needed? Absolutely.
Can Kayako be trusted to provide it? Absolutely not.
I'd LOVE for these guys to prove me wrong (really), but my guess is that they'll keep the same clear text passwords stored in the database that they've got now, and they'll just stall and stall and stall and stall forever.

They pulled the same stunt when going from v2 -> v3 , promises, promises, promises, take forever, take forever, take forever. If they haven't released even a beta yet, look for it around the end of 2011 at the very earliest.

but my guess is that they'll keep the same clear text passwords stored in the database that they've got nowThen you would be guessing wrong, there.

If they haven't released even a beta yet, look for it around the end of 2011 at the very earliest.We have released our estimated release roadmaps. I'm not sure where you get 2011 from.

I fully appreciate that it is your life's mission to find every 'Kayako' related thread and post bad feedback in it, but please stick to facts :)

Then you would be guessing wrong, there.
you mean after years of being hounded and denying it's a problem you're FINALLY going to remove clear text passwords from the system. Wow, you learn soooooooo quickly don't you.


We have released our estimated release roadmaps. I'm not sure where you get 2011 from.

Try personal experience. I started following (and using) kayako long before you started with them. History repeats itself when individuals don't learn from the mistakes of the past, and this is following down the same path as the WHMCS module, v2->v3, and almost every other "development" from kayako. Start out with big promises, hold back for a while, offer more big promises, hold back for a while, finally release an estimated timetable (which will never be adhered to), and much later than schedule release the final product.


I fully appreciate that it is your life's mission to find every 'Kayako' related thread and post bad feedback in it, but please stick to facts :)
I have stuck to facts. Just because you don't want to admit those facts are real doesn't mean they're not facts. Development at kayako is insanely slow, everyone knows that, and historically, this is the way things go with kayako, again, everyone who's watched the company knows that. You'd think people would learn from past mistakes, but it'll just be a repeat of the past.

As far as the remote desktop? I wouldn't trust Kayako for that, honestly. Anyone that stores passwords in a database via clear text for years, and ignores repeated reports that it is insecure really shouldn't be trusted with control over a user's desktop.

you mean after years of being hounded and denying it's a problem you're FINALLY going to remove clear text passwords from the system. Wow, you learn soooooooo quickly don't you.The hashing of user passwords was always the plan for V4. This discussion happened in 2007 (http://forums.kayako.com/f170/system-password-encryption-hashing-13075/), where we explained why user passwords were stored this way, and that we'd change things in V4 (note - staff and admin passwords were not stored in plain text). It is not a new position.


History repeats itself when individuals don't learn from the mistakes of the past, and this is following down the same path as the WHMCS module, v2->v3, and almost every other "development" from kayako.We have learned from the past. However, we're not magicians. We cannot magic products out of the door. We have been very open about the progress of V4 and the time frames we have in mind. Sure they change, but what roadmaps don't? We made the possibility of changing time frames very clear from our first ETA announcement.


Start out with big promises, hold back for a while, offer more big promisesWe haven't promised anything we haven't met, as far as I am aware.


Development at kayako is insanely slow, everyone knows that, and historically, this is the way things go with kayakoDevelopment has been slow in the past. I never disputed this fact. I disputed the 2011 date - which came from no where. You cannot support a rotten apple with a ripe orange.


Anyone that stores passwords in a database via clear text for yearsLike I said - the matter has been fully explained on our part. You can review the discussion that took place in 2007, along with our saying that V4 will have all passwords irreversibly hashed.


and ignores repeated reports that it is insecure really shouldn't be trusted with control over a user's desktopWe have not ignored any reports about insecurities in our software.


shouldn't be trusted with control over a user's desktop.
We (Kayako) have no control over a user's desktop, if you're referring to Kayako OnSite. The actual VNC connection is not proxied through us - it is direct.

We have not ignored any reports about insecurities in our software.

Ahh, but you see, you just said you did.


The hashing of user passwords was always the plan for V4. This discussion happened in 2007, where we explained why user passwords were stored this way, and that we'd change things in V4 (note - staff and admin passwords were not stored in plain text). It is not a new position.

come, come now. This was reported in 2007, the year is now 2010. For 3 years, you've ignored a serious flaw and vulnerability in your software that should have been patched immediately, not in the next major version (release date unknown).

Blowing off insecurities = ignoring them.

Oh, and btw, that explanation is completely incorrect. It IS entirely possible to store a user password in the database without it being plain text AND have them recoverable. nice try though

a serious flaw and vulnerability in your softwareIt isn't a vulnerability. The passwords (and all your customer data) are as secure as your web server. Kayako software would be vulnerable if it could be used by anyone to view user passwords, but this is not the case. Someone would need to hack your server and copy your database from your web server in order to compromise those end-user passwords.



that should have been patched immediately, not in the next major version (release date unknown).You will find an explanation about why we kept the legacy support in Kayako V3 in the thread I linked you to earlier. If you are still concerned, there is a free mod available in modifications/addons forums that enables MD5 hashing of user passwords.

I will quote myself from that thread:
The reason why passwords have been stored in plain text, up until now:
As we explained in the previous discussion, the reason why end-user passwords have been stored in plain text was because a large number of our customers wanted authentication details to be included in every ticket receipt sent out to their end-users.

The reason why passwords will be irrecoverably hashed in Version 4:
Anyone with access to the database has access to the end-user passwords. Because end-users tend to reuse the same password for a number of services, this exposure of information is a potential security risk. Times have now changed, and the benefits of being able to send out password reminders are outweighed by the security implications of storing clear passwords.



Oh, and btw, that explanation is completely incorrect. It IS entirely possible to store a user password in the database without it being plain text AND have them recoverable. nice try thoughYes, I know it is. I didn't say it wasn't possible. However, we will be hashing passwords, and digest hashes are not reversible. I never said we'd be encrypting them (reversible).

It isn't a vulnerability. The passwords (and all your customer data) are as secure as your web server. Kayako software would be vulnerable if it could be used by anyone to view user passwords, but this is not the case. Someone would need to hack your server and copy your database from your web server in order to compromise those end-user passwords.
mmhmm, storing passwords in clear text isn't a vulnerability, right. And pigs fly, too. Yes, it is a vulnerability, a CRITICAL vulnerability, no less.

It really doesn't require "hacking" to get that information from your database, it merely requires someone to have mysql access. Say, a developer, or disgruntled employee, or even an unethical admin. All it takes is one person, with or without brute-force attacks.


The point that your company fails to grasp and understand is very simple:
This IS a security and design flaw that should have been addressed years ago, not by a "plugin" but a simple redesign. It is something so basic that even I could do it. Instead, you ignored this security flaw for years and have no intentions of patching it in current versions. Surprised? Not really.

It really doesn't require "hacking" to get that information from your database, it merely requires someone to have mysql access. Say, a developer, or disgruntled employee, or even an unethical admin. All it takes is one person, with or without brute-force attacks.Indeed. If these people access or misappropriate use electronic data, then that is 'hacking'. Like I said, the information stored in your database is as secure as your web server.

However, for the third time, we appreciate that times and the requirements of our changed customer base are different and we will be hashing passwords in V4.


The point that your company fails to grasp and understand is very simple:
We have not failed to grasp anything. I even quoted a statement from me about why end-user passwords are stored in plain text, and what we're changing in V4 (fourth time).

You are taking this around in circles. You are not saying anything different, and you are not contributing anything to this thread. My answers are the same: This has been discussed long ago, and a decision to hash passwords in V4 had also been taken long ago.

The majority of our customers are entirely happy with the situation. For those who are not, there is a free modification that can be applied to implement end-user password hashing.

There is nothing more I can say, so please don't derail this thread any further.