10 ms·

Patronizing Passwords

163 points by sethbannon 11y ago

cm2187 11y ago
On one side I understand the need for good passwords given how bad websites are at keeping their clients data private, but fundamentally the problem is rather that websites are leaking data, not that passwords are too weak. How do we solve that problem?
- LukeB_UK 11y ago
  The two aren't mutually exclusive. Teaching users to create better passwords as well as hardening systems and making them more difficult to hack are both beneficial.
- scrollaway 11y ago
  > 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.
- misthop 11y ago
  The simple answer is that you don't. A bad actor with a success rate of >0% is successful. A website with a protection rate of <100% is a failure. The unbalanced economic underpinnings (cheap to attack, expensive to protect) along with the necessity for perfection in protection makes it virtually assured that _every_ system, in time, will be compromised. 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.
rtl49 11y ago
Does anyone really believe the world needs yet another article bemoaning the common and unpopular practice of imposing arbitrary requirements on passwords? 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.'"
- dec0dedab0de 11y ago
  There are many more words than characters, so an 8 word passphrase is harder to crack than an 8 character password even if the attacker knows the passphrase is composed of all lower case words.
  - rtl49 11y ago
    True, but (again, as a layman) I don't believe that's the gist of the comic. The artist seems to measure the entropy of the password based on the characters alone. I think a dictionary-based attack would reduce this entropy. I'm happy to be educated about why I'm wrong, though.
    - gabemart 11y ago
      The entropy count for each word represents picking one word at random from 2^11 choices of words. It doesn't have anything to do with the characters.
      - 11y ago
bradleyjg 11y ago
"The point here is that it’s my decision. Perhaps, to me, the convenience of a single email/password combination is worth the risk of my accounts being cracked in bulk. 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.
zokier 11y ago
I'm actually thinking something completely opposite; do we really need to have users input their own password? Why not just generate one for them? Users are notoriously bad at creating passwords (on average), and generating one for them would allow us to throw away all that complex password rule dancing. 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.
- JoeAltmaier 11y ago
  In my naive thinking, I'd let my computer and the server manage passwords independent of me. Let them share some secret; then my machine creates a 1024-bit challenge and get a response from the server. Why involve me at all? I'm terrible at managing large random things.
  - bradleyjg 11y ago
    If you always used one computer that would be fine. But if you create your account on your home computer and then want to use it on your work computer, your ipad, your android phone, and occasionally at your brother's house then we need some way of authenticating you instead of your computer. And even if you don't want to log on from any of those places, eventually you are going to get a new computer.
    - JoeAltmaier 11y ago
      And how does that differ from a huge, unrememberable password?
  - zokier 11y ago
    That sounds a lot like TLS client side certificates. Sure, something like would be nice but getting there would practically require new standards, then those standards need to percolate to server and client software across different platforms, then users will need to get used to them etc etc. Meanwhile autogenerated passwords can be made with a perl cgi script, be compatible with Mosaic from 1995, and be immediately familiar with most users.
astazangasta 11y ago
I have the perfect solution to this, but software systems aren't with me yet. The answer is: a keychain. Not a digital keychain, an actual one. On this I put my "infinity key" - it's a little USB flash drive with a LUKS-encrypted file system on it that holds a private key. Lots of tech people have something like this. It's great for SSH - I can add my infinity key to any host and be assured that I will always be able to login securely from any machine I want. We're all used to the physical metaphor of keys as security, and needing a physical key to get into things. This is not a huge change for us. 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.
- angelbob 11y ago
  Though he says a lot of this is to avoid bulk cracking of your passwords. As with, say, OneLogin, your keychain provides a really easy way to bulk crack all your passwords - steal the key.
- jclulow 11y ago
  You can't really "add" your key to a computer you don't trust, though. At best, it could destroy your USB device; at worst it could copy the contents out once you decrypt them. This may be better than using one password for everything, but it's certainly not a panacea.
  - zz1 11y ago
    You could also catch BadUSB...
  - astazangasta 11y ago
    I think the panacea is dedicated hardware that can produce secure tokens (a signed message) without having to expose my key to the machine I plug into. But existing systems still require that level of trust; I'm doing no worse than someone with a password typing it into a possibly insecure machine.
Someone1234 11y ago
I completely agree with the article. From what we can tell password strength meters mostly work, or at least work "well enough." Some users attempt to game the system and in doing so wind up with marginally more secure 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.
- vectorjohn 11y ago
  Just curious, but long passwords shouldn't in any way affect CPU load. After the first hash (of thousands?), it's just hashing a hash, which is always the same length unrelated to the original password length. Even though I can't think of a legitimate use for > 256 character passwords.
felipesabino 11y ago
I really like the idea behind passwordless [1], where users never use a password but just confirm they are who they say they are. 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. [1] https://passwordless.net/about https://passwordless.net/about [2] https://www.youtube.com/watch?v=8ZtInClXe1Q https://www.youtube.com/watch?v=8ZtInClXe1Q
- jand 11y ago
  A disadvantage is the media break while using passwordless. 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).
  - miseg 11y ago
    If you can catch a person's email address upon their registration, it's the re-logging-in that would require them to switch to a different medium.
  - felipesabino 11y ago
    I think your argument would also valid for 2FA approach, which is is widely encouraged regardless. Sign-up rate would drop drastically for a majority of common users if a good UX is not into play while developing the system workflow. 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.
    - jand 11y ago
Grue3 11y ago
There's no way I would give away my phone number to any random website. Thus, I would never use two-factor authorisation that involves my phone, unless it's a bank or something. Most of "social" accounts aren't all that important anyway.
- sp332 11y ago
  Most of my two-factor auth involves a time-based one-time pad (TOTP) that involves scanning a QR code once to sync the phone to the service. The service doesn't know what phone or other device I'm using.
- klapinat0r 11y ago
  2FA doesn't mean phone number. There's also HOTP and TOTP, dongles, bio, etc.
- webo 11y ago
  You don't have to use your own phone number. I use a Google Voice number for similar purposes. It also works online so I don't need to worry when my phone is out of battery.
avens19 11y ago
This exactly is why I use LastPass
- Zikes 11y ago
  Ditto, but I still get annoyed at having to re-generate a password half a dozen times to fit whatever opinionated rules a particular site comes up with.
morgante 11y ago
I hate the recommendation of 2FA as the solution. I find 2FA more patronizing than anything else. 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.
- tptacek 11y ago
  I use 1Password but enable 2FA anywhere I can. If you can store your 2FA keys in 1Password, you're not really doing 2FA. (The distinction may not matter much in practice!)
  - morgante 11y ago
    > I use 1Password but enable 2FA anywhere I can 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.")
    - tptacek 11y ago
      If your Mac gets popped, attackers are going to own the kernel, and thus your keystrokes. 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.
      - morgante 11y ago
        > If your Mac gets popped, attackers are going to own the kernel, and thus your keystrokes. 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.
butler14 11y ago
No love for spaces in passwords? i.e. spacebar presses
w8rbt 11y ago
There's a RFC for everything else... why not have one for password requirements? https://en.wikipedia.org/wiki/Request_for_Comments https://en.wikipedia.org/wiki/Request_for_Comments
iamsohungry 11y ago
> The Attorney General of Texas Child Support website It would not surprise me at all if this password hell was intentional.
rkayg 11y ago
I work at Okta(https://www.okta.com/ https://www.okta.com/), a SSO product among other things, and we deal with this all the time. We use a variety of techniques to help secure the user's identity and access to various applications. 1. Use the SAML protocol to log in to apps as opposed to passwords. (See https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language 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)
digitalsushi 11y ago
I switched jobs last month and decided to audit all my personal stuff while the old place was auditing all the work accounts I left behind. We'd been using google/gmail 2 factor authentication. 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.
- gefh 11y ago
  I second a usb authenticator. It's also an effective defence against phishing attacks - unlike OTPs.
  - aidenn0 11y ago
    How does it work against phishing attacks? Does the browser pass the domain to the USB authenticator?
    - Niten 11y ago
      Yep: https://www.yubico.com/applications/fido/ https://www.yubico.com/applications/fido/
- mrec 11y ago
  What's the procedure if you break or lose the FIDO hardware key? (Not a rhetorical question; I'd never heard of them before either.) 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.
svckr 11y ago
This is exactly what happened to me on MULTIPLE occasions with multiple websites. Right down to the special characters table flipping. 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…
zhkirill 11y ago
Reminded me of this video: https://www.youtube.com/watch?v=luv_bWmb9lE https://www.youtube.com/watch?v=luv_bWmb9lE
massysett 11y ago
"It’s time to use the password reset link again, which at this point is basically your login button." 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.
- r0muald 11y ago
  healthchecks.io follows this pattern and it works really well: you just get an email with a login URL. No passwords are involved.
- s_kilk 11y ago
  I did something like this with http://nightchamber.com http://nightchamber.com, where your 'login' is just a unique URL. It's a fun idea, but it only works when the stakes are low (which they are for nightchamber, it's not like there's anything useful in the account anyway). I sure as hell wouldn't want paypal or amazon using that kind of scheme though.
untangledlaurel 11y ago
1password... last pass... is the only way to survive... Now how soon can we completely abolish passwords?
falsedan 11y ago
Nothing about password, but the nav banner show/hide on scroll for the page is delightful (and should be adopted by all sites post-haste IMO).

163 points by sethbannon 11y ago

On one side I understand the need for good passwords given how bad websites are at keeping their clients data private, but fundamentally the problem is rather that websites are leaking data, not that passwords are too weak. How do we solve that problem?

LukeB_UK 11y ago
The two aren't mutually exclusive. Teaching users to create better passwords as well as hardening systems and making them more difficult to hack are both beneficial.
scrollaway 11y ago
> 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.
misthop 11y ago
The simple answer is that you don't. A bad actor with a success rate of >0% is successful. A website with a protection rate of <100% is a failure. The unbalanced economic underpinnings (cheap to attack, expensive to protect) along with the necessity for perfection in protection makes it virtually assured that _every_ system, in time, will be compromised. 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.

rtl49 11y ago

Does anyone really believe the world needs yet another article bemoaning the common and unpopular practice of imposing arbitrary requirements on passwords? 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.'"

dec0dedab0de 11y ago
There are many more words than characters, so an 8 word passphrase is harder to crack than an 8 character password even if the attacker knows the passphrase is composed of all lower case words.
- rtl49 11y ago
  True, but (again, as a layman) I don't believe that's the gist of the comic. The artist seems to measure the entropy of the password based on the characters alone. I think a dictionary-based attack would reduce this entropy. I'm happy to be educated about why I'm wrong, though.
  - gabemart 11y ago
    The entropy count for each word represents picking one word at random from 2^11 choices of words. It doesn't have anything to do with the characters.
    - 11y ago

bradleyjg 11y ago

"The point here is that it’s my decision. Perhaps, to me, the convenience of a single email/password combination is worth the risk of my accounts being cracked in bulk. 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.

zokier 11y ago

I'm actually thinking something completely opposite; do we really need to have users input their own password? Why not just generate one for them? Users are notoriously bad at creating passwords (on average), and generating one for them would allow us to throw away all that complex password rule dancing. 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.

JoeAltmaier 11y ago
In my naive thinking, I'd let my computer and the server manage passwords independent of me. Let them share some secret; then my machine creates a 1024-bit challenge and get a response from the server. Why involve me at all? I'm terrible at managing large random things.
- bradleyjg 11y ago
  If you always used one computer that would be fine. But if you create your account on your home computer and then want to use it on your work computer, your ipad, your android phone, and occasionally at your brother's house then we need some way of authenticating you instead of your computer. And even if you don't want to log on from any of those places, eventually you are going to get a new computer.
  - JoeAltmaier 11y ago
    And how does that differ from a huge, unrememberable password?
- zokier 11y ago
  That sounds a lot like TLS client side certificates. Sure, something like would be nice but getting there would practically require new standards, then those standards need to percolate to server and client software across different platforms, then users will need to get used to them etc etc. Meanwhile autogenerated passwords can be made with a perl cgi script, be compatible with Mosaic from 1995, and be immediately familiar with most users.

astazangasta 11y ago

I have the perfect solution to this, but software systems aren't with me yet. The answer is: a keychain. Not a digital keychain, an actual one. On this I put my "infinity key" - it's a little USB flash drive with a LUKS-encrypted file system on it that holds a private key. Lots of tech people have something like this. It's great for SSH - I can add my infinity key to any host and be assured that I will always be able to login securely from any machine I want. We're all used to the physical metaphor of keys as security, and needing a physical key to get into things. This is not a huge change for us. 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.

angelbob 11y ago
Though he says a lot of this is to avoid bulk cracking of your passwords. As with, say, OneLogin, your keychain provides a really easy way to bulk crack all your passwords - steal the key.
jclulow 11y ago
You can't really "add" your key to a computer you don't trust, though. At best, it could destroy your USB device; at worst it could copy the contents out once you decrypt them. This may be better than using one password for everything, but it's certainly not a panacea.
- zz1 11y ago
  You could also catch BadUSB...
- astazangasta 11y ago
  I think the panacea is dedicated hardware that can produce secure tokens (a signed message) without having to expose my key to the machine I plug into. But existing systems still require that level of trust; I'm doing no worse than someone with a password typing it into a possibly insecure machine.

Someone1234 11y ago

I completely agree with the article. From what we can tell password strength meters mostly work, or at least work "well enough." Some users attempt to game the system and in doing so wind up with marginally more secure 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.

vectorjohn 11y ago
Just curious, but long passwords shouldn't in any way affect CPU load. After the first hash (of thousands?), it's just hashing a hash, which is always the same length unrelated to the original password length. Even though I can't think of a legitimate use for > 256 character passwords.

felipesabino 11y ago

I really like the idea behind passwordless [1], where users never use a password but just confirm they are who they say they are. 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. [1] https://passwordless.net/about https://passwordless.net/about [2] https://www.youtube.com/watch?v=8ZtInClXe1Q https://www.youtube.com/watch?v=8ZtInClXe1Q

jand 11y ago
A disadvantage is the media break while using passwordless. 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).
- miseg 11y ago
  If you can catch a person's email address upon their registration, it's the re-logging-in that would require them to switch to a different medium.
- felipesabino 11y ago
  I think your argument would also valid for 2FA approach, which is is widely encouraged regardless. Sign-up rate would drop drastically for a majority of common users if a good UX is not into play while developing the system workflow. 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.
  - jand 11y ago

Grue3 11y ago

There's no way I would give away my phone number to any random website. Thus, I would never use two-factor authorisation that involves my phone, unless it's a bank or something. Most of "social" accounts aren't all that important anyway.

sp332 11y ago
Most of my two-factor auth involves a time-based one-time pad (TOTP) that involves scanning a QR code once to sync the phone to the service. The service doesn't know what phone or other device I'm using.
klapinat0r 11y ago
2FA doesn't mean phone number. There's also HOTP and TOTP, dongles, bio, etc.
webo 11y ago
You don't have to use your own phone number. I use a Google Voice number for similar purposes. It also works online so I don't need to worry when my phone is out of battery.

avens19 11y ago

This exactly is why I use LastPass

Zikes 11y ago
Ditto, but I still get annoyed at having to re-generate a password half a dozen times to fit whatever opinionated rules a particular site comes up with.

morgante 11y ago

I hate the recommendation of 2FA as the solution. I find 2FA more patronizing than anything else. 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.

tptacek 11y ago
I use 1Password but enable 2FA anywhere I can. If you can store your 2FA keys in 1Password, you're not really doing 2FA. (The distinction may not matter much in practice!)
- morgante 11y ago
  > I use 1Password but enable 2FA anywhere I can 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.")
  - tptacek 11y ago
    If your Mac gets popped, attackers are going to own the kernel, and thus your keystrokes. 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.
    - morgante 11y ago
      > If your Mac gets popped, attackers are going to own the kernel, and thus your keystrokes. 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.

butler14 11y ago

No love for spaces in passwords? i.e. spacebar presses

w8rbt 11y ago

There's a RFC for everything else... why not have one for password requirements? https://en.wikipedia.org/wiki/Request_for_Comments https://en.wikipedia.org/wiki/Request_for_Comments

iamsohungry 11y ago

> The Attorney General of Texas Child Support website It would not surprise me at all if this password hell was intentional.

rkayg 11y ago

I work at Okta(https://www.okta.com/ https://www.okta.com/), a SSO product among other things, and we deal with this all the time. We use a variety of techniques to help secure the user's identity and access to various applications. 1. Use the SAML protocol to log in to apps as opposed to passwords. (See https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language 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)

digitalsushi 11y ago

I switched jobs last month and decided to audit all my personal stuff while the old place was auditing all the work accounts I left behind. We'd been using google/gmail 2 factor authentication. 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.

gefh 11y ago
I second a usb authenticator. It's also an effective defence against phishing attacks - unlike OTPs.
- aidenn0 11y ago
  How does it work against phishing attacks? Does the browser pass the domain to the USB authenticator?
  - Niten 11y ago
    Yep: https://www.yubico.com/applications/fido/ https://www.yubico.com/applications/fido/
mrec 11y ago
What's the procedure if you break or lose the FIDO hardware key? (Not a rhetorical question; I'd never heard of them before either.) 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.

svckr 11y ago

This is exactly what happened to me on MULTIPLE occasions with multiple websites. Right down to the special characters table flipping. 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…

zhkirill 11y ago

Reminded me of this video: https://www.youtube.com/watch?v=luv_bWmb9lE https://www.youtube.com/watch?v=luv_bWmb9lE

massysett 11y ago

"It’s time to use the password reset link again, which at this point is basically your login button." 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.

r0muald 11y ago
healthchecks.io follows this pattern and it works really well: you just get an email with a login URL. No passwords are involved.
s_kilk 11y ago
I did something like this with http://nightchamber.com http://nightchamber.com, where your 'login' is just a unique URL. It's a fun idea, but it only works when the stakes are low (which they are for nightchamber, it's not like there's anything useful in the account anyway). I sure as hell wouldn't want paypal or amazon using that kind of scheme though.

untangledlaurel 11y ago

1password... last pass... is the only way to survive... Now how soon can we completely abolish passwords?

falsedan 11y ago

Nothing about password, but the nav banner show/hide on scroll for the page is delightful (and should be adopted by all sites post-haste IMO).