That's quite a tedious path you follow every time :) It might be fine for a one-off action like Genoa2Siena migration, but there's no need to do it with regular updates.
First, let's repeat the rule #1: don't copy entire database and datas from localhost to production, it breaks things. Apart from that login issue, you loose all the data that has been added by users on the production site from the period you made a dump of it for your localhost.
Then, let's make it clear that there are different kinds of updates that you make to the production site:
Cotonti updates, 0.9.10 => 0.9.11, 0.9.11 => 0.9.12, etc.
Theme updates, editing tpl/css/js files, adding pngs, etc.
Extension updates. Installing new plugins, modifying tpls for them, testing data.
Content updates. Adding new content on site like pages, forum sections, etc.
Now comes the rule #2: these kinds are handled differently.
These are described here. Shortly, after downloading another cotonti update, just overwrite the old files and run install.php to update the database. I apply the same procedure to localhost first and if it is fine, I apply the same procedure to the production site (without copying stuff to localhost and back again).
Edit and test on localhost, then upload to production.
This gonna be the trickiest part. If you add new functions to your site and want to make them work on localhost first, then:
Yes, copy files and data from your production site to localhost if you feel that it is necessary to test stuff. But don't copy these: datas/config.php, datas/cache, and some MySQL tables such as cot_config and cot_cache. In most cases this step is optional, I don't do it more often that once a few months.
Install plugins, modify tpls, enter test data on localhost. Remember what files you modify and how you enter the data, but all you do here is mostly a draft.
Copy the new/updated files in modules, plugins and themes folders to production site.
Don't copy the database or datas! After uploading the files, you have to install plugins on the production site and enter the data if necessary via forms. But it doesn't break anything or loose data users submitted while you experimented on step 2.
This is it.
OK, here comes the rule #3: don't use localhost to update production site's contents. Really, use localhost to play with extensions and templates, but contents should be edited on the production site directly. Use Drafts, Validation queue and Permissions to hide stuff from visitors' eyes unless you want them to see it.
Ah, and the rule #4: make backups of the production site from times to times. Just in case it all goes absolutely wrong one day.
May the Source be with you!