This is a nice article. Only thing missing is calling out "secret questions" as asinine.
I loathe when sites require you to set them up as it requires manually generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3) and saving the pair (question plus random text) as metadata associated with the account. Not exactly pulling teeth but it's pretty annoying to manually do that for 3-5 entries.
Even worse offenders are the sites that don't even let you enter a value in a text box but instead require you to pick from a drop down with a handful, say 10-15, of entries (cough United Airlines cough).
And the very worst offenders are the ones that, after successfully authenticating with your password, ask you for the answers to the secret questions every single time you log in (cough again United Airlines cough).
When joining my place of employment I had to fill out my I9 electronically. The website had me set up an account to store my information, and gave me the following dropdown for my secret question: https://i.imgur.com/iOsNmIk.png . For those unwilling to click, they are:
- What is your mother's maiden name?
- What was the last school you attended?
- What color eyes did you have when you were born?
- What was the last year you attended school?
So obviously you just fill in some random string as the answer, but immediately after it you had to check a box that said that you swear under penalty of perjury that all information you put into this form is accurate... I'm sure that was intended to apply to the I9 stuff but technically it includes the secret question :[
This "protects" an account that has my social security number in it, among other things.
It's nearly impossible to remember what you answered for those questions anyway. For first car did I write "Ford", "ford", "Focus", "Ford Focus", etc?
I don't have a specific favorite movie or song. Lord knows what I entered into one of those boxes a year or two ago. Whatever it was, I bet it wasn't as secure as my password.
One of the questions my bank asks is what middle school I went to and I used my elementary school by mistake. I just listed every school I went to to the guy on the phone when trying to unlock my account. It's a good thing they also ask for SSN/amount previously in the account/who your last check was made out to and that sort of thing.
A secret question asked by a bank would be a strong hint for me to take my money elsewhere. They definitely should be using one-time keys from a paper slip or some similar third factor.
Does any bank (or anyone, actually) really do this though? It's easy to say you should take your money elsewhere, but where would you actually take it?
In Finland they all do. Before mobile apps, they mailed you cards with one time passwords in them, every time you logged in you had to provide your account number and OTP. Also, every time you confirmed a payment, you had to use a random security code from said card.
These days they provide apps for phones where when you make a payment you have to open the bank app and enter your PIN to confirm the payment. Same for logging in to online banking (for which there are mobile apps as well).
Also, when making a debit/credit card payment online, you also have to confirm it with one of the aforementioned methods. You can't do anything with just the card details.
I can't believe some banks around the world use plain old passwords only...
If a bank doesn't offer something like that, but still happily does online banking, I'd take my money... anywhere else, even a mattress or the sugar jar.
My bank goes a step farther and requires me to physically show up in their branch office and verify my ID. It has to be the branch near my residence.
It's not a bother since it's a 5 minute walk but I imagine that it would be hard for anyone other than me to actually do this, they'd have to show up there and convince the people there they are actually me (and some of these people now me personally)
I'd say that this would be the optimum in security.
Answered the sibling already, but I have experience only with European banks where I don't see this happening. I have account in two banks, both of which provided a paper slip with one-time authorization codes.
One european bank I have account at uses security question, but it seems to be only used as additional layer of authentication when you make changes to your account settings (in person) and not for anything online.
I started to store them in my password manager for that very reason that months later I'd never remember exactly what I put down.
Then the next point is realizing since they are "bonus passwords" anyway you might as well randomize them and use password fields. (In the Advanced Fields properties of an entry in KeePass, for instance, you have a key-value store and when you add one the "Protect in Memory" treats the value the same as KeePass treats other passwords.)
The final realization was that these questions should probably be labeled "Phone Passwords" and in which case use something like Diceware that produces easily pronounceable over the phone passwords.
When they ask you for a first car you should answer, for example, "yellow" or "miskatonic university". When they ask for favorite music band you answer "ford". Choose random words or even random strings. Nothing related to the question itself. Just write them down. Most password managers allow you to add a notes. Of course only when you can't avoid "secret" questions... At least no one will be able to profile you and guess the answers.
Lets see, when I answered this question was I listening to heavy metal, classical, country, or... I happen to enjoy all of the above at times despite them being vastly different they are all music (or can be - I have heard examples from all 3 that are not)
I generate answers to secret questions, and store them in my password manager. They're specific to the account – “mother's maiden name” at Site A is not the same as “mother's maiden name” at Site B.
If you do this, use a password recipe that generates a small number of words instead of a large number of characters. If you ever need to use the recovery questions, it will likely be by reading them over the phone.
Apple security questions are limited to 32 characters or the like. I used 5 words answers and they where accepted but not recorded in full length :-(
One day I needed them and then I had to reverse engineer their security questions algorithm. Imagine the poor soles that aren't as technical to figure this out.
One time I was so irritated with security questions when registering online with a financial organization that I answered "I fu_____ hate these g______ fu_____ security s_____ questions" (use your imagination on the blanks) and tacked on a trailing random number string. And dutifully recorded that answer in my password manager. Done!
Well, about 3 years later, I had to complete a financial transaction over the phone. Out of the blue, the young lady asks me for my challenge answer. Oh my, I was so embarrassed by the quiet snickering and muted snorting when I read her my answer.
Someone here mentioned a while ago that such random character non-answers could potentially be bypassed by answering "oh it's just a bunch of random characters" when asked for the security question over the phone.
A plausible but incorrect answer is better I think, e. g. Q: What city were you born in?, A: Severodvinsk (a random town in Russia)
I like the ones where they not only require you to do that, but then they also require you to know the answer to those to change them, even if you know your password. A couple of AAA MMORPGs have this particular antipattern, where I've forgotten what the hell I put for these questions, and even though I have managed to remember (because at least one of them, the recovery options -suck-, to where even contacting support didn't get me back into my account, but happily I was able to derive the password I used, because it was a -weak password-), I -still- can't change those questions.
I had a priceless experience trying to get my credit report about a year ago. I haven't had a car loan since about 2009 and even then it was on auto pay. I got locked out because I wasn't able to guess whether the monthly payment was, like, $237, $253, or $312. The other thing I've run into is where I can supply an arbitrary answer, but none of the questions are applicable to my life, like "who was your favorite high school teacher". More depressing than anything else, since my answers are always nonsense anyway, but still...
Oh yeah, those are a nightmare for people with bad memory (me). I don't even know the payment amount of my loans, I create my own payment schedule, thank you very much! I couldn't even tell you my mortgage payment.
I got a tip from a friend when he had to produce past addresses and dates lived there. (Did I live on 123 Main St or 321 Main St?) Keep your credit reports and keep them handy. Refer to them for things you can't remember.
Once I got asked how old my mom was. Um... yeah, I'm honestly not sure of that. It was an age range and I guessed probably around (my age) + 25 and I got it right.
Look, webmasters, the simple truth is - I don't care. I have a default password that is very simple to memorise (and hence guess/hack), that I use for most logins, because frankly, I just don't care. Unless you're vitally important to my life (email, Facebook, backup, services that I use so often that they keep my personal/credit card data), your login/password is just an annoyance for me, as is your password security policy.
I commend reddit and webshops that allow "checkout as guest", that recognise this.
At the same time, requiring better passwords is an anti-spam mechanism for the platform.
I once registered a Reddit account that had the same password as its username. After my first post, the account's password was changed and it started posting spam.
The only explanation I have is that someone was crawling the latest posts and trying to crack new accounts so that they have a legit first post and registration IP address to avoid auto-moderation.
Or, for example, a forum that drops all rate-limits once you are 1 year old with 1,000 posts. It now may be attractive to crack trusted accounts so that you can send mass PM spam. Or imagine if a moderator gets their password cracked.
So it's not necessarily just in the best interest of the platform, but also everyone that uses the platform. Though that's no excuse for particularly annoying password requirements.
True, but this bar for password complexity is very low, unless the platform is allowing very high numbers of failed login attempts. The attacker can only try a tiny number of possible passwords (hopefully only thousands per day or less), which even very weak passwords can defeat.
Another point worth considering: even if your site or app does require user accounts (and this is not a given), that's not the same as requiring a password login.
For each user, just store a unique token and secret in local storage. That's their identity and password. So long as they log back in using the same machine (and they don't log out or are in incognito mode or whatever), they're good. For most sites or apps, this will be good enough for 90% of your users 90% of the time.
Now if you want to enable logging back in on another device, just ask for an email during your sign up. Then, when your user logs in from another device, you can email a login link that resets a new token / secret. Maybe a little more inconvenient for the user than just asking for a password, but it's a fairly minor inconvenience and it saves you from having to deal with storing passwords and worrying about screwing that up.
Plus it removes a step from your first-time sign up process! Which probably matters more than ease of re-logging in from another device.
Why is this downvoted? This is what a few sites do (ie, Craiglist) and it works well and I prefer it. It's not much different than a password with email recovery option. I've also seen shopping sites do this to manage past orders.
You really should be using a password manager then. You still only have to memorize one password, but you’re not severely compromising your security anymore.
I have a default password that is very simple ... that I use for most logins ... Unless you're vitally important to my life...
That's all fine if you're a perfect robot. It will turn out that you aren't, though.
You could let one of your important passwords slip to a compromised dumb-password site by mistake; you could fail to appreciate how important a dumb-password site had become to you until it was too late; you could just make a human goof and set up PayPal (or what have you) with your dumb password.
But your personal ability or inability to get this stuff perfectly correct forever is kind of beside the point when you're setting policy. In a population of dozens, mistakes will be made. In a population of millions, mistakes will be legion.
If more organizations followed this guidance, it would make password systems easier to implement, easier to use, and more secure for everyone who did care. It wouldn't effect your practice in the slightest.
This same principle also applies if you have one Serious Business e-mail (job applications, professional-related things), and another "Just For Random Crap" email address -- you may find yourself, one day, having signed up for a cloud service or other thing (I don't know, bitcoin exchange?) with an account that you suddenly wish were your Serious Business one.
I understand you might not care now, but what about later?
A upset love interest, a border control agent, someone who disagrees with you on Twitter, the police, a frustrated colleague, children with too much time on their hands, trolls, hackers.
None of these adversaries may be something to worry about today, but they might tomorrow.
We can all aspire to be bland enough to not be targeted, but I'd like to have that insurance policy in place just in case.
The real problem relating to "profit" in these cases is that companies are not penalized at all for leaking their users' secrets, not the fact that security has "tradeoffs".
Software industry is in the same boat regarding this as car manufacturers were decades ago, i.e. it was "more profitable" to make cars that killed their passengers in every other car crash, since people were just making the very rational choice of buying the cheaper rather than safer car.
It's a usability nightmare. I played a bit with password crackers recently and to me it is still often completely counterintuitive which passwords are easy to crack and which are not. Now good luck explaining that to your users without frustrating them. Take for example '_=$%=_$ _ !'. Why is that a bad password? Because it's in one of the common wordlists (yes, it has two spaces and no, I didn't make that up).
That's why I think there should be more focus on the point that users should never produce passwords themselves, but leave that job to a good random generator. This is also something I missed from Troy's otherwise excellent article. What is the point of using a password manager if you only use it to store your weak passwords?
I also believe the argument about passwords being memorable is a red herring. It is possible to remember a low number of sufficiently long truly random passwords. It takes effort and it is risky, but it is not impossible. Producing a good password without the help of a random generator on the other hand is simply impossible.
I have a few sites where this is effectively what happens. They have really bad security to where triggering a password change has them send me a new -password-, not just a link to reset my password. And then it doesn't force me to change the password when logging in.
Well, that actually works out (except that the password is too short to survive brute forcing), because I then log in with that, do my business, and move on. Next time, same thing happens, "forgot password".
Which presents a much better authentication flow to my mind. Nevermind passwords at all; just focus on whether they own a particular email account. If the email account gets pwned, the attacker can likely log in with them anyway (and if that's an issue you need 2-factor).
So rather than force a password at all, send them a verification email, and have that immediately give them a token. If/when the token expires, have the login window require their email address, and send them another link that, when clicked (in the next X amount of time) will log them in with another token.
I know for me that would mean -every- account I have is suddenly 2-factor (since my email account is), they all have strong security (since my email has a long, complicated, hard to brute force password that I keep only in my head; it's the only one like that), and I'd stop having to rely on a password manager.
Curious if there's any obvious flaws that I'm missing.
No, you missed nothing, that scheme works. Add a bit of OAuth magic to support direct logins for gmail, and you basically described portier (https://portier.github.io/), a successor project for Mozillas Persona.
This kind of hubris is ecactly the reason why most [1] passwords are cracked so easily[2].
The scheme you applied is well known. Making a wordlists from every sentence of the HN dump should be doable. And why stop there? Project Gutenberg, the whole Wikipedia and other Wikimedia projects like Wikiquote are just a download away.
A project I'm currently working on is facilitating the Google Ngram database for password cracking. I already generated almost 500 GiB of wordlists but haven't measured their success rate yet.
[1] Good wordlists have a success rate around 70% against the common leaks. Running one of these lists against a set of fast hashes takes less than an hour on a plain average business notebook.
[2] Assuming a fast hash, possibly salted. Slow hashes like bcrypt, scrypt, argon2, etc. are another story.
The Hubris System(R) provides adequate protection and is highly practical.
The scheme is well known, but what attack against it outperforms an exhaustive search?
How do you build a database of poetry I haven't written yet and will never publish?
Frequency analysis may help, but many of my poems are about a yellow zebra named x-ray who plays the xylophone.
If you come up with an attack that outperforms an exhaustive search, I will just write longer poems. You will never catch me.
Password cracking is an arms race. The crackers can't win. The math is against them. Every character I add to my password makes their problem exponentially harder.
>The Hubris System(R) provides adequate protection and is highly practical.
If the protection is adequate is up to you, but as your phrases get longer they quickly get impractical and memorizing and entering will get error prone.
>The scheme is well known, but what attack against it outperforms an exhaustive search?
Everything that is not truly random has a pattern that can be exploited to
outperform exhaustive search.
>How do you build a database of poetry I haven't written yet and will never publish? Frequency analysis may help, but many of my poems are about a yellow zebra named x-ray who plays the xylophone. If you come up with an attack that outperforms an exhaustive search, I will just write longer poems.
Per position markov chains are one way. The point is, that as long as it isn't random there is a way to improve on simple brute force.
>You will never catch me. Password cracking is an arms race. The crackers can't win.
Cracking a single password is always hard but in a spear phishing attack there are often better ways anyway. Cracking passwords en mass is a different story and looking at the success rate for cracking passwords from leaks I'd say the crackers already won. There are also arguments why mass cracking gives an edge to the attacker [1].
>The math is against them. Every character I add to my password makes their problem exponentially harder.
Longer passphrases quickly get impractical and as long as the character you add isn't random there is a way to guess it.
yeah, and here's the problem. Security is at complete odd with user friendliness. Two-factor auth is amazingly secure, until you've lost your second factor.
This seem like a a relatively easy problem to solve:
User: I want my password to be "monkey"
System: Sorry, that password is in the dictionary. May we suggest one of these strong client side generated passwords? ...
User: OK, I want my password to be "monkey1"
System: Sorry, that password is on a list of exposed passwords. May we suggest one of these strong client side generated passwords? ...
No, they don't but you give them an option. It's only a suggestion for a password that will work and you can use any of a variety of tools that generates passwords that a not that hard to remember.
For anyone who is thinking about using unicode for passwords, remember to normalize the unicode before hashing it. Different human input devices may output different codepoints for what appears to a human to be the same character/string. Obviously make sure you manage the decoding/encoding as well.
Here is what NIST has to say about allowing the user to display the password on screen:
> In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.
Math tells us longer passwords are better than longer alphabets, yet I am often forced to add special characters. If I have 12 character password over an alphabet of 26 characters, there are 26^12 possible passwords. If I have the choice between adding 5 special characters or increasing the length of my password by 5 characters, math says do the latter:
(26 + 5)^12 = 7.88 x 10^17 < 26^(12 + 5) = 1.13 x 10^24
That's over six orders of magnitude higher. How come supposedly computer savvy people don't know the difference between x^N and N^x?
What makes you think that these composition rules are being set by the computer-savvy folks in the room, not box-checking bureaucrats? No engineer worth his salt would propose any of the terrible password requirements (10 char max, no pasting, etc.) featured in this article.
Except for the poor engineer that has to maintain password compatibility with an ancient COBOL database that was plaintext EDCDIC in the middle of a binary fixed field record file. In which case, give that engineer a drink, and then the budget to build a modern system before the whole house of cards comes tumbling down.
Auditors.. Its always the damn auditors.. SOX, SAS, HIPAA, PCI, etc.. Horrible, 20 year old password requirements, that the auditor doesn't even understand, but they ask the question, because they asked it last year....
That's not how entropy works. Yes they've expanded the search space, but not how large the typical set is. The latter is still determined by the user's memory habits.
That math is only correct for randomly chosen passphrases, but the rules you criticize are for user-invented passphrases. Even just adding capitalized letters to user-invented passphrases can drastically increase their security.
To be fair, there are good reasons to assume that even long user-invented passphrases are no longer secure enough against offline attacks, especially when the keystretching algorithm is nonstandard or does not even use salt.
Actually adding special characters reduces the search space. Most places adding them also require them, which means for one of the 10 characters the search space is just those 5 special characters, and for another the space is just the 10 numbers, and there is still one more where the search space is just the 26 letters.
> Actually adding special characters reduces the search space. Most places adding them also require them, which means for one of the 10 characters the search space is just those 5 special characters, and for another the space is just the 10 numbers, and there is still one more where the search space is just the 26 letters.
But you don't know which slot has the special character and which has the number, and that choice expands the search space again (agreed not mathematically the same as with no restrictions, but then again users don't necessarily explore the whole mathematically available space of passwords).
The entropy would be(26+26+10+32) depending on what special characters by the system. That is much more comparable to a 17 character password without any numbers, special characters, or uppercase. The strength of the password depends on the possible special characters and not necessarily how many of them there are.
On systems that disable the pasting of passwords: could I give a special shout-out to Apple OSX which, in 2017, still refuses to allow users to paste a passphrase when the ssh agent pops up a window to request it?
Perhaps the reason is to prevent anything from spying on the clipboard. Keyloggers are likely prevented by Secure Keyboard Entry. In contrast, websites cannot spy on clipbaord, so there is not real reason to prevent paste on websites.
One thing which I find Troy constantly misses to advertise and which I personally think is a much better solution than using password managers and each individual system having to develop their own login + verification and security system is to use 3rd parties to authenticate.
I am a big fan of password managers, but I don't think there is a need for them, because WE ALREADY HAVE ALL OUR EGGS IN ONE BASKET: email.
If someone gets access to your email address then they have effectively access to every single service you signed up with that email. Therefore every single service might as well just use Google/Hotmail/Microsoft/etc. to authenticate their users instead of building their own login system and asking people to come up with a new password which forces them effectively to use a password manager and yet another place to store all eggs in one basket.
The password to your email account == the password to your password manager.
If we would all just rely on Google/Hotmail/Microsoft/Facebook logins then we would be even more secure then everyone having to use a password manager, and it would be a much better user experience. Also I am pretty sure that Google + Microsoft + Facebook have a lot more talent + resources to secure their accounts then every new service which pops up every day. Let them do the security and you focus on your actual business value...
1. Not everyone uses those email services. Indeed, for a certain subset of users (especially on technical forums like Hacker News), using them is seen as opening yourself up to unwanted surveillance.
This means tech forums relying on such a system are potentially driving away a decent portion of their userbase.
2. Not everyone wants to use the same account details. For instance, if I join a site with a more professional audience, my current username (and my email one) may come across as awkward or robotic. If I join a fan forum, I might want a username based on the game or show. Etc.
3. A lot of people want to keep their online identities seperate for security reasons. I mean, do you really want to use the same email for a dating site as you do your bank? Not really, but tying the login systems of each site to Gmail or the likes means you've either compromised said privacy or given yourself another Gmail/Hotmail account to memorise the details for.
4. It encourages centralisation. We've already got a problem with a few large services having an untoward amount of influence online, and having their login systems used for numerous other sites only makes that worse. It means if they decide your site is against the rules or 'hate speech', your users can't log in.
So nah, I'd rather sites didn't use third party authentication. It has too many drawbacks.
re 1.: Support the 10 most used email providers and you will probably cover 99% of users. Most people have a Gmail even if not as their primary email, but so they can use various Google services on Android, or an Apple ID to do the same on an iPhone. Unless you have data that suggests differently, I really don't think this is a valid issue nowadays anymore.
re 2.: If you don't want to use your private email for everything, then you already must have another secondary email, because there is literally no registration process which you can get past without an email. So just use the email which you find appropriate for a given website.
re 3.: Same as 2. You must have any sort of email to register anyway, so whether it's your primary email or your secondary "anonymous" email, it's still the same principle.
re 4.: Not doing something smart today, because there could be potentially a futuristic abuse scenario in some point in the future is not smart. Do what's best today, if tomorrow all email providers turn evil, then re-introduce your own login system, but you'll still need these email providers to verify your users.. so not sure how far you will get... but anyways.. this is a non-existing problem today and probably never going to happen. So why degrade experience and security for a Utopian future?
So yeah... I much rather use a secure and convenient auth system, because it has way too many advantages and we already rely on it, we just don't admit it. Might as well go the full length to get the best experience from it.
When I talk about security, the question I like to pose is this:
Imagine every password for every one of your users is published...can you identify people? How would you clean up the mess? Imagine a malicious person logged into EVERY one of your user accounts and tampered with them, changed email addresses, etc. Can you identify it? Can you clean it up? Can you prevent it from happening again?
If the answer to any of those is no...then you're sitting on a time bomb.
Start with the assumption that the username and password is convenient but unreliable, then move forward with actual security.
The problem with a password manager is that you don't have easy access to one when you're on a different machine.
A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password.
This is why these arbitrary demands need to die: they make the only way to securely and conveniently access accounts from different devices impossible.
Your suggestion is bad for a ton of reasons. For example, how do you change your password for a specific site after it had been compromised or due to normal password rotation?
Another downside is that changing master password means you need to change passwords for all sites or have multiple master passwords.
Another is that an attacker can use the knowledge of your password on site A to bruteforce your master password offline.
Why on earth is this being downvoted? If you've used a hashing generator for any length of time you'll know how multiple master passwords inevitably creep in. Also, when your generator no longer works because the login FQDN changes (which happens alarmingly often) you'll have all the fun of resetting your password. For no good reason.
Re. portability, KeePass and its siblings are compatible with every major platform.
...an attacker can use the knowledge of your password on site A to bruteforce your master password offline.
This might be a concern if you're the victim of a state-level targeted attack. That's not a threat most of us have to deal with. Hackers aren't likely to spend a lot of effort cracking John Doe's password list; they want to steal a few million password hashes and sift out a few thousand easy or re-used ones.
Your other points about the weaknesses of the scheme stand. Still, if we could get more users to use not-terrible, not-duplicated passwords, even with a flawed scheme like this, overall internet security would improve immeasurably.
You don't need to be the victim of a state-level targeted attack. You just need to be a public figure online[0] and attract the attention of a bored hacker.
I'm not super familiar with the Honan story but I recall (and quick skimming seems to confirm) that it was more about lax security policies at Apple et al, the interconnectedness of social media accounts, and social engineering than it was about reversing a computed hash or human "hashing" scheme.
Did those attackers guess or compute even one password at all?
Not in this specific instance, but they could have. And that level of scrutiny would have enabled a complete digital takeover like Honan suffered if his accounts were poorly protected by a system of passwords proposed above.
There are many types of targeted attacks on passwords that don't come close to including state-level actors. Divorces. Corporate Espionage. Any one of the people on Judge Judy who posted information online about their co-workers.
As far as I can tell, we're talking here about reversing a cryptographic hash and sifting the one true master password out from the much more numerous hash collisions. Do you really expect that level of effort to be common in a divorce?
I _know_ that level of effort has already been expended in divorces. Targeted attacks do not need to be common. The point is that there are many types of targeted attacks.
That's assuming that the master password is really strong. Otherwise you could bruteforce it by testing millions of passwords ("password", "secret", short ones and so on). I assume most people will choose somewhat weak master passwords.
With this scheme ANY site where you register can attempt to brute-force your master password offline. I fail to see how it's a good scheme.
You're right. If you choose a weak password, nothing can save you. This holds in any case, so this is not specifically an argument to this use. Let's do some math to see if your argument about bruteforcing holds stake (spoiler: it doesn't).
Let's say you're master password only uses letters, numbers, and special characters. Just counting keys on my keyboard, there are 94 such characters. You should pick a random sequence as master password (very important).
Let's say you use the Antminer S9 (which can compute 1 gigahash per joule). For ease of analysis, let's say you can recognize the master password instantly. Also, say we're paying $0.2 per kwh. Then we can define the average cost c of finding the master password as a function of the master password length l:
c(l) = 94^l/(1.8*10^10)
c(5) is about 40 cents, c(6) about 40 dollars
c(8) is more than 300k, c(12) = 26e12
In comparison, the estimated amount of money in the world (in 2009) is 52e9 dollars. By the way, this is if you use a single SHA256 hash. You can make the hash arbitrarily expensive by iterating (computing h(h(h(master_pass)))).
The one and only argument against using a master password that is used to derive passwords is the single point of failure. If someone catches you typing your master password on video, you're pretty much fucked. But I guess this is the same for password managers.
You can add something (e.g. a number) to the end to make a different password. The idea is that you have a _very_ secure master password (so bruteforcing it is not practical - to make this even more true you could hash a huge number of times instead of just once) and never change it.
There is still some truth in your arguments. I'm curious what you consider a good alternative?
How often do you need to type passwords into a machine that you either cannot or are unwilling to sync with a decent password manager? How do you trust this machine not to record and exfiltrate everything you ever typed into it? IMO it's a Good Thing (tm) that I have to jump through hoops to access my passwords on unfamiliar machines.
How does one even calculate H(username|service name|master password) on an unfamiliar machine that might not have a decent scripting language installed on it? If you asked me to do it on my father's laptop, for example, I'm gonna have to download Python first.
Re. the number of machines, it's something I've encountered as an obstacle from a fair proportion of people I've spoken about password managers to. I think its more a perceived issue than a real one.
Just spitballing which systems I would realistically want access to passwords on, at a minimum, includes: personal desktop, personal laptop, tablet(s), cellphone(s), family (parent, sibling, in-laws, etc) computers, office desktop, office laptop.
In my case (many cases?), the latter two prevent software installation, so I would need to manually type from a manager synced on my cell. Which really is no different to what is required for 2FA - just a longer character string. Overall, a some setup and synch related inconveniences but not to a damaging degree, which is why I think this is more a matter of perception - once you think through where you're typing passwords it appears less of an obstacle.
Chrome syncing browser plugins with a password manager makes personal desktop/laptop, and office desktop/laptop pretty trivial (barring, yes, overzealous IT).
Cellphone and tablet I install the relevant app once and am done.
Either way, web access to the credentials isn't uncommon, though you'll need a device for 2-factor confirmation it's you.
For family devices...I wouldn't want to log into them. I don't trust their security sense and don't want to risk compromising my stuff because of their mistake. Why would I anyway; I have my cellphone on me, at minimum; I can access the account there.
> the [office computers] prevent software installation, so I would need to manually type from a manager synced on my cell.
I don't know about other Password Managers, but LastPass lets you access your vault using any web browser. So long as your network doesn't block the LP site, you can access your password manager from anywhere.
On a similar note, Keepass can be used without admin rights with the portable version, so you can keep the portable executable along with the encrypted db file in some secure and accessible email account/web service that your network doesn't block.
Most of my passwords never need to be typed onto strange machines, so I can use 1Password with long random complex strings.
If it is a password I need to type, I use diceware "Correct Battery Horse Staple" style passwords. If I don't remember the password, I always have my phone, where I can retrieve the password from 1Password. There is no relationship between my different passwords. As long as my password vault is secure, so are all my passwords.
With your system, if I learn your master password and hashing mechanism, I basically have all your passwords.
FYI, diceware has been shown to be insecure with three words. Four is better, but also crackable by an attacker with a few thousand dollars to throw at it. Five and up is safe for the next few years.
True! So you have to choose a good master password and use an expensive hash.
On the other hand, if you take any other approach, you place either confidence in the security of a service (1password), or you store passwords somewhere. In both cases, you have a problem when you can not retrieve the passwords anymore.
If 1password is hacked or simply offline, or your phone gets stolen, you basically lost access to all services.
If you use a sufficiently good hash function with a salt to stop rainbow table based attacks and key strengthening for good measure, then an attacker who has one compromised password of yours isn't going to be able to reverse the hash to find what your source password is so that they can generate new per-site passwords using it. That is assuming they even try: how would you know that an arbitrary string of characters was generated that way rather than just being randomly picked by a password manager?
Of course all your accounts are compromised if someone knows your master password, but that is little different to an attacker getting your pass-word/-phrase for an online password manager that doesn't use some form of 2FA.
But how would the text being hashed be attacked without either attacking the hash by brute force or knowing the master password (which is likely a human factors hack, to which online password managers are similarly susceptible?
Using hash functions in an attack is not the same as performing a cryptographic attack against the hash function.
These are two different classes of attacks, both being real-world attacks. The attack being discussed is against a suggested formula to generate passwords.
From the top of the thread, "a scheme that hashes your username, service name, and master password to generate a password." Discovering the password by determining the inputs to the hash function is all that is needed. This is the case even if a different type of function is used instead of a hash.
Ah yes, I was thinking about the other end. Yes, this would be trivially susceptible to a simple dictionary attack if the user chose a bad master password, just as a plain password would.
Introducing a good salt would stop that but then the salt would need to be stored and managed somewhere (securely synced everywhere you might need to regenerate a password - it can't be a public value or you are back to square one with the dictionary attack). You could also introduce a CPU and memory intensive key derivation function to frustrate the brute force attack a little but that is a race you won't win if you need the function to work on a low resource device and the attacker has a large cluster of processors and/or plenty of time to work with.
It would protect against password reuse attacks even without the salt: if site1 stores plain passwords and leaks them then getting into my account on site2 becomes no easier than it already was if I had different passwords for each site (we are still looking at a brute force dictionary attack against the master password) so the scheme could work if the user has a sufficiently complex master key (and never needs to change that key). Making the master key complex enough but memorable is the challenge there, back to one of the core password related problems but at least with only one (or a few) to remember not one per account. Changing the master key once you believe it has been compromised would be quite some hassle in a similar way to if your master password for a service like 1password were compromised (worse: with a service like 1password you at least have a list of accounts to work down but with this scheme you need to remember them).
An interesting though exercise, but I'm probably overthinking an unrecoverably weak idea...
> A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password.
This is a very bad mechanism to create passwords that will create severe security vulnerabilities. You are adding complexity and false-security without benefit.
Passwords are a secrecy mechanism, not a formula mechanism. In your method, all one needs is the formula, then all passwords will be disclosed.
The suggestion might then be to interject a secret with enough entropy into the text being hashed. But, that is no different from a secret password itself!
Does anyone provide a regularly updated bloom filter of exposed passwords you could use for meeting the last point? Seems like something Troy could do...
Hey! A thing I can actually help with! I put together a PoC of exactly this when I had the same idea a couple years ago. Here's a basic generic example I put together at the time, that also defines interfaces for other policy directives (e.g. min length, etc.): https://github.com/milo-minderbinder/policy/blob/master/src/...
I'll add docs and updates if people give a shit. The passwords.dat file in the resources folder is the top 1m most common pws that I compiled from a number of lists available at the time.
I implemented a redis-backed instance of the above common-password bloom filter in a sample Spring app which I was using to show off some features of spring security to a dev (I work in AppSec). You can see the policy and redis config here: https://github.com/milo-minderbinder/spring-ref/blob/indev/s...
It's not ideal, but shouldn't be a big issue, since a false positive just means that you (very rarely) tell a user that a password is unacceptable when it should have been fine. That's a bit annoying for the user, but the result is that they just end up picking a different secure password. False negatives would be worse.
Really though, a list of common passwords to block is such a small amount of data that it's probably best to just use an exact list. I can't see it being more than a megabyte or so.
A "list of common passwords" isn't the guidance though - it's a list of passwords exposed in previous breaches. That list can be huge, and only practical to check with some efficient lookup mechanism.
Ah okay, sorry. I was thinking about it from the perspective of common passwords since that's something I've tried to find an existing bloom filter for before.
I agree with you that Troy would probably be one of the best people to provide something like that. I wonder how feasible it is, that would be a really great resource to have available.
While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being. Even if UI and market standards for cryptographic based auth finally gets improved, it'll still be a long haul for it to grow in usage. That being said this seems like a solid overall listing of the basics that all password using services should follow, except as koolba said earlier "Security" Questions (scare-quotes extremely intentional) were always a horrible anti-user & anti-security idea and should be eliminated everywhere.
My only actual quibble/concern with this piece is in the "Notify Users of Abnormal Behaviour" section. I agree it's a good idea in principle to perform notifications, the only niggle though is that some common forms of notification are not authenticated in general, and in practice that particularly means email. I have only ever seen a few companies, even in the financial sector, that sign emails (and without that more aggressive automated domain anti-forging is hard too). At least from the stats I've seen on my own servers and for users I'm responsible for, "Notification/Alert" emails are an ever greater favorite of spearphishers & spammers. A lot of the major companies deal with this by using better authenticated purpose-made notification systems or even just text messages, but email still enters in, and if the practice spreads I'd expect to see a lot more places just using email. I think it's worth being careful about getting users trained into any habit that might lead them to immediately assume something from an unauthenticated source is real and should be clicked. This might be an area that'd be worth coming up with better standards and UI for as well.
"While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being."
There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords.
>There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords.
I don't think it's that simple. After all, the basic tech to handle this stuff has been around for literally decades at this point. Even in terms of open source, projects like OpenSC date back a decade and a half (2002 or before). The problem has always been in terms of bringing the elements together into a standardized system that has a least a few major implementations with good UI, and gaining critical mass to kick start a virtuous circle of adoption, uptake, demand, and more adoption. It's not a technology problem. I've seen enough hopes raised followed by false starts or even flat out regression that I think it'll be a hard slog, though as the problem is only getting worse I'm hopeful we'll get there eventually. And even more, that once there is at least one good mass example showing people how things could be better there will be mass demand and we'll see a nice S-curve of adoption rather then linear.
The problem with passwords on the web is that they require sending and trusting private credentials to someone else. As devs we need to working on making better systems (e.g. TLS client certs and SRP (e.g. TLS-SRP or PAKE)) more usable.
It's not a magic bullet and not something a switch can be flipped on, but the status quo is terrible.
SRP doesn't solve the problem you think it does. SRP (and PAKEs in general) still requires the server to store a verifier. Those verifiers can be cracked just like password hashes; in fact, they're often easier to crack.
U2F is definitely nice, but it's impracticle to expect everyone to have a hardware key. There are software only wins that can be much better than the current status quo.
Sure, you can gave software U2F keys, but that's not commor or expected from what I understand.
There is no reason software based U2F tokens can't exist. We actually released one just this week: https://github.com/github/softu2f. It went through a certification process and was certified as a valid FIDO U2F implementation. I'd love to see more and more non-dongle based solutions going forward.
That seems to be the only one out there, hence my conception that it's mainly a hardware-key. I would also be interested in seeing more cross-platform software U2F implementations!
For sure, software based tokens are not the norm (yet). Part of our hope with releasing a software based token is to push the security vs. user experience conversation forward. Sure, hardware tokens are great. But, they don't have the best UX and have a pretty steep barrier to entry. Hopefully Soft U2F helps to spawn a more varied set of solutions. Over time, browsers and password managers could integrate these kinds of features. For example, https://crbug.com/678128 is a tracking issue for implementing U2F in Chrome itself, which would be great.
Not the current OAuth. It is different for each provider. The standard isn't strict enough. I have to write something special each implementation I want to use. The standard needs to be modified so every implementation works exactly the same way - then I'd say OAuth would be a good potential solution.
One thing that bothers me about this article, and the way everyone does passwords is this assumption that the output of a cryptographic had function is alphanumeric. It's not, is binary. Store the actual data in your database, not the base16 representation! This applies to anything, not just passport hashes—don't transmit around data as base64 unless you're actually using a medium that requires it (e.g. email)
Good question, I'd like to know SeoxyS's reason, too.
Aside from the space consideration already mentioned, if I had to surmise, I'd guess it would be faster to process because we're skipping the encode/decode steps unless we are explicitly "importing" or "exporting" the hash, and less chance of making mistakes to encode/decode through Base64 before doing anything with the hash.
It is marginally more of a hassle to debug in a live production environment, though. When you are troubleshooting, grabbing the binary representation and running it through a Base64 decoder is annoying. Doing this from inside a mass file search to look for all instances of the same hash can be a bother.
I suspect we're storing as Base64 everywhere because so many hashes are held in XML files, and the standard strongly encourages storing binary within XML as Base64. Once they are doing it in an XML file somewhere, I gather lots of teams make that the canonical representation everywhere, even in a database when it isn't strictly necessary.
It's going to be a third bigger than storing the bytes directly - which doesn't seem that big a deal. Storing images or video base64 encoded in a database columns would be silly but for hash values I'd be inclined to go for something that is slightly easier to code against.
It's unnecessary CPU work and also takes more storage space in the database.
In practice I doubt that it makes much difference in terms of performance as hashing is way more expensive than base64-encoding. The rant is probably more against the misunderstanding of developers.
On a quick scan that looks like interesting analysis. Though one point that I find most run-downs like that miss is the number of accounts that are throw-aways, where the user simply doesn't care and will never use it again. At that point using "123456" or "password" isn't an issue, anyone who hacks the account gets nothing more than they would get if they just created a throw-away account themselves.
The hacker can grief / spam everyone else in the system from this "normal" account. Depends how much public interaction / content posting there is, though.
True, but this is not really a problem for the user, but a problem for the system. It is reasonable to assume that the user that creates these type of accounts does not really care about the security of the system either.
Whenever a site requires special characters, it just ends up limiting me to one of the few memorized passwords I have that matches the criteria, most of which are barely 8 characters long.
I use LastPass but I don't like using the password generator because I want to be able to log in on mobile or other computers when necessary, but I don't do so enough to justify signing up for a subscription (I dislike subscription models) that would allow me to access use it on mobile.
I wish I could just use giant password strings on all of my sites.
Not a huge fan of subscription models, but if using password manager software, it seems like an appropriate pricing model. You expect/demand the software vendor to be consistentsly up to date on best security practice and vulnerability patching. A subscription model gives more incentive to provide this due to the risk of losing future revenue(subscribers & reputation) in the event of a failure.
Excellent read. I've finally decided to do what I've been saying I would do for two years and create an open source demo Ruby on Rails application that applies these principles using the Devise gem and a few others. Will show it supporting multiple two factor strategies as well as account lockout, recovery, and access downgrading based on confidence. It's a private repo at the moment but I will share as soon as its worth showing.
I like the concept of "Notify Users of Abnormal Behaviour" but how. I mean that in a technical sense. This XKCD seems to apply[0].
People take for granted that an organisation can just hook into a bunch of paid external services, GeoIP, Browser/Device Database, etc. First off, there's a great many organisations who cannot or will not be able to use an external GeoIP database for example, and even if they could how is a threshold of "abnormal" determined?
I too love Facebook's implementation. How do I make that without hooking into half a dozen paid external providers? I'm legitimately asking, because this seems like a "research team and five years" type of issue.
You can implement a basic level of this just by storing some information about users and then comparing it on login. Some relatively simple examples
- Inform users of unsuccessful login attempts since their last sign-in. This can let them know if someone is trying to attack their account.
- Notify the user if they login from a new browser. You can record information about the client (user agent plus other identifiers that are visible server-side) and then notify the user when connections are made from new systems that haven't been seen before.
- For GeoIP there are basic datasets that cover things like country of origin that are generally available for free. You could use one of those to note the customers general country of origin and then notify when that changes.
None of these are flawless of course, but they could provide some basic means to help users protect their accounts.
I think this is actually a case for delegated authentication, you can quite simply let Facebook(or Google,MS or some other trusted auth provider) handle these things
instead of implementing them yourself. Use some form of social login(OAuth2/OpenID Connect)
Is there an independent body that certifies that a site uses good practices? I mean, I have no way of knowing whether a website is storing my password in the clear (unless they email my password to me), using a symmetric cypher, a site-wide salt, etc. It would be nice if a trustworthy party could investigate a site's security practices and certify that they are doing things properly.
A person only has so many memorizable passwords that they can hold at a time; the entropy source is very very low rate. Revealing any memorizable password to stupid random sites is itself an antipattern.
I use a pass phrase salted with the first n characters in the name of the site, so I only have to remember one password and have unique passwords for all accounts. For example, monkey + ycombinator = myocnokmebyi
I am not a security expert; I'm sharing my experience, not attempting to answer the question.
Back before I used a good password manager setup, I used a mental algorithm of [base password] + per-site modifications. These were saved in Firefox and I'd sometimes forget them when I wasn't on my normal device. If I needed to get on to a service (eg, email) whose password I'd forgotten, I'd reset it, then reset again, back to what it was, when I got back to a place it was saved.
At some point, gmail prohibited this, and I had to update all my passwords whenever I needed to reset. The result was the same as forced password rotation: I just started using more memorable (less secure) passwords.
That said, there's definitely measures Google could take to mitigate this effect. For example, drawing from the article, there could be tiered access control, where one tier (eg, 2fa but no pw) lets me get some limited access without changing the password. Then there would be no legitimate reason for returning to an old password, so such a policy is not harmful.
The policy of not allowing previous passwords exists in the first place to ensure password rotations really happen. I've been in organisations where you tell people that passwords change every thirty days, and they say "that's ok, I'll just change it and then change it back".
Why do I need to change passwords every thirty days? Because it's one of only three questions our risk assessment auditors actually ask, and "failing" is bad news.
If we accept we don't need to rotate passwords arbitrarily, there's no reason to have rules like this - it's more secure and less effort to not retain the last 20 passwords.
No mention of how to authenticate on mobile? I don't think a guidance on how to authenticate for the Modern Era is complete without having a mobile solution
I'm curious; why aren't we dropping the use of passwords in favor of U2F?
I guess for one; not everyone wants to buy and carry a key. But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.
> I'm curious; why aren't we dropping the use of passwords in favor of U2F?
Well, you are favoring U2F, which is a _specific_ _implementation_ of 2FA. U2F isn't being used generally, because it isn't a general purpose solution.
> I guess for one; not everyone wants to buy and carry a key.
This statement is the problem with looking at specific implementations to solve a general problem, instead of looking at all the solutions.
There are many solutions, not all of which even use physical keys fobs.
RSA is a straightforward example of why a 3rd party shouldn't automatically be trusted for auth mechanisms.
> But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.
The burden isn't just a user side issue about carrying a fob. For general password replacement, key fobs will get lost. Passwords are a burden to the user, having to pay or deal with key fobs and their replacements will be an even greater burden. You are proposing to solve the auth problem by causing many users to stop using websites.
Unfortunately, there are also issues with soft tokens. There are still applications that only use the "first soft token" in a list of soft tokens owned by a user. Plus, soft tokens are quite amenable to being copied.
There are also many banks and credit card issuers who have consciously chosen various forms of 1.5FA instead of 2FA. In many cases this is a valid solution, a form of dual sided auth that works across all clients.
The first general-user services to enforce 2FA of any kind will be sacrificing a massive number of users to do it. As a company running a service for money, you have no incentive to make your system more secure on the user end - obstacles for the user are just users lost.
Security-conscious users can push for 2FA on services, but we probably won't hit it being mandatory any time soon.
But if there's any money at stake, then any money exfiltrated from your users is money that you never receive, so there's certainly an incentive but also trade-offs.
2. A password crack can result in them losing a significant amount of money, and
3. This happens often enough that it offsets the userbase losses of 2FA
If your user accounts are important enough to let them lose a large amount of money, your users are probably demanding better security from you already. The real blocker to 2FA are services which rely on being convenient, and make money off their users being users e.g. social media.
I believe eventually passwords will become cognitive thumbprints. I.e. instead of a password, we play a short game, type in some text of which the cadence can be analysed.
Authenticating against something that cannot be changed but can be counterfeited is a horrible idea. Plus, good luck storing that kind of thing securely.
Somewhat redundant as that is actually referenced by the article itself, both as a general discussion point regarding passphrases/passwords and specifically because that specific string is actually found a number of times in the reference data sets.
I disagree. Author pointed out "all eggs in one basket" issue, but it doesn't look like he completely understands the whole problem. The main problem is that passmanager holds a lot of metadata.
For example, you use unique password with high entropy for every service you use. Once attacker gets your one master password (through zero-day or just by watching you type it), potential damage is massive. He doesn't have to try to find where you are registered, password manager will tell everything, about every single account and possibly more; some people even store credit card/banking info in passmanager. At that point it's over, you lost.
"... if (password manager) gets compromised it's going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials."
This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes. With good hash algorithm, he have to spend considerable amount of time cracking every single hash. He doesn't target you in particular. You are just one of many. If attacker cares about you, after cracking hash and getting your password, he has to do a lot of research (trying to find other sites where you used that password and hope you didn't change anything there) to make any use of it. Objectively, he doesn't actually have much. So going after popular services you use, just to get your password, doesn't look like a good attack vector in the first place.
People should know, that password manager is just a glorified notepad file with one password. By using them you are trading safety in situations when attacker targets you, for safety in situations when attacker targets someone else and you are just a collateral damage. If you must, use them only for information you don't care to lose.
I don't think that's true. The scenario you presents requires the user to already be compromised by the attacker. What does it matter if they use a password manager or remember and type their passwords manually, if the attacker has access to your machine?
Of course there is a trade-off with the master password, but on the whole, I'd say it's a definite security win, because the user only has to remember one strong password instead of many, and an attacker only has an advantage if they've already won anyway.
>What does it matter if they use a password manager or remember and type their passwords manually
The main difference is amount of information attacker will get.
With passmanager, he will get everything instantly once you type master. With manual typing, he will have to wait until you tell him about every single account, one at a time, so it's a bigger risk for him to get caught.
And password managers, in general, give average Joe false sense of security. So he starts storing everything in them. Bank accounts, credit cards, you name it. And once he gets hacked, amount of damage he receive will be much greater.
It's about the attack vector though, right? My dad has passwords written in a notebook, but to compromise that you'd need to break into his house & find it.
If the alternative to not using a password manager is password reuse or enumeration (sup3rMan!_gmail), it becomes for attackers even if they're not explicitly targetting you, as they can run patterns against the whole DB against Gmail/Hotmail/Facebook etc
If an attacker has root access to your machine, he can easily:
* Extract passwords and session tokens from your browsers
* Keylog your system and wait for you to type a certain password
* MiTM your TLS connection to grab credentials
>This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes
Wait, who said they are hashed? Perhaps an irresponsible webmaster stored them in plaintext. Now, even if that service itself isn't very important, it's likely that certain users re-used the same(or a similar) passwords in more important services, such as Google.
Now, while you're right that using a single master password does pose a risk, there aren't other viable solutions to secure password authentication,
unless you;
Memorize a strong password for every service that you use
Never share passwords among the services
Don't store saved logins in your browser
Never link your services to your email (because then if your email account is pwned, your accounts in those services would be pwned too, another "all eggs in one basket" issue)
If you can do all of the above, then great, but most people can't.
>Memorize a strong password for every service that you use
I keep hearing this argument and i think people who use it just don't understand why password has to have high entropy (e.g. strong). It's not to stop attacker from bruteforcing login page (nobody is doing it nowadays), it's to stop attacker from cracking hash, if he gets it. If password is unique, it doesn't have to be strong.
>If you can do all of the above, then great, but most people can't.
And this stuff again... "Security is hard, just use this password manager, dum-dum." All you have to do, is divide your accounts into two groups: accounts you care about and accounts you don't. Most people would not have more than 4-5 accounts in the first group. Create and memorize strong password for them. For the second group, you couldn't care less, so use passmanager, that is the only good use case for it anyway.
What about a Password Manager combined with 2FA? A bit of redundancy in case your master password is somehow compromised, so that you can individually still change each websites' passwords and store them in a new password manager with a different master password. The same applies if your 2FA device is stolen, you may store their recovery passwords on a separate password manager that isn't accessed as often.
What kind of "2FA"? SMS 2FA is not secure. Stand-alone device for every single service? Secure, but acquiring one is not so simple and not every service provides them.
And do you really need to bother with multiple passmanagers at that point? Just store accounts you don't care about in one.
For accounts you really care about, you should make strong unique password yourself and use stand-alone 2FA device.
> Once attacker gets your one master password (through zero-day or just by watching you type it
A bit off-topic perhaps, but can a keylogger really grab your master password as you type it? 1password and OSX has secure entry for entering a system password, no?
I don't know much about OSX, but do you really think it will stop him once he is already in the system and has kernel access? If i understand correctly, "secure input" just tells operational system to stop sending keyboard events to other programs. If that's the case, then it doesn't help against zero-day at all.
Key loggers don't need to be software. A USB interception, a weak proprietary 2.4GHz radio interface, or a badly implemented Bluetooth keyboard can all leak password plaintext directly to an attacker.
I loathe when sites require you to set them up as it requires manually generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3) and saving the pair (question plus random text) as metadata associated with the account. Not exactly pulling teeth but it's pretty annoying to manually do that for 3-5 entries.
Even worse offenders are the sites that don't even let you enter a value in a text box but instead require you to pick from a drop down with a handful, say 10-15, of entries (cough United Airlines cough).
And the very worst offenders are the ones that, after successfully authenticating with your password, ask you for the answers to the secret questions every single time you log in (cough again United Airlines cough).