Attached patch provide the following:

1. Define password store scheme in schema.py. For example:

user = Class(db, "user",
                username=String(),
                password=Password( scheme = 'SSHA'),  # !
                address=String(),
                ...
                timezone=String())

2. Make available {SSHA} password store scheme.

{SSHA} store scheme is widely used in various subsystems. 
Password stored as {SSHA} can be transfered to and from different
authentication services. This make possible to sync passwords.
For exapmple, roundup password stored as {SSHA} can be transfered to
OpenLDAP userPassword attribute.



Needs testing.

Comments from email list:
=====
From:    Thomas Arendsen Hein <thomas at intevation.de>
Subject: Re: [Roundup-devel] Clearing tracker backlog: issue2550880 add SSHA
         hash for passwords

--===============0527081911609401105==
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline

--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* John P. Rouillard <rouilj at cs.umb.edu> [20160409 03:50]:
> Does anybody believe adding the patch attached to:
>   http://issues.roundup-tracker.org/issue2550880

Feel free to copy my answer into the issue:

It is a good idea, because Roundup already supports SHA, MD5 and
crypt and if people can't use PBKDF2, but can use SSHA or SHA in
their existing environment, they might be forced to fall back to
SHA, or worse: storing the password in plaintext and hashing it
separately for each service.

> is a good idea? The rationale to support a password that is used by
> ldap and other authentication providers seems reasonable, but is that
> something we want to allow/promote?

It is not just Roundup -> OpenLDAP, but OpenLDAP -> Roundup could
then be easily done, too.

> I did a quick review and at first glance it seems to be doing what I
> expect. The tests run and produce what looks like sane hashes.
> I assume SSHA is not considered sufficiently secure since it is based
> on SHA-1.

PBKDF2 is based on SHA-1, too.

SSHA is not insecure, it is just less secure than PBKDF2, which in
turn is less secure than other algorithms (e.g. PBKDF2-SHA512).

But this less security is better than no security, see above.

> If the consenus is that SSHA should not be used, would
> SSHA-512 be considered better?

Same problem: If SSHA-512 is not supported with the other services,
people might fall back to something worse.

> Openldap has a way to use pbkdf2, so that could be used as a common
> password interchange format fulfilling the original requirement.

The module is not included everywhere, e.g Debian jessie. So people
would have to fall back to unsalted SHA or compile _and_ maintain
the module by themselves.

> Unless I hear otherwise, I am tempted to close out the ticket with a
> comment that we only support pbkdf2 and SHA1 is not supported.

At least add support for reading SSHA, but not writing it.

And regarding writing: I think the admin should have a choice.

I'm currently using Roundup's PBKDF2 hashes for Moin wikis, but when
Roundup moves to e.g. PBKDF2-SHA512, this might no longer work until
Moin supports that, too (unless it already does, I have not
checked).
===

More updates from mailing list
starting from:

https://sourceforge.net/p/roundup/mailman/roundup-devel/thread/20160409011634.9DA1781809%40vm71.cs.umb.edu/#msg35003091

This is private email from when I messed up and emailed Thomas
directly.:

------- Forwarded Message
Date: Mon, 11 Apr 2016 16:07:16 +0200
From: Thomas Arendsen Hein <thomas at intevation.de>
Subject: Re: [Roundup-devel] Clearing tracker backlog: issue2550880 add SSHA
 hash for passwords
Message-ID: <20160411155845.746897666.thomas@intevation.de>

* John P. Rouillard <rouilj@cs.umb.edu> [20160411 15:16]:
> >It is a good idea, because Roundup already supports SHA, MD5 and
> >crypt
> Note that all of those are listed as depricated, so should I add in
> SSHA as a depricated algorithm as well?

Sounds good! Then hashes copied from an external source will be
converted to PBKDF2 on the next login.

But make sure that if schema.py specifies a certain hash algorithm,
this algorithm must be the target format for updated hashes, even if
they are deprecated.

> >and if people can't use PBKDF2, but can use SSHA or SHA in
> >their existing environment, they might be forced to fall back to
> >SHA, or worse: storing the password in plaintext and hashing it
> >separately for each service.
> >
> >> is a good idea? The rationale to support a password that is used by
> >> ldap and other authentication providers seems reasonable, but is that
> >> something we want to allow/promote?
> >
> >It is not just Roundup -> OpenLDAP, but OpenLDAP -> Roundup could
> >then be easily done, too.
> I claim that people already using LDAP or AD should be querying those
> services using the recipes on the wiki for getting authentication
> from LDAP/AD.

That should be the case, but often enough isn't, sometimes even with
a good reason, e.g. availability, performance or security reasons.

> Alternatively they can off-load authentication to a web server like
> Apache and use the REMOTE_USER variable to determine who is logging
> in.  (Note using the REMOTE_USER variable may require that the user be
> pre-created. I don't think there is a mechansim for creating a user
> on the fly like there is with the LDAP/AD integrations.)
> Where there is an external source of authority, I claim it should be
> consulted for authentication and roundup should not be using a locally
> cached password.

In an ideal world: Most of the time.
In the real world: Would be nice, but ... :)

Gruesse,
Thomas

[...]
------- End of Forwarded Message

The discussion on the mailing list tended in favor of the patch.

I have merged it in version f0f5293d9939