Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

221–230 of 277 posts

Re: Why [Insert Thing Here] Is Not a Password Killer

#221

Earlier quoted context omitted.

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#222
post #135
post #116

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…

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?

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#223

I can't help but think that browser vendors could have at least made an effort to make client certs and Kerberos authentication more user-friendly on the web. Perhaps not so useful for private consumers, but it would sure come in handy in enterprise.

Is there a good place to go for the current state of client certificates?

I've heard that there was an issue where other websites could see the certificate, so there were privacy problems with having them installed.

It seems like something that would have been fixed, but it's hard to search for. Server certificates are so much more common. They end up taking over all the search results.

Re: Why [Insert Thing Here] Is Not a Password Killer

#224
post #196

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,…

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#225
post #7

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 o…

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

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

Re: Why [Insert Thing Here] Is Not a Password Killer

#226

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 lin…

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#227

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

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#228
post #42

Earlier quoted context omitted.

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…

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#229

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

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…

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

Re: Why [Insert Thing Here] Is Not a Password Killer

#230

Earlier quoted context omitted.

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 suppor…

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.
Post reply on HN