I don't get it- how can I put a "one time password" into one password? What is that even- a one time password? Is this the kind of code that I get sent via text in a two factor auth app? Saving this would defy the purpose, wouldn't if?
1Password generates the code. Same as one you'd receive over text, yes.
A One-Time password is the same thing as receiving the 6 digit code via Text.
To be clear, although the user uses it in a similar manner (enter username/password, get challenged for a code, get the code, type it in), the mechanism is both different, and more secure. And the code generated for 2FA (two factor authentication) is
not the same code you would have been sent via text or email.
With systems that send you a code, they generate a random number and both send the number to you (via text or email), and store it on their system for a limited time (could be 5/30/60 minutes, perhaps even a day, all depending on how they balance security/paranoia vs customer convenience). If you type in that code before they expire it off their system, you're in. And it doesn't really matter what number they choose, as long as a) it isn't easily predictable, and b) matches between what they generated and what you typed in.
The problem is, if someone can intercept your email or text messages, then they can get that code too. This is easy enough with email if someone can get/guess your password, but it can happen with phones too: Say a bad guy calls up your carrier, pretends to be you, says they(you) are on vacation and somebody stole your wallet and phone and you just got a replacement phone, and darn it, just can't remember the code (or weird answer to a security question) right now, as that information is at home and you're on vacation and you really need the phone to work right now so you don't miss your flight/cruise/reservation/whatever. Social engineering 101. If they're skilled and emotional enough, and the customer rep wants to be helpful (and isn't vigilant enough), your carrier may end up changing the MEID/IMEI associated with your phone number, in your account, to the MEID/IMEI that the bad guy gives them for a phone he has (your "new phone"). Now the bad guy gets your text messages. And can use them to receive the needed security code for logging in to your account. And this is a thing that has actually happened. More than once.
With 2FA systems, both the website/company, and the individual (and their phone or special security device) know a shared secret. Often a very large number or a non-trivial passphrase. And every minute (actually, they generally skip doing the work unless you ask) they take the current time, as a number, and encrypt it using that shared secret as a key, and then do someting to shorten in to a small number (say, 6-8 digits), either by using only the last/lowest 6-8 digits, or taking a checksum of the encrypted value. Given today's accurate, synchronized clocks (your phone can easily be within a second of the real time as can the website), now you've got a code number that can be matched between the two ends to verify that you both know the same original shared secret. And the code number changes every minute, in a way that is
completely and utterly unpredictable without the shared secret. It doesn't matter (to the security of this test) if anyone can read your email or text messages, because the website/company isn't sending you anything right now - your shared secret was chosen long ago. (And even if someone gets the code number right now, say by looking over your shoulder, in less than a minute that particular code number will be useless.)
So, both systems end up with a 4-8 digit number for you to put in after your password, but the mechanism behind the scenes is quite different, as is the resulting level of security. The code-sent-via-text method is better than only having a password, but it can still be subverted by a determined attacker. The shared-secret method is much harder to break (they need to find a flaw in the 2FA implementation, or hack into the website or your phone to obtain the shared secret - which, hopefully, isn't sitting around in plaintext on either end).
And it seems that 1Password (which I've happily used for many years) can now handle the real-time generation of these one-time codes (indeed, it seems it's been able to do so for quite some time - I hadn't been paying attention - and now makes it more convenient). As a number of kind forum members have pointed out in response to my previous post
(Thank you, @BasicGreatGuy, @farewelwilliams, @jclo, and @Fiestaman!). Clearly I need to look into this.
Footnote for those suggesting Safari & Keychain, vs. 1Password: Keychain, for storing website passwords, is good, as far as it goes, but it's mostly limited to Safari. Not as helpful with other browsers. And I also use 1Password for storing a variety of information I may need to access but want locked away (e.g. my wife's SSN). Keychain isn't very helpful in this regard - you can make notes in Keychain Access on the Mac, but they not well-organized, and there's no equivalent iOS app. 1Password is great for this kind of stuff (and it's cross-platform as well).
