DDD – Managing Long Running Background Threads and Reporting Progress

Sounds like you are using domain entities for both domain operations (commands, which modify application state) and queries (which don't modify application state, but return data for the user). The problems you describe are a direct result of trying to get that single domain entity to do both jobs, which don't mix very well.

My recommendation is to read on CQRS (Command Query Responsibility Segragation) e.g. CQRS by Martin Fowler and try to limit your domain entities to only retrieve what data they need to complete the domain operation. Even though the amount of classes and interfaces will grow, your application will become much more simple and more maintainable due to more adherence to the Single Responsibility Principle.

Also, your choice of domain objects and especially Aggregate roots leads me to question the validity of your domain model. Is a File really such an entity, that it's of dire meaning to the business people? What kind of operations do you do on the file, and what's their value to the business? The whole idea in Domain Driven Design is to identify the actual business entities on which you should act, as if you wouldn't have a computer at all. An Order is a common example. Operations on that Aggragate root would be "Submit", "Cancel" etc. File is just an infrastructural concern, which most often has no value or place in the domain logic.

It's not terribly important where exactly the password is hashed, as long as all of the hashing is kept together in one place. E.g. an entity like this would be perfectly valid:

class PasswordAuthentication {
  private User user;
  private String hashedPassword;  // includes salt

  /** Check whether the provided password is correct.
   */
  public boolean checkPassword(String plaintextPassword) {
    return secureCompare(hashedPassword, passwordHash(plaintextPassword, hashedPassword));
  }

  /** Set a new password.
   */
  public void resetPassword(String plaintextPassword) {
    hashedPassword = passwordHash(plaintextPassword, createNewSalt());
  }
}

Your point about an “external service” is correct, in so far as user authentication is often a separate bounded context from your main domain model. It is correct that e.g. an entity the represents a user profile shouldn't also do crypto.