Hacker News new | comments | ask | show | jobs | submit login
Patronizing Passwords (joelcalifa.com)
163 points by sethbannon on Nov 17, 2015 | hide | past | web | favorite | 103 comments

"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.

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.

> This could easily become the norm, and should.

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.

A government-issued private key doesn't solve a main problem I'm concerned about. This needs to be something people can roll themselves. If you can't generate your own key, you're not secure.

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.

Maybe the only answer is to air-gap the two devices and have the user input a secret code shown on the dongle. So you press the button, type the code on the website and log in that way.

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.

The device could instead have a display that displays a password, QR code, one-time-key, etc... and then you would scan it using a webcam or your phone (or type it manually).

Yeah, but that way it's displayed out in the open and you can make a mistake copying it. I think just exchanging usb flash storage sticks is preferable unless you sufficiently distrust the system you're on.

Maybe like a phone running a TOTP application?

I would have more trust in a separate device that has no networking capabilities.

What if it's in a "secure element" whose hardware and firmware make it provably incapable of divulging the private key?

I don't think that's possible... it reminds me of Apple saying that they can't decrypt your phone, but it is decrypted when you use it and many apps have permissions to transfer basically everything over the network (and Apple has root too).

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.

You could also catch BadUSB...

>The problem is, no website or browser supports this kind of authentication

Aren't you describing Yubikeys? Which aren't widely supported, but IIRC are still supported by some websites and apps.

A Yubikey-like device is actually more secure than what the parent comment describes, because it prevents the private key from being viewed or copied by the host computer. You can think of it as a dedicated piece of hardware that runs something like ssh-agent, except over USB instead of a socket.

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.

Wouldn't it be better to have your "infinity key" not reveal the secret data, using a smartcard or similar technology? That way if the computer that it's connected to is untrusted, no further damage could be done after removing the card. That + TLS client certificates stored on this card seem like it might not be the worst user experience, while still remaining reasonably secure. From my brief Googling it looks like the US military uses something like this.

Yes, RSA provides systems like this also I think. My solution is worse, but only uses commodity hardware and free software. When I can program my own smart card I will prefer that.

Firefox, which I think would be considered free software despite some of the shit they've been bundling, does client certificates, and I'd imagine one could program their own smartcard, although I don't know much about it.

The Basic Card is programmable: http://www.basiccard.com/

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 :|

> We're all used to the physical metaphor of keys as security, and needing a physical key to get into things.

I was hoping this will go away in my lifetime.

> it's a little USB flash drive

Uhm, yes, but why not use something a little more convenient, like a smartwatch with NFC/wifi?

A flash drive that lives on my keychain would be much more convenient for me than a watch, which I dislike wearing.

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.

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.

I'm not 100% certain, but when I setup 2FA for many services they give you ~10 single use emergency codes that you can use to get into the system in the event that your second factor is unavailable for whatever reason (phone stolen, you are out of the country, fido broke, etc.)

Contacting your domain admin, using your backup codes, if none of those work you'll need to fill an account recovery form with the service provider, ie: https://support.google.com/accounts/answer/185834?hl=en#phon...

I second a usb authenticator. It's also an effective defence against phishing attacks - unlike OTPs.

How does it work against phishing attacks? Does the browser pass the domain to the USB authenticator?

I work at Okta(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_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 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.

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!)

> 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.")

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.

> 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.

That's only true if you routinely log into those services. If they pop your Mac, they get all your 1Password passwords. I like 1Password, and this isn't a flaw in 1Pw, it's just the limitations of relying on your computer for secret storage.

Good point, I hadn't considered the exploitation of sites I don't log into.

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.

I have one. I used LastPass browser extension for Chrome which autofills my (unique) login credentials. This is incredibly convenient, but obviously opens up the possibility that if someone sits down at my unlocked computer, they can visit any site I have an account on and login as me.

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 also use a password manager, and enable two-factor authentication when possible. I mark my personal devices as trusted, so I only have to do two-factor authentication whenever I get a new device.

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.

I'm curious what you prefer for your second factor.

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 have a physical token, and then a couple things on my phone.

I'm not super comfortable with SMS authentication but use it for lower-value stuff.

What 2nd factor has a static key that allows you to store it in 1password? I don't think I've seen a second factor that isn't hardware (phone, dongle, whatever) and/or a dynamically generated code.

> What 2nd factor has a static key that allows you to store it in 1password?

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...

Neat, I had no idea about that feature of 1password.

For services using standard protocols, you can use software for OTP (google authenticator is the most famous example and uses TOTP/HOTP).

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.

Yeah, I didn't know 1password supported that, I've always just used Authy on my phone.

My biggest question with this is, what if I ever have to login using a computer or tablet that is not mine? How does 1Password deal with that case?

1. I have my keychain on my iPhone, so I can always look up the password there.

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).

Most users would have a smartphone or other device with 1Password or their password manager of choice on it, so you can copy the password manually from that device. I tend not to log in on any device that isn't mine, though.

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.

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.

> After the first hash, it's just hashing a hash

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...

Cannot argue with that. It should be noted that 256 characters is our default across all inputs if no other maximum has been selected.

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.

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

[2] https://www.youtube.com/watch?v=8ZtInClXe1Q

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).

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.

But most sites let you "trust this device" once you've done 2FA - passwordless doesn't have that option from what I can tell. Also, 2FA is an extra, optional layer for most users. They can choose if they want the extra hassle in exchange for security. Passwordless gives you no such option, you have to switch apps, period.

You are right. Here comes the "target group" aspect (and some others) into play. Oversimplification: Are you targeting techies or eldery? Some will endure security-related hardships, others won't. As said, there is the need to watch who you design for.

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.

An issue with passwordless is its vulnerability to passive attack. From perusing the source code, it looks like they authenticate users based on a token and uid embedded in a link sent to the user's email address. If that link is intercepted, an attacker can impersonate the user.

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)

What if I don't want to confirm that I'm Pavel Lishin to a given website? Do I have to create a new Facebook, etc., account? One per website I don't want to identify myself to?

You can always use browser identification [1] for that

(Yes, that's a joke :p)

[1] http://kluge.in-chemnitz.de/tools/browser.php

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.

Most users do not use password managers, thus most users won't remember the password you generate and you will have the same problem.

That tends to degenerate into resetting the password every time, or logging in from the password reset email you sent them.

In either case, you've moved security to the user's email program which is (sadly) probably an improvement.

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.

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.

And how does that differ from a huge, unrememberable password?

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.

What new standards would be required? All modern browsers that I'm aware of support TLS client certificates, there's even an HTML5 <keygen> element that causes the browser to generate a CSR and send it to the server for signing.

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.


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.'"

> To my knowledge, these are usually dictionary-based attacks, which would significantly decrease the "search space" to discover even a long, lower-case sentence.

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.

I appreciate the clarification. Sorry to be on the other side of the "infuriating argument with someone who doesn't know information theory and security."

Not at all, I know only a tiny amount about this field myself.

> 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 :)

I used to be of the mind that the service provider should let me choose whatever password since it was after all, my password and my account.

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.

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.

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.

No, he measures the entropy based on a machine knowing the format.

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
as used in the comic.

If, instead, the password was taken to be 28 random characters from [a-z ], the entropy would be

    28 × ln₂(27) ~= 133
This is the overestimate that the artist didn't make.

With a genuinely random alphanumeric password, like 0LsW-nT5#^kQ, the entropy is higher:

    12 × ln₂(92 keys on the keyboard) ~= 78.
but the point of the XKCD was to show a memorable password.

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.

Especially since the average vocabulary is closer to 2^14

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…

"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.

I did something like this with 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.

healthchecks.io follows this pattern and it works really well: you just get an email with a login URL. No passwords are involved.

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?

> 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.

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.

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.

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

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.

2FA doesn't mean phone number. There's also HOTP and TOTP, dongles, bio, etc.

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.

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.

There's a RFC for everything else... why not have one for password requirements?


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).

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

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

This exactly is why I use LastPass

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.

> The Attorney General of Texas Child Support website

It would not surprise me at all if this password hell was intentional.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact