You can use a YubiKey for Google 2-factor along with a helper app like Yubikco's "sidekick" for Windows [1] or my company's OneTime on Mac [2]. A YubiKey costs about $25 but is very portable, fast and convenient option.
My company has a line of credit from our bank. Thankfully, we've only had to draw heavily on it once, but it was a life saver at the time.
We had a situation where we simultaneously hired new employees, kicked off several sizable consulting projects and were stuck with late payments on several projects. As a result we were cash-flow negative for several months. Drawing on the line of credit helped keep payroll, AP, etc running smoothly. As a small company it's a nice low cost way to have ready access to money which you can use for anything (not just purchases).
With decent credit we were able to get a line capped at about 1/6th of our yearly revenues with a ~4.25% interest rate. This was a much higher limit and better rate that we could get with AMEX advances. The only downside is the amount time and paperwork involved, since you generally need to provide tax returns, P&L, balance sheets, AR statements, and go through lengthy approval process.
The keychain is really great for convenience, though it is dependent on the iOS passcode. Users are free to setup their phones without one, use a weak pin, etc. It's exceedingly rare to see an iOS user with a strong multi-character passphrase. For enhanced security there is really no substitue for a suitably long/strong passphrase.
With regard to the second point, one added benefit of SQLCipher over a roll-your-own solution is that SQLCipher automatically applies PBKDF2 derivation. It handles most of the security under the hood so that the application doesn't need to worry about it.
On iOS keychain access is not dependent on the passcode. Each application has access to its own keychain and cannot access the keychain for other applications. The keychain will still be encrypted even if there is no passcode set.
Perhaps my comment wasn't clear. I agree that its not possible for one application to access another's keychain items. However, this isn't the only attack risk, and access to keychain items in general is based on the passcode. This can be a problem if weak passcodes are used and an attacker can get access to the device. There are some relevant comments in this paper:
http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-...
I agree that this could be a problem but in this paper in order for the attack method to work the developer of the App would need to explicitly set the keychain attribute with the flag "kSecAttrAccessibleAlways", making the keychain data available even when the device is locked, "Otherwise the credentials of the app are not affected by the attack method."
Section 2.15 deals with the conditions under which the Keychain should be considered secure:
- Items are stored with a protection class that makes them only available when the device is unlocked. (see Section 2.14)
- A strong passcode of 6 alphanumeric digits is enforced (reduces the risk of brute-force attacks)
The second point is as relevant as the first. The paper goes on to say:
according to [App10b]: ... The standard simple code of 4 numeric digits would be brute-forced in less than 9 minutes. Based on the assumption that the counter for wrong tries in the iOS can be bypassed, as it is not hardware-based. [BS11b] provides a tool for passcode bruteforce attacks.
Forensic toolkits, like the one from Elcomsoft (http://www.elcomsoft.com/eift.html), are able to recover numeric pass codes and extract data in less than an hour, even on newer devices.
With a weak passcode, which most people use, the keychain does not offer much protection against dedicated attackers with device access.
[1] http://yubico.com/totp [2] http://zetetic.net/software-onetime