Duplicate.
The password will never be completely secure, because it only represents one side of the security pyramid (who you are, what you have, what you know).
Seeing the various USB password keepers gave me an idea: a USB Key. I am imagining a small USB drive-like device that contains a kilo-bit or mega-bit encryption password for each website you create a password for. So to log on to your bank account, you would need to enter a username, a password, and insert your USB Key. 256 bit encryption is difficult to crack, 256,000,000 bit encryption would be near impossible.
I like my bank’s feature that doesn’t allow me to access my account from a different computer without jumping through some hoops (phone call verification).
I run a phrase through a l33t translator and adjust it back a little if it’s a little too complicated to remember.
th@t ¡§ @ v€r¥ ¡nt€r€§t¡ng @ppr0@çh £§µr@.
We have things like that already. The problem is in the infrastructure. Financial institutions have been deploying physical security devices to customers for years, but the things are unique to that bank as they are supported 100% by, and only by, that bank. Even within a bank, they’re not inter-operable between departments. I used to have four tokens, all made by the same company, and I had to put labels on them as they’re otherwise identical, save for the serial numbers engraved on their backs. Pretty horrible, actually - one for remote access, one for Unix server administration, one for bank wires access and one for some obscure but highly-secured thing that I only needed to access once or twice a year.
There have been a handful of pretty feeble attempts to get a common infrastructure set up for consumer-oriented websites to be able to use these types of devices, but they’ve all died for various reasons.
“There’s no money in it” is probably the most popular reason, followed by “Can we really trust <fill in the blank> to safeguard our information after they <were hacked and/or leaked consumer data>?”
One of the biggest problems with “What you have” vs “What you know” is not losing or breaking what you have, or it becomes what you had, and useless.
Tokens, USB keys and smartcards are not necessarily laundry-proof, nor are they apt to survive being left in your car in hot Arizona sun, and they really don’t survive being chewed on by dogs. Anyone who wants to implement these things must be prepared for a drastic increase in helpdesk calls.
Like them or not, we’re pretty well stuck with passwords
Then someone needs to come up with some kind of “password certification” program - to be certified, the system must at a minimum accept a password with the following rules (example):
-
Maximum significant password length cannot be less than 30 (significant meaning that two passwords, each 30-character long, with only the last character being different, are considered by the system to be two different passwords)
-
Acceptable characters in a password include at least the following characters
2 a) ASCII certification: any character in the US-7 ASCII set from hex 21 through hex 7E
2 b) Western European certifcation: any character in 2 a) or in the MES-2 Unicode subset
2 c) International certification: any character in 2 b) or in one of the following: chinese characters unicode NNNN through MMMM, japanese characters unicode NNNN through MMMM, korean characters NNNN through MMMM, etc.
(edited to add rule number 3)
3) Minimum acceptable password length cannot be greater than 8 (meaning 8-character passwords are OK)
other rules as devised by people smarter than me
Eh, maybe in thirty years, once we finally get rid of the legacy systems that I deal with every day like Unix servers that will cheerfully ignore anything after the eighth character - **passwrd1 ** and **passwrd12 ** are read as the same, crotchety old mainframes that can only use **# ** as a special character, Tandem-based relics that can not use any non-alphanumerics at all, Oracle-based things that demand the first character be a letter, and so on.
My idea wouldn’t work with legacy systems, but it could be a standard for any new password system. Like most new versions of operating systems / databases have facilities for dealing with unicode representations.
By the way, I’m an Oracle DBA so I was nice enough to choose criteria that would work with Oracle. 
Though I should have modified rule 2 to read:
It is acceptable (but not required) to restrict the first character of the password to this set: ASCII-7 character in the range Hex 65 through Hex 90 (latin alphabet uppercase A through Z) or Hex 61 through Hex 7A (latin alphabet lowercase a through z)
I have a huge number of passwords, and it’s hard to remember them all…so, what I do is use the first three letters of the site I’m accessing as the beginning of the password and then use a standard alphanumeric to finish out the rest.
For example, if I was signing in to MySpace, I would use something like:
Mys0831Mary!
(I don’t have a MySpace account—that’s just an example).
Helps in remembering all the damned things. And, for those sites that require changes periodically, I make my way down the special characters on the keyboard:
@,#,$,^,%,&,*, etc.
Works for me.