Hashing a password before using for online accounts
Is there any problems from using the approach I am suggesting?


Yes, there are several.

First of all, some sites generate first time passwords, or even long time passwords. You may want to store those too. What if a site requires frequent updates?

If one password is reversed, you'd still loose confidentiality.


  Would it actually be less secure if the server encrypted my already encrypted password?


No, usually not. If you don't know the server's key then using encrypted input will not change encryption. Same goes for password hashing basically. If you don't operate with the same parameters (e.g. salt), then you are unlikely to be vulnerable.


  Should I encode the output in base64 or ascii85, or something similar?


Anything the target site accepts. This points to another issue since the sites may require passwords in a specific format. Both the alphabet (character input) of the password and the size may be restricted. So some sites would be better off with base64, some with base 85 and others with neither of the above. E.g. an 8 character base 64 string only has 48 bits of security, allowing brute force attacks. How are you going to remember which format is best for specific sites?


  Which algorithm would be best suited to this task? Do I need something more secure like SHA-1 or will the more primal MD5 be adequate (would anyone care enough to try to break the hash)?


When constructing security protocols you'd have to assume that somebody "cares". Otherwise you might as well skip the whole thing. That said: no, SHA-1 or MD-5 will likely not influence the choice much.



That all said and despite all the indicated issues, hashing the password is still somewhat more secure than providing a password with extension directly. But since you would need to have a device &amp; application for this anyway, I'd recommend using a password manager instead (that e.g. applies a password hash or PBKDF over the master password to decrypt the database).