I would suggest making your authentication stuff go into one object, but is used by the user object. It's not so much that authentication related to users or certain thigns, but because it deals with persistence usually. By keeping it as a seperate object, you can plug in a new authentication object later.

Same thing for your display vs controller/processing logic. Suppose you wish for your display to be either html, xml or tk? If you seperate your controller stuff from your persistence (persist to screen and database), you gain some future flexibility.

Of course, if this is not really a theory/achedemic question and you just want to get something done, do whatever is concise, and well organized. It's all matters of opinion at that point.

Update: Separating data moving/displaying/persisting logic into own objects allow for easier mock object testing. Implementing your own test object vs doing some sorta code injection by overriding certain things is a huge pain in the ass.