How to deal with password in the EPerson Rest serialization

[abollini]

From the #29 (comment)

I'm not sure to like that... I know that this is what happen right now as we have the password in-memory but we should eventually consider the need to reload the entity after the update to be able to serialize information automatically updated for some reason (think about a last_modified or other generated value). In this later case we will be unable to provide the password after the update....
I'm not sure about what to suggest here... maybe we can add a custom serialized that will always expose the password as ***** or we can exclude the password from the returned object (I tend to prefer this solution)

[tdonohue]

I'd like to revisit this ticket as it does seem like a possible minor security issue -- we likely should try to minimize the number of times a password is sent between the client & backend (ideally though that communication is secured behind HTTPS, CORS, etc)

It seems like we might be able to simply fix this as @abollini originally suggested -- ensure that the password is always excluded from the returned object after a successful PATCH. Does anyone have any objection to that approach, or would it cause any issues for the Angular UI? @benbosman , @artlowel or @atarix83 -- any immediate thoughts on how to move this old ticket forward?

(If we agree that it's just a matter of not returning the new password, we might be able to assign this minor cleanup to the same person who claims DSpace/DSpace#2988 as that involves the same area of the codebase.)