I’m operating in an AD environment and obviously the first thing everyone does with Spark is tick the “save password” option. Now, I don’t know where Spark stores this information, or how it protects it (a hash within the CURRENT_USER key?) but were we to use this program for more users than our current trial, this is obviously one of the things I would prefer to disable.
Does the enterprise plugin allow for this?
With this option the password is stored on client side, so server has no influence on it. You could write your own client (e.g. modify Spark) so password can’t be stored. Using the enterprise plugin you could allow only your own client.
the first thing everyone does with Spark is tick the “save password” option.
What is bad about it? Even if Spark stores the password as plain text, it should be secured though the user account on that specific machine. Better use a long and secure password and store it, than have a password like “123” because you have to type it every time. If your server is Internet accessible, an attacker could make an easy brute force attack on that password. He just needs a client that tries to connect to your server. It is much more complicated to hack the local machine.
Coolcat
The ‘save password’ box in Spark should be defineable on the Openfire Server IMHO and it represents a pretty fundamental security hole:
The password would be saved in the user’s profile on a Windows machine
Any other admin of that box could therefore read the file
The encryption is pointless. If I can read the file then all I need to do is:
a) Copy the file locally to my machine
b) Install and launch spark
c) before logging in, but Spark in debugging mode, which will show the password in plain text
The security risk is therefore that any local workstation administrator is able to reveal another users domain password. For me, that’s not a great state of affairs.
The only reasonable solutions are either to use Single Sign On, disable password caching, or disable the display of passwords in Spark’s raw packet debugging.
Has any progress been made on this? We are running Openfire on a linux server so SSO is not an option. I cannot roll this out to my users with this security hole in place.
Any movement on this front? Is SSO the sole solution?
SSO is an option with linux it just takes a bit of work.
I just tested the debug functions of spark and the password does not show as plain text. The saved password is encrypted.