Make your classes be nouns, and your methods verbs.

That is, classes are things in your design. Methods are what those things do. This isn't, of course, the only way to design an OO system. But it is a principle that generally leads to reasonable designs, and can sort out a lot of confusion about where the boundaries of class responsibility lie.

With this principle in mind, User is a reasonable class. It represents a person. But Authentication is not a good class. It sounds too much like a verb. If you don't want to put authentication methods into User, the suggestion above to have a Session class makes a lot of sense. In that design responsibility for authentication gets shared. It is up to the Session to know who is logged in. But when you try to login, the Session will have to ask the User to verify the password.

Let's apply this principle to the second problem. Display again sounds like an action, and therefore is a bad candidate for a class. For one thing you're going to have confusion about where methods go. (If I want to display information about a user, where does Display leave off and User begin?) How should you replace it? One approach is to say that Users know how to display themselves. But this turns out to be a bad factoring as you get many different ways in which user information is displayed - User is supposed to know about being a User, not about HTML, reporting, and so on.

A popular solution is the Model-View-Controller paradigm. In this paradigm User is a Model class, it represents actual information about someone in your system. Your Views are your actual output code, generally these are not classes but are actual web pages. The Controller is where Model meets View. It specifies business rules about how and why the Model will change.

In that paradigm, the answer to your question is as follows. You have code that displays and accepts the login attempt. That code calls the appropriate Controller to find out what View comes next. That Controller checks with the Model (in this case User and/or Session) to find out whether a login attempt succeeded, and then decides whether you're next going to have a login failure view (and if so then which one), or an account page.

This may sound complex, but it isn't really. In practice you'll find that your views are very straightforward. Your Models are also straightforward. The icky logic winds up in the Controller. While it still gets icky as business rules pile up, you at least know where to look for that logic in your system.

If you're interested, CGI::Application and CGI::Prototype are two modules to help you get going on writing MVC applications in Perl. Maypole and Catalyst bill themselves as frameworks to help you do the same, the former is simpler but will restrict you more if you want to vary from The Chosen Path. The latter is more complex and flexible. I know that you'll be able to get help at Perlmonks for the two modules that I named. I'm less sure that you'll get good help (though you may) for the frameworks.