That's not TFA since the piece of paper with the passphrase is not "A thing you have". It's just "another thing you know." and thus brute-foreceable. It's the same as not allowing the user to choose a password but rather generate 12-character random passwords with special chars.

Authentication devices for TFA are designed, so that you really have to have the device close to you when you do a login.

Another issue with this is it breaks password managers, including the built-in browser password storage. While you might say that's a Good Thing for security, it's not something you could easily pull off as a startup.

Due to lock-in effects, people have to deal with all manner of usability hell from their bank, but the same logic doesn't apply to startups. Not that your idea is usability hell, but you probably don't want to make it any harder than it needs to be.

I think adding a few characters to the minimum password would be equally secure and more consistent with tooling, as well as a more familiar model for users.

Also, 2FA might be easier than you think using a service like Twilio. Or another way to do it would be to let the user connect via a service that does support 2FA (e.g. Google or Twitter;and maybe adding your own password if you want to harden that).

I recently added 2FA (OATH/Google Authenticator) support to Persowna[1], and it only took about two hours, 1:55 of which was spent on the UI. It's really not very hard.

[1] https://www.persowna.net/

> I think adding a few characters to the minimum password would be equally secure

Do you mean saying to the user, "your password must be at least 12 characters long"? That would just result in the user adding "12345" to the end of their standard password. Still seems much easier to crack than 4 random words.

> Also, 2FA might be easier than you think using a service like Twilio.

It might be easy for me to set up, but for my users (who are mostly non-technical) it is still relatively painful to install and set up a two-factor authentication app. I think most of my users would prefer the write-down-four-words option, even if it is a little less secure.

> you probably don't want to make it any harder than it needs to be

OK, so the question is, "does it need to be harder than the standard login form of username and password field?". Since my system deals with sensitive financial data, and given the problems with allowing users to pick their own password, I would say the answer is "Yes"

I think you need to analyze the risks more specifically.

You should rate-limit login attempts on the live site. Even allowing only one login attempt per second kills any brute-forcing attack if your passwords have even mediocre complexity.

Password cracking is only really a threat is the bad guys get your database. And if they do, it's not much more difficult to crack two passwords than one.

The point of true two-factor is that the second "password" which comes from the device is never stored in your DB, so it cannot be cracked. That is not true of your approach.

Yes you are right that it is not 'true' two-factor authentication. It would certainly be more secure if all my users were able and willing to use something like Google Authenticator. However, I suspect that most of my users (who are not especially computer literate) would prefer the simplicity of writing down 4 words over having to install and configure an two-factor app on their phone.

You say, "it's not much more difficult to crack two passwords than one" but I don't see how that is the case if the second password is four words chosen at random from a dictionary of say 5000 words. Such a password is far more difficult to crack than the average password chosen by the average user. Having a second passphrase generated by a computer also eliminates the problem of users re-using the same password between sites, or choosing "letmein" or "password1" as a password.

Why not just require your users to set a 4-word passphrase as their password? You'll capture more variations than you would working from a fixed 5,000 word dictionary, and your users can still choose to write the words down if they want--or they can use the password management features of their browsers if they want. Plus it would be more simple to build and maintain, which is a plus when it comes to security.

The problem is that the average user is really bad at choosing a password. If the system requires a four-word passphrase then the user will choose easy-to-crack passphrases such as "use the force luke" or "john paul george ringo".

If the system randomly chooses the four words then you force the user to exchange convenience for security.

Then why let users choose a password at all? Why not just assign them one that they have to write down? And if they're going to write it down anyway, why make it words? Why not generate a 20 character random string?

I obviously don't have the whole picture of your effort, but from your description so far, I think you are over-emphasizing the importance of clever password schemes. As Colin points out in the top comment, hashing with scrypt will make even mediocre passwords uncrackable. So it would be a better use of your time to implement scrypt or bcrypt with just one password.

And high-speed cracking is only a problem if the bad guys get your password table. To do that they will have to get into your application...and if that happens there are all sorts of other problems. So I'd argue that spending more time testing and proving the overall security of your app is also a better use of your time.

> Then why let users choose a password at all? Why not just assign them one that they have to write down?

Because then anyone who reads what is written down gains full access to the user's data. A password (kept in human memory) plus passphrase (written down) is more secure. I would agree this comes at the cost of convenience, but I think the trade-off is worth it.

> Why not generate a 20 character random string?

Because it would be a real pain to type each time the user logs in. In this case I don't think the security/convenience trade-off is worth it.

> As Colin points out in the top comment, hashing with scrypt will make even mediocre passwords uncrackable.

True, but what percentage of users choose poor passwords - not mediocre ones? Scrypt will not be much good if the user chooses a password from the dictionary, or a word that appears in a list of the top 10,000 most common passwords. (Edit: According to Mark Burnett [2] such passwords are chosen by 99.8% of users)

> And high-speed cracking is only a problem if the bad guys get your password table.

The password + passphrase model also protects users who choose the same password for different online systems. A weakness in some other website (or something more evil [1]) will not compromise the security of my online system.

Edit: Low-speed cracking might also be a problem. Mark Burnett says 14% of users have a password from the top 10 password list [2].

[1] http://xkcd.com/792/

[2] http://xato.net/passwords/more-top-worst-passwords

You are presuming that your users would not write down the password they choose for themselves as well, perhaps on the same sheet of paper.

I'll leave this final thought--how many other websites have implemented a double password system like the one you're proposing? I don't know of any.

Is that because you have come up with a more secure solution that no one else has thought of? Or that your approach does not confer the security advantages that you think it does? Which is the more likely explanation?

It's certainly better than just a password, and as you say is a nice balance between usability and strong passwords.

However, I'd be careful about thinking of it as any sort of 2-factor authentication and wouldn't bestow any of the advantages of 2-factor auth on your scheme.

A static secret, no matter how complex, doesn't really prove ownership because multiple people can trivially have a copy of the secret at the same time. So you don't have a knowledge and a physical factor, just a convoluted knowledge factor.

Better than just a password, but don't let it g e you a false sense of security.

The passphrase looks to be very weak if it is just something like 4 english words. And fails on the convenience test.

Correct horse battery staple comes from https://xkcd.com/936/

Except everyone will lose their passphrase. Everyone.