There are some problems with the security of how Roundup handles passwords.

(a) Password hashes default to SHA-1 with no salt.  The absence of a
salt means that precomputed rainbow tables can be used to attack
passwords (in case the same password was used on another system, say) if
the password hash is obtained.

(b) This is only a single iteration of SHA-1, which means that
brute-force searches can test passwords very quickly; good practice is
to use many iterations.

(c) If a user has access to see another user's item page, the history
section shows past password changes - showing the most recent password
as *encrypted*, but all previous passwords as their full hashes.  I
don't think storing past password hashes is a particularly good idea, as
it gives more information to an attacker who gets the database contents
about passwords that might still be used on other systems, but giving
out the past hashes freely to everyone certainly isn't a good idea.

To fix (a) and (b) I'd advise using an existing algorithm for salted
password hashes such as PBKDF2, based on HMAC with some convenient
underlying hash algorithm and a sufficiently large number of iterations
(say 10000) for modern processor speeds (the number of iterations should
be stored in the hash in the database to facilitate increasing the
default value over time).  Various Python implementations of PBKDF2 are
available.  The salt should be at least 64 bits (in general, the number
of salts should be on the order of the square of the number of passwords
that might be hashed using a given scheme, so that most passwords will
need cracking individually without effort cracking one password helping
on another, and 64 bits is a reasonable approximation to the square of
the number of people alive).

To fix (c) I advise both not journaling password changes in future and
showing all passwords in existing journals as *encrypted*, rather than
just the current one.

Ideally the fix for (a) and (b) would include automatically upgrading
passwords to a stronger hash when users log in, though that only makes
sense in conjunction with a fix for (c).