The Psychological Reasons Behind Risky Password Practices (helpnetsecurity.com)

Orome1 quotes a report from Help Net Security: Despite high-profile, large-scale data breaches dominating the news cycle -- and repeated recommendations from experts to use strong passwords -- consumers have yet to adjust their own behavior when it comes to password reuse. A global Lab42 survey, which polled consumers across the United States, Germany, France, New Zealand, Australia and the United Kingdom, highlights the psychology around why consumers develop poor password habits despite understanding the obvious risk, and suggests that there is a level of cognitive dissonance around our online habits. When it comes to online security, personality type does not inform behavior, but it does reveal how consumers rationalize poor password habits. My personal favorite: password paradox. "The survey revealed that the majority of respondents understand that their digital behavior puts them at risk, but do not make efforts to change it," reports Help Net Security. "Only five percent of respondents didn't know the characteristics of a secure password, with the majority of respondents understanding that passwords should contain uppercase and lowercase letters, numbers and symbols. Furthermore, 91 percent of respondents said that there is inherent risk associated with reusing passwords, yet 61 percent continue to use the same or similar passwords anyway, with more than half (55 percent) doing so while fully understanding the risk." The report also found that when attempting to create secure passwords, "47 percent of respondents included family names or initials," while "42 percent contain significant dates or numbers and 26 percent use the family pet."

Comments

Passwords exist

[Anonymous Coward]

That's the reason.

Re:Passwords exist

[thsths]

Passwords suck. Even with SSO, even with a password manager, even with salting and hashing, passwords suck, and will always suck.

You need an authentication token. *One* authentication token. Microsoft can do it, Google can do it, Facebook can do it (but of course they are not compatible).

Millions of little websites still use passwords.

Re:Passwords exist

[Anonymous Coward]

You need an authentication token. *One* authentication token. Microsoft can do it, Google can do it, Facebook can do it (but of course they are not compatible).

So, you are saying that they really cannot do it...

We can download a password manager for free. Authentication token managers are going to cost money, with the price depending on how many authentication tokens you need them to manage.

Re:Passwords exist

[johannesg]

Passwords suck. Even with SSO, even with a password manager, even with salting and hashing, passwords suck, and will always suck.

You need an authentication token. *One* authentication token. Microsoft can do it, Google can do it, Facebook can do it (but of course they are not compatible).

Millions of little websites still use passwords.

And then Microsoft makes use of Windows 10 (or compatible Windows Phone devices) mandatory for their SSO. Google randomly decides to just drop the whole SSO business. Facebook suspends your account because some asshole from Brazil has complained about one of your holiday snaps. What now? Will you just rebuild your whole online identity? Or forget about the dozens of sites you were participating in?

Re:Passwords exist

[Opportunist]

There's three possible kinds of security factors. Something you know, something you have and something you are (or, more cynically, something you can forget, something you can lose and something that can be chopped off). They all have their advantages and disadvantages, but saying that one is superior to the others is simply and plainly wrong.

And the key reason, btw, why pages don't do it is simple: When people forget their password, resetting that is easy (plus they get your email address so you can reset it in the first place), but if you lose the token...

Re:Passwords exist

[tburkhol]

We can download a password manager for free. Authentication token managers are going to cost money, with the price depending on how many authentication tokens you need them to manage.

You can get a U2F USB token about the size of your house key for $8 that will manage as many separate authentications as you like. For $50, you can get one with NFC that will talk to your phone.

They look like a great system now, until you lose the physical token. If they ever become popular, then I'm sure there will be techniques to subvert them - MITM, phishing or misdirection - I'm not smart enough to guess. If they every become popular, then I'm sure the 'lost token' problem will frequently be solved by having a password backdoor around the token.

Re:Passwords exist

[RandomSurfer314]

Centralized authentication and entropy sources for encryption keys is certainly the wet dream of all law enforcement and intelligence services of the world, but it makes zero sense from a security perspective. Zero.

Re:Passwords exist

[Anonymous Coward]

You can do it with no passwords or tokens at all.

I'm posting right now. No name, no password, just post. It's a realistic solution for upwards of 70% of the "passwords" I've had to resort to writing down on a pad in my desk drawer.

Re:Passwords exist

[The-Ixian]

SQRL!

Re:Passwords exist

[Anonymous Coward]

Oh come on. If you lose the token, they can email you a code and send another part of the code to your phone. You then use both parts of the code to log back on. Or something else that does two parts. It is only rocket science keeping the hashes and all secure. The implementation side for users is simple.

Re:Passwords exist

[Anonymous Coward]

Pay attention Doug!

Re:Passwords exist

[jofas]

This is a significant comment.

The context of security with regard to inter-connectivity has evolved. Our current thinking is largely based on the old one user, one device world of 30 years ago. Now, not only do we need to establish a separation between machines and humans in the realm of authentication, but we also need to abstract authentication away from "points of entry" thinking; we don't necessarily need to identify ourselves everywhere. We don't provide identification when buying gum or shoes with cash. We don't have body scanners and security guards at the entry points to our homes.

What we really need is to shed the idea of the password as an authenticator. Authentication is not a secret, it is validation of identity. When we have non-intrusive instant DNA enumeration, that's when we will finally ditch the terrible idea that is the password.

Re:Passwords exist

[RandomSurfer314]

Right, because it's totally impossible to get a DNA sample such as a hair form someone...

Re:Passwords exist

[jofas]

Did you miss the "instant" part??

It's all about risk. You make the DNA verification instant, fraud is much more difficult.

Re:Passwords exist

[chihowa]

He's talking about an authentication token, not SSO. A real cryptographic token with take a challenge from the website and sign it with your key (possibly after entering a PIN) to prove that you are in possession of the token (and know the PIN). There's no way that this is tied to any one provider, because it's not SSO. (See PIV, OpenPGP card or any number of similar approaches.)

The tokens in use now are all TOTP or HOTP-type tokens where you generate a hash that proves that you and the authentication server both know the same secret. Microsoft, Google, and Facebook's systems are incompatible because there's no secret that you know that they don't. Making them work together would mean sharing the means to log into your account with all of them (and every shady website that you want to use the token with).

Re:Passwords exist

[mjwx]

Passwords suck. Even with SSO, even with a password manager, even with salting and hashing, passwords suck, and will always suck.

You need an authentication token. *One* authentication token. Microsoft can do it, Google can do it, Facebook can do it (but of course they are not compatible).

Millions of little websites still use passwords.

And then Microsoft makes use of Windows 10 (or compatible Windows Phone devices) mandatory for their SSO. Google randomly decides to just drop the whole SSO business. Facebook suspends your account because some asshole from Brazil has complained about one of your holiday snaps. What now? Will you just rebuild your whole online identity? Or forget about the dozens of sites you were participating in?

This.

Also you'll end up with 15 tokens because some sites only support Microsoft, others Google, Apple will have their own system entirely, then you'll have 156 different Open Source projects doing the same thing with massive flame wars about which token is open/GNU enough.

And woe betide you if you lose a token. RSA tokens work in the corporate world because the organisation manages the tokens, not RSA. If I lose my work token it's a 10 minute job to issue a replacement. Try doing that with a Google or Microsoft provided token, at work I dont have to prove my identity as everyone knows who I am, some random tech flunkie from Microsoft wont know me from a bar of soap so it'll be an ordeal to get a replacement.

Passwords may suck... but there isn't a better alternative.

Re:Passwords exist

[RandomSurfer314]

Your DNA doesn't change over time, so instant or not is totally irrelevant. Somebody collects your DNA and waits until you next use it.

Re:Passwords exist

[jofas]

What do you mean "waits until you next use it"? Also, I don't see what DNA changing over time has to do with this.

I don't give a shit about the gritty details of how the system would work. The point is that DNA is the only thing we know right now that's the closest thing to a "unique identifier" for all users. Since the point of authentication is to verify identity, then it stands to reason that DNA might be part of the solution. Of course the system has to be worked out to prevent abuse.

Passwords are terrible authentication mechanisms.They are an antiquated and very basic filter and we should start getting away from them. An authentication mechanism doesn't need to be something you know.

Re:Passwords exist

[Opportunist]

And before you're done even explaining this to your customer, he'll say "screw that, way to complicated, I move to $competitor, there I only need a password".

Re:Passwords exist

[Rexdude]

Facebook suspends your account because some asshole from Brazil has complained about one of your holiday snaps.

Why is some asshole from Brazil able to view your holiday snaps in the first place? It's amazing how many people continue to blithely post everything on Facebook publicly.

The author has a certain level of understanding

[93 Escort Wagon]

"Only five percent of respondents didn't know the characteristics of a secure password, with the majority of respondents understanding that passwords should contain uppercase and lowercase letters, numbers and symbols."

This would be great advice... for a person in 2002.

Re:The author has a certain level of understanding

[Anonymous Coward]

I'm pretty sure that most employees who are forced to pick new passwords once/month just use something like:

Password@7/16
Password@8/16
Password@9/16

This meets all of the upper/lower/digit/symbol requirements, and it never repeats.
I also think the ones that don't use this method just write the password down on a post-it note that they keep in the office.

Re:The author has a certain level of understanding

[Anonymous Coward]

I'm pretty sure that most employees who are forced to pick new passwords once/month just use something like:

Password@7/16
Password@8/16
Password@9/16

This meets all of the upper/lower/digit/symbol requirements, and it never repeats.
I also think the ones that don't use this method just write the password down on a post-it note that they keep in the office.

I dont think you can really compare choosing a password to protect your own data vs choosing a password to protect things that are not your own. That's why people who pick passwords like in your example, don't care about putting it on a post it note at work.

If someone forgets their password at work they get into trouble for not doing their work. If another employee were to sign into another persons account via their post it note and it became an issue you can be pretty sure that person will be sacked. Many employees share their passwords anyway so if one person is away sick or whatever another person can pick up their work or grab a file inside their account. I'm not saying any of this is right just why people might not care about having secure passwords at work.

Re:The author has a certain level of understanding

[Z00L00K]

That's too long for some systems used where I work where the length has to be exactly 8 characters and not contain any "special" characters in order to allow the passwords to work also on some oddball systems.

Re:The author has a certain level of understanding

[Anonymous Coward]

I also think the ones that don't use this method just write the password down on a post-it note that they keep in the office.

Anyone who has access to the post-it has access to to computer.
If you can't trust the the people in the building, lock the door to the office.
Considering that some people opt for using password managers that aren't air-gapped and that puts all eggs in the same basket I am a bit surprised at the hate for post-it notes.
Writing down the password on a paper makes it so that the user is less reluctant to select passwords that are easy to guess or brute-force.

As for the entire premise for the article they make the same mistakes expert always does. They assume that their field is the most important one in the world.
Everyone knows that air-gapping is the way to go if you really want to secure your data, yet every security expert refuses to cut his cords.
We shouldn't have to go to that extreme end for them to realize that the primary objective is to get other work done and security only is acceptable to the level where it don't interfere with the rest of the work too much.

Re:The author has a certain level of understanding

[Anonymous Coward]

All this password drama is just smoke and mirrors for IT security guys to gain some visibility and prod users' minds to be security-aware. Most of activities about passwords, except using long and random passwords and not reusing them, are pointless:

Enforcing that passwords must contain representatives of certain subsets of all characters set actually makes number of possible combinations lower, thus easier to brute-force, while at the same time it does nothing to prevent dictionary attacks (which is a main rationale for putting in place such stupid requirements), because users will use "leetspeak" or add additional required characters at end or at the beginning of their chosen words. Better let an application generate password for user's eyes only and force user to memorize it (or to write it down, at their own risk).

Oh, and another pet peeve: changing passwords often - it does nothing for password guessing, all passwords with same randomness have same probability of being guessed. Changing passwords are meaningful only if old password is already compromised, but you never know when it exactly happened, so unless you are changing password after each session, it is almost completely useless.

Re:The author has a certain level of understanding

[Anonymous Coward]

Exactly. Passwords should be random. Adding rules (other than a minimum length) makes them less random.

Once people hear that passwords should have all these silly rules, they start adding more rules to make them even more secure, and soon you end up with very few passwords to choose from.

Re:The author has a certain level of understanding

[gfxguy]

Yeah... I don't know anyone who writes it down on a post-it next to their computer, but we do have a 90 day policy, and my password strategy is not quite what the GP described, but it's not too far off, either. That's the stupidity of just not allowing us to create a really great pass-phrase that would take years to break. That's all on top of two-factor authentication (RSA SecureID) when not signing in from our internal network.

The stupidity is that on systems that have multiple users, we have a shared account that we use - it's actually assigned to a large number of systems; these are not user's desktops, but graphics productions systems that any number of operators might use. The problem is that the IT department implemented this password policy without asking any departments about the effects, and after 90 days we were blocked from this account because none of the operators had the authority to change it, and if they did they'd lock out everyone else who didn't know it - many offices, or even buildings away. Moreover, none of us get the email from that account - which doesn't even really have email, so nobody got a warning the password was expiring. So we do live TV, and people couldn't log into the systems that generate the on screen graphics. Of course now that login is an exception, but it points out a problem with IT blindly creating a policy without input from the people it's affecting.

The other stupid thing is that our MS Office accounts are tied to our logins, and we can authorize up to 5 boxes. There are at least 100 production boxes, and we can't license them by box. We do a lot of daily production data in spreadsheets because it's easy for the user and easy to use as a data source.

In any event, the more passwords humans are required to remember, and the more complicated they are required to be, the less secure we're going to make things as people do skirt the guidelines to make them as easy to remember as possible - or they write them down, or whatever.

Frankly, I don't see what's wrong with the scheme the GP described (although I would make it more complex). If someone has to brute force decrypt it, it will still take just as long. With the special characters in there, it's highly unlikely someone could guess it. It's true that once they got it once, they'd be able to guess it correctly later on, but the idea is to make it hard to get even once.

Re:The author has a certain level of understanding

[CCarrot]

That's too long for some systems used where I work where the length has to be exactly 8 characters and not contain any "special" characters in order to allow the passwords to work also on some oddball systems.

Tell me about it. But sometimes it's simply shockingly bad security choices on the part of the company, as well. For instance: my old bank started requiring a fixed-length, 6-letter password that was case-insensitive and mapped to the corresponding phone digits to consolidate their dial-up and online logins...I have no idea if they still do that, since I abandoned ship shortly thereafter. I simply wasn't comfortable with having my banking access protected by, essentially, a 6-digit number.

To be fair, they did have some sort of device-based recognition checking in place, so if I wanted to log in from anywhere besides my home computer I had to practically scan my birth certificate and send it to them before they'd acknowledge that yes, this person typing in the ridiculous password and trying to access my account is actually me.

Re:The author has a certain level of understanding

[Safety Cap]

the majority of respondents understanding that passwords should contain uppercase and lowercase letters, numbers and symbols

Yup. A password under 8-12 characters in length, consisting of a simple dictionary word (with simple digit substitution of a = 4, e = 3, i = !, random capitalization, etc) can be solved by a GPU in less than a second or two. Combine several non-related words together and you might have a fighting chance. Don't even get me started about how many friends and relatives don't use 2-factor auth.

Re:The author has a certain level of understanding

[gfxguy]

... Better let an application generate password for user's eyes only and force user to memorize it (or to write it down, at their own risk).

Let's see... my work account, two banks, several credit cards, two healthcare accounts (FSA AND HSA) as well as my health insurance, accounts for my kids in school (like paying for school lunches), ISP account, several streaming services, slashdot, reddit, and a number of other forums I participate in (and not me, but most people will have several social media accounts).... you get the idea. I'm supposed to remember all those completely random passwords?

Oh, and another pet peeve: changing passwords often - it does nothing for password guessing, all passwords with same randomness have same probability of being guessed. Changing passwords are meaningful only if old password is already compromised, but you never know when it exactly happened, so unless you are changing password after each session, it is almost completely useless.

Now that I can agree on - our company's policy is just damn annoying and often screws up our production work.

Re:The author has a certain level of understanding

[Guybrush_T]

Absolutely. And since we're not machines, remembering multiple random passwords is just impossible. Seems like we all understand the situation. Yet, even big companies still enforce password rules of the 90's. What's wrong with them ?

Re:The author has a certain level of understanding

[networkBoy]

I'm guilty of the increment counter in pwds at work.
As to the SecurID token...
Co-worker has pwd and username on post-it on back of token...
smh

Re:The author has a certain level of understanding

[Anonymous Coward]

Granted, I am not most employees, but I do use a password manager, and I let the manager select my password, which is usually large and has all the required bits of complexity. That let's me easily set and change a password.

Of course there are two problems with that. First, the manager has its own password, which I do have to be able to remember. Not a big deal, but if someone gets their hands on my password database somehow, that password is not as good as the ones I set for every other account because I actually have to remember it. And more to the point, even if I change the password, if someone gets an older copy of my database, then it is still encrypted under the old password and does not change.

Second, to be honest, because of the complexity of the passwords and how many there are... I don't actually know any of my passwords other than the one for the password manager and maybe one or two others. In some senses, that's pretty secure, as then you can't even torture me for passwords I don't know. On the other hand, if I lose my database or it is merely unavailable to me, I'm fucked. Still, I have yet to run into that as an issue yet, mostly because I can sync my file with the password app on my phone, which means that it is usually on me, even if it isn't as convenient to use.

If you can get around those issues, I think a password manager is a really good idea. It certainly takes away the pain of having to select a new and different password for every account I have, which you want to do given the prevalence of hacks of network services that may expose your password. You don't want to have the same password for your accounts if that is the key to everything.

Re:The author has a certain level of understanding

[Anonymous Coward]

Requiring regular password changes is the biggest security risk there is. Nearly nobody can remember good passwords when they keep changing. But let me keep a password for decades, and I'll have no problem with 16 characters or whatever.

Re:The author has a certain level of understanding

[Anonymous Coward]

Yet, even big companies still enforce password rules of the 90's. What's wrong with them ?

Stupidity.

Keep firing IT policy makers until it stops. "Best practices" aren't good just because MS or some book says so. A password timeout policy is one of the biggest security risk there is these days. I keep telling my students that . . .

Reality is...

[Anonymous Coward]

... corporations are the ones making the world insecure by forcing things online and to have online accounts to track everything. They create massive attack surface in their mad quest for transparent user/customer data and profit.

Re:Reality is...

[Anonymous Coward]

This article is utter Bullshit. It's right there on the first page:
"More than 500 million passwords were leaked so far in 2016 from the recent LinkedIn, Twitter and Myspace hacks."
No, there were no password Ninjas in the deep of night , looking for Post-It Notes under keyboards, or going through Veterinary Databases looking for the names of favorite dead Guppies.

The "Risky Password Practices" are _ALL_ on the Corporate side, and they have gotten away with blaming _US_ for far too long for their crappy lazy habits.
1-2-3-4-5 properly hashed and securely stored is a fine password, and the likelihood that any individual has to worry about somebody going deliberately after their passwords is slim. The value is in gaining a lot of compromised accounts on the Server side.
"Security Experts" make me want to puke. They keep on reciting the Litany of Personal Blame, while avoiding any responsibility for the awful corrupt state of their own industry.

Re:Reality is...

[pla]

What form of "properly hashed and securely stored" would make a five character numeric-only password even remotely acceptable?

Mind you, I don't disagree with your premise - The problem here has nothing to do with end-users, and everything to do with expecting them to remember over a hundred distinct "secure" passwords. But that glaring flaw aside (which leads people to use the least secure password a site will let them, and reuse it at every site they can), there *is* still such a thing as a pathetically weak password.

We've all seen, and can debate the exact accuracy of the relevant XKCD strip, but the general idea holds true - We'd all do a hell of a lot better to use memorable three to five word phrases, than trying to squeeze something we can almost remember into leetspeak with an extra random character or two tacked on at the end.

Re:Reality is...

[bondsbw]

No, there were no password Ninjas in the deep of night , looking for Post-It Notes under keyboards

Sad thing is, after all this time and warnings about how it is unsafe, a sticky note out of plain sight is probably one of the most secure ways to store passwords. Especially if you trust the people who have access to your equipment, or if you simply lock them up in a drawer.

Nobody actually takes the risk of physically breaking into a place just to steal passwords. Attempting to break into your database is likely much less risky, much easier to do (given a reasonable hacker skill set), and much more rewarding.

Re:Reality is...

[Anonymous Coward]

Regarding XKCD:
A system shouldn't allow 1000 login attempts to the same account per second.
If something like that happens there is a targeted attack going on and login should be blocked.
A human user wouldn't even notice if the login is limited to one per second so at least a rule like that should be enforced. If there is an ongoing attack then the user will have trouble logging in and contact support.
After a dozen faulty logins from the same IP it might be a good idea to lock that one out. (A human should give up before this limit is hit, it is supposed to block out machines.)

Network-based brute-forcing shouldn't be prevented by password strength. Just block out the 100 most common passwords to prevent "lucky" guesses.
Forcing obnoxious password practices on the users just makes them write them down and doesn't improve security that much.
Just configure your computers to stop brute-forcing instead and you won't need to rely on good passwords.

Re:Reality is...

[Tijaska]

Great advice. The average native language speaker uses a vocabulary of about 20,000 words. There are 8,000,000,000,000 possible three-word phrases taken from a vocabulary of 20,000 words. If you draw the words from more than language, assuming you know some words from another language, the combinations go through the roof. The old rules on what constitutes a "good" password were devised by robots to torment humans. They lead to unreadable, unrecallable monstrosities. l33tsp34k is easier for computers than humans. Requiring users to change passwords regularly just compounds the problem, and the rule is there only because the servers that validate logins get compromised. If these servers stored only the hashed version of each password then even if they are cracked, the cracker would not be able to use the information thus gained to log in. Don't force users to jump through hoops to compensate for the slack practices of system admins, and then complain that their hoops are set too low.

Re:Reality is...

[Spacelord]

> A system shouldn't allow 1000 login attempts to the same account per second.

Cracking passwords generally isn't done by attempting to login, but by hacking into the database, obtaining the password hashes and then running a password cracker on them offline (using a dictionary, rainbow tables and whatnot). Cracking passwords like 1-2-3-4 is almost trivial in this case. "Difficult" passwords are a lot harder to crack this way.

So if you use 1-2-3-4 as a password on several sites, and only one of those sites gets compromised by a hack, your password for all the other sites get exposed.

Re:Reality is...

[vtcodger]

This is entirely too sensible and therefore has no chance whatsoever of being generally adopted.

Reality is that passwords are a huge usability problem that is exacerbated by trying to treat the user as a programmable system component. Sadly, passwords of practical length/format don't, and probably can't, provide much security. And users, in general, are not reliably programmable.

What's my answer? Don't have one. But what folks are trying to do isn't working and probably can't work.

I think that the situation might be worth worrying about. But what do I know?

Re:Reality is...

[shilly]

I have never been able to accurately type four common words without spaces and with the letters obscured. For that reason, I've always used Ross Anderson's suggested method of taking a phrase that means something to me and using the first letter of each word in the phrase. Sure 8 to 10 characters are less secure than 24, but it's a damn sight easier to type.

Re:Reality is...

[h33t l4x0r]

A 10 char password is guaranteed to get cracked in a scenario like the Yahoo breach, so congratulations, you fall into the "risky password" group.

Re:Reality is...

[shilly]

24 character passwords are pretty impractical in my life, and indeed the life of tens of millions of others. Security engineering is much more successful when it works *with* the grain of human nature, not against it.

Re:Reality is...

[Anonymous Coward]

"What form of "properly hashed and securely stored" would make a five character numeric-only password even remotely acceptable?"
One that was properly hashed and securely stored, Silly. A concept that still evades you and the "Security Experts". You are all _still_ thinking about this wrong.

"...there *is* still such a thing as a pathetically weak password."
No, My Gentle Fool, there isn't. It is entirely possible that 1-2-3-4-5 could be _Everybody's_ Password. You are still thinking along the lines of infinite Passwords, and only one means of pathetically and weakly parsing them. Turn that around. One Password, and infinite means of parsing them. Jesting aside, We have figured out how to do just this very thing, based on research done by the Berkeley Real Time Systems Group, around 1980. The trick lies within two inner words in that group's name... and Time Dependance.
Any Password, hashed in any number of many ways repeatedly, and yet each one with a unique Time Stamp embedded and invisible, should do the trick.

But this matters not a whit if Names, Email addresses, Phone numbers, etc. are stored in Plain Text along with those utterly secured and impenetrable Passwords, as is so often the case. I got caught on this recently on a very old Site- My Password was fine, but the Database associated with it was in Plain Text, so it turned out to be very easy to compromise the Email Account associated with it.

"Mind you, I don't disagree with your premise..."
Thanks, but you still have the premise wrong.
"...The problem here has nothing to do with end-users, and everything to do with expecting them to remember over a hundred distinct "secure" passwords."
My premise is that Password security is utterly and deliberately lacking on the Corporate side, not our side, and that our trying to outwit a system so thoroughly designed to be so weak is futile. Just use 1-2-3-4-5 everywhere, and yet trust nowhere, until Trust is finally deemed to be Worthy..

Hell, circa 1980, BRTSG was uniquely Time-Stamping _everything_. This mostly had to do with "ACL", (Different ACLs back then...), Checkpoints and State Saves, needed for reproducible Nuclear Physics Experiments; and only incidentally to prevent Fraud. (Our MODCOMP H-OSs was designed around this very concept...) It was just those very Time Stamps that tripped Ninov up, over a decade later. (Three unique Time Stamps supposedly assigned to certain Alpha Decay Chains stuck out like three sore thumbs upon later Analysis. Those Decay Chains didn't even know that they _had_Passwords.)

That XKCD strip still makes me chuckle... but it is still thinking about This all wrong. It is still concerned about the Horse, long after the Barn has been nobbled.

Re:Reality is...

[dirk]

It all depends on who you are trying to secure against. For example, everyone says not to use things that are important to you because they are easy to guess. The thing is, if you are worried about outside hackers with no connection to you, they have no basis of guessing that stuff. In most attacks, the hacker has no clue who the account belongs to, so they have no idea that Pepper is your dog and 11/23/99 is your wedding day, so Pepper!112399 is not a terrible password. On the other hand, if you are worried about targeted hackers (whether it is someone who takes the time to actually research the user or someone in the user's life), that is going to be an easy password since they will know that information.

If you are worried about outside hackers, one of the best thing you can do is make really secure passwords and then write them down and keep them in your wallet. For most people, your wallet is one of the most secure places you have, since you already keep cash and credit cards there. Yes, people in your house have access to it, but if those aren't the people you are worried about it works great.

Re:Reality is...

[tburkhol]

In the old days, you might have accounts on a dozen systems, and each of those systems might have a few hundred or a few thousand users. In that context, hacking an individual user seems like a reasonable tactic. It's fairly high effort, but the individual targets were fairly high value. Today, you might have accounts on a hundred systems, and each of them has hundreds of thousands, if not hundreds of millions of users. It's harder to hack a system than a user, but the return is so much greater that it's just not cost effective.

My point is that password policy was originally developed in the context of protecting the user from an outside attacker, and today we need to think of password policy protecting the user from the system itself. Complexity is less important than diversity.

Re:Reality is...

[pscottdv]

But that's the point of the original comment in this thread, isn't it. What makes 1-2-3-4-5 insecure is the fact that the companies storing the hashes can't be trusted to keep them safe but the user gets blamed for having an insecure password.

Re:Reality is...

[pla]

No, My Gentle Fool, there isn't. It is entirely possible that 1-2-3-4-5 could be _Everybody's_ Password.

You've missed my point entirely. "12345" is the fifth numeric password an attacker would try (after "1", "12", "123", and "1234"). It doesn't matter how securely you store it or how long each guess takes, if an attacker has a reasonably high chance of guessing it by a mere educated guess.

Sure, you could lock the account after X guesses - But then you've just given me a trivial way of locking out the legitimate account-holder as well - Arguably, a lot of kids just out to raise some hell rather than seriously wanting to compromise your accounts would prefer that (applied on as large a scale as possible) than actually guessing the right password. "Oh, look, we just locked the entire Microsoft staff out of their own network, ha-ha!"


Any Password, hashed in any number of many ways repeatedly, and yet each one with a unique Time Stamp embedded and invisible, should do the trick.

That accomplishes nothing more than slowing down any brute force attempts. It certainly doesn't somehow magically make one of the top few million passwords more secure. Or, looked at another way, let's say you use such a horrendously complex hash that each guess takes a whole second. You've just handed any potential attackers a trivial on/off switch to DOS'ing (no leading "D" required) your site, as your poor server farm tries to keep up with just a handful of bad login attempts per second.


Time Stamps supposedly assigned to certain Alpha Decay Chains stuck out like three sore thumbs upon later Analysis.

Would you care to provide a link on how timestamped audit trails have anything to do with brute-force password cracking? It sounds like you've mixed up two separate concepts here. Yes, you can make an RTPS virtually tamper-proof; that doesn't have much in common with proving my identity to Facebook from a previously untrusted computer.

Re:Reality is...

[gfxguy]

It's 9 characters and not numeric only.... you forget the dashes. Not that it's a great password, just saying...

Re:Reality is...

[CCarrot]

I have never been able to accurately type four common words without spaces and with the letters obscured. For that reason, I've always used Ross Anderson's suggested method of taking a phrase that means something to me and using the first letter of each word in the phrase. Sure 8 to 10 characters are less secure than 24, but it's a damn sight easier to type.

I'm sorry...why is this? If you don't lose track of where you are when mentally parsing a sentence and only typing in the first letter of each word, why would you lose track when typing the words themselves? I'm sorry, it seems to me that the first-letter thing would be much easier to get lost in while typing.

And why no spaces? Spaces count as 'special' characters and increase entropy...of course, some logins don't allow them, while at the same time requiring other special characters...so in those cases replace them with hashtags or ampersands or something similar.

Re:Reality is...

[shilly]

I don't mentally parse a sentence each time -- it quickly becomes a mnemonic requiring no mental effort to recall. By contrast, typing 24 characters in a row without making a mistake while they're obscured is tricky.

Let's say your sentence is "A generation which ignores history has no past and no future" (Thanks, Robert Heinlein!). Your password becomes Agwihhnpanf. Probably you'll add or substitute a special character in there somewhere. It won't take more than five uses before you remember the letters. Then another 20 or so and it'll be muscle memory.

Of course, YMMV. But this has been my experience. Even more so when trying to use a mobile device.

Re:Reality is...

[RandomSurfer314]

Nevertheless, your password will be cracked when the server is compromised. You can't square a round pig, so to say.

Re:Reality is...

[CCarrot]

I don't mentally parse a sentence each time -- it quickly becomes a mnemonic requiring no mental effort to recall. By contrast, typing 24 characters in a row without making a mistake while they're obscured is tricky.

Let's say your sentence is "A generation which ignores history has no past and no future" (Thanks, Robert Heinlein!). Your password becomes Agwihhnpanf. Probably you'll add or substitute a special character in there somewhere. It won't take more than five uses before you remember the letters. Then another 20 or so and it'll be muscle memory.

Of course, YMMV. But this has been my experience. Even more so when trying to use a mobile device.

Okay, thanks for explaining! My M does V, since I haven't had a problem typing in longer passwords (3 to 5 words, 2 to 7 letters each), yet have a heck of a time typing in (and primarily remembering, but I guess the base sentence would help with that) shorter mixed-case visibly nonsensical passwords. I use the muscle memory I have developed typing real words elsewhere to...type real words while obscured. Yes, sometimes I get ahead of myself and flub up once (but rarely twice), and I always like when there's the 'quick peek' option that offers a look at what you've typed in unobscured for checking before hitting enter (KeePass mobile client does this, some web logins too).

Just goes to show, we're all wired different! And sweet Heinlein reference! :-D

Re:Reality is...

[networkBoy]

that is only suitable for an idiot's luggage or atmospheric shield.

Re:Reality is...

[Anonymous Coward]

24 character passwords are pretty impractical in my life

Not really. Just look at the phrase "24 character passwords are pretty impractical in my life"... 50 characters, and it would be a pretty secure password. It would be easy to remember a simple passphrase ("correct horse battery staple" perhaps) to be a fairly substantially long password, assuming the target system accepted it.

Re:Reality is...

[david_thornley]

Suppose an on-line attacker can get a list of user names. Then the attacker can try a series of weak passwords on each user. On a large site, the odds are that somebody's using an easily guessable password, and if the attacker just wants one login, and doesn't care which one, that could work nicely. Blocking IP addresses doesn't do much good against a botnet.

Re:Reality is...

[david_thornley]

I've had problems with passphrases. I can remember something that's unlikely to be guessed, but I keep forgetting if there's a comma between clauses, or exactly what the capitalization is, or something like that. All it takes is one slip like that and I can't log in.

Re:Reality is...

[Anonymous Coward]

No, what makes 12345 insecure is that you can triviality just try all 5 letter words and see if one matches. That one "word" will be used on any dictionary attack.

Re:Reality is...

[shilly]

It *really* helps if you read the whole thread. The issue is not remembering the phrase, it's typing it accurately lots of times a day when you can't see what you're typing because the text is obscured.

Cognitive Load

[Jarik C-Bol]

The way I see it, password reuse is a matter of cognitive load. Most people are unable or unwilling to attempt to remember the umpteen dozen unique passwords they would need on a daily basis, if they where to attempt to use unique secure passwords on every service/device they use. This results in password reuse, more or less out of sheer laziness. It is probable that among this group, there is a cognitive bias against using password keychain services and tools, because it 'feels' like putting all your eggs in one basket. (somewhat flawed) Logic dictates that if someone breaches the master password to your keychain, and they have all of them, which is no different than using the same password everywhere. (of course, this is not entirely the case, but like I said, cognitive bias)

Now, as for using 'good' passwords, it follows a similar pattern, with most people unwilling to dedicate the time and effort to memorize what amounts to a 'good' password, when they can remember their spouses birthday and their first pet's name just fine.
Of course, we have seen time and time again articles arguing both sides of the court, that long random passwords are either effective or not, and correct horse battery staple passwords are effective or not, so this portion of the discussion is going to be long, stupid and frustrating for evangelists on both sides.

Honestly, I've reached a point where I use 'good' passwords where it matters, (main email, financial items, Amazon etc) and just sort of hope for the best when I re-use the same 'decent' password everywhere else (forums, etc)

I say 'good' because we're at a point there have been enough breaches that we're all probably fucked anyways.

Re:Cognitive Load

[Anonymous Coward]

Not to mention that my work requires me to change my password every 6 months for both bootup, login, and exchange; none of which can be equal to each other, and I can't reuse any password. Ever.

Re:Cognitive Load

[Anonymous Coward]

The problem with key managers is that you've now got to build infrastructure to manage storage across multiple devices. None of the vendors play nice so you end up having to manually synchronize across devices. Or you can go KeePass with a cloud storage backend and now you have to pay for DropBox and find some way to sync your database to your devices. Then you have to find a compatible app for each platform.

Given this it's not even surprising people just don't want to deal with it. Every service...nay, every portal into every service wants you to make a profile, and a password. Tomorrow they'll split the service and require two passwords, then three then ninety. Who wants that burden?

Re:Cognitive Load

[Anonymous Coward]

Honestly, I've reached a point where I use 'good' passwords where it matters, (main email, financial items, Amazon etc) and just sort of hope for the best when I re-use the same 'decent' password everywhere else (forums, etc)

I'm the same, except I have a re-used everywhere 'crap' password for places where there's no goddamn reason to need a password in the first place, but you have to create an account to read an article or some such nonsense.

Re:Cognitive Load

[Shane_Optima]

Six months? Luxury. The places I've worked at all required monthly or 60 day changes, which means that virtually everyone ends up simply appending a number matching the current month to the end of the password. What they don't bother to do is inform you when your credentials have been used to log in at 3am. Or from someone else's workstation. Or from a Hong Kong IP address.

Call me cynical, but most user security policies don't make much sense except from a job security standpoint.

Re:Cognitive Load

[h33t l4x0r]

For big brute force attacks like the Yahoo breach, it's all about length (assuming you don't choose something in a wordlist). Correct horse battery staple passwords are ok but they need a bit of punctuation. A random char password is never getting cracked unless it's too short.

Re:Cognitive Load

[Shane_Optima]

The sane fix would be to push web standards that require all passwords be hashed with server-provided salt on the user's side prior to being sent over an HTTPS connection to the server.

Websites meeting this standard could have fancy little badges of honor to display on their homepage.

Websites failing to meet this standard should be regularly listed in security advisories, companies could discourage or forbid their employees from using these websites, your web browser should warn you that your password on this site should not be considered safe, etc.

This solution to password compromise occurred to me a very long time ago, almost immediately after I learned about hash functions. It seemed so obvious and easy to implement that I was certain it would come about within a year or two. But what have we received instead? Sites that still transmit and store your password in cleartext, but now they send you little verification emails every time you try to log in from a new browser (or the same browser with the cookie deleted).

It's bulletproof!

Re:Cognitive Load

[Shane_Optima]

To clarify, what this would do is allow people to reuse a quality password with all websites and apps that adhered to this standard. If any one site was subject to a data breach, this would only give the attackers access to the hash and the salt; they wouldn't be able to reconstruct your password (as long as it was a good password), thus they wouldn't be able to log in to any other website you used the same password with as long as the hashing algorithm remained secure (e.g. as long as collisions couldn't be engineered with arbitrary salt values.)

If a hashing algorithm is ever compromised such that chosen collisions with arbitrary salt values become feasible, someone immediately issues a bulletin and hash security upgrade. All sites that upgrade their hash algorithm immediately become invulnerable to collision attacks (after the user logs in at least one time, post-upgrade), even if a data breach happens on a server that hasn't yet upgraded their hash. This upgrade could happen in the background, without forcing the user to change their password. The only action the user would need to take is to log in to all websites or apps they have an account with as soon as possible (but neglecting to log in to one site, post-upgrade, would not compromise the security of the others.)

And none of this would prevent client-side scripts from running during password generation to inform the user that their chosen password is too short/weak.

Re:Cognitive Load

[shilly]

And single sodding sign-on never works reliably, so there's always some system that doesn't get updated in any reasonable timeframe with your new password

Re:Cognitive Load

[tinkerton]

I agree. Maintaining many passwords and changing them regularly is demanding . It's no use to exhort people to try harder(it only shows the person doing the exhorting does not understand the situation). Some people devise clever strategies but in general it's better to ask people to use a password manager so they don't even have to memorize the password.

Re:Cognitive Load

[houghi]

Most people are unable or unwilling to attempt to remember the umpteen dozen unique passwords they would need on a daily basis

This makes me mad when IT people are blame shifting as this is like "you are holding your phone wrong" sort of excuse. Security must look at the weakest link and see how they can handle it, not blame the weakest link.

I am not unwilling, but simply unable to remember all my passwords. I have around 50 sites that I use on a regular places and that includes banks, stores, home, email, fun sites and what not.

I can not install a password tool. Tried it once, had a HW crash and then I was fucked. Luck would have it that I wanted to use it because of ease and I had not yet transferred all my passwords to it. I will not be using an online system, because I do not trust them. Not that they are not trustworthy, but because they will be broken into at one point or another. Just a matter of time.
I also do not have the (legal) ability to install them on machines that do not belong to me.

So what I now have is basically layers of 6 passwords.
1) Home access. Highest level as this will have access to everything
2) Email services. These will be used for verification of other things, except what I do at home. I use only 2.
3) Banks. Separate from Email. Confirmation goes to email.
4) Stores. Places I buy things from on a regular basis. I have a list of these
5) All the rest.
6) Work. These must be changed each month and because of that they are the weakest. Also some systems accept only 8 characters, so I use that for everything.

I also use separate emails for every store in 2-4. e.g. Slashdot.org@example.com for this site and bank.tld@example.com for my bank. Easy to not only filter out to the correct folder and easy to detect fraude, but also nice to see who is selling your email address and stop doing business with them.

5 secure passwords and a weak one I can remember. More will not be reasonable. If one of the 1-4 is compromised, it is pretty easy to replace. If it is in 5, I might loose the ability to post cat pictures to Imgur and the like. If 6 is compromised, it is not my problem.

And passwords are not the only thing anymore. Pin codes are much more important now. They are shorter and they will be linked to my bank and are on my phone. So having something there is much bigger issue. Just watch in the queue at Starbucks and you see people typing their password and you can easily see what it is most of the time.

Re:Cognitive Load

[AmiMoJo]

If the company cares even slightly about security, they offer 2 factor authentication.

Re:Cognitive Load

[Anonymous Coward]

6) Work. These must be changed each month and because of that they are the weakest.

Can't be repeated enough. I have worked with systems that forbade the reuse of the last 16 passwords (disconcerting), and even disallowed a letter or character from being in the same place as it was the previous month. I'm not sure the company wasn't just using the software to phish people's passwords, but I'm probably being paranoid.

I typed that above quote into google and got https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes which seems relevant.

Re:Cognitive Load

[Anonymous Coward]

The way I see it, password reuse is a matter of cognitive load. Most people are unable or unwilling to attempt to remember the umpteen dozen unique passwords they would need on a daily basis, if they where to attempt to use unique secure passwords on every service/device they use.

I'm actually more likely to use unique, strong(er) passwords on things I use on a daily basis, because entering the password every day makes it unlikely I'll forget it. It's things I might only use once or twice a year, like niche forums or specific e-commerce sites (unchecking "save my card for next time"), where if I don't use a single password there's no chance I'll remember whatever I came up with when I was there last.

Re:Cognitive Load

[The-Ixian]

This is the tragedy of the commons... everyone only thinking of themselves, then complaining about all the spam they are getting in their inbox.

If everyone put forth a little bit of effort to secure their shit, we might be able to have nice things.

Instead.... oh, who cares if this account is compromised... it doesn't affect me that greatly... so why should I bother?

You should bother because that compromised account is now a platform for malicious activity which then affects us all.

Re:Cognitive Load

[pscottdv]

Our family would have *loved* to have a password for 60 days. We had to change our passwords every 30 seconds and every password had to be 80 characters long and contain Unicode characters that hadn't yet been assigned!

Re: Cognitive Load

[Anonymous Coward]

When I was in the military, it was every 10 days. And IT had a cluster running Jack the ripper on its hashes all the time in order to detect weak passwords. Needless to say, there were a lot of post its on monitors in the building. And no machine was connected to the internet, so the passwords didn't stop any outside hackers...

Re:Cognitive Load

[The-Ixian]

I remember a long time ago (probably like 20 years ago now) doing a password audit using l0phtcrack. Us IT guys got our passwords cracked in about a day of it running. We were using 6 - 8 character passwords with upper/lower/numbers/symbols.

The password that took the longest (actually, it ran for a week and never got cracked) turned out to be 2 dictionary words concatenated together with a number in between them. No upper case, no symbols. It just turned out that it was all about length.

That made me a believer in password length vs. complexity.

Of course, with a password manager, you can achieve both.

Re:Cognitive Load

[HBI]

1) Remembering 15-20 complex passwords is impossible. Not just "not easy", but impossible. You'd have to write them down.

2) You have no idea how many businesses have a black binder with a few pages of passwords in it. If the passwords are written down, they can be stolen, and they can't easily be changed without making consistent changes to your binder of passwords.

3) Shared passwords are not easily managed using a password manager "keychain service"

4) Some computers cannot have the password manager installed on it, ruling out its use (my biggest problem - I have a locked down computer that it is completely impossible to install 3rd party software on)

5) In the event that (4) applies, you could use the manager but then have a bunch of random passwords to remember, compelling you to do (2).

6) Sync between password managers. Not that it's impossible, but it has issues similar to any other networked application. Firewalling, filtering, proxies...

I'm not against the password manager as a concept, but we're a long way away from the common user being able to use it easily.

Re:Cognitive Load

[wagnerrp]

All that does is prevent an attacker from intercepting the plaintext password at the server, as it is received and decrypted by the server. The Yahoo breach compromised the hashed passwords, so whether they were hashed by the server or hashed by the client makes no difference.

Re:Cognitive Load

[Anonymous Coward]

and even disallowed a letter or character from being in the same place as it was the previous month.

So they were storing passwords as plaintext? Because how else can they verify that Apple99 and Opera56 both have a "p" as the second character, unless they stored "Apple99" in plaintext somewhere?

Re:Cognitive Load

[Anonymous Coward]

even disallowed a letter or character from being in the same place as it was the previous month

Yeah... whoever came up with that one should be fired, as it means they're storing the plaintexts.

Re:Cognitive Load

[Anonymous Coward]

This is the tragedy of the commons... everyone only thinking of themselves, then complaining about all the spam they are getting in their inbox.

If everyone put forth a little bit of effort to secure their shit, we might be able to have nice things.

Instead.... oh, who cares if this account is compromised... it doesn't affect me that greatly... so why should I bother?

You should bother because that compromised account is now a platform for malicious activity which then affects us all.

Yeah, because if the hackers can read articles online that require an account by hacking my password, that's surely the first step to nefarious article-reading. And then if the article they're reading in a nefarious manner taught them how to crack a different account that can send mail, then they could send spam! Surely it's the weakness of the former account, and not the latter account, that's to blame!

Re:Cognitive Load

[Jamie Lokier]

Unfortunately, if I understand correctly, most of the publicised password breaches aren't due to intercepting the password in flight; they are due to successfully finding plaintext that matches the salted hash in the stolen database.

But still that's an interesting idea for protection against intercepting passwords in flight or recovered from RAM later.

Not only are passwords in plaintext in-flight behind a TLS terminator, typically on the LAN or virtual LAN or unix socket going to authentication services, but they also linger in kernel, router and middleware memory long after they have been transported around. Good security software knows to erase its own memory of sensitive data after use, but in between the TLS-terminating load balancer or web server (NginX, Apache etc) and back-end application processing of security URLs, usually there are a great many subsystems that transport the data of HTTP requests in plaintext, and don't have special provisions to erase their memory of them. So they linger in RAM afterwards until randomly overwritten. This can be made more secure than it usually is, but it's quite advanced.

The encryption part of your idea can be implemented today by sending Javascript to the client to encrypt the password.

But unfortunately if there's a real-time breach on the server, the attacker can probably change the Javascript as well.

Re:Cognitive Load

[q4Fry]

Mod parent up. GP's system is roughly the worst password security proposition I have heard this year.

Re:Cognitive Load

[Shane_Optima]

I don't know or particularly care how yahoo did things. From your brief description, it sounds like they did things fairly moronically. Both clientside and serverside hashing have a function: client-side reduces the attack surface to the least possible extent for discovering the plaintext passphrase, whilst proper server-side hashing can prevent a read-only database breach from being used to break into an account.

Client-side is the most easily auditable version and as I said, offers the maximum protection against the actual password being found out. If the hashing is handled by a website script, then only a compromise of that website could reveal the pre-hashed password. If the hashing could be handled by the browser itself prior to passing to the website, then only a compromise of the browser itself would reveal the pre-hashed password. Concealing the pre-hashed password is important because it encourages and allows people to take the time to memorize a really strong one and re-use it, which is something that currently isn't viable due to the fact that many big name places store passwords in plaintext.

Serverside hashing has its uses as well. If handled correctly, then it can prevent an attacker with simple database read access (but no write access) from being able to access arbitrary accounts. The server should hash all incoming passwords (which have already been hashed with salt on clientside) with different salt. This salt can be known or not; it doesn't really matter. The passphrase stored in the database will be the doubly salted-hashed password (once on client, once on server.) So, let's say the entire contents of the database is read by an attacker. That means they can access any account they want, right?

Wrong. Read-only access buys the attacker NOTHING, assuming it is a strong password. (I do not care about protecting weak passwords that can be cracked with brute force here.) He needs the pre-hash value in order to log into an arbitrary account. If he tries to use the server-hashed version of the password (which is the only one permanently stored on disk), it will be hashed AGAIN by the server before it is compared to the one in the database, and thus will not match. So, the attacker has to do more than just access the database; he has to either be able to write to it (to overwrite the server-hashed value with something of his own choosing, which should have the undesirable side effect of spoiling database integrity checks and locking the rightful owner out of his/her own account, thus raising the alarm) or he needs to be able to intercept the pre-server hashed password in memory, since the pre-server hashed password should never be written to disk.

Re:Cognitive Load

[Shane_Optima]

I know I earlier said that I wouldn't mind seeing this implemented in JS, but on reflection I think this should become a deep and universal standard such that it is handled by a special api call to the browser itself. Thus, only a compromise of the browser itself (and not merely the website) should reveal the original plaintext password. All secure password fields should be colored or highlighted by the browser in an un-spoofable way by the browser. However, I still believe that even a JS implementation (assuming the site in question already requires JS) would be an improvement over the status quo for auditing and reduced attack surface reasons, though a server-side hash should always been used to reduce the usefulness of database breaches (see my reply to wagnerrp below for a full description of how that should work.)

(Speaking of unspoofable GUIs, Joanna Rutkowska, the lead dev for Qubes, has some interesting ideas about display security and points out that for all of its flaws, Windows 7's UAC actually is superior to most implementations of sudo on Linux because the display-darkening prompt is much harder to spoof and doesn't reveal a superuser password even if it is spoofed.)

Re:Cognitive Load

[Shane_Optima]

And once again, I'm only talking about protecting good passwords. Protecting bad passwords that can be broken by brute force is impossible without introducing another verification system that essentially replaces the password as the main point of failure, but it becomes much easier to convince users to use good passwords if we can allow them to reuse them (and also not have to change them every month.)

Re:Cognitive Load

[Shane_Optima]

Aww comeon, give this one more +1 funny! I was hoping for a reply like this.

Re:Cognitive Load

[cthulhu11]

Agreed. And when somewhere that 1password isn't available or working, you're screwed. BOA bought Merrill Lynch a while back, and enforced a *weaker* password than I had been using. How perverse is that?

Re:Cognitive Load

[Shane_Optima]

Actually I should clarify the salt used for the serverside hash doesn't offer much except:

1. Protection vs. precomputed rainbow tables (brute forcing the hash will be slower, which buys you some extra time if a password is moderately weak. Since in my scheme the client-side salt will be known--for ease of use and portability reasons--it would be ideal if the server-side salt was not known in advance.)

2. Protection vs. an improperly salted (or otherwise improperly executed) client hash.

I'm specifically talking about the salt for the server-side hash. You still need the server hash regardless (for the access-denying reasons I described, which obviously won't be doable with client hashing because you can't trust a client run by the attacker to perform the hash properly), but in the presence of a competent client-side salt and hash then #1 is the only benefit provided... but since users can't be expected to provide bulletproof passphrases, it's one that's well worth having. A password like "!unic0rn73" will certainly be crackable with any decent behavioral-aware dictionary attack, but if you remove the possibility of rainbow tables then it may take considerably longer for anyone who doesn't have access to a powerful computing cluster.

Just a detail that was nagging at me; I wanted to clarify the precise roll of both salts: The client pre-hash salt is primarily for minimizing collateral damage from using the password with other sites; the server pre-hash salt is for minimizing the value of a database breach and increasing the amount of time dictionary attacks would take (thus giving them more time to detect the intrusion and giving the users more time to change their weak passwords.)

Re:Cognitive Load

[peawormsworth]

how can they verify that Apple99 and Opera56 both have a "p" as the second character, unless they stored "Apple99" in plaintext somewhere?

The user is prompted for the new password and also the original password to verify against the stored hash that they are the owner of the original and consent to the new password change.

It's not my system. But this is how it can be done without storing old passwords.

Re:Cognitive Load

[wagnerrp]

Client-side hashing only protects the password if the content server itself has been fully compromised, in which case none of it matters, because the server is compromised and they have full access to everything. They don't need your password any longer. The only value there would be to knowing your password at that point would be if you had reused it on other sites, that they could in turn access.

What could owners and servers do?

[AHuxley]

Encrypt all data on their own end? If staff walk away with data or someone enters the network, nothing useful can be fully recovered?
The site works with the username and weak password on creation to ensure better server side protection against plain text walk outs, usable network data loss or buying into cheap "standard" reversible cryto?
Could an extra layer of security be added to data on an network, during storage and real time use be added?
Expecting users to change habits and still enjoy a site is a big ask, what could owners and admins code in to help?
No more walk outs, no more bulk plain text data left on any internal or internet facing server for years?

uh

[Anonymous Coward]

wasn't there just an article on the front page saying that using a variety of different passwords, and changing them often, is a less secure approach to passwords?

Complex Passwords

[darkain]

Or maybe the complex passwords *ARE* the problem. Who the hell can remember 100 different complex passwords?

Repeat after me: TWO FACTOR AUTHENTICATION!

Use a simple password and an authenticator that produces a one-time password.

Re:Complex Passwords

[Anonymous Coward]

Who the hell can remember 100 different complex passwords?

The little 79 cent notebook I keep in my desk drawer can. Like most people I'm not important enough for someone to do both a digital attack and physically break into my house, so it works pretty darned well for securely keeping a large number of unique passwords. It is immune to digital attacks, and it is unlikely a random burglar is going to care much about a small esoteric notebook when there are much more valuable items lying right next to it, so I'd say it works pretty well. It's dead simple: site, username, password. Safe, secure, cheap, easy. Sometimes the best tech is old tech.

Re:Complex Passwords

[joe_frisch]

two factor authentication is great when done correctly, worse than useless when done poorly.

"security questions" are not 2 factor authentication. They are just low entropy passwords.

If 2 factor includes a device, then there needs to be some way to authenticate if that device is stolen when you are in a remote location. That of course also breaks the concept - but what is the alternative?

Bio-metrics can work if they can be made sufficiently reliable,

Re:Complex Passwords

[d0ran$]

This works for me:
1. Don't bother to remember or write down password.
2. Get the application to send me a password reset.
3. Change the password to some long random thing.
4. Login do my stuff
5. Logout, rinse, repeat.

Pros:
Don't need to remember password.
Password can be long and complex.
Kind of like 2 factor auth.

Cons:
Works only for places that provide password reset (who doesn't?)

Re:Complex Passwords

[Zumbs]

If 2 factor includes a device, then there needs to be some way to authenticate if that device is stolen when you are in a remote location.

Another horrible version of 2 factor authentication is when the device is a smart phone that you are using to log onto the service in question.

Re:Complex Passwords

[Anonymous Coward]

Same here, but I am a bit paranoid so I scramble the passwords just enough that I can easily figure out what I did in a decade or two.

Re:Complex Passwords

[Anonymous Coward]

Who the hell can remember 100 different complex passwords?

Me. This is a solved problem.

Re:Complex Passwords

[Anonymous Coward]

Security questions do nothing but narrow the number of people involved in hacking my account to people who know my dog's name.

Re:Complex Passwords

[Opportunist]

Like, say, text message transaction codes sent to a smartphone used to do online banking.

And please don't think nobody would be stupid enough to do that.

Re:Complex Passwords

[AmiMoJo]

Smart phones are at least somewhat secure, if you bother to set a good password.

Even fingerprints with enough to defeat most thieves, not that many of them will be bothering to log in to your email on the off chance there is something useful there. They will try to wipe and dispose of the phone as quickly as possible.

Re:Complex Passwords

[Opportunist]

Chances are good that you're as creative as 99% of the pet owners out there and picked the name for your pooch from a rather small pool of possible choices.

Re:Complex Passwords

[Opportunist]

That's pretty much what someone did at an office I worked before.

They had a system where someone could call IT to say they forgot their password, which resulted in their account being locked and a new password was generated. What this person did was to call IT as the last thing before he went home, said he forgot his PW, had his account locked, then next morning he would show up, pick up his password "for the day", enter it, shredder the paper it was printed on, do his stuff, call IT at noon with a lost password...

He pretty much got away with it because he had the agreement with IT that they wouldn't cause a stir and he won't tell anyone about his trick to avoid memorizing passwords with ridiculous requirements.

Re:Complex Passwords

[Anonymous Coward]

Until that is compromised.

Re:Complex Passwords

[Anonymous Coward]

So then the you use a simple password for your banking and another simple password for the porn forum you frequent, and combine both with the same authenticator. What prevents the porn forum from trying a few logins at the bank in the background?

Re:Complex Passwords

[Anonymous Coward]

Who the hell can remember 100 different simple passwords?

Re:Complex Passwords

[Anonymous Coward]

Or just keep using the "I lost my password" options:
https://medium.com/@olivier_83243/the-passwordless-approach-securing-access-to-genetic-data-5099c1fae3c#.tgerbf2v5

Re:Complex Passwords

[Anonymous Coward]

That just converts the problem from remembering 100 passwords to carrying 100 authenticators.

Re:Complex Passwords

[Anonymous Coward]

Maybe the authenticator?

Re:Complex Passwords

[Anonymous Coward]

Smart phones are at least somewhat secure, if you bother to set a good password.

Wow. I consider my smart phone to be, BY FAR my #1 least secure machine.

I didn't install it. I don't know if South Korea or China (or even US) backdoored it.

But I do know the software is crappy, poorly maintained, and infrequently updated.

I also know it has powerful networking capabilities. And one of the networks that it can use (e.g. the cell one) and has the easiest time connecting to, is tightly regulated to make it illegal for it to be secure.

It's also small and portable, so it's probably the second-easiest type of PC to lose or have stolen.

It's hard to do worse, overall, than a smartphone. I don't think anyone has. Maybe you can find some Windows 98 machine out there that is more compromised, but a smartphone will at least put up a good fight to retain the title.

Password fatigue

[Anonymous Coward]

Look no further than the simple explanation: Password fatigue.

It's not uncommon in a large employer to have 6-10 passwords to different systems, all with different rules. And they change every 30-60 days.

Naturally, this causes users to write them down, sometimes on stickies under their keyboard (agh), sometimes on the stickies program on their frickin desktop (ARGH).

Rather than lamenting this obvious fact, it's time we change standards to recognize what REALLY happens, instead of what SHOULD happen. (Reference: Speed limits, and the real effects. Yes yes, if everyone followed the law exactly, blah blah blah blah. Only stupid or young engineers insist on following this paradigm, completely ignoring the reality.)

Re:Password fatigue

[networkBoy]

going to do a quick count of how many pwds I deal with at work: ...
49.
I have 49 separate pwds I need to know to do my job.
of those *several* are in a one-note file that is on a secure server so others with the same need to know can remain synchronized.
Three or four of these also require a SecurID or similar token.
Only two are committed to memory.

nb

Bad habits are forced

[ArtemaOne]

I often come up with nice long passwords that would take decades to crack, but the system wont let me, so I end up with some sort of keyboard pattern that *gasp* shockingly get repeated with shift held down to double the characters and this allows the minimum number and symbol count. If they removed the stupid rules, we could use good passwords.

Re:Bad habits are forced

[PingSpike]

Paypal, the assholes, only allow 20 characters max. Apparently they were running out of bits and have to save money somewhere. Anyway, that's not the aggravating part. The aggravating part is when you enter the password, it just truncates to 20 without telling you. Then you go to log in with the password you just set and find it doesn't work. It doesn't work because you've entered to many characters, but it lets you enter them when setting the password...it just throws the extras away and performs the set! But when you go to log in, it DOESN'T throw the extra away and fails the login.

A password should NOT contain a mix of characters

[FeelGood314]

A good password is hard for a computer to guess and easy for a human to remember and enter. That is the only metric we should be using for passwords. Screw the 100 different sites and work logins that expect me to have a different password for each. I have a couple of sites that I value enough to use secure passwords on, the rest Password1! is good enough.

Work policies that require 8 characters, 1 upper, 1 lower, a number, a symbol and change every 3 months are guaranteed to result in everyone eventually adopting Common1! where Common is any common 6 letter word and the number 1 increments every 3 months.

It's very simple

[Brett Buck]

A password is intended to ALLOW access. If I come up with random "complex" passwords, I will either have to write them down, or use some sort of passwords safe, because they are intrinsically not "mnemonic". For many things I just don't care very mush, and I have to have dozens to hundreds of new passwords a year.

      There has to be a compromise between security and functionality, and people are making that compromise.

Re:It's very simple

[Anonymous Coward]

A password is intended to ALLOW access.....

No; a password is intended to PREVENT access (to those without the password). If all you wanted to do was allow access, there'd be no password, just a username.

Re:It's very simple

[Anonymous Coward]

Last time I bothered counting I had precisely 56 accounts requiring passwords. That was a year ago, so the number will have grown wince. With "good practice" that's 56+ distinct passwords, all at least, say, 10 characters minimum, no words, with numbers and symbols. Presumably changing every 6-12 months.

Now I'm a nerd with a very good memory, but *no-one* can reliably remember that many passwords. It's just not possible. Hence the problem.

Re:It's very simple

[Anonymous Coward]

I have a couple of passwords from /dev/random I use for important stuff. (Yes, I use some of them for multiple things.) One of them was a ten-character random password I got for registering for an online game back in 2001.

I initially write them down, but it's wonders what muscle memory can do after a few weeks of practice.

passwords are a burden

[Gravis Zero]

It's quite simple, remembering passwords is a mental burden that you rarely find anywhere else in life. For our possessions, we have physical keys that provide weak security and we expect law enforcement to ensure a violation of that weak security and our insurance companies to replace our losses. The closest thing in real life is remembering people's names and there is a common set of names people have that are phonetic as well. If you want to solve the password issue, people need a physical object (a key) that will authenticate them. We will all carry a key like this and once again rely on our weak physical security which requires physical proximity to undermine.

Re:passwords are a burden

[Anonymous Coward]

...we expect law enforcement to ensure a violation of that weak security...

Thanks to more people catching them on film, there are certain unjust actions we've come to expect of law enforcement, but ensuring they violate our locks isn't among them.

Re:passwords are a burden

[AmiMoJo]

Phones make good keys. They have multiple layers of security (physical, then an unlock code or fingerprint), the good ones are encrypted by default and everyone carries them anyway.

Computers should have NFC pads so they can do a secure challenge/response kind of thing when logging in to sites, like how mobile payments work.

Not as big an issue as poor password POLICIES

[Shane_Optima]

I recently lost an email account I've had since I was twelve apparently due to one of the eBay breeches. Yes, I used the same password for both (never got around to changing them after I made the transition to randomized passwords) so it's my fault, right?

How about great big "fuck you" instead? How about a wall of shame for every website that does not hash passwords, with salt, prior to transmission over the internet? This is kiddy level shit here. The slowest smartphone in the world should be able to do this in its sleep.

And the majority of sites still have incredibly stupid password policies, almost all forcing you to use special characters and numbers instead of long passphrases which, if properly constructed (such as via dicewords), can be considerably more secure than the average "unicorn16!" type password. Some sites even impose a ridiculous maximum length policy, and some sites also forbid certain special characters, probably for some horribly depressing reason like they can't be bothered to make sure the password field can't be used for SQL injection or overflow attacks.

Work passwords aren't much better. The constant changing is completely pointless; everyone either uses a very simple incrementing number system (often tied to the current month) or they use Post-Its. A sane alternative would be to track logins and alert the user and/or security admins of unusual times or locations and to use keyfiles on smartcards or regular USB drives.

I've checked the literature and these ridiculous practices are still being taught to people studying for CompTIA certifications. Can't someone please... I don't know, do something about this? Can't we have some industry leaders say that they're no longer recognizing CompTIA Security+ or Network+ certifications as worth anything? This shit has been going on for far too long, and in an effort to made up for their shitty password infrastructure many places are adopting painfully annoying supplementary security systems.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

I forgot to include the obligatory xkcd on dicewords: https://xkcd.com/936/

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

*breaches. In before the pantaloons wisecrack.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

How about a wall of shame for every website that does not hash passwords, with salt, prior to transmission over the internet?

I saw this same argument the other day on slashdot. There are a few reasons why not;

1) It explicitly requires JavaScript on the client browser to be enabled.
2) Where do we store the salt? On the server? Well, that means we have salt+hash on the server which is what you wanted to replace in the first place (we'd also need to send it back to you without really knowing who you are, which doesn't seem secure). So we'll store it on the client! Which means it will be unique to the browser. Sucks to be you if you ever want to log in from a different device or clear your cookies, your password wont be valid.
3) Since we can never really trust that the client is actually doing what it should be doing - it may well still just be sending us a plaintext password - to be secure we're still gonna have to salt and hash it on the server anyway.
4) Hopefully the above points demonstrate that the security gains are, realistically, utterly minimal if salting/hashing is done server side PROPERLY. Sure, ebay wouldn't have lost your password if they followed this scheme (usability be damned of course) but likewise they wouldn't have if they were salting/hashing server side in the first place.

Lastly, I find it difficult to be sympathetic to someone who never changed his email password since they were twelve. What was the point in transitioning to a randomized password if you used it everywhere? Here's the golden rule of internet security: Your email account is the single most important account you have. Make sure the password is totally unique and don't reuse it. EVER. You don't need to change it often but COMMIT it to memory and DON'T write it down.

Everything else can be crap. Use a password manager for those if you care. Stick to hunter123 if you don't.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

1) It explicitly requires JavaScript on the client browser to be enabled. 2) Where do we store the salt? On the server? Well, that means we have salt+hash on the server which is what you wanted to replace in the first place (we'd also need to send it back to you without really knowing who you are, which doesn't seem secure). So we'll store it on the client! Which means it will be unique to the browser. Sucks to be you if you ever want to log in from a different device or clear your cookies, your password wont be valid. 3) Since we can never really trust that the client is actually doing what it should be doing - it may well still just be sending us a plaintext password - to be secure we're still gonna have to salt and hash it on the server anyway. 4) Hopefully the above points demonstrate that the security gains are, realistically, utterly minimal if salting/hashing is done server side PROPERLY. Sure, ebay wouldn't have lost your password if they followed this scheme (usability be damned of course) but likewise they wouldn't have if they were salting/hashing server side in the first place.

1. I'll take that risk. Better yet, get one third party source to provide the script and box for everyone and I'll whitelist only that source in uBlock. Better yet, put this in HTML6 or something. Implement some highly specific DSL stuff that hopefully can't be exploited. (Protip: Offer $100k reward during draft phase to the first one to publish an exploit.)

2. Storing it on the server is fine. You obviously need some salting, prior to it being stored in the database, or else a break-in would be trivial with a stolen hash (just modify the client side JS.) But the salt doesn't need to be kept a secret--that's the great part about (some uses of) salt.

3. Uh, no. That's dumb. The server just stores the salt. The server doesn't perform the hash. If the client is responsible for the hash then it makes it easy to audit and make sure they aren't screwing you over. If someone gets infected with something that stealthily replaces the site's JS with some other JS that doesn't properly hash it... well, if an attacker can do that then there are a lot of very nasty things they can do anyway, and having the server do your hashing for you isn't going to change anything. Use HTTPS and pay attention to your certificates, but that has nothing to do with what I'm talking about here.

4. No. Heck, the server doesn't even need to store the salt--the salt can be the root domain name--ebay.com. Years ago, I was tempted to write a browser extension that would do just this... but it seemed like a fair bit of effort to do it properly and I never got around to it.

Lastly, I find it difficult to be sympathetic to someone who never changed his email password since they were twelve. What was the point in transitioning to a randomized password if you used it everywhere?

I didn't say that. The email account had its password changed several times over the years, and the last password I'd changed it to was very secure and wasn't used for anything other than other important accounts, not random forum stuff. I let myself slack off changing it to something unique (and totally random, although what I had was very strong) for that very reason, since all of my bank accounts and such were by then changed to something unique and at the time the breach happened there were only a couple big name accounts (but not the ones I generally used a lot) that still shared that same robust (but shared) password.

Here's the golden rule of internet security: Your email account is the single most important account you have.

It wasn't my main email account any more, but there was a lot of legacy and nostalgic stuff of lesser importance that I didn't yet have the time to manually transfer over to the new address. Do you have kids? You sound a tiny bit like someone who does not have kids.

You don't need to c

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

does not hash passwords, with salt, prior to transmission over the internet?

Why reinvent the wheel when you're already using HTTPS.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

-the salt can be the root domain name--ebay.com.

A single site-wide salt greatly reduces the effectiveness of salting passwords.

Salting passwords is primarily a defense against rainbow tables - precomputed password hashes. While a domain-specific salt does mean that an attacker can't use a general rainbow table against your stolen database, it does mean that it is possible to make a domain-specific rainbow table. (An attacker might not bother for the 1000 members of Gary's cross-stich blog, but if they get their hands on the complete Ebay password database? Hell, yeah, they're putting in the effort.)

Which means *everyone* who uses any of the most common passwords gets cracked pretty much instantly, as the attackers can easily see that 1) they all share the same hash and 2) it matches the (just computed) hashes for these common passwords.

To make salting actually work, you need per-account salts. This way the attacker needs to crack each account individually. True, you don't *really* need random salts - as long as the salt is unique to 1) your login and 2) each user. A simple deterministic function of the user name and domain works decently.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

To clarify 2-4, which I mangled a bit (it's 9am, so sue me), yes you can and should have the server do its own private hash because that brings a few advantages to the table, particularly in the rather obvious case of using a stolen hash with the very site you stole it from; however, overall the client side hash is much more important for the basic reason that the client is already trusted. It HAS to be trusted. And if the only practical way to standardize such a system is through JS, then that's a small price to pay, and those scripts can be whitelisted. If you hate JS to the point of not even being willing to whitelist stuff using extensions... well, good luck with that.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

Seems you have a fundamental misunderstanding of what a salt is and what it is supposed to do. With your... recommendation of just using 'ebay.com' as the salt I can only say I seriously hope you are not in charge of secure web development somewhere important. This ignorance is exactly why passwords get pwned from breaches like the ebay one despite being hashed. Salts need to unique per user or you may as well not use one.

I'd go into more depth with some of the other points, but at this stage it seems pretty moot. Ultimately, you've overlooked numerous usability shortcomings, introduced subtle security holes and added a mountain of additional complexity for imaginary gain.

I don't wish to be cruel but essentially your entire suggestion boils down to "I want websites to protect me from myself because I'm lazy and want to use the same password everywhere". Which they actually do - if they're hashing stuff correctly.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

2) Where do we store the salt? On the server? Well, that means we have salt+hash on the server which is what you wanted to replace in the first place (we'd also need to send it back to you without really knowing who you are, which doesn't seem secure).

Furthermore, you cannot add pepper to passwords this way.

Assume the hashing goes this way:

hash_function(password || user-specific salt || application-specific pepper)

You can get the user's salt and hashed password with an SQL injection, but the pepper is not inside the database but stored inside the application's configuration files, and requires a more thorough hack to get.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

Seems you have a fundamental misunderstanding of what a salt is and what it is supposed to do. With your... recommendation of just using 'ebay.com', all I can say is this ignorance is exactly why passwords get pwned from breaches like the ebay one despite being hashed. Salts need to unique per user or you may as well not use one.

I'd go into more depth with some of the other points, but at this stage it seems pretty moot. Ultimately, you've overlooked numerous usability shortcomings, introduced subtle security holes (e.g. account enumeration in the server-side salt scenario) and complexity for imaginary gain.

I don't wish to be cruel but this is why web security is such a goddamn mess. Security 'experts' with half-baked ideas based on misconfigured technical implementations.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

Seems you have a fundamental misunderstanding of what a salt is and what it is supposed to do. With your... recommendation of just using 'ebay.com', all I can say is this ignorance is exactly why passwords get pwned from breaches like the ebay one despite being hashed. Salts need to unique per user or you may as well not use one.

I'd go into more depth with some of the other points, but at this stage it seems pretty moot. Ultimately, you've overlooked numerous usability shortcomings, introduced subtle security holes (e.g. account enumeration in the server-side salt scenario) and complexity for imaginary gain.

I don't wish to be cruel but this is why web security is such a goddamn mess. Security 'experts' with half-baked ideas based on misconfigured technical implementations. Your suggestion will never be 'more' secure than correctly implemented hashing/salting on the server. At best it may come close to it. But as a web dev, I know where I'd rather put my trust (never the client) and I know which version I'd rather maintain.

Re:Not as big an issue as poor password POLICIES

[Junta]

Note I *think* he's saying that whatever string the client ultimately sends to the server should still be one-way crypted and salted in the usual way. Meaning a compromise of the database still has reasonable protection.

He wants something to automagically take his password and make it unique per site so he doesn't have to remember them all. Note that this is what things like the extension Hashpass do, generate a site specific password derived from your master password and transformed for the site.

Of course, all this said, the dictionary attack required involves just adding that transform, hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts, and your password would be secure against dictionary attacks offline. It makes zero sense as part of a websites arsenal against attacks.

Re:Not as big an issue as poor password POLICIES

[Junta]

So there exists a browser extension to implement what you desire, it is called HashPass.

However, if you use such a strategy, you *still* must have a password resilient to dictionary attacks. The attack scenario it provides *some* protection against is if you use a site that has poor security storage policies, without your knowledge (e.g. stored in clear text). The idea is that if such a crappy site gets compromised, it's view of plain text password is the end result of your client side salt, which now can be run against a dictionary attack. It basically is ensuring that *someone* is doing a secure hashing strategy that would reasonably protect a strong password in the manner the server side *should* be doing anyway.

If an otherwise secure site adds what you describe, it would do nothing to enhance security. If your password is *truly* strong and they employ proper salting and one way hash strategy (scrypt, PBKDF with adequate passes, what have you), then a leak of their password database is not actually that big a risk. If your password is weak, then the salting strategy client side doesn't add anything, as they could modify their brute force attack to do the client transform in a trivial fashion, and they can work their way back to the password you *really* use.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

The salting/hashing cannot, CANNOT, be done client side, if it is, then the hash simply becomes the password, and the salting/hashing has accomplished NOTHING.

The password must be transmitted (encrypted) to the server, then the server must do the hashing (and might as well do the salting too, since there is no need to send the salt out), then the comparison is done with the salted/hashed database entry.

If you did the hash client side, then a miscreant with the salted-hash database can simply send the salted-hash and gain entry. I suppose that you could salt/hash the password twice, once client side and once server side, but that still allows for capture of the once hashed password, which is what they need to send to get in. The secrete token (password) MUST be sent encrypted, because it must be the same every time you use it, but not the same when in transit.

The only known method to send a message that must be fixed at both ends, but must be different every time it transits is encryption.

A better solution would be an authentication token, which signed a nonce with the private key so the server can check the nonce with the public key, but that is again encryption.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

Definitely have to post AC here. This is one of those situations where I really don't like for people to know where I work, because while I love the place in some ways, there are a handful of embarrassments like what I'm about to tell you about.

Can't someone please... I don't know, do something about this?

No.

Our site stores passwords in plaintext. I noticed this when I first started working here many years ago. It's an easy thing to fix. Fixing it is still unapproved. Fixing it isn't going to make us money.

We know the database has been taken many times. We know the passwords therein have been used. We know every account's email address is now forever on spammers' list of valid targets. We know that some of our own employees' passwords on our site, thanks to reuse, have been used to log into our own mailserver and send spam. We know our mailserver has been occasionally temporarily blacklisted because of this, interfering with both routine business and new-client marketing. It's inconceivable that the same email+password combos haven't been tried everywhere else. They bothered with our SMTP server, so they'll bother plenty of other places.

It has had horrible, obviously-foreseeable consequences, and yet, our current policy is that we want to not fix the problem. And there is nothing I can do about that. Telling me "fix it" will not increase the probability of us fixing it. I already know I need to fix it. Fixing it is priority #1, but the job is paused, apparently forever. Telling me "fuck you" won't do anything either.

Here's the bigger picture: if it happened here, it happens other places, everywhere. Whatever our stupidity, I guarantee you it isn't unique. And even if I am some day allowed to fix it, you still have to assume the problem is still out there, and my counterpart in some other company is still waiting for his even more absurd block to get lifted.

Ergo, hoping the problem gets fixed isn't a realistic option. Everyone needs deal with a world where password policies simply suck and can't be made to not suck. That is the immutable environment, and your job is to adapt to it. You can't change it; you have to change you.

You didn't. You know people are stupid, or inflexible, and oftentimes broken things remain broken. What are you going to do with this knowledge? Live in denial and re-use passwords?

I used the same password for both (never got around to changing them after I made the transition to randomized passwords) so it's my fault, right?

Thinking in terms of whose fault it is, can be interesting but it not going to lead you to good personal strategies. I'm not saying you're wrong that "fuck you!" is applicable, but it doesn't address the problem. Tell me "fuck you" if it makes you feel better, but also: ADAPT TO REALITY. Got it? Adapt to reality, and then we can bicker and argue about who killed who.

Re:Not as big an issue as poor password POLICIES

[Jamie Lokier]

Good points.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

"How about a wall of shame for every website that does not hash passwords, with salt, prior to transmission over the internet?"

If you hash passwords with salt prior to transmission, then you have to store the plaintext password on the server. Otherwise, there is no way to verify the hash.

As Junta has already suggested, encrypting the password with public key crypto prior to transmission may give you the effect you desire. Sending a plaintext password over https also achieves a similar result.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

Can't someone please... I don't know, do something about this? Can't we have some industry leaders say that they're no longer recognizing CompTIA Security+ or Network+ certifications as worth anything?

Unfortunately, it is a "tragedy of the commons" style problem, where the benefit of the group is against the benefit of the individual. Nobody will do this, because it sticks their neck out for almost no gain.

Let's assume for a second that there is a stupid password practice which does no good (e.g. "it is best practice to force users to start a password with the character '1'"). If somebody pushes back ("CIO of Google says they will no longer be following this procedure"), they will gain almost no benefit. Then, if they get coincidentally breeched, they will need to go to court, congress, and/or the media and explain "why were you not following best practices?" That's not even considering the fact that by being publically visible, you are drawing attention to yourself, which makes hackers more likely to target you.

It's the same reason why the DHS threat warning level never goes below orange... why wants to be the person to signal it as green, but then something bad coincidentally happens?

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

As per my little sob story, I am talking about protecting GOOD passwords from discovery (and thus allowing their safe refuse), nothing more. And I specifically said I was much more interested in client-side salt (although there is an argument for server-side as well.)

This was about good passphrases, not bad ones. If you don't understand how using a cryptographically secure hash function with salt (even known salt) accomplishes this goal, then "I am sorry" but you do not understand the first thing about cryptography.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

No. Look, this MIGHT be a confusion of terms (there's something called a "nonce", for instance, that's like salt but used in a different way. And then there are IVs...), but the fact is it's OK if the salt is known--as per my sob story, I'm talking only about protecting good passphrases, not bad ones. Bad passphrases can only be protected with what I usually term a "keyfile", which should be guarded the same way that the password is guarded, but you can achieve quite a lot with known salt hashing on both client and server sides.

By good passphrase, I mean one that can survive all brute force attacks using all of the common known behavioral tricks.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

Because it allows the safe reuse of a GOOD passphrase (not a bad one) on multiple sites without a reduction in security--if one site is compromised, it doesn't take down the rest.

HTTPS serves a different purpose.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

Holy crap. The ignorant ACs are really out in force today. I don't mean to be unpleasant, it's just... depressing.

The salted hash is to prevent a GOOD password from being discovered even if a site is compromised. If that same GOOD password is being used with a different site (and thus with a different salt, but all salts and the hash algorithm can be entirely known to the attacker) then the attacker can... what? Good cryptographically secure hashes are one-way things. He can't use the stolen hashed passphrase to retrieve your original passphrase, which is he needs in order to re-salt/hash it for the different (unbreached) site.

I'm not concerned with protecting bad passwords that can be cracked. Go use a secret keyfile if you want to protect your bad password.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

No, he is completely wrong. Salted client-side hash would have completely prevented my email account breach, because the passphrase in question was a good one. Pre-computed rainbow tables do not help you crack a *good* passphrase. The whole point of my scheme is to prevent a stolen password from being used with an account on another website, utilizing a transparent system requiring no active work on the part of anyone.

Protecting *bad* passphrases from being discovered is completely beyond the purview of my scheme and is ultimately impossible to do without requiring the user to do something different ("you can't fix stupid.")

There's also an argument for the server doing its own hashing (and not permanently storing the pre-server-hashed passphrase it receives), since this would prevent certain types of database breaches from immediately translating into full account access.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

No, no no no no no.

You store the salted-hashed password on the server. The server never gets to know your "real" password.

Your "real" password, if it's a good one (i.e. long and unusual enough to resist the cleverist brute force cracking systems out there), can be freely reused with any website you wish (as long as all websites use this scheme) and each site breach will be completely contained--knowing your hashed version on site A doesn't get the attacker anywhere with site B, because a completely different salt was used. It doesn't matter that both salts are publicly known; that doesn't make reverse engineering easy if the password is strong and the hashing algorithm a sound one.

Sending a plaintext password over https also achieves a similar result.

Am I really that bad of a storyteller or are you people really that ignorant about crypto? Jesus fucking Christ...

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

Well, this is something that can be easily verified on the user's end. So there remains a glimmer of hope that with enough fuck yous and making noise that people could be shamed into adopting at least a client-side fix (there are important server-side bits as well, but we have to take your word for those things.)

The other possibly, that I'm currently thinking very hard about, is to write a suite of free (with premium upgrades and management available) tools to allow the users to add this layer themselves. I'm currently not sure the free version can be made interesting enough or easy enough for most people to bother with (especially vs. the solution of just having random passwords for everything and storing it in an existing password manager), and the premium versions, while interesting, could only accomplish so much without the user actually trusting them with all their passwords, which isn't a general trend I would like to see in the realm of computer security.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

I'm not sure how many different ways I can say this, but here goes: "I don't wish to be cruel, but you really should take the time to understand how cryptographically secure hashing works, and also maybe re-read the specifics of my issue." It was a good, strong passphrase. If I had two client side hashed versions of this passphrase, one with "ebay.com" and the other with the email provider, and I sent each to the appropriate server to act as my server-stored passwords... please, explain to me exactly how an eBay breach could result in my email being collateral damage?

Answer: It can't happen without a massive break in the hashing algorithm. And the fact that this could be all client-side means it's very easy to spot weak or cheating implementations. It could also mean that someone could write a browser extension to do it without the cooperation of the sites, but since it seems like the majority of people here don't even understand how a known salt hash could help, I'm a bit pessimistic about the prospects of it attracting a decent-sized user base.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

Yes, that. I thought that was clear enough, particularly after I elaborated on some of the details, but about seventy ACs seemed to misunderstand entirely.

Also, it's good to know that such a browser extension already exists, although there's no excuse whatsoever for websites not doing this on their own unless they have some good reason for wanting zero client-side scripting (which obviously excludes almost everyone on the web today, including eBay and most webmail.)

This is about protecting good passwords, not bad ones. My password was strong and long enough to resist even a very clever dictionary attack run on very powerful machines.

hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts

"Only" ?? Uh, this is ebay we're talking about here, and they're not alone. It happened to some other big names. It happened to Ubuntu Forums a while back. I recently saw confirmation that our ISP (a name you would recognize) uses plaintext password storage. it appears that the industry standard practice with websites is to use plaintext password storage. Am I wrong?

It makes zero sense as part of a websites arsenal against attacks.

Well, first off it makes sense because you, the client side guy, can fix things even if the backend guy can't/won't. More importantly, it's important because it's user-visible and auditable, so everyone will know whether or not your site uses it. If enough of a stink can be raised--"Don't use gmail! They use incorrect security procedures that allow your password to be easily stolen and used on other websites! Use [x]mail instead." (this being the simplified version you tell non-technical people) then enough corporations might be pressured into adopting the standard to make it a de facto industry standard, at which point we can dispense with the canard that the user needs to memorize a different password for every single website they visit. In the future, any website not using a salted client side hash should prompt security alert emails, and your browser should give you big red popups strongly advising you against creating an account with the website (or at least to make sure to use a completely different password.)

There are slight negatives in the sense that the backend guys may no longer feel any need whatsoever to do further hashing (which would be unfortunate, since a server-side hash can prevent many database breaches from translating into instant account access), but I think on net this would be head and shoulders above the current situation, where casual users (people who aren't going to use special password management tools) are completely and totally fucked because there is no way they are going to be able to memorize a totally different and robust password for every site they use.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

Yes, I've since clarified ad nauseum that the password was a strong one. Protecting bad passwords is intrinsically impossible. You can use a keyfile but that's basically akin to having a strong password and then writing it down in notepad.

See my reply to your other email for my response on the "this wouldn't add to security." I think the big takeaway is it's visible and auditable and it would thus in principle be possible (with enough of an outcry) to force an industry standard to be adopted and aggressively shame and warn against sites that refuse to adopt it. "But we do it all perfect on our server!" just doesn't cut it, sorry. I. don't. believe. you.

You're also wrong to imply there's no theoretical advantage whatsoever to a client side hash. HTTPS is very important but successful attacks aren't unheardof. Client hashing would prevent collateral damage in such cases (assuming the client hash scripting runs and transmits correctly--I'm not talking about successful whole-website spoofing that uses a different script entirely.)

Furthermore, putting this on the client reduces the attack surface of the server, since only a website spoof would suffice (if you could only gain access to the back end, you would have no way of forcing it to start recording plaintext passwords if hashing were being done on the client.) I do support the idea of a second hash prior to database storage, but it doesn't and cannot replace the client hash stage.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

reply to your other post*. Sorry, 'email' on the brain. Nothing of vital importance was lost with either the eBay account or email address, mind, but there were thousands of nostalgic emails in there that I'll never see again, some of them from people I'll never see again.

It's annoying.

Re:Not as big an issue as poor password POLICIES

[Shane_Optima]

I'm not sure how many different ways I can say this, but here goes: "I don't wish to be cruel, but you really should take the time to understand how cryptographically secure hashing works, and also maybe re-read the specifics of my issue." It was a good, strong passphrase. If I had two client side hashed versions of this passphrase, one with "ebay.com" and the other with the email provider, and I sent each to the appropriate server to act as my server-stored passwords... please, explain to me exactly how an eBay breach could result in my email being collateral damage?

Answer: It can't happen without a massive break in the hashing algorithm. And the fact that this could be all client-side means it's very easy to spot weak or cheating implementations. It could also mean that someone could write a browser extension to do it without the cooperation of the sites, but since it seems like the majority of people here don't even understand how a known salt hash could help, I'm a bit pessimistic about the prospects of it attracting a decent-sized user base.

Re:Not as big an issue as poor password POLICIES

[Anonymous Coward]

You are describing a password manager/generator thing.

Re:Not as big an issue as poor password POLICIES

[Junta]

Client hashing would prevent collateral damage in such cases

No, it wouldn't. If the traffic is intercepted, then the fact that the data is the password straight or the result of a one-way hash is of little consequence to the attacker, since the target system takes the value verbatim. The server does not *know* that the user is using the blessed javascript implementation or html form. They are only able to take the submitted data at face value. If you use the result of a one-way hash as a password, then either way the password is known.

If you want to protect against interception in the event of defeating TLS, there must be some pre shared key component to it. Using the password as a pre-shared key is considered bad form as the frequent occurance of a leaked password database would cause cries of storing the password in plain text. Server side hash and salt is the only recognized strategy and deviating from that risks being crucified in the security world (trying to explain the subtleties of going off that is going to be a very uphill battle). So something like RSA, U2F, TOTP or similar supplementing a password in a two factor scheme is the generally accepted way to get both the benefit of an ultimately shared secret based approach and password protection.

Ultimately, as far as the *site* is concerned, server side is the most widely accepted strategy, and there's no value in terms of the security they provide in doing it both places. If you want to protect yourself, then HashPass will do that job, though a much more comprehensive approach is a master store of site unique passwords with no actual relationship between your passwords, and *that* would completely divorce your password in any sort of way from the site unique password, truly compartmentalizing an attack against one of your services.

Re:Not as big an issue as poor password POLICIES

[Junta]

I'm saying that *if* a site is competent enough to consider what you propose, it would be competent enough to do server side hashing. Hence a user should take ownership of how this is done to assure themselves, and *not* expect to audit every websites javascript implementation of their particular hashing scheme. So if you have a website, doing the right thing in the server is important. Doing additional things in the client doesn't really help if you've done the right backend stuff.

I think that's where we are deviating. I'm saying solutions like password managers and hashpass where the user *independently* has total control of the scheme make sense as a means of enforcing their sensibilities above and beyond what unknown methods the site is using. Solutions relying upon the javascript sent down by the site do not make sense as *those* guys have every reason to be able to do things right on the backend.

It doesn't dominate the news cycle.

[Anonymous Coward]

That's why most people don't care and don't change their behavior. Those of us with technical backgrounds are seeing this problem from a fundamentally different perspective that most people don't share.

Most people just don't care enough about this, that is the sad truth.

Re:A password should NOT contain a mix of characte

[Anonymous Coward]

Amen. One medical lab I must access patient reports from on a roughly monthly basis has the usual annoying password rules (upper case, lower case, number, punctuation), and forces me to change it every couple of months (no repeats). How the hell do they expect me to remember a seldom used password that changes almost every other time I use it? So it's incremental Keyword.## for me (I'm up to Keyword.32 as of this writing). Seriously, I've been forced to change my password to this site 32 goddamn times. End users will always find an easy hackable way around inconvenient password restrictions.

I do residential IT services...

[Applehu Akbar]

Because the biggest single problem my customers have is remembering passwords, the first thing I tell them is write them all down in a safe place. Everyone has a good place they can hide a sheet of paper.

I'm fully aware that a significant fraction of the password cheat sheets will end up taped to the monitor, but in my customer demographic the online threat and the physical breakin threat are totally disjoint. Even their laptops seldom leave the house.

But we do know what secure passwords

[Antique Geekmeister]

> Only five percent of respondents didn't know the characteristics of a secure password, with the majority of respondents understanding that passwords should contain uppercase and lowercase letters, numbers and symbols.

These requirements profoundly _discourage_ secure passwords. The difficulty of remembering them, and typing them well at a hidden password field, strongly encourage storage of passwords locally in cut&paste text windows or in local plaintext password storage. The current champion application for this security failure is AWS, which stores complex randomized alphanumeric strings which _no one_ can remember, forcing their default inclusion in plaintext local user fules or even hardcoded in saved wrapper scripts.

I'm afraid that robust password generation was much better explained and documented in an old XKCD cartoon, https://xkcd.com/936/

Obvious

[BlytheBowman]

Because people remember fidothedog or maybe f1d0th3d0g better than 656&+fDs9()x/\-

Re:Obvious

[h33t l4x0r]

All of which would be cracked in the Yahoo scenario. Come on people, it's like you're not even trying.

Is there really a paradox?

[Cochonou]

As written in the summary:

My personal favorite: password paradox. "The survey revealed that the majority of respondents understand that their digital behavior puts them at risk, but do not make efforts to change it," reports Help Net Security.

But among all the accounts that people have, how many of them are really worth of effort to reduce the hacking risk? I'd think a lot of people reuse the same passwords on many sites, because they do not really care if they are hacked on most of their accounts. Actually, this is kind of hinted at in TFA:

Additionally, consumers prioritize their password strength based on which accounts they believe need to be the most secure. Respondents indicated that they create the strongest passwords for financial (69 percent), followed by retail (43 percent), social media (31 percent) and entertainment (20 percent).

That would seem to indicate that if people reuse many passwords, they still don't use the same one for their bank and for facebook... It is strange the TFA asked people if they thought their accounts had values to hackers, but didn't go as far as asking the surveyed people what value they perceived themselves in their accounts.

Re:Is there really a paradox?

[Anonymous Coward]

Raises hand!
Strong password for banking, email and hard disk. For everyting else? Fuck them, I don't give a fuck if somebody else take over my on-line accounts.
It may help that my bank notifies me via SMS for every transaction :P

Re:Is there really a paradox?

[jbmartin6]

When I read "doing so while fully understanding the risk" I thought, where is the paradox? We make decisions like this all the time. There risk in simply getting up in the morning.

a crypto-token already in your wallet

[Anonymous Coward]

Every chip and pin credit card already has a crypto-token in it. The solution is literally in our pockets. It doesn't rely on the cell phone, or the cell phone battery being charged. It requires only a banking account. It's not a government-issued ID, and you're not restricted to one. It's adequately secure for banking, which is a pretty high bar. It can be used as an authenticated ID in every country that requires banks to identify their customers, and with a trivial amount of work, could also hold an anonymized token. And, requiringa PIN, it's quite secure against both physical compromise and keyboard sniffing.

The solution and the problem exists.

Re:a crypto-token already in your wallet

[locofungus]

In the UK for while we started getting little keypads - completely stand alone that you plugged your card into, entered the PIN, entered some other details (e.g. amount of transaction if necessary) and then got an 8 digit code back to use as a passcode.

Completely OS/browser agnostic.

Unfortunately, it never really took off. I think people just didn't find it convenient enough to have the keypad. Of course, had it taken off then people would have had multiple keypads and left one at work etc so they wouldn't have to carry them around. Also, of course, it was completely interchangeable between cards, so the business that paid to produce and distribute would have ended up subsidizing other businesses anti-fraud department.

I don't know whether something similar is possible now using a phone and near field communication with the card. But even if it is, I cannot see it taking off. The businesses that could do this are too concerned with locking customers into their app rather than getting together to solve a common problem in a common way.

Similar has happened with "smart meters" for electricity. We're in the middle of a national rollout (costing goodness knows how much) but change supplier and your smart meter will revert to a dumb meter.

Re:a crypto-token already in your wallet

[Anonymous Coward]

They can be copied. Not easy, but has been done. Something with more flexibility would be better.

It's great to get a lecture from someone dead wron

[chaboud]

Passwords should be long to be secure, and they should *allow* for upper and lower case, symbols, and numbers.

The key is length. A "complex" short password is easy to own and hard to remember. A "simple" long password is easy to remember and nearly impossible to own.

The only drawback is entry with limited input systems.

Re:The reason for risky password practices

[Anonymous Coward]

In the early '90, when you had one password for your email and that was it, password were useful. Now you are supposed to keep more than 30 different, complex passwords. Oh, and you should replace them every 3 months.

But, yeah, people follow risky password practices because of laziness. It's not because passwords are a simple, lazy way to implement authentication that has became unmanegable.

simple

[Anonymous Coward]

People are bone idle lazy tests,who think they can always pass the buck for their own laziness having consequences..
Simple..

If only

[Anonymous Coward]

There was some sort of cryptographic way to identify users. Like a certificate or something that was checked by a notary. Ahhh to hard I'll just implement complex passwords, hmmm users find my app to hard to log in I'll just relax this requirement a little.

Passwords shouldn't have to be good

[jopsen]

If servers would just be smart about always requiring a captcha for each additional login attempt, and limit amount of login attempts, email on failed login attempts, have timeouts between login attempts...
Well, then passwords don't have to be strong. This doesn't fix password reuse though :)

Re:Passwords shouldn't have to be good

[RogerWilco]

Most password cracking is done by stealing the database with the password hashes and then using some GPU based system to crunch those against known rainbow tables and some well known tricks people use to create passwords.

None of what you suggest would make any difference.

Re:Passwords shouldn't have to be good

[Junta]

crunch those against known rainbow tables

Note that this *also* would be a sign of an incompetent site. Password databases should be impervious to rainbow tables. Also, a GPU would not really be that useful for a rainbow table. A rainbow table is a precomputed table of hashes, meaning it's a straight lookup rather than actually having to perform the hash calculation. A competent site would have a sufficiently long random salt incorporated to render rainbow table impossible.

Of course, dictionary attacks against offline database are still a problem, and so it would be good if your password is not likely in the first 100 trillion or so guesses a system would make (which on a decently secured password database would buy you about a year of time against 8 full time GTX 1080s working on your password and your password alone).

Long story short

[wonkey_monkey]

Begin article.

Passwords are a chore to remember. People are lazy.

End article.

Bloody stupid article

[shilly]

The reason people re-use passwords is overwhelmingly because so many sites require them. A vanishingly small percentage of the population could realistically expect to remember what may be 100 or more passwords to manage all their online activities. The variations in password acceptance across all those sites is equally irritating ("Do not use special characters" "You must use at least one special character" "Password must be at least 8 characters" "Password must be exactly six characters" etc etc).

Re:A password should NOT contain a mix of characte

[shilly]

There are a number of sites I use infrequently, such as my pensions website, where I have to rely on password reset *every* *goddamn* *time*.

an excellent video about passwords

[hufter]

Password Cracking - Computerphile

Fuck your symbols

[Anonymous Coward]

A password's usefulness is in both its length uniqueness. |\|() @/\/\0V|\|+ 0F $`|'/\/\B0|_$ makes a password more secure, it just makes it frustrating to remember.

If a site puts any form of restriction on passwords, I don't bother using it. You want numbers, uppercase, and symbols? Well my password is now "Qwerty1!", congratulations, it's easier to hack than SlapTheDamselYouHooligan and harder to remember.

Re:A password should NOT contain a mix of characte

[serviscope_minor]

There are a number of sites I use infrequently, such as my pensions website, where I have to rely on password reset *every* *goddamn* *time*.

That's fine. Think of it as an ad-hoc form of authentication service. Instead of providing a password to prove who you are, they securely send a token to you via a trusted third party service (your email provider) which you then authorize.

Because the reset goes via that system, it's no less secure relying on it all the time than it is remembering the password. I actually explicitly use that method for some websites. I just generate a random password using:

head -c 10 /dev/random | base64

(The 10 characters ensures == at the end so you always get symbols), then paste it in and reset the password using the same mechanism 6 months later when I want to return.

Some websites have started getting with the program and as well as a full reset offer to send you a 1 time login link.

strong/weak accounts

[Anonymous Coward]

I think a typology of accounts is more relevant than this (quite speculative) typology of users.

Weak accounts: Most of my accounts are absolutely worthless to other people. I've only registered them because the stupid site forced me to have an account in order to post or view content. If Slashdot didn't have AC posting I would use a bugmenot clone or register throwaway accounts all the time, while taking great care not to establish identity, i.e. switch and share them, and keeping them as separate from strong accounts as possible. The password for those would be as weak as the site allows. If the site requires a "strong" password I write it on a postit and into an unprotected passwords.txt file.
Weak passwords are unrecoverable because the account was registered to a throwaway email address for spam/tracking protection.

Strong accounts: Anything to do with money, realname, personal data or authorities. Also sites where I want to establish longterm pseudonymous identity. Those would use a separate, secure browser with antitracking, HTTPS only, session cookies only. A strong account needs a strong, ideally random password. Strong passwords are too complex to remember more than one of them, so I need to use a password vault with one master password. Whenever I am away from the password vault, I use the "forgotten password" link.
Most important rule: Never write a strong password down, never give it to anybody. As soon as you entrust a password to another person or worse, to another site, consider it compromised.

Re:A password should NOT contain a mix of characte

[RogerWilco]

I have seen argued by experienced security professionals that any password that can be remembered is probably easy to crack with current CPU based systems.

A serious question

[Anonymous Coward]

I'm bummed that I have to post AC because I have no idea what my PW on Slashdot is (ironic, right?) because I have a serious question about this and likely no one will see it. My question is, what's my exposure that would drive me to a more secure password? What exactly do I have to lose? I don't do online banking, I talk to my broker on the phone only if I want to make adjustments to my portfolio. So, someone is going to post mean things to my neglected Facebook account? They'll mess with my Yahoo FFL team? Years ago Blizzard got hacked and PWs were taken - Blizzard sent out an email warning users to change their PW, which I ignored. Six months later I felt a yen to play StarCraft II, and found I couldn't get into my account because someone else had taken it and changed the PW. I emailed Blizzard, told them someone else had my account from their PW hack, and within 24 hours they had reassigned it to me with a new PW. Problem solved (oh, and whoever used the account had purchased Diablo III, so I got a free copy of that, plus the insane amount of legendary equipment they had accumulated). Absolutely the worst thing that might happen, and I'm not really sure how it would, is someone would use my credit card to buy stuff (maybe by logging into my Amazon account as me or something, but even then the would need the 3-digit code off the back of the credit card to complete the transaction), and by law (at least in America) my liability is limited to $50, and the one time years ago, long pre-internet, that I had a credit card stolen I didn't even have to pay that. So again I ask, what's my motivation to be all cloak and dagger with my PW?

Please...

[Anonymous Coward]

Obvious observation is obvious. How about an informed presentation/discussion of solutions to this problem? That would make this an interesting submission, which it isn't. Borderline clickbait.

TROGLODYTES

[Anonymous Coward]

Troglodytes don't realize the implications of credentials being shared across multiple services--especially for sensitive services--and they never will. These are the same folks that don't care. I know lots of troglodytes ... they all believe that they're such a small target that they don't have to worry. They're also the same folks that don't pay attention to world news. TROGLODYTES!

Passwords aren't the problem. We can't fix stupid. PEBKAC. All. The. Time.

Let's look at it this way. As long as there are troglodytes ... we'll all have jobs designing and implementing policies and services which just work in the background. I don't know about you all ... but I don't mind the work.

My favorite password

[Anonymous Coward]

for low level sites is "deleteC:\*.*"

Why it's hard

[Junta]

passwords should contain uppercase and lowercase letters, numbers and symbols

No, far more effective would be minimum password (phrase) length. People thinking 8 characters are fine as long as it is leet-speak is a problem. The way most people use uppercase, numbers, and symbols make the dictionaries a little more tedious, but not *that* much more so.

Sure, the most secure approach is totally random, but if people insist on it being human friendly, number of characters is the key point to emphasize.

This is a problem best tackled now

[Anonymous Coward]

They look like a great system now, until you lose the physical token. If they ever become popular, then I'm sure there will be techniques to subvert them - MITM, phishing or misdirection - I'm not smart enough to guess. If they every become popular, then I'm sure the 'lost token' problem will frequently be solved by having a password backdoor around the token.

It's like losing your house keys, only worse. Tokens are a good first step, but before they become widespread we need to consider curation, recovery of data if the token is lost, damaged, or corrupted (or just breaks over time), etc. Google-style pre-generated keys are one idea (but again, where are they stored, how vulnerable are they, and how can you ensure they're available when needed.

All of these questions will have reasonable technical answers (blockchain might make an interesting audit/recovery trail, but I don't know enough to do more than wildly speculate) or at least sensible compromises that cover most use cases and scenarios, but it requires a lot of thought, and a standard agreed upon by everyone that is solid, "upgradeable" in the sense that the standard can change in a modular fashion if issues are found (as they usually are eventually with most cryptographic solutions).

This is a precursor to how we would use quantum encryption in anger, as that becomes a token subject to decay if you look at it wrong. . Seriously though, a quantum particle pair is the ultimate token, both in terms of security, but also in terms of fragility. How do you recover data in such a scenario if the token is lost or corrupted, without leaving a backdoor that compromises your security entirely. Multiple valid keys, but curated, managed, maintained, and stored how?

Completely misses the point

[holophrastic]

It's not about understanding the risks. It's about considering the dangers to be significant. I reuse passwords all over the place, and most of my passwords are very simple. And I understand that because of my behaviour, it'd be very easy to hack into my slashdot account. There's no paradox there. I don't consider my slashdot account to be vital. If someone wants to hack into my slashdot account, I could care less. I'll get another slashdot account. It was free the first time. It'll be free the second time.

There are very very few passwords that actually protect something special. Even with my bank account, I'm not responsible for losses due to theft. Everything's insured by everybody along the chain, and most things are completely reversible.

Even my business passwords, that protect all of my clients' data, and support my livlihood, are restricted from the office, and the data is backed up in eight ways.

Identity theft would probably be the biggest threat to most morons these days. For me, it'd be a ten-minute inconvenience. It would mean visiting the bank, and saying: "I think someone's stolen my identity". Lori would say: "That sucks, let's freeze the old accounts and create some new accounts for you."

So what passwords protect something vital in your life?

Passwords are outdated.

[dagarath]

The issue is that GPU scaling has exceeded the functional life of passwords. So we make longer more complex passwords and next year or the next some GPU breakthrough will enable those to be broken in reasonable time. It's just a delaying action against the inevitable death of passwords as a valid authentication option.

Re:Passwords are outdated.

[Anonymous Coward]

I take it you've never had a course in combinatorics?

Don't bother - even if your password is strong....

[Dr. Crash]

Unless there's money involved, I don't bother with a strong password.

Why? Because even if my password protocol and tradecraft are bulletproof, most sites aren't. Sites get
compromised so often that even a good password will fall in a year or two. Or your password _manager_ gets
compromised.

So... why bother? Start with "Password#1!" (which almost all sites will accept as "strong" and
when (not if, when) that compromises, move to "Password#2". And so forth.

Okay.... don't use the word "password". Use "Starbucks#1". Or "Galactica#!".

Other than a very few sites worthy of _trying_ to protect (your bank and maybe your primary email) one password
shared across all sites is more than adequate because compromise is inevitable. Make the cost of
compromise as close to nil as possible; that's the optimal behavior. I mean, who cares if your brownie
recipe gets trashed?

And never, ever store a password that can be turned into money on anything more connected than a
post-it note in your wallet next to your Benjamins.

The psychological reasons...

[Anonymous Coward]

Where's the study of the psychological reasons security techs think users will listen to their stupid demands. They say things like, "first, pick a hard-to remember password for *each* of your hundred or so websites, and don't write them down." The proper response to that is clear-- "yeah, that'll happen." Security technology that depends on user memory is doomed to fail and stupid on its face.

The fastest, most bang-for-buck fixes

[Sloppy]

Go through your text, and everywhere where it says "password" change it to say "passphrase."

The password-setting step, where you have the user initialize their password, should also say "don't re-use the same passphrase that you use somewhere else." Just say it. (If users want to ignore it, fine. You can't help people who don't want to be helped.)

This doesn't fix all the problems, but it fixes the most, in the smallest amount of time/effort. One of your interns can do all this in a single morning.

...

After that, make sure you're hashing, but use something already invented for this job rather than trying to figure it out yourself. (This might not be a job for an intern, though I bet it could, at some places.)

Congratulations, your site is now better than the other 99.9%. We'll revisit and update these decisions in a century or two, when you're considered to be better than only about 90%.

Re:A password should NOT contain a mix of characte

[Guybrush_T]

Not to mention current GPU-based systems. Add 2 characters. Now, how is able to remember a 14 digits random passwords ? No-one. So let's giveup on brute force and just implement attack detection on web interface. The rest is futile.

Simplest Secure Solution

[Anonymous Coward]

Keepass protected by a password that is a long (30+ character) meaningful (to the user) SENTENCE.

For more security, add a made up word or two and numbers to the sentence.

Memory

[Anonymous Coward]

If you can remember it then it's insecure.

U2F is the answer

[Anonymous Coward]

https://fidoalliance.org

Different web services require different password

[Anonymous Coward]

I have a bunch of web sites that I use that have no need for a strong password. I don't have a credit card stored on them. I use disposable e-mail accounts with them. So YES I reuse passwords on them. Big freaking deal.

Now for my financial sites... AWS with two-factor authenticiation... work... etc. Yes, I use good password policy.

But seriously people, you can't generalize password behavior.

Just saying

Easy Secure Password

[hyades1]

Just make up a word. Use just the word on its own for stuff you don't care about. Put it into a little poem or sentence for sites you do care about.

Example: "Goosnarp". Even without exotic characters, it's not an easy crack. For your on-line banking, you might use "I am Goosnarp, take me to your liter".