As you've identified,
saveUser(User user) couples the two classes. This is not always bad. If the sole purpose of class B is to save a User then it's fair enough for it to expect a User object to save. However, it does potentially lead to extensibility issues, if the model is complex enough.
It also gives the saveUser method access to any logic you add to your User class. A low risk, but a risk nontheless.
On the other hand,
saveUser(String username, String password) carries its own problems. it is very easy, especially when you have 10 or more parameters, to get them mixed up. If someone accidentally types
saveUser(user.Password, user.Username) then you're not going to get a compile-time error, or even a runtime error, it's going to happily save those strings in the wrong fields.
Also, a very long list of parameters can make your code unreadable.
A better option is probably to use an interface
saveUser(IUserDetails user) which doesn't couple the classes to each other, but rather couples the saveUser method to any class that contains the data it requires to perform the task it has been given to do -- save a username and password.