Spark is using a publicly available key to encrypt passwords

Hi,

i had the same question since i have deployed Spark & OpenFire in our Company with the ability to logon via LDAP.

What i have discovered is that there is at least one security flaw because of some static/public known encryption key.

See this Links:

Spark/Encryptor.java at master · igniterealtime/Spark · GitHub ( private static String secretKey = “ugfpV1dMC5jyJtqwVAfTpHkxqJ0+E0ae” )

  1. Decrypting Spark Saved Passwords - Adam Caudill (worked for my Spark Version 2.6.3)

  2. Recover Spark IM Stored Passwords with Metasploit - Pentest Geek - Penetration Testing - Infosec Professionals

I just stumbled onto this today, i think maybe i can circumvent this by compiling my own Spark binary (dunno, me is neewb).

Cya guys, btw spark rocks ! =)

Ferit, thanks for sharing (though in the future it is better to use a separate thread for this). I have filed this as

SPARK-1601

But as i said, there are no active developers for Spark currently, so can’t say when it will be fixed. Unless someone shares a patch, then it can be at least patched in the nightly builds.

Hi Ferit,

i think that the encryption method in spark isn’t that insecure as it seems to be. However, it could be better. For example spark could create its own secret key during the first start or you can change it and build your own spark.

But the problem will remain the same, because you have to store the secret key somewhere on your system, because you need to decrypt it. In fact, the a stored key is not a vulnerability because it can not be accessed remotely. If there is somebody who has access to your machine you are always in trouble, because it is necessary that you can trust your computer. Otherwise you will need some kind of asymmetric encryption using a public/private keys to store server specific credentials.

Btw there are a lot of “password encryptors” out there for google chrome, firefox, pidgin, trillian, whatever… but they all need (admin) privileges on your machine.

greetings

Holger, i agree that this is not as a big vulnerability as it seems. But as the key itself is available freely on the Internet, one can find it and use to decrypt passwords if he gets someone’s properties file somehow (say someone’s share it in the forums to investigate some issue without knowing he is actually sharing his passwords in almost plain text).

Considering such a situation, what is your preferred solution? We can create a unique key during first start and store it in a separate file or key chain, as i mentioned above.

btw: we are totally off topic, maybe some one could split this conversation in two different threads?!

I have branched out this from the original thread.

I think generating a new key for every new user (profile) is the preferred solution, in my opinion.