
Patronizing Passwords - sethbannon
http://joelcalifa.com/blog/patronizing-passwords/
======
bradleyjg
"The point here is that it’s my decision. Perhaps, to me, the convenience of a
single email/password combination is worth the risk of my accounts being
cracked in bulk.

As a user, I have the right to weigh my own pros and cons."

If you bore the full cost of your account being hacked, that might be true.
But in practice that's not the case. There are laws and contracts that protect
you from the full costs of your being hacked and shifts some of those costs to
the proprietor of the website. Even leaving aside those direct financial
risks, the proprietor of the website bears customer support costs if your
account gets hacked, and quite possibly PR risk too.

I like the Password Security Guide idea though.

------
astazangasta
I have the perfect solution to this, but software systems aren't with me yet.
The answer is: a keychain. Not a digital keychain, an actual one. On this I
put my "infinity key" \- it's a little USB flash drive with a LUKS-encrypted
file system on it that holds a private key. Lots of tech people have something
like this. It's great for SSH - I can add my infinity key to any host and be
assured that I will always be able to login securely from any machine I want.
We're all used to the physical metaphor of keys as security, and needing a
physical key to get into things. This is not a huge change for us.

This could easily become the norm, and should. It requires only one key for
all of us, it is perfectly secure, doesn't require storing secrets on the
remote end, never needs to be changed, can't be forgotten because it doesn't
need to be memorized (there is one password for the LUKS encryption). There is
no penalty for using the same key in thousands of places.

The problem is, no website or browser supports this kind of authentication,
and most people are not savvy enough to build this sort of thing for
themselves. These are both problems that should be solved; we desperately need
to move the Internet away from passwords, password resets, and so on.

~~~
jclulow
You can't really "add" your key to a computer you don't trust, though. At
best, it could destroy your USB device; at worst it could copy the contents
out once you decrypt them.

This may be better than using one password for everything, but it's certainly
not a panacea.

~~~
anon4
Maybe the only answer is to air-gap the two devices and have the user input a
secret code shown on the dongle. So you press the button, type the code on the
website and log in that way.

Edit: Or maybe have two devices: one dumb flash storage and a device that
actually computes your key. You press the "compute my key" button while the
storage is connected to the keychain, then disconnect it from the keychain and
connect it to the pc. Next time you connect it to the keychain, it's wiped
before use and never ever read.

~~~
privacy101
The device could instead have a display that displays a password, QR code,
one-time-key, etc... and then you would scan it using a webcam or your phone
(or type it manually).

~~~
Skunkleton
Maybe like a phone running a TOTP application?

~~~
privacy101
I would have more trust in a separate device that has no networking
capabilities.

~~~
dazmax
What if it's in a "secure element" whose hardware and firmware make it
provably incapable of divulging the private key?

~~~
privacy101
I don't think that's possible... it reminds me of Apple saying that they can't
decrypt your phone, but it is decrypted when you use it and many apps have
permissions to transfer basically everything over the network (and Apple has
root too).

------
digitalsushi
I switched jobs last month and decided to audit all my personal stuff while
the old place was auditing all the work accounts I left behind. We'd been
using google/gmail 2 factor authentication.

There's a few layers to it, most everyone has seen. Ok, 1st factor is your
password, so you log in with your password.

2nd factor can vary - a list of codes you print and keep in your wallet, or
they can send a txt message to your phone. Or you can get an authenticator
app, which you configure with some magical seed value, and then you have
what's effectively a software RSA token device on your phone.

Even easier? I just found out about these FIDO usb hardware keys. 9 bucks,
wait for it in the mail... go to your gmail account settings, click the link,
put the hardware key in, press the button... and that's it, from then on you
can plug that key into a web browser (chrome, actually) and it will pass the
second factor. Anyways, it's been out for a while, but I just found out about
it, and it's so easy to do I wanted to jot a note down here.

~~~
mrec
What's the procedure if you break or lose the FIDO hardware key? (Not a
rhetorical question; I'd never heard of them before either.)

This is the sort of the thing I always worry about when discussing or
considering strengthening security. At some point the risk of accidentally
locking yourself out outweighs the risk of someone else getting in.
Particularly so for something like gmail, where there's no customer service as
a last resort.

~~~
granos
I'm not 100% certain, but when I setup 2FA for many services they give you ~10
single use emergency codes that you can use to get into the system in the
event that your second factor is unavailable for whatever reason (phone
stolen, you are out of the country, fido broke, etc.)

------
rkayg
I work at Okta([https://www.okta.com/](https://www.okta.com/)), a SSO product
among other things, and we deal with this all the time. We use a variety of
techniques to help secure the user's identity and access to various
applications.

1\. Use the SAML protocol to log in to apps as opposed to passwords. (See
[https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language)
for more)

2\. Use MFA as much as possible. Our product works with a variety of MFA
options, including hard tokens, such as Yubikey, and more software based ones,
like our own MFA app that pushes a notificication for MFA.

3\. Generate random passwords for other applications that can be rotated
frequently and easily.

There's a lot more we do underneath the covers and other ways of improving
passwords and logins, such as adaptive MFA (prompt MFA if the login passes
some threshold of suspiciousness)and no password login (simply use the
multifactor token as the primary factor)

------
morgante
I hate the recommendation of 2FA as the solution. I find 2FA more patronizing
than anything else.

I use a password manager (1Password) and have a unique, secure password
generated for every site. If someone gets access to my passwords, that means
they've compromised my 1Password keychain which is game over anyways. I'm not
interested in any protection mechanisms for such an unlikely scenario. So I
end up storing the 2FA keys inside of 1Password as well—bringing it back down
to 1 factor, but adding annoyance and hassle.

Don't make assumptions about how your users secure themselves.

~~~
drumdance
My biggest question with this is, what if I ever have to login using a
computer or tablet that is not mine? How does 1Password deal with that case?

~~~
morgante
1\. I have my keychain on my iPhone, so I can always look up the password
there.

2\. 1Password lets you publish an encrypted HTML viewer which you can share
via Dropbox, so I can retrieve passwords online if need be (just need to
remember my Dropbox and 1Password passwords).

------
Someone1234
I completely agree with the article. From what we can tell password strength
meters mostly work, or at least work "well enough." Some users attempt to game
the system and in doing so wind up with marginally more secure passwords.

We also found 2F easier to implement than even we expected. Google
Authenticator uses something called "Time-based One-time Password Algorithm"
or TOTP for short. Even ignoring all the open source code and libraries, it
actually isn't really at all complicated to do yourself. The hardest part is
generating the QR codes for Google Authenticator (which, yes, we did utilise a
library for). Even the storage requirements are low.

Our current passwords rules are:

\- Minimum 6 characters

\- Maximum 256 characters (for DDoS protection reasons, long passwords cause a
high CPU load on our micro-instances)

\- We technically allow a "weak" password but bring up a pop-up (strongly
discourage it).

\- We do have password expiration (90 days) and history (3x) due to
unavoidable organisational requirements

But overall we're pretty liberal. You can use sentence based passwords and
typically they're marked as "secure" in the traffic light score system.

> Forget about the now famous XKCD strip that proves a long lowercase password
> is more secure than a short dollar-sign-riddled password.

Technically what it proves is that you can replace one character in a complex
password with one word in a sentence based password and get similar (or
better) levels of security, even if the attacker knows you utilise sentence
based passwords.

For example, a En-US keyboard has approx. 100 characters on it. A child's
dictionary has about 10,000 words in it. But in reality less than 1/2 of those
keys are ever typed, and less than 1/16 of those words regularly used (plus
you have predictable words like "The" "A" "I" "And" etc which have less
security value).

So a good rule of thumb is: If you move from random character passwords to
sentence based passwords, keep the letters in the former the same as the words
in the latter (e.g. 6x characters = 6x words, 8x characters = 8x words, etc).

This gives you the best chance of remaining either as secure or MORE secure
while moving to lower case sentence based passwords.

~~~
vectorjohn
Just curious, but long passwords shouldn't in any way affect CPU load. After
the first hash (of thousands?), it's just hashing a hash, which is always the
same length unrelated to the original password length.

Even though I can't think of a legitimate use for > 256 character passwords.

~~~
phlo
> After the first hash, it's just hashing a hash

The recommended password hashing functions (PBKDF2, bcrypt, scrypt) actually
use the provided password in each iterated round of the algorithm. The DoS
vector Someon1234 mentioned is real and has previously affected Django[0]
(and, I believe, others). In order to prevent it, you should either limit the
maximum password length (256 characters seems sensible, as does Django's
choice of 4096) or hash the password (to a known length) before passing it to
the KDF.

[0] [http://arstechnica.com/security/2013/09/long-passwords-
are-g...](http://arstechnica.com/security/2013/09/long-passwords-are-good-but-
too-much-length-can-be-bad-for-security/)

------
felipesabino
I really like the idea behind passwordless [1], where users never use a
password but just confirm they are who they say they are.

I always remember Tom Scott saying "Don't store passwords yourself if you can
all avoid it" [2] and how you should leverage google, facebook and other 3rd
party authentication methods as a way to add a layer of security and remove
one way to compromise your user data.

[1] [https://passwordless.net/about](https://passwordless.net/about)

[2]
[https://www.youtube.com/watch?v=8ZtInClXe1Q](https://www.youtube.com/watch?v=8ZtInClXe1Q)

~~~
jand
A disadvantage is the media break while using passwordless.

Some folks i met strongly believe that using a different medium while
interacting with a site distracts new users, by this lowering the sign-up
rate. I have no data on that but it sounded at least plausible.

If you believe in this, it would depend on your target group how you should
handle passwords (or the lack of).

~~~
felipesabino
I think your argument would also valid for 2FA approach, which is is widely
encouraged regardless. Sign-up rate would drop drastically for a majority of
common users if a good UX is not into play while developing the system
workflow.

But I want also say that for a great variety of solutions having 2FA or
passwordless as default is valid, Slack for example has an option of demanding
2FA for all team members, which a lot of people would agree is a good thing.

The "Password Security Guide" section at the article is a good example of
educating people how insecure storing password, and you could do the same
thing showing/enabling passwordless as a clear and easy alternative to migrate
to.

~~~
cvburgess
But most sites let you "trust this device" once you've done 2FA - passwordless
doesn't have that option from what I can tell. Also, 2FA is an extra, optional
layer for most users. They can choose if they want the extra hassle in
exchange for security. Passwordless gives you no such option, you have to
switch apps, period.

------
zokier
I'm actually thinking something completely opposite; do we really need to have
users input their own password? Why not just generate one for them? Users are
notoriously bad at creating passwords (on average), and generating one for
them would allow us to throw away all that complex password rule dancing.

For the people that are already using password managers it would be fairly
minor change in workflow when creating accounts (which is relatively rare
occasion anyways), and for the rest it would be massive improvement in
security.

~~~
JoeAltmaier
In my naive thinking, I'd let my computer and the server manage passwords
independent of me. Let them share some secret; then my machine creates a
1024-bit challenge and get a response from the server. Why involve me at all?
I'm terrible at managing large random things.

~~~
bradleyjg
If you always used one computer that would be fine. But if you create your
account on your home computer and then want to use it on your work computer,
your ipad, your android phone, and occasionally at your brother's house then
we need some way of authenticating you instead of your computer. And even if
you don't want to log on from any of those places, eventually you are going to
get a new computer.

~~~
JoeAltmaier
And how does that differ from a huge, unrememberable password?

------
rtl49
Does anyone really believe the world needs yet another article bemoaning the
common and unpopular practice of imposing arbitrary requirements on passwords?

I'd much sooner read a piece discussing the reasons developers so often make
this design choice. Is it a thoughtless formula, a common misconception about
how brute-force attacks are conducted, or something else?

I'm far from an expert on the subject, but as an aside, I'd like to point out
that the XKCD comic on the topic seems inconsistent with what I know about how
brute-force attacks are usually conducted. To my knowledge, these are usually
dictionary-based attacks, which would significantly decrease the "search
space" to discover even a long, lower-case sentence. Thus a password with
random characters and shorter length might be more secure in practice than a
longer password composed of English words.

Edit:

I've been informed that my layman's speculation on the comic was mostly wrong.
As I said below, "sorry to be on the other side of the 'infuriating argument
with someone who doesn't know information theory or security.'"

~~~
gabemart
> To my knowledge, these are usually dictionary-based attacks, which would
> significantly decrease the "search space" to discover even a long, lower-
> case sentence.

The xkcd comic assumes a dictionary-based attack. It points out that choosing
4 words at random from the 2048 most common words provides more entropy than
choosing one word at random from the most common 65536 words and performing
some letter substitutions on it. In both cases, it is assumed the attacker
knows the formula used to create the password.

If your formula for creating a password is "Choose a printable ASCII character
at random, then repeat", you only need a password that is 7 characters long to
beat the "4 random common words" formula (95^7 > 2048^4). But the percentage
of people who construct passwords by choosing random printable characters
rounds to zero.

~~~
rtl49
I appreciate the clarification. Sorry to be on the other side of the
"infuriating argument with someone who doesn't know information theory and
security."

~~~
gabemart
Not at all, I know only a tiny amount about this field myself.

------
svckr
This is exactly what happened to me on MULTIPLE occasions with multiple
websites. Right down to the special characters table flipping.

But the best one yet was my car insurance (have since switched to another
one). I logged in maybe once or twice a year and that thing was asking for a
PIN. Turns out this was not actually a number they were asking for. When
clicking through their password reset forms I found out that they were
actually asking for a password (with multiple rules in place to make it more
secure). Gaaahhh.

Ok, sorry for rambling…

------
massysett
"It’s time to use the password reset link again, which at this point is
basically your login button."

This actually is not a bad idea. For rarely used sites I might as well just
make something up that is impossible to guess and that I will never remember,
and then just use the reset link every time.

~~~
s_kilk
I did something like this with
[http://nightchamber.com](http://nightchamber.com), where your 'login' is just
a unique URL. It's a fun idea, but it only works when the stakes are low
(which they are for nightchamber, it's not like there's anything useful in the
account anyway). I sure as hell wouldn't want paypal or amazon using that kind
of scheme though.

------
cm2187
On one side I understand the need for good passwords given how bad websites
are at keeping their clients data private, but fundamentally the problem is
rather that websites are leaking data, not that passwords are too weak.

How do we solve that problem?

~~~
scrollaway
> How do we solve that problem?

You don't solve it, but you mitigate it.

1\. Decentralize authentication and get rid of passwords. Persona/BrowserID
had the exact right idea in mind and .. well, whatever, it's gone now, and
we're all pissed off; plenty was said about it. We need the concept back and
we need it to be popular.

2\. Stop gathering so much data. Stop keeping it for so long. If your client's
data is sensitive, ask yourself - and your client - whether you should really
be keeping it and how long should you be keeping it for. You're not Google,
Facebook or anything close to them - the odds are you will _not_ be able to do
anything with "big data". Either make the data public in the first place (if
it's appropriate for it to be public), or wipe it out if you don't need it.

3\. Start treating security malpractice in large companies as seriously as we
treat Food & Health standards. Leaking hundreds of thousands of passwords
because you hashed them with md5 no salt is _criminal_.

4\. Build a better framework for users to learn the basics of security. How it
works, why it matters; the fundamentals necessary to figure things out on your
own. Make them understand what they're giving up if they are not treating this
seriously. Education, education, education.

------
zhkirill
Reminded me of this video:
[https://www.youtube.com/watch?v=luv_bWmb9lE](https://www.youtube.com/watch?v=luv_bWmb9lE)

------
Grue3
There's no way I would give away my phone number to any random website. Thus,
I would never use two-factor authorisation that involves my phone, unless it's
a bank or something. Most of "social" accounts aren't all that important
anyway.

~~~
klapinat0r
2FA doesn't mean phone number. There's also HOTP and TOTP, dongles, bio, etc.

------
w8rbt
There's a RFC for everything else... why not have one for password
requirements?

[https://en.wikipedia.org/wiki/Request_for_Comments](https://en.wikipedia.org/wiki/Request_for_Comments)

------
falsedan
Nothing about password, but the nav banner show/hide on scroll for the page is
delightful (and should be adopted by all sites post-haste IMO).

------
untangledlaurel
1password... last pass... is the only way to survive... Now how soon can we
completely abolish passwords?

------
butler14
No love for spaces in passwords? i.e. spacebar presses

------
avens19
This exactly is why I use LastPass

~~~
Zikes
Ditto, but I still get annoyed at having to re-generate a password half a
dozen times to fit whatever opinionated rules a particular site comes up with.

------
iamsohungry
> The Attorney General of Texas Child Support website

It would not surprise me at all if this password hell was intentional.

