I will start with two assumptions:
1) Online file storage and transfer is cheap, and it’s getting cheaper every day.
2) Generally, the longer a password is, the more secure it is, because it takes longer for attackers to brute force any stolen password hashes. [1]
So why can’t we replace this…
… with this?
Details
Instead of worrying that your 10, 15, or 25 character password is long enough, what if you could upload a 1MB authentication file containing about 1,048,576 characters? How long would it take an attacker to brute force any stolen password hashes, in that scenario? (With today’s advances in modern computing power, I’d argue it would still be orders of magnitude better than today’s typical secure password.)
Most password managers (e.g., 1Password, KeePass) can auto-generate unique, strong passwords with sufficient entropy — why not extend those mechanisms to auto-generate unique 1MB authentication files per online service, instead?
Yes, this proposal places more burden on online service providers to process a larger quantity of initial authentication data (1MB instead of ~20 characters), but this additional processing cost is typically tiny compared to all of the data users upload (e.g., photos, videos) to a typical service after successful authentication.
Why are we even still using passwords?
Sometimes, information security improvements are more evolutionary than revolutionary — for good reason. Retooling infrastructure to support something completely different is costly, and various human factors (e.g., users resistant to change) stifle overall adoption of the new security measures.
Passwords are a single factor authentication (1FA) mechanism. This concept has been around for 30+ years within computer security. People are used to it by now. Yet most passwords are considered woefully insecure for modern, secure online transactions. People have to remember their passwords, and so they naturally choose predictable ones.
Password Revolution
Then came the idea of two-factor authentication (2FA) or multi-factor authentication (MFA). It is generally agreed to be more secure, because even if an attacker manages to guess your password, they would need access to all other factors (e.g., keyfob, time-based token) to gain entry.
However, 2FA is hard for the average online user to setup and use, so service providers have resorted to using “weaker” second factors, like SMS messages to a user’s mobile phone. However, with a weak password and an ability to intercept SMS messages, an attacker can still gain access. [2] Still, 2FA makes it incrementally harder for attackers (and therefore better than 1FA).
Lastly, there are real efforts to make 2FA/MFA easier to use online (e.g., FIDO UAF/U2F), but they still lack seamless interoperability across all vendors. For example, if you enable your Google Account to use a FIDO-compatible Security Key, you won’t be able to access Mail/Calendar/etc using native Apple iOS apps on the iPhone/iPad (you’ll have to use the Google-specific iOS Gmail/Calendar apps). [3]
Password Evolution
So others started to focus on fixing the original, core problem of 1FA in parallel — password reuse and weak passwords. “Password managers” now exist, such as 1Password and KeePass, which simplify a user’s ability to create unique, strong passwords that are only ever used for authenticating to a single online service.
Many online services validate and (sometimes) enforce a minimum password length/complexity, and these approaches incrementally raise the bar against attackers. But attackers evolve too. It is extremely cheap for an attackers to spin up cloud computing infrastructure to brute force stolen password hashes. [4] As these resources become cheaper, service providers are forced to keep raising the bar on password length/complexity, accordingly. This is our modern day authentication “arms race” across all 1FA service providers.
Conclusion
Online service providers will always need to authenticate users. To be crystal clear, I am absolutely in favor of promoting easy, ubiquitous multi-factor authentication, long term. As such, while I applaud the fact that providers are making 2FA and MFA mechanisms easier for normal users, I still believe the “password” factor can and should be improved in parallel.
Will switching to ~1MB authentication files solve all computer security problems?
No, but it seems like a good next step. We have been waiting for universal MFA for years. There’s still a lot more work to do with getting MFA used across every service provider. This proposal might be arguably faster to implement, as a near-term step.
That said, this proposed improvement likely won’t work in all cases. For example, if you want to read your Gmail from your Apple iPhone, both Google and Apple would have to update their authentication mechanisms to allow users to specify “authentication files” instead of passwords.
But, no one is going to manually type a 1,048,576 character long password into an iOS text box. Again, password manager apps could help make this process easier by storing and providing these authentication files transparently to online services, upon user request. These type of code changes to existing authentication mechanisms can be costly and non-trivial to implement; however, I’d argue that such changes are likely less complicated than completely revamping authentication to support something like FIDO UAF/U2F.
On the server-side, we’re proposing changing all password fields from a variable character text field (with a limit of perhaps 128 characters) to a variable multibyte field (with a limit of perhaps 1MB).
On the client-side, we’re proposing transmitting multibyte data as the password, and we cannot expect users to manually type in this data — instead, some sort of password manager tool must exist on the client to auto-generate and manage this data upon user request. Thankfully, such tools already exist across most client platforms and can be extended to support this functionality.
What other issues remain?
This proposal doesn’t solve all problems. For example, even if you improve initial authentication using “authentication files” and/or strong MFA controls, there are still other avenues of attack.
For example, consider self-service “account recovery” mechanisms that exist across most service providers.
In many cases, attackers can successfully compromise accounts without any credentials, by tricking users into sending them answers to all account recovery questions. [5]
If 1FA service providers store clear text passwords directly (rather than storing password hashes), then game over.
If an attacker manages to compromise the 1FA service provider directly and successfully steal clear text user passwords, it won’t matter if the password length is 20 characters or 1M characters.
Though, an interesting side-effect of using authentication files is the increased storage costs for those 1FA service providers who choose to insecurely store clear text passwords directly. Hopefully, they will be incentivized to reduce storage costs and choose to securely store password hashes, instead.
Of course, there are other issues with this proposal that I haven’t explicitly acknowledged. Feel free to comment below, as I welcome a healthy debate on this issue. Thanks for reading!
References:
[1] https://www.grc.com/haystack.htm
[2] https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/
[3] https://support.google.com/accounts/answer/6103523?co=GENIE.Platform%3DiOS&oco=0
[4] http://www.infoworld.com/article/2625330/data-security/amazon-ec2-enables-brute-force-attacks-on-the-cheap.html
[5] https://www.symantec.com/connect/blogs/password-recovery-scam-tricks-users-handing-over-email-account-access
Darien Kindlund's Blog 