Why [Insert Thing Here] Is Not a Password Killer • Hacker News Board

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

#251

Post by lifeisstillgood » Mon, Nov 05, 2018, 11:26 PM UTC

Wowfunhappy wrote: post #91

lifeisstillgood wrote: post #65

Ancient Egyptians probably made the same argument "Keys just won't work - everyone knows how to use a door knob, but these new dangled keys, no one carries them, we have not invented key rings yet so people will fumble. Best not to." No people dealt with keys and locks because they did not want their stuff stolen. As more and more valuable stuff is kept behind our passwords we will accept more and more cost to protec…

Keys aren't actually secure at all. Anyone with a lock-pick and a bit of practice can break in. I'd say that's actually about equivalent to a poor password—it's not that secure, but random person off the street won't be able to break in with a snap of the finger. Yes, with a password on the internet, there are far more possible attackers because you can attempt to break in from anywhere in the world. But that's somew…

It's kind of not the point - there are levels of security we accept because they match the cost / benefit ratio - at least the perceived cost benefit ratio.

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

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

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

He is not happy with passwords.

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

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

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

#252

Post by aeternus » Tue, Nov 06, 2018, 12:24 AM UTC

BitterSweets wrote: post #81

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.

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

#253

Post by acdha » Tue, Nov 06, 2018, 12:54 AM UTC

hyperpape wrote: post #240

acdha wrote: post #230

Earlier quoted context omitted.

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…

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.

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

#254

Post by kijin » Tue, Nov 06, 2018, 1:43 AM UTC

npongratz wrote: post #243

jniedrauer wrote: post #235

Earlier quoted context omitted.

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

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

#255

Post by hyperpape » Tue, Nov 06, 2018, 2:15 AM UTC

acdha wrote: post #253

hyperpape wrote: post #240

Earlier quoted context omitted.

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…

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.

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

#256

Post by ukulele » Tue, Nov 06, 2018, 2:29 AM UTC

ngrilly wrote: post #220

ukulele wrote: post #219

Earlier quoted context omitted.

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

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

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

#257

Post by czei002 » Tue, Nov 06, 2018, 4:42 AM UTC

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

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

#258

Post by ryan-c » Tue, Nov 06, 2018, 7:23 AM UTC

jermaustin1 wrote: post #212

ryan-c wrote: post #133

Earlier quoted context omitted.

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

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.

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

#259

Post by ryan-c » Tue, Nov 06, 2018, 7:25 AM UTC

onepostoneacct wrote: post #194

ryan-c wrote: post #132

Earlier quoted context omitted.

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

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

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

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

#260

Post by ngrilly » Tue, Nov 06, 2018, 7:55 AM UTC

ukulele wrote: post #256

ngrilly wrote: post #220

Earlier quoted context omitted.

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

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