Has anybody made a list of [Insert Thing Here]s? I'm curious what kind of trade-offs they offer.
Why [Insert Thing Here] Is Not a Password Killer
181–190 of 277 posts
Re: Why [Insert Thing Here] Is Not a Password Killer
#182Earlier quoted context omitted.
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#183Earlier quoted context omitted.
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.…
> 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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#184It 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 b…
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#185Earlier quoted context omitted.
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#186Earlier quoted context omitted.
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 co…
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#187Earlier quoted context omitted.
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 co…
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…
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#188From 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…
"... 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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#189Earlier quoted context omitted.
Writing down passwords is usually less bad than password reuse and use of weak passwords.
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).
Re: Why [Insert Thing Here] Is Not a Password Killer
#190Earlier quoted context omitted.
> 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 qual…
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.
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.