powered by Jive Software

Password hashing


I have read the various threads relating to password hashing and it seems like there is a general request to provide hashed passwords.

Digest authentication is already supported but as I understand it, this is triggered from users login request (SASL, digest etc)

What is not supported is the ability to hash plain text passwords. The arguments against it are well documented in the forums in that its not really secure etc., however if it helps the uptake of messenger, why not add this functionality. A simply property or check box can be added to enable this feature for people who really need it.

What do you think developers? Can we open a JIRA for this?



Does JM-291 meet your needs?


I’‘ve edited this text over and over again, because I’‘m constantly tempted to include all kind of argumentation that probably has been covered before. I’‘m guessing that’'s not what Conor expects from this thread.

So, in conclusion: yes. I’'d really prefer hashed passwords over plain-text ones.

Thanks Noah, missed that one!

Hey guys,

We definitely want to add support for this but it will require a db schema change. We thought that would be too disruptive for the 2.3.0 release, but we’‘re open to other opinions if people feel like it’'s a super-critical new feature to add.



How about removing all user information from Jive completely! I know it sounds crazy, but here me out…

What if we opted to use Apache Directory (and it’'s embedded ldap server). That way…everything is ldap ready…no more configuring ldap as a pre/post process to setup. Ldap becomes a first class citizen in messenger. Another advantage is that we can delegate certain areas to third party ldap server (Microsoft AD and ADAM (user mode active directory)), like user principals and security. User profiles can be stored in the directory or federated out to a third party provider like a database or another ldap server.

What do you think?


Thats a great idea Noah. +1


I think there are some definite plusses to this idea. But, some big negatives too:

  • We’'d have to write LDAP code that can write changes to the directory. The current provider is read-only.

  • Using a directory makes backup much harder. You can’'t just dump your database. Now you have to dump your database and backup the directory.

  • Imports of user data are more complicated.

  • I’'m not sure we can depend on directory functionality. Lots of times, people want to tie into their home-grown user systems.

It’'s also just more… complicated… and at this point you probably know I have gut reactions to things that sound complicated. Have you used the Apache directory before? Is it pretty easy to make work?



This is off topic from the original post…but fun nonetheless

  • We’'d have to write LDAP code that can write changes to the directory. The current provider is read-only.[/i]

Right…the suggestion is to do away with providers and use the directory as the user/profile interface.

  • Using a directory makes backup much harder. You can’'t just dump your database. Now you have to dump your database and backup the directory.[/i]

Different…yes, harder…well that depends. For all the folks that are using AD out there, this isn’‘t a issue that even concerns them. Someone else is managing the AD server anyway or they have their own back up procedures already in place. Perhaps this beckens for an export/import process to be created so entire servers can be upgraded to different backends. HSQL to Oracle isn’'t trivial unless you have an intermediate format. Something to consider.

  • Imports of user data are more complicated.[/i]

LDIF is the import format for ldap. A user can take their address book and export that into LDIF format and vice versa. Complicated for the PHP crowd…you’'re probably right.

  • I’'m not sure we can depend on directory functionality. Lots of times, people want to tie into their home-grown user systems.[/i]

I assume you’‘re talking about existing database schemas as opposed to home grown ldap directories. If someone wants their own database directory than they’‘re going to have to go an AuthProvider anyway and these folks fall into two categories…either they know what they’‘re doing and don’‘t need our help, or they don’'t.

What I’‘m suggesting is just an idea to make Messenger more flexible when it comes to configuration. I don’‘t have experience with Apache Directory, but I do know Ldap, OpenLdap and AD pretty darn good and it sad to see directory used in such limited ways. I’‘ll admit that not everyone has my anti-social agenda to spend time digging through these protocals and just wants the thing to work out of the box. Is there a better way? I’‘d say yes, but it’'ll require some engineering on our part to get there.

Here’'s something to feed your gut

Things should be made as simple as possible, but not any simpler.[/b] Albert Einstein[/i]

Better LDAP support would be great (in the form of setup wizards), but from my experience its a pain if you have to do more than read from it. There are better tools to do that kind of work, and given the variety of users out there, mandating LDAP would be a real turn off outside of the corporate environment.


Hi Conor,

I agree with you 100% about mandating LDAP support. I was thinking of more adding ldap as the underlying interface to user/profile information. From a user/admin’'s perspective nothing has changed. A default ldap provider could still use the database to store information just like it does now, but the java interface is JNDI and not JDBC. This would be an OOTB configuration and changing it could be done on the fly with an admin gui, or they could sit side by side since difference OUs are mapped to different backends.

Food for thought.


Would it be feasible to map roster to address book? And what about everything else stored in the messenger database, the point Matt raised is very valid where then with a baseline installation you have a Directory and Database, this makes setup, backup, and other maintenence related activies much more difficult.

It would be feasible to map roster to address book (if we’'re using ldap ;).

You missed my point. If we create a level indirection through JNDI (LDAP) to the database then switch between the two won’‘t be so “hard.” Backup is still a database, assuming that the default configuration is an Ldap provider backed by the database. Like I said before, the user/admin won’‘t see any difference. Only if a user chooses to use an Ldap provider that stores the information elsewhere would they have to worry about backing up to spots, but by the very fact they’‘re interested in this functionality means they’'re ready to take on the additional maintenence.


http://penrose.safehaus.org/ looks interesting…you can configure to use a database behind the scenes and actually mix and match database to AD. There’'s even a tool for those that are inclined to make such a mapping. Initially backup for OOTB would still entail backing up a single database (plus configuration, but you need to do that anyway).

Interesting piece of software.


Storing passwords in plain text would have our security people crapping themselves.

For us its super-critical.

Let me know if there is anything we can do to help.