Hacker News new | comments | show | ask | jobs | submit login
Why [Insert Thing Here] Is Not a Password Killer (troyhunt.com)
212 points by nikbackm 7 days ago | hide | past | web | favorite | 271 comments





It is not just that everyone knows how passwords work. It is also that you can always enter a password.

What if I don't have my phone to scan a qr-code? What if I want to use a minimalistic browser that doesn't implement a key pair store and I don't want to or can't set up one external? What if my minimal browser is text only? What if I'm on another device and don't have my stuff on there?

I will pretty much always be able to enter a string of characters. To quote the unix phillosphy:

Text is the universal interface.


Sort of. You're selectively quoting "Write programs to handle text streams, because that is a universal interface" -- but that was from the days when "text" was basically synonymous with "ASCII".

Passwords aren't streams, and in the Unicode world, they're not even (predictable) byte arrays. This isn't just hypothetical. There have been recent bugs in major systems where people with non-ASCII passwords couldn't type them.

One of the major failings of QR codes for consumer use, IMHO, is that there is no fallback. With UPC, the number is printed right below the barcode, so when it doesn't scan, the clerk can just type in the digits.

ASCII digits are universal. Bytes are universal. Text is ... complicated.


> There have been recent bugs in major systems where people with non-ASCII passwords couldn't type them.

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.


> ASCII digits are universal. Bytes are universal. Text is ... complicated.

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


Unicode itself gets pretty complicated:

https://en.wikipedia.org/wiki/Unicode_equivalence


Let's rephrase what GP said: All text should be UTF-8 in Normalization Form C.

The idea of "text is the universal interface" informed the design of unix and it resulted in text streams. But if I apply it to something entirely different, authentication, I come out at passwords.

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.


The back story of the work some significant UNIX people did to get UTF8/Unicode into workable state in standards is amazing. Application of brilliant minds to a corner-case problem in international standards.

http://doc.cat-v.org/bell_labs/utf-8_history


Another aspect to this is that it’s single channel: no problem if your phone is out of data or at 1% battery, you need USB-A but have USB-C, etc. Nobody needs to regularly read a code to someone over the phone but the people who have are probably going to remember that when getting pitched on any new system.

This is terrible from the perspective of phishing but we really need to avoid that causing us to ignore the usability hassles to everything else.

I’m happy to see that conversation get more nuanced, too, rather than just being game-theoretical about perfect security: acknowledging the usability and security costs of password complexity requirements or expiration, having intermediate checks for more sensitive operations so you’re not training users to hammer their password out hundreds of times a day, etc.


"It is also that you can always enter a password."

You are correct, as long as you throw out all the other password advice that, ironically, Troy Hunt has given us about not reusing passwords, making them long or full of hard-to-memorize characters, etc.

Once you use secure passwords by making them long and/or hard to memorize, unique for each website, etc., you can't just rely on your brain, fingers, and an awkward on-screen keyboard to "always enter a password." You need your password manager with you, you need privacy so nobody can shoulder surf while you agonizingly peck out your password on your touch screen keyboard (remember everyone learning Kanye's cell phone password recently?), etc.

Your statement about universality is only technically true.


It is also practically true.

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.


I was just about to type the same response.

I can also write down passwords (unencrypted) to sites that I use infrequently, and for which I have low security requirements. For many such sites, a password reset is reasonably implemented and fast, and so for a vast number of sites, email security (and thus, email password security) == arbitrary site password security anyway.


I'm not sure it has to be so difficult. It took me about an hour to come up with a scheme for creating long, unique, and random looking passwords that are very easy to remember.

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 used to do something like this too before I moved to password managers. The reasons were:

- If a password on a website is stolen or if the website forces me to change password, then my "rules based password generation" becomes a problem. Now, it needs to handle variations. And, with hundreds of websites, I won't remember which variation a certain website password is on.

- If a website has password rules that don't let me use my "rules based password generation," then what do I do? I tried having an alternative generation rule, but different websites have different password rules. So, no one / two / three generation rules will be able to generate acceptable passwords.

- The "append a different word" requirement is tricky. How do you append a different word for each of the hundreds of domains while having a way to mentally recall them? I chose to use the domain name and shift all letters up by one. However, that failed with sites that use multiple domain names.

- Sharing passwords with my wife became a hassle because the rules and variations were becoming too much for her.


Yes, there are this and myriad other schemes to accomplish the same thing.

This doesn't much help the average customer service worker who struggles to give correct change if you hand them cash in an amount that's not a round number.

Passwords are a thing that need to work for everyone, which means they need to work for the lowest common denominator too, which means the GP is correct to point out that password advice is contradictory: the lowest common denominator cannot both use strong, unique passwords and avoid using some other kind of technology to assist with that.


Do you really think regular users will do anything remotely close to this? Based on my interactions with normal/regular users, the chance for this to happen at any meaningful scale is zero (0)

I'm not certain regular users will, but I do believe that this should probably be practical knowledge that could be taught in schools considering the far reaching impacts of having financial accounts or email accounts hacked.

Alternatively teaching about the use of password managers might not be a bad idea.

But digital literacy should certainly be something that our society focuses on teaching it's young adults and keeping your accounts secure is one big component of that.

But considering our schools don't teach us about credit scores, and a myriad of other very useful things that can impact you in large ways down the line, I guess I'm not so hopeful.


It is generally always a trade-off between security and convenience. You can demand that a site allow passwords but you also aren't memorizing a 24 character nonsense password for each site login. The holy grail is can you bend the line and have something that is super secure and mostly convenient.

I currently work in an environment where I don't have access to a password manager, yet I am expected to have unique passwords for each service, and rotate passwords every month, and am not allowed to store passwords somewhere. Of course, this method requires you to remember more passwords than practically possible.

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.


Once you have a counter, you have state, and you might as well just use a password manager.

It may be you're working in the one environment where the master password + derived password scheme + counter scheme would be an improvement, but the above objection is why it doesn't work well for most users.


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

This has been tried. While it initially sounds appealing, it is a monumentally terrible idea.

* You need software to implement the scheme.

* Rotation is a problem, you need a counter for state

* Different services have widely different password rules which are additional state

* If a site stores password data in cleartext or weakly hashed, your master password/passphrase can potentially be cracked

* People choose passphrases just as badly as they choose passwords

Just write your passwords down. Maybe leave a few characters off or don't label them.


> * If a site stores password data in cleartext or weakly hashed, your master password/passphrase can potentially be cracked.

It all comes down to the threat model you are defending against. The threat model I'm defending against is automated attempts to catch me reusing the same password with different accounts.

Even if you were defending against a motivated actor putting human eyes on your passwords, something like`XXXXXXsXXXXXXsssXX` where the X are reused across sites and the s is a derived, site-specific chunk is a) as good as completely random until your adversary is manually correlating multiple leaked passwords for you and b) not trivially obvious to derive once they are correlating multiple leaked passwords.


> until your adversary is manually correlating multiple leaked passwords for you

This is a thing that is done, and even automated. If you have a couple password dumps, checking levenshtein distance between them is not hard.


I know that environment well, you pretty much have to come up with a hash function you can do in your head. Is it secure? Maybe you can pull it off. I think most people can't, and that's what leads to people writing down passwords.

Writing down passwords is usually less bad than password reuse and use of weak passwords.

Its the same concept of the majority of offline password managers. You are hiding all of your amazing 32 character randomly generated unique passwords behind a single memorable password.

BUT its safe, because unless YOU are the target of the attack, the contents of your random slip of paper on your desk, or the password protected one note file on your dropbox, or the encrypted pwsafe3 file on your usb stick are outside of the reach of some bad actor trying to get ALL of the passwords, not just YOUR password.


Did you reply to the wrong comment?

Normally, to attack a password manager, you must have a copy of its database. With a deterministic password scheme, this is not required. This proves to be disastrous in practice for cryptocurrencies.


No, I'm saying writing your password down in a notebook on your desk in your locked office is nearly as safe as any offline password manager.

If you aren't the one under attack, and you still create different passwords for each service, the method of offline password storage (be it a spread sheet, a password manager, or a sticky note) are all similarly-ish safe.


Depending on the physical security posture of the location where the passwords are stored, that can be a correct statement. I wouldn't argue "usually" simply because most people aren't smart about where they're stored.

It depends on the threat vector, though. Printing out my passwords in 72-pt font and taping them to the wall is obviously insecure if I leave them up for the house cleaner to see, but there's zero risk that a remote attacker will see them (barring them taking over the webcam or something, but at that point they probably have root access anyway).

Or paying your housecleaner to take a picture and email it to them...

The key is to come up with a repeatable pattern that defeats whatever repeatable pattern detection that is in place and just apply it. You don't write down the password, you write down parts of the pattern.

Is it secure? No. But if you work at a place where SSO isn't a thing in 2018, it's not secure anyway.


This. I had a keyboard pattern I used in a similar environment. Just shift a row over every month. I couldn't ever tell you what the password was from memory, but could type it in no problem.

This is bad security advice. Don't this if at all possible.


> I currently work in an environment where I don't have access to a password manager

How is that reasonable? If you make a case that restricting password managers lowers security, could you possibly change it?


Password card.

Medium is frustratingly guilty here. Your login choices are limited to sharing data with Google/Facebook/Twitter or clicking a magic link in an email.

If you don't like to share your data with third parties then you are basically restricted to logging in on devices that have access to your email. Which means you're stuffed when that doesn't apply.

Security at the expense of usability is fine when it's warranted. All too often it's not.


What about a throwaway email? Does that leak device data?

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


It's not so much the choice of email address (throwaway or not) but the fact that you physically can't log in on a machine where you can't/don't want to access your email. You can't access the link and it's too long and cumbersome to type out manually.

So your only choice is to access your (personal) email on a device where you may not want/be allowed to.


I don't find that so objectionable, to log into their site you need to enter some credentials, _usually_ that checking is being offloaded from medium onto a third party you may trust more. In the case that you really need to access it where you don't wish to log into your primary email you will still need to login to something, their approach allows you to choose what sort of login security you'd like (maybe you want 2FA via google, maybe you want a more security lax service)

I think password managers are great but the service I see them providing that has the most benefit is to reduce the number of passwords the user needs to actively remember. The single sign on approach has it's weaknesses but the idea itself is pretty sound, you should legitimately trust facebook or google or whoever to know more about secure authentication than some random site... the fact that this service comes with a privacy leak and implies greater online presence tracking is terrible, but the core idea is sound. It'd just be nice to have a neutral party doing it.


I have no objection to them offering Facebook/Google etc for those who wish to use them.

The problem is the lack of an alternative which is how this whole thread started - their approach allows you to choose between logging in via a third party, or logging into your email on the same device. It doesn't let you log into their website directly.

I wouldn't mind if they emailed you some kind of time-limited one time token you could enter on the other device, rather than using a conventional password. But all they supply is a lengthy link, which can only practically be opened on the device that has access to your email.


I agree that it's a more salient point IMO. Smartphone based authenticator are not exactly difficult to understand, at least from a user's perspective. You enter your username, you get a prompt on your password, you're done.

Yubikeys are not difficult either. You enter your username, you focus the password field and you press the button. There, you're done. If anything it's easier and more convenient than a password.

Passwords are just the lowest common denominator. Everybody can memorize a character string, not everybody has a smartphone or yubikey with them at all times.


> You enter your username, you focus the password field and you press the button.

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.


They provide software that you install to configure your device. I haven't used it personally (my Neo 5 is being delivered), but they've done a pretty good job of making it easy.

The biggest problems are:

- limited selection of sites that support U2F - U2F is off by default in Firefox (it's a little buggy apparently) - somewhat expensive ($45 for Yubikey Neo)

Those are getting better, and I think the Yubikey can be used OOTB (you just enable it on an existing login to prove you own it). I'll be regenerating keys, but most users probably won't bother.


U2F is a legacy feature. New sites should deploy WebAuthn and existing sites should migrate, the Firefox pref override is for those remaining legacy sites. It basically bodges their WebAuthn implementation to offer a passable imitation of U2F.

I don't know if a Neo can replace the secret key that makes FIDO (and thus U2F/WebAuthn) work but doing so seems pointless. If bad guys tampered with it, they presumably neutered this feature; whereas if not it's fine out of the box. Certainly Yubico's cheaper FIDO2-only product offers no way to regenerate the secret.

Nobody today deploys WebAuthn to replace passwords, only as a second factor so it doesn't really undermine Troy's point, though perhaps our other countermeasures (long complicated passwords for every site, changed frequently) are less necessary if you have a good second factor like this.


The second way is to use one time pads in addition to passwords.

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.


> It is also that you can always enter a password.

If you remember it. You either have to use weaker passwords (for example, same password on several sites) or you won't be able to remember them. Or you can write them down which is pretty secure, but is not it easier just to carry a hardware key instead of a notepad with passwords?

Also, once I accidentaly deleted Latin keyboard layout in Linux (yes, it is easy). And having only Russian layout I was unable to enter the password to log in (and even if I could I wouln't be able to use the console). I tried to use on-screen keyboard, but in Debian it cannot input characters not present in keyboard layout.


A bit of a bodge I find works is to make my passwords of the form word+site+number, say Mangohn4234 for HN. Then they are all different, pass the has it been pawned thing and its quite easy to remember Mango 4234 or similar if you use that for them all.

I see where you are coming from but sometimes you have to enforce some things. If you don't have 2FA, you can't login into this site is a completely rational consequence if for example this site is handling financial assets of yours.

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


There’s also room for nuance even with financial sites: e.g. do MFA for everything which causes money to change hands but don’t require it every time someone checks their balance or confirms that their rent check went through, especially from a frequently-used client.

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.


Indeed, the best policy is to not store any data. Even easier to comply with GDPR this way. No account is best account.

This requires that the site supports automatic completion and pasting. Quite a few sites explicitly prevent it for stupid reasons like assuming user browser is compromised.

(If it is, you shouldn't be using the webpage for authentication.)


I really value the GDPR for getting companies to see stored data as a potential risk rather than just something which can potentially be sold later.

They could also:

- increase your subscription and watch using your account for free - send DVDs to their house and sell them - use your same email/password combo on other sites

If you use 2FA for most things, it's much harder exploit anything. However, you need to use good 2FA, not that SMS crap.


Everything you mentioned was covered in my original comment:

> - increase your subscriptio

This should force a confirmation and notifications as I noted. Simply checking the credit card CVV is way more useful than traditional MFA.

> and watch using your account for free

Not your problem and Netflix must monitor that to catch friends and family sharing anyway.

> - send DVDs to their house and sell them

Also a financial change which should trigger checks. Again, CVV does the job perfectly fine.

> use your same email/password combo on other sites

This is only true if they utterly botch the design by storing passwords insecurely and displaying them to the user. If either of those are true, it’s virtually certain that they’ve made equally bad mistakes elsewhere which MFA won’t help with.


I would never claim there is no legitimacy to enforcing 2FA. At my last job we ran into a situation like that. I always lacked things other people and services took for granted for financial and political reasons (like a smartphone). When we were required to use 2FA for some services at work it caused some friction for me. We found a workable solution, but it was less than ideal.

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.


For your telnet example, you can still use ncat, opens, or gnutls-cli to enter HTTP commands directly over a TLS transport. Yes it's more complicated, but it's still doable.

Of course I feel a lot better using ssh than using telnet. I just don't want people to discount that this added complexity is the price we pay for the security.

Or, what if I don't own a phone? I do own a phone, but my wife does not because she doesn't want one.

I am particularly empathetic to that position, because I didn't own a phone until very recently and it caused a bunch of problems for me. It informed my perspective a lot.

> Despite it's [sic] many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone.

I think the problem is that people don't understand how to use passwords. They will reuse them among sites. They pick easily-guessable and low entropy ones. They will type them into any website that asks. The end result is that not much security is provided.

(Things are just as bad on the server side, of course. Developers store them in plain text. They will email them to you. They delete entropy so that you can use your password to log in over the phone or from a computer terminal that apparently only has capital letters. I've even seen a website where the password is sent to the browser and the password checking happens in Javascript. Not great guys, not great.)


> I think the problem is that people don't understand how to use passwords

From the looks of it, neither do the authenticators. The capital letter + symbol + number requirement had led to the current predicament. Just asking for really long passwords would have been a lot better.

As it stands, people either use a predictable string of num-symbol to satisfy requirements or remember that one strong password,.which qualifies for all of the above.

Software like Lastpass are great, but I don't always have access to them. They also make all of my.online security have a single point of failure.

I think it would be a lot better if companies just changed password requirements to a decently large length eg: min 20.

This eliminates the likely hood of password like abc123, qwerty and the oh so lovely "password".


The problem with that is that in quite some cases I don't care about the security so I can just use a crap password.

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.


Just by itself, long passwords will result in people using "franklymydearIdontgiveadamn" and other things susceptible to a dictionary attack.

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.


Pretty much everybody I know and asked in the office just sticks some punctuation at the end, e.g. "Passw0rd$". IDK how much of an "improvement" that is, compared to e.g. 4 extra characters.

That's definitely a thing, and you're right, it doesn't add much entropy (people choose from a few numbers, a few special characters, not that many substitutions). Four extra characters that are truly random (even just out of 26 letters) is way better. However, that's not the alternative I'm worried about. I'm worried about people using phrases that will be in the first few thousand entries in a phrase dictionary.

And that's still better than a crappy, short password. I use lyrics, quotes, etc for my important passwords (password manager, email, etc), and my passwords are >20 characters (usually >30) and really easy to remember (and I can secure it by placing one extra symbol in there).

The attacker doesn't know what I'm using for my password, so they have to attack all valid combinations up to the max length the server supports.


Song lyrics are not safe https://arstechnica.com/information-technology/2013/08/there...

I don’t know exactly where the breakeven point is, but there is some point where a song lyric or other phrase provides less entropy than a relatively short password.

Bottom line: use a lot of random ascii characters(at least 14 or 16, or 4 random words) and you’re probably set. Use less, or a found phrase and it’s not good.


You can't talk about safe without a threat-model, especially distinguishing between whether you're trying to prevent offline attacks against stored data or brute-forcing a running login system. If you can rate-limit many things are fine, especially if you have some confirmations at key points (“Your account was just accessed from …”) with restrictions which make it hard for an attacker to permanently wrest control of the account or incur large costs immediately after gaining access — think about how Amazon.com doesn't require 30 character passwords because adding a new shipping address requires you to re-confirm the credit card information first.

That's definitely true, though you can simplify matters by saying "I'm always going to try to have passwords that are safe against offline attacks".

I would ask what’s the cost benefit ratio for defending against offline attacks with increasingly unpleasant password requirements versus things like increased KDF rounds, general server security improvements, and the defense in depth measures which increase the costs of actually profiting from a user account compromise.

I think we’ve historically been shaped by classic Unix crypt() memories where something couldn’t easily be fixed without breaking compatibility even though that era is largely in the past.


I see how this wasn’t obvious, but I never actually said anyone should implement any particular password requirements, just that certain requirements might not increase entropy as much as you might think.

My above comment about offline attacks was my personal stance/ideal: I use a password manager for just about everything, not something I’d mandate.

As a developer, in many contexts I might implement min 8 chars with no special char requirements. I think the bad password check is also a good idea.


People aren't good at memorizing long lists of things, so just requiring long passwords isn't sufficient unless you are willing to also allow everyone to use the same password everywhere, and that's worse than the single point of failure problem than password managers because that's a distributed point of failure (just one breach of any site/application that you use; your security there is only as good as the weakest link).

>People aren't good at memorizing long lists of things

It's much easier to remember a 40 character passphrase of real words than a 12 character password of random symbols including punctuation


Yes, but it doesn't solve the problem of memorizing a list of 40 character passphrases for every single website/app that you use. Length alone as a password strength requirement is not sufficient. Length alone only further encourages password reuse, because people won't memorize more than one or two passwords, especially as they get longer.

A 40 character password of real words is usually easier to crack than a random 12 character string, though.

Citation needed (that sounds wrong without seeing the maths).

But also missing the point. It just has to be better than the usual 8 + some punctuation at the end that most people resort to when faced with these shitty, asinine password rules.


English words are ~1.5 bits per character, random ascii garbage is ~6.5 bits per character.

It really starts to depend on the details. If there are 10,000 words and you use 5 of them, that is 1.1x more than 12 characters where you only use lowercase letters, numbers, and shifted numbers. Tweak the allowed symbols, length, and your dictionary and you can make either one look better than the other.

I think there are probably less than 10,000 words that people would choose for their password, and that people use capital letters... maybe, but don't use 12 character passwords (8 more reasonable) so it could really go either way.


screye is almost certainly referring to XKCD-style passwords, like "correct horse battery staple" [1] which are memorable and comparatively high-entropy, but don't have symbols or numbers.

[1] https://xkcd.com/936/


Yes, one is memorable, which is why it is a great password for your password manager of choice. Again, the problem is if screye is advocating that password managers are a "single point of failure" and that length should be sufficient: people don't have the mental hardware to remember an XKCD-style password for every single website or application they use.

> I think the problem is that people don't understand how to use passwords.

They do understand it. They just trade security for laziness.


Exactly. The thing is, they keep doing it because... it works.

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.


Agreed.

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.


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

And they're probably right from their own perspective.


I honestly don't give a shit about 90% of the services I sign up to that require passwords

This does not work, you're a single point of failure. If you say, get sick, family members will override security.

Nice try though. I'd recommend an actual password manager instead. Authenticated with biometrics and a simpler local password.

Your service does the same, using voice and phone number as biometrics. (Perhaps with recovery question.) Feel free to replace it with sufficiently advanced AI.


Please, try to be in my shoes. Even teaching copy-paste is so difficult, how do you want me to teach them biometrics?

The "I'll manage all your passwords for you" is the only solution that actually works. The ONLY other alternative is that they use 123456 as password everywhere. I already explained why I can't get them to use a password manager.


What about going back to the notebook idea? You give them a notebook that's called 'Passwords' and it sits on the desk beside their computer. They only write passwords in that notebook, and you can explain to them to write at least 20 random numbers and letters for new passwords.

When you visit, you can write those passwords down in your password manager. This way if the book goes missing or there is a disaster, you have a backup.


They lose the entire notebook. The thing is, they only need login credentials a couple of times a year or so. Things like social media and email are apps that are logged in all the time so they only need to reauthenticate when something is wrong or when a special event happens (like buying a new phone). So that only leaves a thousand different boring things that they only rarely access, like the government ID, the utility company account, the insurance company account, etc. So every time they have no idea where that particular notebook is among their tens of other notebooks, pieces of papers etc.

So what if 123456 is a sensible password for them? Explain them why they should use a more secure password. If they don't get it's maybe they really don't need a more secure password (they don't care who has access to their accounts, and the likelihood of them being hacked is very low).

People get killed every day making similar assumptions with automobile safety. The ability for a person to "get it" is not a good indicator of their susceptibility to harm.

I do this for sites that I don't particularly care about. My wife and I have something we call our default password and it's protecting our Hulu account, our newspaper login, our Pandora login, etc...

> They will type them into any website that asks. maybe off-topic but on many linux distro the prompt to unlock your keyring does not mention what application is asking.

i had a theory a few years back that human-chosen passwords would get simpler due to mobile keyboards. Not sure if anyone has compared leaked password dumps from before and after the great mobile-migration to see if that's happened or not.

Seems like a pretty logical theory. If you ever use a password manager on desktop and then decide you need to access the same service on mobile... well typing in that 20 character string of random characters becomes a real pain in the behind.

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.


Why is it not great for the password checking to happen client-side? What is the security risk? You can do client-side hashing safely as well.

Because if it happens client-side, then I can completely bypass your site's security by opening the dev console and changing `if (enteredPassword === correctPassword)` to `if (true)`.

I presume GP is talking about the plaintext password, not the hashed one. If plaintext, then every client gets to see the password so they can use it on the second attempt. If hashed, it still leaks more information than is otherwise necessary, and opens the door to rainbow tables (if inadequately salted) etc., since the server can no longer rate-limit validation requests.

Sorry but I'm still not really following...where is the leak if it's hashed client-side? And the client will see the plaintext password regardless of whether there is processing or not.

I guess what I'm asking is this: can someone walk me through the attack scenario? I don't really get it.


Consider: Mallory wants to access Alice's account on a website.

1. Mallory enters Alice's username and a random password

2. Website sends back Alice's plaintext password to be checked client side

3. Mallory inspects network traffic and retrieves Alice's plaintext password

It's also bad if the hash is sent back; now Mallory can run all sorts of attacks on the hash itself without worrying about rate limits or any other protection the site operator could implement.


Wait why is the password being sent back by the server to the client? Is that what the commenter originally meant?

If that's the case I completely misunderstood what they meant by processing the password with JavaScript. What you've described is insane; I thought the critique was in regards to processing a password locally before sending it to the server (e.g. local hashing).


I believe so. This was the original description (emphasis mine):

> I've even seen a website where the password is sent to the browser and the password checking happens in Javascript.

i.e. the server sends the (plaintext or hashed) password to the client, and the client verifies it locally.

Edit: the original commenter replied as a sibling to you: https://news.ycombinator.com/item?id=18382949


In the case I was talking about, it was even worse. The Javascript just set a GET param that said the password is OK. You can then log in as anyone with this method.

As I recall, it did send you the plaintext password too, of course.


From the article:

> I'm referring to passwordless solutions that involves things like QR codes, pictorial representations, 3rd party mobile apps, dedicated hardware devices or "magic" links sent via email.

I'm not entirely sure the argument holds for the magic links sent via email. To me, those feel like lower friction that entering a password. Because all of a sudden, users don't have to remember their password.

For any company considering this, I'd suggest looking at how often the 'forgot my password please send me an email' feature is used. I know that, before I had a password manager, there were accounts where I simply never remembered my password. I had to use them like once every month, and it was easier to just get the password reset link.

Now consider how much easier a 'click here and be logged in' link is than a password reset system. This only really gives friction for those few people who aren't always connected to their e-mail system. On account creation, this system is even better. All a user needs to enter is their e-mail address. No more needing to enter a password (twice!). No more dealing with password requirements.

"magic" e-mail links feel like they really could be a password killer in terms of lower friction.

However, it isn't clear at all that "magic" e-mail links are more secure than passwords. I'd guess that, given enough adoption, they'd develop some issues.


There are some minor issues with the magic link workflow - one of them is security scanning software potentially visiting the link.

So then you need to open the link in the same browser you want to use. But what if you want to log in on a desktop browser and only have your email on your phone?

Maybe have the magic link show a couple letters you need to type into the browser?


> one of them is security scanning software potentially visiting the link.

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.


They are trivially solvable problems. PKCE and just displaying a QR code if you open it on the wrong device makes it pretty much foolproof.

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.


> They reuse them, they forget them, they write them down on text files on their computer.

Writing them down in a textfile on the computer might not even be that bad _if_ they, as a consequence, are not or less reused.


Does this work for the case you have your email on your phone but you want to use the site on a computer? That seems more likely to me than the case that you have your email on your computer only, but it is neat to see that case addressed.

Yeah it's a fair point. The case I mentioned is for Cuvva, which currently is mobile-only.

Webmail is always a decent backup option though, so doesn't give me too much concern in terms of people getting stuck. But may be a little less seamless, particularly if they're using a shared/public computer. That scenario throws password managers out of the window too though.


The QR-code thingy hits a friction barrier. For me needing to go to my phone is more friction than unlocking my password manager. Note that I only need to unlock my password manager once per reboot, and that for most people the password manager is already too much friction.

You'd only use the QR code thing if you were logging into an app on your phone, but had opened the email on your laptop. It wouldn't make sense in the other direction.

We've had "magic" links as the primary sign in method for our site for about a year now. It works well but we very regularly get requests to allow password login. So much so that we'll introduce that eventually.

Seems like both in combo could be a nice solution, but I'm sure we'll just start getting support requests from people whose password doesn't work because they never set one...


Interestingly, we replaced our login with magic links only over a year ago. We have roughly 1600-2000 active users, and as far as I know, we've never had anyone request a password login.

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


Did you have issues with delayed email delivery (the user wants to login but the email is delayed because of some grey listing or some network glitch)?

Did you have issues with delayed email delivery (the user wants to login but the email is delayed because of some grey listing or some network glitch)?

No, we use Postmark which delivers very fast.

We use Mailgun which delivers quite fast, but we noticed that some customers, especially the big companies with an IT department running its own email server, tend to have some form of greylisting: if it is the first time they receive an email from our system, then they refuse it temporarily, and ask our system to retry in (for example) 5 minutes. Mailgun manages this nicely, but during those 5 minutes, the user is still waiting his/her magic link.

Postmark doesn't allow marketing emails, so their reputation scores are better and hence they have better deliverability. That's their main value prop.

I know about this, and about Postmark great deliverability, but the greylisting some companies use is naive and doesn't care about reputation: if you are a new sender, you to have wait 5 minutes and retry, whoever is sending (Postmark or Mailgun).

This. I think Slack is doing this perfectly, they still use passwords but emphasize the magic link email. I find it a lot easier to just use the magic link the first time I join a new slack. Then once you are logged in you basically never need to log out and if you ever need to reset the password its just a click away.

"... friction for those few people who aren't always connected to their e-mail system."

I'm not sure the size of this population is well understood to be able to label them as "few" - it may be few for a given set of services, but may be many for a different set of services.


I don't agree with the author. Passwords are difficult to remember and easy to steal. Example I saw: old people write their card's PIN code on it because they cannot remember it. Everyone knows how to use it, you say?

I think that for an average, not computer-loving type of person, a hardware key is the best solution. You don't need to remember anything: just insert the key and press the button.

Why aren't they popular? I think because they are not a standard and are not built in. You don't get a free key when buying a laptop or a smartphone and that's the main reason why nobody is using them.

But there already are applications that don't use passwords. For example, Telegram (IM application): when you install it you only have to enter your phone number, it sends the code in SMS, the app reads the code without user's interaction, and authenticates the device. No passwords, no need to remember anything. I don't like this (it is not convenient for those who use a burner phone number for registration), but for a more typical user it is convenient and doesn't require them to remember anything.

I think we will see more passwordsless authentication in the future.


When using hardware keys remember to register at least two. In case one stops working or is lost/stolen you're locked out of your account. Backup codes help but they're another barrier one have to remember.

In my humble opinion, very few know how to use a password. Most of the people still believe that their cat name starting with a capital letter and with 1 in the end is a good password. Or that once you have a good password it is enough to use it everywhere. Same passwords everywhere is not a security, it's a vision of security. It may surprise author that main reason to provide authentication is to give some security, and in case of every single non-it person I know their passwords are just an illusion.

So, I would argue, while anyone can type in some staff, how to make it secure is rare knowledge almost no one has. So, is it, really "everyone knows how it works"? Or just everyone repeating their not quite secure passwords to make machine happy without any understanding of consequences


You could argue that few people use passwords in a properly secure manner, and you'd likely be right, but the real question is what will replace passwords?

The truth you describe doesn't mean that we should convince people to use passwords correctly, rather that passwords aren't the best security medium for humans. It's unreasonable for people to be expected to craft highly secure, brand new passwords each time they need one, and also expect it to be stored in long-term memory. That process is simply out of scope for most humans.

So then, how do we make this easier without compromising security?


All valid points. But there two other main reasons I see as why (strong) passwords are essentially a superior choice to everything:

1) Using passwords properly is an exceptionally powerful way of protecting your account/data/etc. If you use strong, unique passwords and store in a password manager (with the PW database encrypted, of course), it's virtually impossible to break into anything on the user side of things. You might be able to gain access via the server/business side depending on the hack you are pulling off, but that's on the company rather than the user. For instance, I do personally have my passwords stored in a password manager with an encrypted database. They're all unique and strong, as is the password used to access the password database. That password exists only in my mind. It's not written down anywhere or stored in some file on any computer. It's not physically printed out on paper or anything like that. It literally only exists in my head. And given its complexity and length, there is effectively nothing that will be able to break it in any reasonable amount of time. The government also can't force it from me as they could with other methods like 2FA, QR codes, fingerprints, etc. due to 1st amendment issues. Basically, short of getting me to log in from a compromised (i.e. keylogged) device (highly unlikely) or torturing me for the info, there's no way of getting it. And if you're willing to torture me for it - ok, you win then.

2) From a technical point - basically every device we would use to log into anything has either a keyboard (whether physical or on-screen) or some sort of keypad (again, physical or on-screen). This makes for universal compatibility. If people need to have special QR-code scanning/creation software installed on a device, or fingerprint-reading hardware - that creates a non-trivial barrier to the device compatible with the login process.


"If you use strong, unique passwords and store in a password manager (with the PW database encrypted, of course)"

You aren't talking about passwords the same way everyone else here, especially TFA, is talking about passwords. You might as well be talking about RSA keys at this point.


Perhaps more appropriately AES keys, as they are a shared secret (shared with the target site even if it's using a decent password hash) rather than a private key.

For #1, the master password gets entered in when you need to decrypt the password file, right?

Doesn't that mean that anyone who can read the input stream from your keyboard can decrypt all your passwords?

I mean, I use a password manager because it's the least-shitty way I can think of to not reuse passwords, but to me it's a matter of when and not if some bad guy manages to insert malware into the password manager code and get all the passwords.


Correct. That's why I mentioned the keylogger risk.

I haven't heard of any system that replaces passwords all the way. Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token). So they don't replace something that you have to remember (password).

Passwords are easy to change and while they can be copied, that would be the result of the user or the login software doing something stupid. Not something wrong with concept of the password login itself.

IMO those systems can be used to make the login more secure but replacing password all together not so much.


> Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token).

Actually... When you log on with a password today, an Identity Provider like Google or Microsoft typically issues you a "ticket granting ticket" (TGT) which you can use to get more tickets. The TGT is stored in a cookie on the web or in the OS. This TGT is something that be can copied. So, today, when you log on, you provide your password to get something that can be copied that you then use to log on to various services. Point being, something that can be copied is in the flow anyway, so switching from password to something that can be copied and revoked is only an improvement.


"copied" in my case is something negative. I meant that as this information is stored unencrypted somewhere and can be just copied and used by an attacker to authenticate as an specific user.

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.


Why I like passwords (and various key locked/unlocked with passwords? Simply because I can change them, I control them.

Biometrics is unsafe by design because our body can change outside our control and our body is public enough and unchangeable enough to be a REALLY unsafe authentication system for anything but human being interacting together.

External other-factor auths like OTP, side verification, port-knocking, ... are good, but they still need a password somewhere in the chain.

So no, it's not only a matter of reactionary users not willing to change but also a matter of rational safety reasoning.


When current bio-related credentials are stolen, they're not stealing your hand or your iris or your face.

They're stealing destructive hashes of those things.

It'd be like having someone sketch a stick figure version of you, and then you claim your identity was stolen.

No, it wasn't. Stick figure drawings only work in stick figure readers.


Take a look at some "sophisticated" retinal scan, they are in the end cameras, a special kind one. Fingerprint readers? Another kind of scanner. It doesn't matter that today's only few simpler model can be cracked with a single strip of scotch, it's only a matter of time.

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.


I signed up for something recently and on the password screen it popped up with something along the lines of "Hey, can we generate a secure password for you, don't worry, your browser will remember it for you?" I said yes, sure enough a strong password appeared and Chrome offered to remember it. Seemed like a nice introduction to using secure passwords. The next thing I signed up for I manually generated a secure password and pasted it in and that is now stored in my browser too.

And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?

As long as they use the same browser on each of those platforms, they're good.

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.


Exporting the passwords is also possible, so it's not really much lock-in. Not to the kind of person who'd care, and want to switch browsers.

You got it backwards. Vendor lock-in rarely applies to experts. It is the people who "don't care" that _we_ should care about protecting from lock-in. After all, that is how we got internet explorer 6.

Those, in my experience, are the same people who can't switch browsers. They aren't capable of learning new things, and can often barely keep going with what they have.

Not in my experience. They are the people who just don't care. What they have works well enough, so they don't look to change it.

Good point—anyone using Chrome is good. I was thinking of people who are using Safari or Edge, which aren't available on other platforms.

Assuming your browser syncs passwords, etc.

I know a ton of people who use Chrome on non-mobile and Safari on mobile.


I think most browsers can import most information from most other browsers at this point.

Or use more than one device to login?

All major browsers can sync their passwords across their desktop and mobile versions. I use Firefox Sync on two laptops, one desktop and an Android phone.

I was unaware that Firefox / Chrome can own all your passwords in their cloud.

Not sure about Chrome, but Firefox encrypts everything on the client before syncing, they only see blobs of bytes. Plus you can run your own Sync server.

Ancient reply, but...

Even if Firefox "encrypts" before syncing, they must decrypt in order to provide the clear text password from another browser, no? They don't send "blobs of bytes" to password form entries.


Most browsers still don't have a second line of defense (like password managers do), correct? So, if a user has access to my browser for two mins, they can see all my passwords in plain text. They can't if my passwords are in password managers which will ask for my master password. I never understood why browsers didn't give an option to have a bit more security with those passwords. Just let the user enter one master password before they can see their stored passwords.

Do you remember the URL of this website?

A little boring and reactionary, I think. Unguessable capabilities (long unchoosable URLs mostly) have been used to replace passwords. Plenty of systems refuse to let users choose passwords, and many common password problems are totally mitigated by this design.

An URL with a randomized path in it is, technically, a password.

Also note that the transportation mechanism is pretty weak. If the URL is passed over HTTPS, then that keeps your ISP from seeing it, however it can still show up in logs on the server side or the client side, in your history. A URL will be remembered or even cached by your browser, whereas a regular password won't, unless you explicitly allow it.

A regular authentication mechanism doesn't necessarily suffer from these weaknesses. Consider that you can derive the server-side password, like a client-side hash which may even be time dependent, such that the actual password is never sent to the server. You can implement systems in which the password you know is never sent over the wire.

Basically a randomized URL is semi-public and you need to treat it as such.

There aren’t many alternatives to classic authentication mechanisms around. The only one I can think of is having authentication links emailed to you, but that’s also less secure and it simply defers the problem to a third-party.


If those password-URLs are one time use then they are better than a static password. Still, it's likely those are managed via email which makes that a single point of failure.

That depends on what you want to do. Do you want to authenticate the system of the user or the user him/herself?

If its the latter, then how do you protect the link from other uses of this system? Encryption? And how are you encrypting something? Password? If you do it via a keyfile then how do you protect the keyfile? If you do it via a hardware token, how do you prevent other people from stealing and using it?


Not the 'my password is on a post-it attached to my monitor' issue though.

I always liked the idea of having a password entry system where a single observation doesn’t provide enough information to reveal the password [0].

However in addition to creating issues with the secure storage of the password... I don’t think people would be able to use it reliably.

Still, some banks still seem to use the “enter the Nth letter of your password” scheme” which seems almostly equally unworkable...

[0] https://41j.com/blog/2011/10/unobservable-pin-and-password-e...


The Nth letter of password thing sounds sketchy to me. Mostly because it sounds like they have my password in plaintext if they can check that.

No they just store a checksum for every letter of your password.

/s


I'd hope they at least apply ROT13.

Yes, it almost certainly is quite sketchy... I can’t think of any way it could be securely implemented. In the case I’ve seen it’s the only password used...

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


I could believe this would be possible with homomorphic encryption, even with today's capabilities, but I can't prove that; I'm not terribly familiar.

That is not to say that it's very likely, because it's not.


It's usually in addition to a password.

They may have it in 2-way encryption in a HSM. That's not what will ever be recommended in a beginner guide to handling passwords for your SaaS, but it's a reasonable approach for a bank.

> Despite their respective merits, every one of these solutions has a massive shortcoming that severely limits their viability and it's something they simply can't compete with:

> Despite it's many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone.

This is (mostly) true, however, there is already evidence that new technology could kill the password indeed. What I am talking about is modern phones which all come with a fingerprint scan or facial recognition which, from my own limited experience and my own observations, has mostly killed of the "passcode" on the phone. Yes our phones still make us pick a passcode, but unless forced to use it nobody does anymore. Even my technology incompetent mother uses the fingerprint scan to log into her phone and I don't see why something similar couldn't replace the current experience of her having to type an insecure password into her hotmail all the time.


<insert standard argument against biometrics>

Biometrics is essentially putting a massively complex system in front of your password input, that lets the device read the password off your body, but the consequences are a) you now can't ever change your password, and b) there's this massively complex system in front of (now hidden) password form, and complexity means unreliability and exploitable holes.

The reason it seems to be working in phones and in laptops is just because the protected systems - personal computing devices of random members of general population - are of low importance, so it's unlikely an attacker is going to bother, whereas the convenience benefits are substantial.


It’s also not the complexity that’s the problem.

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.


That new HP laptop commercial featuring the fingerprint reader makes me facepalm every time. They advertise it as "reinventing passwords" WHILE ILLUSTRATING EXACTLY HOW INSECURE IT IS.

https://www.youtube.com/watch?v=KTn0r0HPXVg


That's too good to be true :-))

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

Kids, or partners. There even was this funny video making rounds around the Internet couple years back[0].

The point about coercion is good too.

--

[0] - https://www.youtube.com/watch?v=fawPebE75xA


My banking app uses the Iphone fingerprint sensor to fill in your password. From time to time the fingerprint fails a couple of times because my fingers are greasy or whatever and you can manually enter your password.

I fail in operating my Samsung phone's fingerprint scanner roughly once in 20 attemts, but sometimes those failed attempts are in a row and I end up having to type in the password. Since biometrics still require you to know the password as backup, they're not going to replace it.

Fingerprint scan and Facial recognition can not replace password authentication because both face and fingerprint are public information, while password is meant to be private. You cannot hide your face or fingerprint from others.

As a rule of thumb (pun not intended), biometric data is a username, not a password.

Disagree. It is not a password for sure, but not even a username. biometrics are an indentifier.

username/password split an unique/secure identifier in a unique part and a (supposedly) secure part. biometrics are that pair together.


Biometrics are really more equivalent to a user name than they are a password.

Sure, they get used in some applications as a "password" because it's "cool" but it's fair to say biometrics is public information so while many biometric services do their best to avoid being spoofed, they're really more akin to a user name.

I'd also like to point out that fingerprint scanners don't work if you need to use then when you've just gotten out of the bath / been swimming. If something is going to replace passwords then I'd want to be damn sure I can use it 100% of the time I need to (baring when I personally fuck up - eg forgetting my password).


that is how it would be used in high/er security environments but not how it is used in the consumer arena.

I've always been of the opinion that biometrics are much more closely related to a username rather than a password. There will always be ways to either fake or compel biometric scans, and having a second layer of proof required to authenticate and authorize seems like the only responsible thing to do.

WebAuthn is coming. In fact, it's actually already here. There are only two things it needs before it can start to take over the world: a cross-browser, cross-platform implementation with synced credentials, and server-side implementations from a few large companies like Google and Facebook.

A cross-browser, cross-platform implementation with synced credentials will solve the one remaining usability issue WebAuthn has; the need for users to register every device with the site they want to sign up on. It's not acceptable for users to sign up on their PCs and then have to jump through a bunch of hoops to sign in on their phones; and bootstrapping with passwords eliminates many of the benefits of Web Authn.

Implementations from major companies will solve the chicken-egg problem that Troy mentions. Once the system is commonplace, smaller sites will be less hesitant to jump on board with an authentication solution that's different from the password-based one that users are used to.


And that too, won't be a password killer.

Heck almost 20 years ago Nortel had something better than what you described, and still we have passwords around.

Everything old is new again, today we are solving passwords with X, tomorrow with Y, etc.


Webauthn is a web standard; not a proprietary product by a company I've never heard of.

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


Doesn't WebAuthn require hardware?

I can't find any user examples that don't mention a phone or yubikey or whatever.


No, it doesn't. It's the most advertised scenario, but a software application could act as an Authenticator too. The spec explicitly mentions platform authenticators that just require a PIN as a possibility.

The only password killer is a password manager. And guess what, is password protected.

I don't know what password manager you use, but I use TouchID to access mine. Yes it still has a password, which I can type if I need to, but it's a device-local password (or PIN in the case of my phone).

I feel like every argument against password managers, uses the worst possible implementation as their basis for how they work.


Keepass can use a key file too.

I use unix pass with GPG, I know what you mean. And how the key is protected? By a password. You can stretch the chain, but at the end the point is the same.

Turning "something you know" into "something you have"... or anyone else can have too.

It's turning "something you know" into "something you know and something you have".

For most people it's completely redundant because the passwords database is also "something you have". But it leads to some nice possibilities.


or worse (and more likely), it's something you can lose

If done right, passwords are a very powerful and universal auth method, i.e. all credentials can be remembered and no third party or auth device are needed (e.g. you are still able to login even when you lost all your belongings while traveling). However, there are problems when reusing passwords and passwords are usually leaked to the remote party when authenticating, e.g. its trivial for a web service to learn what password or password pattern you are using. I am working on an open source project called FejoaAuth where we are working on a secure authentication solution that does not leak the password during login. This allows to reuse a password, e.g. to use a password for authentication and for data encryption. This makes true one password solutions possible. Its an open source project so please get in contact :) https://fejoa.org/fejoapage/auth.html

> Netflix requiring... 4. But I'm hesitant to berate Netflix for what seems like an extremely low number because they're also dealing with the usability challenge that is people logging on to TVs with remote controls

Amazon handled this great when I set up Prime Video streaming on my Sony Blu-Ray player. I don't remember the exact sequence because it was 8 years ago, but it was something like this:

1. Go to Amazon on my computer, log in, and tell them I'm trying to set up a new device for Prime Video streaming. They ask me for the make and model and serial number, which was available on the device in the Prime Video app.

2. Amazon gives me an integer. I don't remember the length, but I'm pretty sure it was in the 4-6 digit range.

3. On the Blu-Ray player, give that integer to the Amazon Prime Video app, and it completes the setup.


One thing I like about passwords is they live in my head. No one can force to me give it up easily. But with a fingerprint or retina scan, anyone can push me up to a sensor and force me to supply the bodypart(s) needed to authenticate.

If nobody understands anything other than passwords, how has 2FA taken off at all? How have password managers taken off at all?

What if the password manager were in charge of logging you in _directly_, through some new protocol between browsers and PW managers? How could that _possibly_ be more friction? It would be strictly less. Hell, it could be done without even informing the user that this new feature was being rolled out, and they sure as hell wouldn't complain about inconvenience because of a step removed from the login process.

Asking people to deal with more and more and longer and longer passwords is a usability nightmare. It's a absurdity.


I wouldn’t say 2FA or password managers have “taken off”. I don’t have numbers, but just from my small sample of friends/family, only people who are technically advanced or who I have forced (my wife ;) use password managers.

Well hey, it's a start. They've got more adoption than Troy claims any of the niche experimental password replacers do.

Where does 2fa replace passwords? It's two FA after all.

And I'd assert that password managers haven't exactly taken off; I'd be curious about their numbers, but the dozen or so people I know who use one are all software engineers. Also, they don't really replace passwords - they're based on them!


2fa doesn't replace passwords but it is added friction that people willingly take on for added security.

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.


Only people on this site have willingly enabled 2fa (to a decent first order estimate). The remainder are forced to by tenant administrators or the occasional application owner who understands they gate important data (eg NuGet requires 2fa for some package owners).

"2fa" as traditionally thought of is a bit of a detour though - what's more important is strong authentication, with passwords being worst and a UAF key being best for now. Authenticator apps satisfy 2FA with a single authentication, but that freaks out plenty of smart people (phone PIN lock + device bound cert = something you know/are + you have) - purely due to years of training that 2FA means 2 authentication.


The claim wasn't that nobody understands anything other than passwords, it was that everyone understands passwords.

The claim was that nothing else will take off. 2FA and password maangers at least are used out there beyond a niche thing nobody ever heard of (which is how he described the viability of other schemes he didn't bother naming)

The claim was that nothing else will take off to the point of becoming a password killer.

2FA doesn't try to replace passwords.


For one 2FA is (often) an addition to password and almost always it is required only at registration time (e.g. email confirmation)

> Asking people to deal with more and more and longer and longer passwords is a usability nightmare. It's a absurdity.

I fully agree with you, but an anecdote.

I find long password to be easy to remember if they are just long lower case strings instead of having wierd symbol-number combinations.


> What if the password manager were in charge of logging you in _directly_, through some new protocol between browsers and PW managers?

FYI, this is exactly what WebAuthn is. The standard was just finalized in August. All we need now is some implementations.


What is wrong with magic links exactly?

Email already is the single point of failure, password resets. People are already used to looking at their email, account verification etc. People are already used to looking at their email after signing in, 2nd factor with email exists on some sites.

Downsides are that they might be scanned by security software and visited, but surely that's also a problem for verification links? I can't imagine that people would appreciate accounts being automatically verified...

All other reasons I can think of indicate a problem with password resets as well, which also gives access to the account anyway.


On a properly implemented magic link system, automatic visiting wouldn't be an issue at all. Should only work within the same originating session, and ideally should use PKCE too.

I just wish there were a more universal acceptance of entropy. I.e.:

Use at least one upper case letter and symbol

OR

Use a password that is at least 20 characters long

Passwords are fine, it's the differing standards that are nutty. Especially when you don't know them until after trying.


You can satisfy most entropy requirements without even trying by using a password manager's "create random password" feature. I feel the more important thing to attack is making password management more approachable to laypeople.

To your point though: the most bothersome constraint put on passwords by applications and web sites are limits such as restricting certain special characters (To what end? You're going to hash it anyway, so why limit my special characters? You are going to hash it, right?) and limiting password length to something surprisingly short like 16 characters.


Password manager? That's what I'm trying to eliminate because they are inconvenient.

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


my _bank_ requires passwords to be exactly 8 characters and is case insensitive. when I first realized I literally couldn't believe it, it's infuriating

Sounds like it might be time to switch banks....

I know, but it's one of those things that are much easier said than done sadly

Passwords, if used correctly, are extremely secure. However 99% of my accounts are just not important enough to warrant that level of security. I don't worry about someone cutting off my finger in order to steal my Reddit account. My Github account doesn't have any projects that aren't forked elsewhere. Temporarily losing access to Steam for a day or two would not be the end of the world.

I have two-factor authentication for email, cloud storage, and banking. For everything else just give me convenience over security, please.


Closest to a password killer I've used so far is the built-in iCloud Keychain. My iPhone and MacBook both have access to the same passwords and most of the are randomly generated.

Ever watch security footage that overlooks people using iPhones? It's amazing how many sites display the plain-text password on the screen briefly even when using Keychain.

Additionally, iOS now integrates third-party password managers, so you get the same convenience with e.g. 1Password.

Related, looks interesting, generated QR on login pages.

A big thread:

https://news.ycombinator.com/item?id=14459537


> The point of all this is that usability is an absolutely essential attribute of the auth discussion. What I often find when I have these discussions is a myopic focus on technical merits.

This problem is ubiquitous to all of tech, pretty much. It's particularly iconic to FOSS grognards like Richard Stallman. Software that respects people's rights is fantastic, and we need more of it, but if you're not making that software usable then you're wasting your time.


I think that a lot of the problems that are inherent to passwords might be mitigated by not allowing the user to choose a password. A strong, randomly generated password being given to the user and changed periodically would almost force the user to use some sort of password manager.

If this were adopted industry-wide (a big ask, I know) then users would be able to use the familiar "enter username and password" system while being protected from common mistakes/misjudgments.


'Ugh, this site forces me to remember this shitty password, Guess I'll go to the competitor'

This kind of friction is exactly what troy is talking about.


As opposed to "Oh, they want a password? I guess I'll use the same one I use for every other website."

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.


Your hotel example is pretty absurd, because there's no friction involved in carrying around a hotel room key.

There is significant friction involved in memorizing a long password. So no, it's not "how most of the world already works".


I will admit that it's not quite equivalent, but there was a learning curve that happened when hotels switched from metallic keys to magnetic keycards. I don't think that it's absurd.

I guess a more direct example would be an employer trusting you with the combination of a safe. You would need to remember the combination which presumably would be changed periodically.

The point I think I'm trying to make is that it's rare for a business to leave the responsibility on the consumer to secure the property of that business whether it's access to a server, a hotel room, or a safe.


If it's a company safe? Well of course that's the employer's decision.

A better example would be a safe deposit box or storage unit with a combination. Where you are accessing your account so to speak. There you can pick the combination yourself in most cases.


Password re-use is bad, true.

But it is frictionless for the user. The entire point of the article is that trading friction for security isn't going to happen in most businesses.


> A strong, randomly generated password being given to the user and changed periodically would almost force the user to use some sort of password manager.

or it would force them to click "reset my password" every time they use your service. now your service is only as secure as their email account.


> now your service is only as secure as their email account.

Surely that was already true?


This would be a valid concern, so I suppose that it would take an industry-wide push (which I know is unlikely) to educate users about password managers, but I would argue that if we want to improve upon the password based authentication then it would be easier to educate users if we are using a familiar interface with just one single change.

In that case the user would use their e-mail as password manager.

Which might be an improvement or might not.


At that point why not just switch to PKI?

pki is a barrier to entry for most. the user would have to set their browser up to present a unique key pair for each site they use. I think mutual auth is better suited to automated administrative tasks.

but isn't a password manager just as much of a barrier in this context?

I don't believe so, I remember learning about Public Key Infrastructure a while ago. It's one of those things (kind of like git) where there is a steep learning curve up front, but once you understand it seems simple.

A password manager on the other hand is just a place to store credentials. Credentials is a concept that most people understand. A password manager in this context could be as simple as a text file on your desktop (not a great idea), or the one included with your browser (a little better, but make sure you set a master password), but if you want more features there are more sophisticated options available.


Ok lets compare these approaches rationally, especially from a user perspective. If you let the service provider choose/generate the password it might as well generate your keys for you, there really isn't much of a difference. From a credential management perspective there really isn't a difference either between a long non-human readable password and a long non-human readable private key. They basically suffer from the same problem, neither can be used without access to the credential manager. The only "advantage" passwords in that scenario have is that you don't need to sign anything you can just send it to the relying party however when you rely on password managers to input your credentials anyway that manager can manage signing as well right. I'm not advocating to use PKI instead of passwords just that forcing the use of password managers through very complicated long forced passwords has in my opinion not much of an advantage over PKI when both are equally opaque for casual users.

I understand what you are saying, but the fundamental difference here is that for PKI, the browser has to be configured properly as your key pair must exist and the correct public certificate must be used in TLS negotiation. The advantage here is that the password can be copy and pasted into a password form after TLS has been negotiated.

Coupling authentication with encryption has its place, but I would think that it would work better when accessing a service through an app rather than a browser since the app publisher can create unique a key pair and sign the certificate with their own CA and use that for authentication, but in the context of a web app accessed through the browser copy-and-paste beats having to configure your client certificate per domain at least from a "user friction" point of view.


This is an interesting argument, given that my phone over the past few years has moved from passcodes to Touch ID to Face ID. Most apps and sites on my phone that want to prompt me for a password are intercepted by the OS, which generates a one-time code and authenticates me via the same Touch/Face ID. The number of passwords I actually key in has been dropping steadily to near zero.

Here's the "password" killer: generating random passwords on the server and never letting users input their own passwords.

All issues with reused passwords, password strength, hashing passwords with slow hashes, etc. instantly solved.

Also improves conversion rate since there's no risk the user gives up signing up because he can't be bothered to think about or generate a password.


> Also improves conversion rate since there's no risk the user gives up signing up because he can't be bothered to think about or generate a password.

Sure, but there's considerable risk of the user giving up signing up because they can't be bothered with memorizing a random password and want to set their own like every other service allows them.


Except that people won't be able to remember them, so expect massive churn when it's time for them to enter the password the very first time.

Just set a never-expiring authentication cookie in the browser, so they never need to enter the password in typical one-device use.

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


If you're doing that, you might as well do the "magic email" link as medium does now (and as mozilla's now-defunct 'persona' did [0]). In that case, you don't have any passwords at all, merely long-lived tokens which the user mints by using a unique one-time nonce in an email link. To login on a new device, they get an email and click a link, and that's it. No passwords ever.

[0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Per...


> show password

You should not be able to do that if you're doing security properly. If you can show the password it means you're not hashing it properly and instead storing it as plaintext


1. You can store it on the client side in a cookie.

2. You can encrypt the passwords with a key outside of the database instead of hashing them. That means that people can now login with a read-only compromise of both your app and the database, but chances are that such a compromise would be a full compromise anyway.

3. You can also not show them the current password, but instead generate another one and have them both be valid (until explicitly revoked)


I agree, but how do you trigger the "save password" dialog of the browser built-in password manager, when using a generated random password?

Edit: Answering to myself, maybe by generating the random password client-side, with JavaScript, and making the HTML input field non-editable. I've not tested it.


Or by using WebAuthn, which has an explicit API you can call to store a password in the browser.

Also there is a lot you can do with pronounceable passwords or easy to memorize ones. Hard to remember password and high entropy password can be very different.

At ClearCoin, we use a stored private key in the user's browser extension to sign every authenticated request. The signature is verified on the server, checking that it matches the Ethereum wallet address listed in the payload.
More

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

Search: