> That user function is a brand new issue that I have not as yet confirmed.
> It is on my radar to address. From my recollection, there is no
> mention of
> anything that should have changed in the release notes of Firebird. If it
> has changed then the Firebird team may have broken something.
>
> Regards,
> Jason Wharton

to quote FBRelease notes:
"In Firebird 1.5 the DES algorithm is used twice to hash the password: first
by the client, then by the
server, before comparing it with the hash stored in security database.
However, this sequence becomes
completely broken when the SYSDBA changes a password. The client performs
the hash calculation
twice and stores the resulting hash directly in the security database."
.....
"To be able to use stronger hashes, another approach was called for. The
hash to be stored on the server
should always be calculated on the server side. Such a schema already exists
in Firebird -- in the Services
API. This led to the decision to use the Services API for any client
activity related to user management. Now, gsec and the isc_user_add(modify,
delete) API functions all use services to access the
security database."

The services API does not send or return GROUPNAME which the AlterUser
session function (which uses the isc_user_add API function) relies on.

Alan