Applying Pavlovian Psychology to Password Management

Ars Technica reports on an interesting and sensible-sounding approach to password policy that I'd like to see adopted just about everywhere I have a password (which, these days, is quite a few). An excerpt: "For instance, a user who picks "test123@#" might be required to change the password in three days under the system proposed by Lance James, the head of the cyber intelligence group at Deloitte & Touche. The three-day limit is based on calculations showing it would take about 4.5 days to find the password using offline cracking techniques. Had the same user chosen "t3st123@##$x" (all passwords in this post don't include the beginning and ending quotation marks), the system wouldn't require a change for three months."

Comments

Forcing password changes is never a good idea

[wisnoskij]

Because all you are going to get is users deciding that they they cannot come up with a 10th password that year and just going picking "123456".

"I'd like to see adopted just about everywhere I have a password (which, these days, is quite a few)"
What a joke. If every site used this method I, and many other people, would need to change multiple passwords every single day of the year. The entire system would break down and become completely unmanageable

Re:Forcing password changes is never a good idea

[Mr. Slippery]

I think the idea is you'd let the user know. "This password would take approximately 4.5 days to crack....

..."if we are incompetent enough to divulge your encrypted password." So, how about you don't divulge my encrypted password, then?

Re:Forcing password changes is never a good idea

[Maxo-Texas]

I struggle when I get a new phone or tablet...

And then I have to remember the netflix, hulu, pandora, google, etc. etc. etc. password.

And when I get it wrong-- I have to reset it.

And then I have to change it on EVERY device.

The other struggle is that

SITE A REQUIRES CAPITALS.
SiTe b treats capitals like lower case.
Site c requires 1st letter capital.
siTe d requires at least 1 capital.
Site! e requires punctuation.
Site~ f doesn't allow !'s.
Site1 g requires at least 1 number
5173 h requires only numbers

SiteSite1 i Has the above restrictions but requires 8 or more letters.
Sitesite j only allows 8 letters- but requires 4 or more
Site k won't work with XKCD since it doesn't allow ' 's
Site L has some permutation of these rules and won't let me reuse prior passwords- or double letters, or various other sequences, or english words in the dictionary-- so my password ends up being almost completely arbitrary.

So these days-- I write algorithmic encoded passwords on paper.
So you can look at the paper - and it doesn't mean anything to you. It's not a simple substitution cypher.

But it still sucks when I buy a new device and have to change all the passwords for something before I started writing down passwords.

Another thing password services (not job passwords) have is a duration of YEARS. I'm supposed to remember a password I created 7 years ago that met arbitrary rules- which they won't tell me now. Meh.

Re:ObXKCD: Passphrases

[Anonymous Coward]

Not a great extent. Most of us knew the math already, but it only works well when you really select randomly from a dictionary instead of making grammatically correct sentences or even personally chosen set of "random" words (from a limited vocabulary). Mixing passphrases and complex passwords works best. battery horse correct staJ&%v1ple

Makes sense only if hashed file is public

[bugnuts]

The three-day limit is based on calculations showing it would take about 4.5 days to find the password using offline cracking techniques.

If you're assuming your hashed password file is public or you allow unlimited login attempts without shuttering the connections, then this makes some sense. But if your pw file is public you need to force a change far before the average crack time (like 2 stddev), which probably means hours on an average of 3 days to crack.

But if your pw file isn't supposed to be public, then you're setting a policy assuming your system has been cracked and are passing bad math onto the users as annoyance. And then blaming them. If you fail to factor in the likelihood of the password file being taken, then all the "average time to crack" might not matter.

Re:Writing passwords down

[ShanghaiBill]

Passwords are security through obscurity. We need a better system altogether.

Absolute hogwash. That is not what "security through obscurity" means at all. Security through obscurity refers to security based on an algorithm being secret, not specific per-user information.

Re:Proliferation of two-factor means

[jonwil]

The problem with the use of SMS for 2-factor auth is not that you have to pay for the messages (paying for incoming text messages is an artifact of the horridly broken pricing model for US cellphone service) but that SMS is unreliable (I have had instances of SMS messages not getting through, especially if my phone happens to be switching cells or entering a dead zone at the time) and also that with more people doing so much internet stuff on their cellphones, having the second authentication factor being the same device you are using to log into the web site makes things a lot less secure.

Re:Preposterous

[stoploss]

+1 to this, using foreign language characters in a passphrase is a great idea, it makes things more secure since it increases the number of combinations hackers need to try (assuming they even have the foreign language characters in their data sets which I doubt they do)

Enjoy being locked out when you realize that UTF8 != CP-1252 != UTF16LE, etc. Oh, and god help you if you need to use a different OS to login, or don't have rights on the given machine's account to change the input charset. And all this is before you get into the potential disconnect between the webapp's stated charset vs the backend password system's charset (your password text field input isn't being passed around as raw bytes no matter how much you might wish it to be, sorry).

There is no hell like charset encoding. Yes, in some imaginary world where everyone dropped IPv4 when IPv6 came out, simply because it was the correct technical solution, your idea might work due to ubiquitous, end-to-end UTF8.

Here in the real world, well, one time I got locked out of a shitty online banking system because I used a punctuation character in my chosen password while setting it and all non-alphanumerics were stripped from input in the login password field, thereby preventing me from ever being able to submit my chosen password.

The real world is horrific and soul crushing.