The unencrypt problem

Openfire Openfire Support
1

this problem is that i want to unencrypt the user passwork where i can find the answer.

thanks buddys.

2

Hi,

Virtually all password encryption algoritms is “ONE WAY” because it’‘s not meant to be read even by its owner. And so, there is no way you could decrypt it or reverse the encryption process. And that is for a good reason: so that the security of this sensitive information is justified. That’'s why if anybody loose his/her password, the system admin always reset it to a known password and ask the person to change it immediately.

FYI, the “TWO WAY” algorithm is applicable when you want to protect a document during its transit, and when it reached the correct destination the person needs to decrypt it so that it’'s readable.

3

Hi,

please look in the free available Wildfire source code, the key which you need to decrypt the password is currently stored in the system property passwordKey.

LG

@aznidin: Wildfire did use a long time no database encryption because "… the client sends the ‘‘username’’, a ‘‘token’’ (the streamID) and a ‘‘digest’’ (digest=hash(streamID, password)). Stream ID’'s are generated by the server and should be unique and random.

To verify the digest Wildfire reads the plaintext password and calculates the ‘‘anticipatedDigest’’ (DefaultAuthProvider.java, line 76ff). If ‘‘anticipatedDigest’’==’‘digest’’ then the client is authenticated.

Storing a hashed password … makes it impossible to calculate ‘‘anticipatedDigest’’."

src: http://www.jivesoftware.org/community/thread.jspa?messageID=111180

4

Ok, understood and thanks again LG for the clarification.

Excuse me for missing the JM-291 and also for not very much into this cipher technology. But the solution caught be by surprise (the way I understood it). Why symmetric cipher? In JM-291 comment collumn, Michael mentioned about the (I think) non-symmetric cipher, didn’‘t he? I don’'t suppose Wildfire is only for services like e.g. chat all the way. What about financial services? Sooner or later the passwordKey will make the sys admin or anybody who can access jiveProperty table rich!

Or am I completely off track?

Please provide me with some insights.

5

Hi aznidin,

  1. if you are the server administrator you can just make a backup of that row, drop the user and re-create it with a new password. After you’‘ve done your ?dirty? $rich$ work you’'ll just drop the user again and restore the column. Also hashed passwords will not solve this problem.

  2. If you are the server administrator you could also write a Man-In-The-Middle plugin to manually filter or change some traffic.

  3. The key will no longer be stored within the database (moving into wildfire.xml) so a DBA alone will not have a chance to do the ?dirty? work on his own.

  4. Use end-2-end encryption to establish a secure connection, this is not yet supported by Spark.

LG

6

thanks for aznidin and it2000’'s help

i know a lot about the encrypt.