Misc / General System -> Password encryption or hashing

[craigbrass]

I suppose (maybe what you are trying to say) is if they have access to the database to obtain the password, they would have access to the tickets table anyway.

[Jamie Edwards]

Originally Posted by craigbrass

I suppose (maybe what you are trying to say) is if they have access to the database to obtain the password, they would have access to the tickets table anyway.

Precisely.

What everyone has to understand, is that "creating your own password" and remembering it, and then having it hashed is all well and good for (say) a forum where you register yourself.

But for years and years, people have preferred that the way eSupport was designed - tickets are raised by e-mail, a password is made for you and you are told that password each time you raise a ticket; as it was the perfect convenience for users and set the standard for a lot of other ticketed support software which operate in this way.

I urge you not to be ignorant of this fact and to dismiss our decisions as badly thought out.

I have said that we will revisit this decision accordingly.

Thank you,

[Chris Boulton]

Jamie,

I think you don't understand the point of passwords being encrypted:

Users generally use the same password over and over again for different services. This is a problem if your database is compromised, apart from someone having access to your tickets, they could potentially have access to clients emails, websites etc if they are for some reason using the same password.

There is also the fact that I may not like the administrator of a site to have my password (this is all theoretical) because I for some reason use that password elsewhere - and you can't trust everyone.

The idea behind the encryption I stated would be something which is completely reversible within SupportSuite's encrypted code - so plain text passwords can still be sent along.

Just "food for thought."

Chris

[craigbrass]

Ah yes, I didn't think of this side of it when I seen Jamie's reply.

[Jamie Edwards]

Hi Chris,

I do understand the point of passwords being encrypted and hashed.

You said: "Users generally use the same password over and over again for different services." - refer to my previous reply which describes the atypical situation that eSupport has usually been used in, users not selecting their own passwords and used to receiving their ticket info in each ticket receipt.

Sure, this could be randomly generated but then the users who do set their own password by registering on the support website get frustrated having their password reset every time their raise a ticket by e-mail.

This is a problem if your database is compromised, apart from someone having access to your tickets, they could potentially have access to clients emails, websites etc if they are for some reason using the same password.

Absolutely, but again I refer you to my previous reply which explains that rarely would clients be specifying their own password anyway. I also said that we do accept times have changed, and we are not refusing to change too; I am just explaining our design choice.

The idea behind the encryption I stated would be something which is completely reversible within SupportSuite's encrypted code - so plain text passwords can still be sent along.

Indeed, but do not deceived by the term 'encryption' in this case - the Zend or IonCube encoded part of a PHP script is reversible to the determined hacker - either by simply decoding the script or a combination of that and reverse engineering (the decoders that do work for Zend or IonCube (earlier versions) reverse the encrypted source into op code based code).

[craigbrass]

To add to Jamie's point about decryption, I know that one of the companies that offers this service for older versions of Zend and IonCube said they are 90% complete in making a one for the newer versions of Zend and 60% though one for IonCube.

Just shows nothing is unbreakable huh?

[NC Software]

First off, you all have to open up your minds to how larger companies operate and not how your "one man company" or Kayako small biz operates. Large companies have sys admins, db admins, mail system admins, etc. One guy may know the passwords to the mail server accounts as an example, but three of the above may have access to the database. OR, maybe a business allows access via phpMyAdmin as an example so you can run queries against the database BUT not all that have access to the database should be able to see the passwords in the clear! Various admins know various things but passwords to the mail server is an example of something not everyone should know. User passwords, no one should see those - NO ONE!

Additionally, it is common for logging in that a logon is done via HTTPS (SSL) and then the system reverts back to HTTP (Non-SSL) for regular use of the application. This is another area that not only does Kayako store passwords in the clear, they transmit them in the clear!

We have a total failure or lack of security here and people need to be aware of this.

[craigbrass]

Maybe its time to get a developer (Varun would be best) to look over this.

[Ryan Lederman]

The fact remains that even if passwords are encrypted in the database it is no more secure than plain text. This is because you would have to store the key in plain sight. If an attacker knows: (algorithm + key) = plain text.

[Jamie Edwards]

To reiterate what Ryan said, encryption would be useless. To only secure way of doing this would be through irreversible hashing, which will mean two 'modes' of system to choose between (a big development undertaking).

[NC Software]

I disagree with both of you. There is symetric vs. asymetric encryption, hashing, all kinds of ways to go about this, even if it's a hash, although things are not purely secure like in trying to protect credit card data, but you do NOT store things in plain text people! There is no question about it that I should not query my database and see passwords. If I am an employee and see a hash I won't know how to access my companies mail server to get into accounts I'm not supposed to, on and on. I cannot believe I'm meeting this kind of resistance in this major security issue with Kayako!

[Jamie Edwards]

Neal,

If you read my replies again you will see on more than one occasion that I have said we are not resisting the request and have aknowledged we need to look at things.

[craigbrass]

Yea, maybe we should all just back off this topic and see what the guys at Kayako come back with when planning for V4 begins.

[NC Software]

when planning for V4 begins

Thank you for making me laugh, that was funny!

[craigbrass]

Is there really a need to have a dig at Kayako on EVERY possible occassion?