Encryption

[spiderpig]

Hi,

my config.pm store sensitive passwords in clear text for the DB and A.d.

what is the best way to encrypt it?

[crythias]

You can encrypt the db password.
https://github.com/OTRS/otrs/blob/rel-5 ... rdCrypt.pm
Once you have it, you can use the result in curly braces {} in the Config.pm for the database. Of course, this is reversible encryption, so consider this more security through obscurity than actual preventing users from having the password to your database.

For onlookers who are looking at this: The fact that the encryption *has* to be reversible -- a clear password has to be decrypted from the encrypt -- to be effective in login to the DB server means anyone else who's able to follow that could, in theory, do the same thing that the code does. Also, if you think "no, it's just a hash" but then ... the hash is directly usable as credentials? How is that better? Just because it's not *the same* password, it's still a key.

For everything else, consider the security as it exists on Config.pm as a file. Obviously root has access, as well as the OTRS user and (possibly) web server context. After that, consider that anyone who has physical access to your server has enough ability to get the data. Heck, they only need to Hit BackSpace enough times.

As for Active directory users, you could make sure that the user doesn't have interactive login as the user isn't anything more than a bind user for read-only access. More to the point, this *also* needs to be decrypted in some way as to be useful. It's probably more problematic that the default is being sent over port 389 unencrypted rather than someone who might have local access to Config.pm.

Then it gets to the backup that you probably don't have, and don't have encrypted if you do :).

All this to say, not really possible, feasible, or worth it in the Config file if all the other external bleed points aren't addressed.

[crythias]

Also, because some people might not understand the difference between user password hashes and program usable passwords (possibly not fully accurate. It's the gist that's important):

When a human puts in a password, that password might be placed into a hashing environment to make, let's say, a big number. That big number is compared against a stored big number. If they match, access granted. But a good password system doesn't know your password. Even if you typed in the big number, that, too, gets changed into a different big number and compared, and will fail. Don't even get started on two-factor authentication which is impractical (ish) for computers to authenticate the same second way humans have now.

When a computer needs to use a password, there are good ways to do this and old ways to do this. For the most part, most applications rely on plain text passwords passed (through hopefully secured/encrypted pathways) to servers to pretend to be human-like. They can't push the hashes for the same reason as above: The recipient server hashes the hash. A better method would be a good Challenge/Response via things like certificate handling and time offset. Both the recipient server and the access server would understand and trust the certificates and expect a specific response to occur at a specific time. This would be hard to intercept but easy to generate (How SSL works, kinda). Certificates are supposed to be unique, and identify both sides and only allow that traffic. The problem is that certificate generation and trust is hard to communicate to someone who is looking to only do things like in house ticket management. Also, considering the recipient servers aren't generally that complicated. Now on the other hand, https://dev.mysql.com/doc/refman/5.7/en ... tions.html when the communication channel is secure, the authentication data doesn't necessarily have to be.

[equijano]

Hi, just to ask if this way of encryption also works with mail account password stored in db?
Or if you know any way to save encrypted postmaster password instead of plain text?

[jojo]

no, as OTRS needs to use the password it will always need a plain version...

[equijano]

But it also needs to use DB password, and it can be encrypted, doesn't it?

[jojo]

DB password can be simply hashed but still is available in the environment...

[equijano]

Ok, thank you for your answer.