Why [Insert Thing Here] Is Not a Password Killer

Similarly, if you’re not a financial site question whether you’re doing anything of value. The Netflix example is great: a huge password really doesn’t matter unless the site allows you to see stored credit card information since the worst thing someone can do is load your viewing history up with high ratings for Iron Fist. Continuing to cargo cult DoD policies from the 1970s has caused more problems than it’s stopped.

They were right to turn on 2FA but it does come at a cost, and that cost isn't always worth it.

>But it's possible that in the future we will put the bar higher. Then these arguments might be considered as silly as "with HTTPS I can no longer telnet into a web site and issue HTTP commands by hand!" (and don't tell me people didn't do that, I did it myself).

I'm actually going to make the opposite counter-argument. I do think https is a great achievement but I also think we lost something with the additional complexity introduced in, what used to be, a fairly simple protocol with wide adoption. I don't think those were silly arguments to have had.

Who needs a smartphone when you can use a piece of paper. Mind you this can be copied so has a similar vulnerability to passwords. But since it can be generated you can think of it as a salted password when combined with a classic one.

And then we use the final way of authentication, hard to forge personal documents, government issued... often in poor ways.

Computer systems cannot be truly fully trusted. Final security always depends on the human operators and equivalent human impersonators. A skilled social engineer can even convince your friends the account is dead. They can call the delivery company or even initiate the procedure to reissue documents or destroy keys. They can phish and scam you which is even easier.

How much set up does it take to get to that point though? Usability at point of use is great but setting something up is usually far more difficult than actually using it.

(This whole thing reminds me of “Your post advocates a ... approach to spam. Your idea will not work. Here is why...” And maybe warrants a similar parody.)

If all accounts would have sane restrictions on the password it would become trivial to have something both secure and convenient. I have been looking for a system that allows me to: 1. Does not require me to remember an absurd amount of information. 2. Allows me to login to services, even from other devices. 3. Has a unique password for each service (so that it is not disastrous if one password leaks).

We could have one master password, use site and username (and maybe a counter, to make it easy to rotate passwords) as salt, and use a hashing or password derivation algorithm to derive a unique password for each service. This would only require you to pick and remember a strong master password.

And I wouldn't say that text meant ASCII. My understanding is that it meant text is the thing that could be understood and written by both people and computers.

All text should be UTF-8. It really shouldn't be complicated in $current_year.

Forget that, I've lost track of how many times I've hit the horrible bug of "site X lets me enter password Y, explicitly compliant with stated password rules, but then rejects it at login time." Either the registered password was mangled by some input sanitization/encoding, or the login password was. After some do-overs, it becomes clear that many "valid special character lists" are just plain wrong. It's 2018, and there's an appalling number of cases where someone doesn't understand that quoting/encoding ASCII/UTF-8/etc. is a 100% solved problem.

Basically I have a prefix of length 7 which is two words, where some of the letters get converted to numbers, and then I use shift to make them into special characters.

Then for each website I append a different word that has some meaning for me, and convert the letters to numbers. Then I add a special character at the end.

A typical password might look like

P!^^w)r$M19175r?

Which is very easy for me to remember and type, reasonably long, and certainly not on any lists of most commonly used passwords.

Ways you could improve this method would be to have different prefixes for different industries (banking, social media, etc).

I remember a couple of passwords for services I frequently have to log into without access to a password manager. I can make choices about the security requirements for different services, and the security of the passwords I use for them. I can make choices about how to store them. I use a command-line program that stores passwords in individual textfiles, encrypts them with gpg and manages them with git. I could also choose to write them into a notebook with a cypher I can do in my head.

These are all choices I get to make because passwords are text, and nothing else.

The vast majority of the time, for the vast majority of people, it never results in any issue at all. And solve plenty of their problems.

I've tried educating non-technical friends and family about insecure passwords and how random long strings are more secure. Their responses are:

1. "I can't remember that password! / I don't want to type that!"

2. "I'm a nobody, hackers wouldn't be interested in me. My account has no interesting data." [explanations about botnets doing damage to others go way over their heads]

3. "If someone REALLY wants to hack me then I can't stop them anyway."

They think that the inconveniences of secure password practices are not worth it.

I don't think a password manager will solve it for them. Especially older family members are "afraid of technology" - they are constantly worried that they will break something, and when something is written on the screen 9 out of 10 times they have no idea what it means. I have enough trouble explaining how copy-paste works — I don't think I can explain them what a password manager is, or how to keep in in sync across their devices, let alone convincing them to pay for such a thing.

I've tried the low-tech way. Advising them to use XKCD-style password and writing them down on paper. The result: they keep passwords over multiple pieces of paper/notebooks and they always lose them.

I've resorted to PMaaS — Password Management as a Service. In other words: I dictate what passwords they use, and I manage it for them in my password manager. Their login method is to call me to retrieve their login credentials.

Though it's also quite likely a lot of users don't even remember their passwords at all now and just use password reset every time they want to log in.

Long passwords plus a bad password check (https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...) might suffice. However, without that check, I suspect requiring special characters marginally improves entropy in practice.

But a sufficiently long password could literally just be 'a', repeated. Would that really be more secure?

Honestly if you want somebody to have a secure password, make it for them and e-mail it to 'em. Virtually no chance they are going to use it for anything else, and if somebody has their e-mail, they can recreate one anyway.

e.g.: https://magic.cuvva.com/auth-callback?code=authzcode_000000B...

We're oriented around mobile use cases. Admittedly less ideal if you don't have your email on your desktop. But ultimately, if all else fails, you can always log into your webmail.

For me the key thing is that it doesn't rely on users having any particular knowledge or understanding best practices - they just need to hit the big green button. Sure people are more used to passwords, but that doesn't mean the usability of magic links isn't still better despite them being much less common.

Normal people are so bad at dealing with passwords. They reuse them, they forget them, they write them down on text files on their computer. Almost anything is better if your userbase isn't primarily technically adept people.

And frankly most popular email providers are pretty good at keeping the accounts secure. Likely much better than anything homegrown we could do. Especially given the fact that you'll just end up having password resets via email anyway.

I gave it some thought, and that seems to be solvable. Have the link go to a 'confirm' page, where the confirm button performs a post request. If security scanning software is randomly hitting post requests, that is just totally ridiculous.

What seems a lot more scary to me is the plaintext nature of e-mail. Even SMTP over TLS doesn't keep any end-points from reading your email, and I'm guessing there is a small but significant set of people who'se email providers don't run TLS.

Besides, if someone can recognize that any request is underway for a login, they might intercept it and send a phishing fake.

Not that I think about it.. it's kinda suspicious that no one has asked for it in all this time. Hmm..

The ticket or cookie or what ever is just used to signify to the system that you are authenticated as user x and specific to http because it is stateless. So an implementation detail and not part of the authentication concept.

I meant cookies here as data that lives in the browser forever or until the user requests a new one just using that cookie alone. And removing that cookie results in locking that account forever.

And we can go up, even imaging quick DNA scanner, quick enough and smart, it does not change that much, your DNA can be grabbed around you in many way.

The essential point is simple: using your body means using an exposed key, using a password means using your brain that it's far harder to "expose". Also passwords are trivial enough, you can even check your keyboard for builtin keylogger, protect your environment from camera, microphone (phone/audio analyze to determine key's you press) etc. Try to hw check a biometric system and well... Good luck.

Yes, vendor lock-in is an issue; and I hope eventually there'll be a way to sync credentials across browsers. But keep in mind that, even as things are now, it only locks you to a specific browser, not to a specific OS.

/s

I wonder if there is a hashing scheme that would work with some kind of ambiguous entry... I.e. “is the 3rd digit between 5 and 10”.

If you could confirm certain properties of a password/pin from its hash...

Even if it’s flawless, which is impossible, with biometrics you can easily be coerced into giving access without effort, whereas we haven’t invented a mind reader yet.

In other words I can easily imagine kids gaining access to a credit card via fingerprints or facial recognition, while their parents are sleeping ;-)

I wanted to write about law enforcement agencies, but this is so easy that your kids can do it.

Whatever it was Nortel had, I highly doubt it was as usable or ubiquitous as what WebAuthn already is.

Password managers are a separate program that (some) people are willing to use as part of their login process. Perhaps whatever adoption it has is based on the fact that people understand passwords. But once they're used to using a program to log them in, I'd argue that's a potential hook into something more secure. Even something as simple as the API I described would mitigate (I'll stop short of saying eliminate) phishing attacks.

But I totally agree with your point about limiting special characters and length.

Surely that was already true?

I agree that the business makes the decision, growth is the top priority and friction reduces growth, but in reality this is how most of the world already works. If you rent a hotel room you don't get to provide your own key and if you lose their key then you must prove who you are to get another one issued.

In the end there must be some compromise between growth and responsibility. If a company cannot grow responsibly then we end up with Facebook all over again.

When they need to change devices, have the standard e-mail based password reset as well as "show password" in the account settings (make the password reset not reset login, unless the user explicitly elects to "log me out on all devices").

thousands (millions?) of people are daily losing money / privacy due to poor "locks" on our digital doors. if millions of people were burgled every day then these poor quality locks would be replaced with hardened steel doors and seven tumbler whatevers.

I think it is the invisibility of the attacks that is mispricing the cost/benefit ratio, and allowing the idea "people won't accept anything better than passwords"

A friend recently lost control of his business email, which lead to someone asking a client to chnage bank routing detail before paying an invoice - police were involved but it's still not clear what's going to happen.

He is not happy with passwords.

Now as these scenarios spread, as attacks cost more money, we will see the perceived cost benefit sweet spot chnage - away from weaker security and towards better solutions - password managers, 2FA, U2F etc.

we will give up our passwords. if the cost not too is too great.