Patronizing Passwords
joelcalifa.com
joelcalifa.com
As a user, I have the right to weigh my own pros and cons."
If you bore the full cost of your account being hacked, that might be true. But in practice that's not the case. There are laws and contracts that protect you from the full costs of your being hacked and shifts some of those costs to the proprietor of the website. Even leaving aside those direct financial risks, the proprietor of the website bears customer support costs if your account gets hacked, and quite possibly PR risk too.
I like the Password Security Guide idea though.
This could easily become the norm, and should. It requires only one key for all of us, it is perfectly secure, doesn't require storing secrets on the remote end, never needs to be changed, can't be forgotten because it doesn't need to be memorized (there is one password for the LUKS encryption). There is no penalty for using the same key in thousands of places.
The problem is, no website or browser supports this kind of authentication, and most people are not savvy enough to build this sort of thing for themselves. These are both problems that should be solved; we desperately need to move the Internet away from passwords, password resets, and so on.
This may be better than using one password for everything, but it's certainly not a panacea.
Edit: Or maybe have two devices: one dumb flash storage and a device that actually computes your key. You press the "compute my key" button while the storage is connected to the keychain, then disconnect it from the keychain and connect it to the pc. Next time you connect it to the keychain, it's wiped before use and never ever read.
Aren't you describing Yubikeys? Which aren't widely supported, but IIRC are still supported by some websites and apps.
a stronger version of this IS the norm in many countries in Europe and large security conscious enterprises in the united states: an ID card issued that is also a high security module. it's better than your scheme because the ID card is also a computer that can respond to signing requests by a host computer and the private key doesn't leave the ID card, ever. governments issue and service tens to hundreds of millions of these cards a year.
Uhm, yes, but why not use something a little more convenient, like a smartwatch with NFC/wifi?
It's what the FSF Europe uses for their OpenPGP cards, that you get if you join their Fellowship.
EDIT: apparently, the programmable version doesn't come with RSA support :|
I was hoping this will go away in my lifetime.
There's a few layers to it, most everyone has seen. Ok, 1st factor is your password, so you log in with your password.
2nd factor can vary - a list of codes you print and keep in your wallet, or they can send a txt message to your phone. Or you can get an authenticator app, which you configure with some magical seed value, and then you have what's effectively a software RSA token device on your phone.
Even easier? I just found out about these FIDO usb hardware keys. 9 bucks, wait for it in the mail... go to your gmail account settings, click the link, put the hardware key in, press the button... and that's it, from then on you can plug that key into a web browser (chrome, actually) and it will pass the second factor. Anyways, it's been out for a while, but I just found out about it, and it's so easy to do I wanted to jot a note down here.
This is the sort of the thing I always worry about when discussing or considering strengthening security. At some point the risk of accidentally locking yourself out outweighs the risk of someone else getting in. Particularly so for something like gmail, where there's no customer service as a last resort.
1. Use the SAML protocol to log in to apps as opposed to passwords. (See https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang... for more)
2. Use MFA as much as possible. Our product works with a variety of MFA options, including hard tokens, such as Yubikey, and more software based ones, like our own MFA app that pushes a notificication for MFA.
3. Generate random passwords for other applications that can be rotated frequently and easily.
There's a lot more we do underneath the covers and other ways of improving passwords and logins, such as adaptive MFA (prompt MFA if the login passes some threshold of suspiciousness)and no password login (simply use the multifactor token as the primary factor)
I use a password manager (1Password) and have a unique, secure password generated for every site. If someone gets access to my passwords, that means they've compromised my 1Password keychain which is game over anyways. I'm not interested in any protection mechanisms for such an unlikely scenario. So I end up storing the 2FA keys inside of 1Password as well—bringing it back down to 1 factor, but adding annoyance and hassle.
Don't make assumptions about how your users secure themselves.
(The distinction may not matter much in practice!)
Why? What is the threat vector whereby you think 1Password would be compromised but an OTP system would still be secure?
> If you can store your 2FA keys in 1Password, you're not really doing 2FA.
I know. (That's why I said doing so is "bringing it back down to 1 factor.")
That can't happen to a properly designed physical token, and even though it can happen to a phone token, it's less likely to happen, because (at least in the iOS case) your phone is hardened much, much more severely than your OS X kernel.
Right, but at that point the account is effectively already compromised.
Even if I have a second factor, they can just piggyback on the session I create when logging in via that second factor.
Sadly, the sites which I would most like to secure in this way (ie. important but I don't use often) invariably are stuck with ancient authentication technology.
Having 2FA within the Google Auth app on my phone prevents this from happening, effectively turning my password into a rotating 6 digit key instead of 32 character nonsense.
I can think of a few examples of threat vectors where an attacker could get one of my passwords without being able to completely take over any of my devices.
1. There might be a browser vulnerability that allows a malicious web page to get one of my passwords - let's say it gets to read memory that was deallocated but not zeroed, or it gets to see the contents of my clipboard, or something like that.
2. The provider of the service I'm using might accidentally leak some of their passwords. In the worst case, they might not even notice it.
3. In some special circumstances I might have to check my mail on a computer that I don't own, and there might be a keylogger.
I don't necessarily consider these threats to be very likely, but I get new devices so rarely, that even a minor improvement in security makes it is worth the inconvenience for me.
Do you store TOTP tokens in one app, and passwords in 1Pass? Do you use SMS? With Yosemite, these are often setup to sync to show up across all your devices..
I'm not super comfortable with SMS authentication but use it for lower-value stuff.
Edit: I might have misunderstood your question. What you can easily store for TOTP/HOTP is the seed. After that you need a software to compute the dynamic codes.
A few implementations (ex. my broker) have you read your code off a physical card they mailed with about 200 codes on it. Of course I just scanned that card into 1Password.
For standardized 2FA systems, 1password actually has support for generating one time passwords (like Google Authenticator). [1]
[1] https://blog.agilebits.com/2015/01/26/totp-for-1password-use...
2. 1Password lets you publish an encrypted HTML viewer which you can share via Dropbox, so I can retrieve passwords online if need be (just need to remember my Dropbox and 1Password passwords).
We also found 2F easier to implement than even we expected. Google Authenticator uses something called "Time-based One-time Password Algorithm" or TOTP for short. Even ignoring all the open source code and libraries, it actually isn't really at all complicated to do yourself. The hardest part is generating the QR codes for Google Authenticator (which, yes, we did utilise a library for). Even the storage requirements are low.
Our current passwords rules are:
- Minimum 6 characters
- Maximum 256 characters (for DDoS protection reasons, long passwords cause a high CPU load on our micro-instances)
- We technically allow a "weak" password but bring up a pop-up (strongly discourage it).
- We do have password expiration (90 days) and history (3x) due to unavoidable organisational requirements
But overall we're pretty liberal. You can use sentence based passwords and typically they're marked as "secure" in the traffic light score system.
> Forget about the now famous XKCD strip that proves a long lowercase password is more secure than a short dollar-sign-riddled password.
Technically what it proves is that you can replace one character in a complex password with one word in a sentence based password and get similar (or better) levels of security, even if the attacker knows you utilise sentence based passwords.
For example, a En-US keyboard has approx. 100 characters on it. A child's dictionary has about 10,000 words in it. But in reality less than 1/2 of those keys are ever typed, and less than 1/16 of those words regularly used (plus you have predictable words like "The" "A" "I" "And" etc which have less security value).
So a good rule of thumb is: If you move from random character passwords to sentence based passwords, keep the letters in the former the same as the words in the latter (e.g. 6x characters = 6x words, 8x characters = 8x words, etc).
This gives you the best chance of remaining either as secure or MORE secure while moving to lower case sentence based passwords.
Even though I can't think of a legitimate use for > 256 character passwords.
We could trivially increase it on passwords, but as you said, 256 is already higher than 99% of people use for a password and not at all unreasonable.
Allowing legitimately unlimited inputs could cause problems regardless of hashing, since our timeout (which is fairly long for other reasons) would ultimately be our only protection.
But if there was a request/need/complaint we would just double it and day to day likely wouldn't notice a thing.
The recommended password hashing functions (PBKDF2, bcrypt, scrypt) actually use the provided password in each iterated round of the algorithm. The DoS vector Someon1234 mentioned is real and has previously affected Django[0] (and, I believe, others). In order to prevent it, you should either limit the maximum password length (256 characters seems sensible, as does Django's choice of 4096) or hash the password (to a known length) before passing it to the KDF.
[0] http://arstechnica.com/security/2013/09/long-passwords-are-g...
I always remember Tom Scott saying "Don't store passwords yourself if you can all avoid it" [2] and how you should leverage google, facebook and other 3rd party authentication methods as a way to add a layer of security and remove one way to compromise your user data.
Some folks i met strongly believe that using a different medium while interacting with a site distracts new users, by this lowering the sign-up rate. I have no data on that but it sounded at least plausible.
If you believe in this, it would depend on your target group how you should handle passwords (or the lack of).
But I want also say that for a great variety of solutions having 2FA or passwordless as default is valid, Slack for example has an option of demanding 2FA for all team members, which a lot of people would agree is a good thing.
The "Password Security Guide" section at the article is a good example of educating people how insecure storing password, and you could do the same thing showing/enabling passwordless as a clear and easy alternative to migrate to.
(Yes, that's a joke :p)
A system that addresses this drawback is SAW [1, 2]; it splits a token in half (via XOR) and sends part of it to the user as a cookie, and part to the user's email address. Clicking the link combines the two and submits them both to the server for validation.
[1] http://isrl.byu.edu/pubs/pp1001.pdf (short) [2] http://isrl.byu.edu/pubs/saw.pdf (long)
For the people that are already using password managers it would be fairly minor change in workflow when creating accounts (which is relatively rare occasion anyways), and for the rest it would be massive improvement in security.
In either case, you've moved security to the user's email program which is (sadly) probably an improvement.
I'd much sooner read a piece discussing the reasons developers so often make this design choice. Is it a thoughtless formula, a common misconception about how brute-force attacks are conducted, or something else?
I'm far from an expert on the subject, but as an aside, I'd like to point out that the XKCD comic on the topic seems inconsistent with what I know about how brute-force attacks are usually conducted. To my knowledge, these are usually dictionary-based attacks, which would significantly decrease the "search space" to discover even a long, lower-case sentence. Thus a password with random characters and shorter length might be more secure in practice than a longer password composed of English words.
Edit:
I've been informed that my layman's speculation on the comic was mostly wrong. As I said below, "sorry to be on the other side of the 'infuriating argument with someone who doesn't know information theory or security.'"
If I roll a dice, and ask you to guess the result, it will take you 3 guesses on average to get the result. If I ask you to guess the random word I've chosen, it will take you around 1000 guesses (if I have a small vocabulary).
Entropy is calculated as ln₂(x), where x is the number of possibilities. With four common words from a list of 2000:
4 × ln₂(2000) ~= 44
If, instead, the password was taken to be 28 random characters from [a-z ], the entropy would be
28 × ln₂(27) ~= 133
With a genuinely random alphanumeric password, like 0LsW-nT5#^kQ, the entropy is higher:
12 × ln₂(92 keys on the keyboard) ~= 78.
The xkcd comic assumes a dictionary-based attack. It points out that choosing 4 words at random from the 2048 most common words provides more entropy than choosing one word at random from the most common 65536 words and performing some letter substitutions on it. In both cases, it is assumed the attacker knows the formula used to create the password.
If your formula for creating a password is "Choose a printable ASCII character at random, then repeat", you only need a password that is 7 characters long to beat the "4 random common words" formula (95^7 > 2048^4). But the percentage of people who construct passwords by choosing random printable characters rounds to zero.
Leveraging song lyrics can be a helpful step in this direction: simply feed in the first letter of each word to create your password. Of course, you would need a fairly long lyric/phrase to exceed the benchmark noted above, but on a scale of 'hunter2' to '8%jFb#P", I'd say it's not bad :)
The place I'm working for right now used to have no password policy for the end users. We also had a feature that allowed them to link their Twitter accounts so that they could automatically share content out to their networks.
Eventually what had happened was that people blamed us for their Twitter accounts getting "hacked". What actually happened was that they set a dumb password (like "password") on their account with our service, authorized us to post to Twitter on their behalf, and now when someone hacked their account with us they could now post to the victim's Twitter account.
We started taking plenty of heat for this, so eventually we decided to impose a password policy (a sane one, at that) and this problem eventually went away. The users of our service aren't particularly tech savvy, so blaming them for their shoddy practices wouldn't have done us any good. It might have made sense to try to fight this if we were a company like Okta, that sells security as a service, but we don't so we had to make the decision to enforce password requirements to just stop the all the bad reviews in the app store and social media hate we were getting.
But the best one yet was my car insurance (have since switched to another one). I logged in maybe once or twice a year and that thing was asking for a PIN. Turns out this was not actually a number they were asking for. When clicking through their password reset forms I found out that they were actually asking for a password (with multiple rules in place to make it more secure). Gaaahhh.
Ok, sorry for rambling…
This actually is not a bad idea. For rarely used sites I might as well just make something up that is impossible to guess and that I will never remember, and then just use the reset link every time.
How do we solve that problem?
You don't solve it, but you mitigate it.
1. Decentralize authentication and get rid of passwords. Persona/BrowserID had the exact right idea in mind and .. well, whatever, it's gone now, and we're all pissed off; plenty was said about it. We need the concept back and we need it to be popular.
2. Stop gathering so much data. Stop keeping it for so long. If your client's data is sensitive, ask yourself - and your client - whether you should really be keeping it and how long should you be keeping it for. You're not Google, Facebook or anything close to them - the odds are you will not be able to do anything with "big data". Either make the data public in the first place (if it's appropriate for it to be public), or wipe it out if you don't need it.
3. Start treating security malpractice in large companies as seriously as we treat Food & Health standards. Leaking hundreds of thousands of passwords because you hashed them with md5 no salt is criminal.
4. Build a better framework for users to learn the basics of security. How it works, why it matters; the fundamentals necessary to figure things out on your own. Make them understand what they're giving up if they are not treating this seriously. Education, education, education.
Certainly there are levels of loss - single user information, just usernames, entire user list with banking data, etc. There are ways to mitigate the amount lost, but generally the more secure the system is overall, the more hoops legitimate users must go through to use the system. Then it becomes an economic trade off between security strength and user loss due to onerous authentication requirements. Our society has, for now, chosen a model that is low barrier to entry, reasonably low cost, with some risk.
It would not surprise me at all if this password hell was intentional.