I am actively developing a Bitcoin hardware wallet (like the Trezor), which has a nice color touch screen. This allows it to have an on-screen keyboard and such. It's about half the overall size of a phone, and could easily be made smaller.

Assuming a device similar to that:

1. You can protect the device with a simple pin, and have it self-destruct or similar after a number of failed attempts.

2. There are a lot of great ways to handle backups. On first thought, I would lean towards the following model. When initializing the device, you enter a master password. This password is fed into a ridiculously expensive KDF to create an entropy pool. By expensive, I mean the device will spend an hour or longer deriving the entropy pool. Since you only need to do this when first using the device, or restoring from backup, the inconvenience is minor. The entropy pool is used to derive any and all site-specific passwords. It is also used to derive your backup key. From now on, as you use the device, creating new logins, etc, it can frequently and automatically create encrypted backups of this metadata and shove it to your PC/cloud. The entropy pool is stored securely inside the device, and possibly encrypted with a pin number (see answer to #1 above).

Now, if you lose/damage this device, you just grab a new one, initialize it with your master password to re-create the entropy pool, and then it can sync to a backup.

Thanks to the ridiculously expensive KDF, a malicious attacker would need to spend one CPU hour (or more) per brute-force attempt. Good luck!

Problems with this model: The master password must _still_ be a good password. None of this dog's name nonsense. Otherwise, anyone who gets hold of your backup(s) could chew through the top 100 passwords or something like that. One way to help mitigate this is to mix personal information into the master KDF's input. e.g. ask the user for their driver's license number. Doing this, however, exposes the user to privacy issues; should a hacker successfully crack their backup they have strong evidence who owns the now exposed logins.

Also, backups are still mandatory, or else you'll be unable to re-derive your passwords and other metadata. Since the backups are quite secure, one might feel confident storing them in the cloud. I would prefer a fully deterministic solution, where one can just enter a website name into the device and get their password out ... but due to the varying password requirements of each site this isn't feasible.

Finally, since the master password is rarely ever used, it may be difficult for the user to memorize it. This could be mitigated by also using the master password as the device's pin (a weak KDF can be used here), but then the user has to enter a password instead of a pin, which takes longer, every time they wish to use the device.

3. It can act as a bluetooth and USB keyboard.

The thought of such a device certainly tickles _my_ fancy. Heck, I could build one right now, since I already have the hardware platform to do it. But there is one fatal flaw ... you _have_ to use the device. Suppose you're travelling, forgot to bring it with you, and have no way to get another one. Now you're screwed. The only alternative at that point is to use a software emulation of the device on a PC/phone, at which point you've exposed your master password to the PC and thus potential theft. You get to look forward to coming home and cycling all your passwords later.