Overall, your implementation looks good.

^{The example you've chosen is slightly contrived (you're reinventing the wheel in regard to validation, and passwords should be either immediately discarded if invalid or hashed, no point in keeping them in plain text regardless of their validity), but assuming that the code is written only in order to get familiar with the pattern, it's fine.}

Design considerations

In the Decorator pattern we need to have a base contract, which is usually an interface, let's call it Foo (sometimes, for example in java.io, an abstract class can be used in this role).

There should be at least one basic implementation of Foo (sometimes way more than one). And several decorating implementations which have a field of type Foo.

The purpose of the pattern is to avoid the combinatorial explosion of types, i.e. there are a lot of combinations of additional features (which decorators represent) and basic implementations so that if every sensible combination would be implemented separately we end up with tons of classes. And that's what you've demonstrated: you have a basic implementation and 4 decorators as an equivalent of 16 classes, representing different combinations of features.

Also note, that the abstract decorator is not mandatory. Yes, in the GoF book there are concrete decorators and an abstract one, but any abstraction introduced in the code should be there to help in managing the complexity (not the opposite).

In your case, all method defined by the base interface are overridden in every decorator. Extending PasswordDecorator in decorating implementations only safes you from placing the field of type Password in each implementation, which is not a lot and if delegate Password would show up explicitly in a decorator it wouldn't be a bad thing.

But you can make the abstract decorator more useful by defining the logic for combining error messages and checking the validity inside it:

public abstract class PasswordDecorator implements Password {
    protected final Password delegate;
    
    public PasswordDecorator(Password delegate) {
        this.delegate = delegate;
    }
    
    @Override
    public String getPassword() {
        return delegate.getPassword();
    }
    
    public boolean isValid() {
        return verifyValidity() && delegate.isValid();
    }
    
    protected abstract boolean verifyValidity();
    
    @Override
    public String getValidationErrors() {
        return getError()
            + System.lineSeparator()
            + delegate.getValidationErrors();
    }
    
    protected abstract String getError();
}

While each concrete decorator would mind only performing its own validity check and issuing only an error message related to this check:

public class MinLengthValidator extends PasswordDecorator {
    private static final int MIN_LENGTH = 8;
    
    public MinLengthValidator(Main.Password password) {
        super(password);
    }
    
    @Override
    protected boolean verifyValidity() {
        return delegate.getPassword().length() >= MIN_LENGTH;
    }
    
    @Override
    protected String getError() {
        return "Need at least %s or more characters".formatted(MIN_LENGTH);
    }
}

Note that isValid() implementations in decorators in the code shared in the question are broken because they do not delegate the call to wrapped Password, but only performing their specific check.

Naming

You would advise using the name delegate (or something similar) instead of password, because it describes its role by telling that it's an object to which the wrapping decorator eventually delegates method calls performed on it.

And also because things like this password.getPassword() look slightly confusing for the reader.

Don't assume system-dependent properties

Line separator depends on the OS of the hosting machine (it might be "\n" or "\r\n").

Use System.lineSeparator().

Try to stay away from objects with invalid state

The idea of having validation in place and at the same time having a type that treats both valid and invalid data as normal isn't looking quite right.

As a consequence, a developer dialing with such a type is always forced to check whether the state of an instance is valid or not.

It's better to disallow illegal states to begin with.

And if you chose to do so, methods isValid() and getValidationErrors() would no longer be needed inside the Password (in fact, there would be no need in the Password object it itself). The proper place for these functionalities would be a separate stateless type:

public interface Validator<T> {
    void validate(T t) throws ValidationException;
    boolean isValid(T value);
    String getValidationErrors();
}

Note that we have an additional method validate which is intended to be used in the client code, and also isValid now expects an object to be validated as a parameter.

Here's the abstract decorator:

abstract class PasswordValidator implements Validator<String> {
    protected final Validator<? super String> delegate;
    
    public PasswordValidator (Validator<? super String> delegate) {
        this.delegate = delegate;
    }
    
    @Override
    public void validate(String value) {
        if (!isValid(value)) {
            throw new ValidationException(getValidationErrors());
        }
    }
    
    @Override
    public boolean isValid(String value) {
        return verifyValidity(value) && delegate.isValid(value);
    }
    
    protected abstract boolean verifyValidity(String value);
    
    @Override
    public java.lang.String getValidationErrors() {
        return getError()
            + System.lineSeparator()
            + delegate.getValidationErrors();
    }
    
    protected abstract String getError();
}

Concrete decorator example:

public class MinLengthValidator extends PasswordValidator {
    private static final int MIN_LENGTH = 8;
    
    public MinLengthValidator(Validator<? super String> delegate) {
        super(delegate);
    }
    
    @Override
    public boolean verifyValidity(String value) {
        return value.length() >= MIN_LENGTH;
    }
    
    @Override
    protected String getError() {
        return "Need at least %s or more characters".formatted(MIN_LENGTH);
    }
}

Validation exception is expected to carry the error messages issued by a validator:

public class ValidationException extends RuntimeException {
    public ValidationException(String message) {
        super(message);
    }
}

And the client code might look like this:

public class PasswordManagementService {
    private final Main.AbstractPasswordValidator validator;
    // ...
    
    public PasswordManagementService(Main.AbstractPasswordValidator validator) {
        this.validator = validator;
    }
    
    public void updatePassword(String newPassword) {
        validator.validate(newPassword); // if it's invalid the execution would terminate
        
        // proceed with business logic: 
        // generate the passwords hash, update the database entry
    }
}

The password is not coupled with the logic of validation. You can still have Password as a separate type if you wish, but it gives no benefit, in popular security frameworks, like Spring Security, hashed password is only an attribute of a type representing an authenticated User (or the user that is trying to authenticate).

Validators are stateless and can be instantiated only once, and then reused and safely shared between different threads.

And yet it's not the optimal approach. Yes we've implemented Decorator pattern, but in comparison with the annotation based validation, it is very rigid and requires a lot more code (see the caveat with the link to Jakarta Bean Validation API at very beginning of the answer).

It would be cleaner to sprinkle a couple of annotations in the DTO carrying the password.