As a recent convert, I highly recommend using a password manager (Lastpass, Dashlane, 1Password, etc.).

For sites where I don't really care about security (present company included :), I use a passphrase, usually in the form of a mnemonic. As an example, the password I may choose for this site would be "Hack_G1bson_RedPill_KungFooey" Much easier to remember and it only makes sense to me. Also, for apps like Dropbox, you better be using multi-factor authentication.

I can't do this for every site because of their tyrannical password requirements. I wish they used overall password complexity as an entropy threshold instead of 1 lower, 1 upper, etc.

I've walked away from signup at sites where I'm mildly curious, and when I go to sign up - I have a 25 char random password-safe generated string rejected as a secure password due to stupidly enforced lowest-common-denominator rules. (Or worse still, rejected as "too long").

If Im feeling "community minded" that day, I might email their contact address and tell them why I didn't complete the signup process - if I'm in a stabby mood I'll more likely just lampoon them as morons on Twitter. doubt either action on my part makes any difference.

Like paypal and their unwritten no spaces rule?

You should absolutely use a password manager and two factor auth whenever you can, but the problem is what to do as a service provider and/or employer if people won't use either of the things. A lot of people are pretty careless about their digital security and don't care for password managers or 2fa; and then of course they reuse passwords because nobody can be arsed to remember a different password for each service.

You could argue that if someone doesn't care for their digital security that's their problem, but we live in a time when one single careless employee can screw over 60 million people, as it was the case with Dropbox.

I use the 1Password Teams service, having converted from PasswordSafe, and it's excellent. Easily worth paying for. Syncing, browser integration, etc - saves a lot of pain.

Enforcing arbitrary password rules. "Must contain at least two '$' characters", "Cannot contain more than one '?'", etc.

However, I think being able to use the same stupid password on all sites I do not care about is a feature rather than a bug.

The problem with that is you never know at signup whether this site is going to be "one you don't care about" 2 or 5 years later.

I had a "stupid" multiply re-used password exposed in a breach of PerlMonks (which I didn't really care about in 2007 or so) which I also used when signing up to check out yet another new social media site in 2008. A couple of years later my Twitter account was sending Acai berry spam to my friends...

(And even if new-site-de-jour doesn't turn out to be something you stick with, it's now got your name (or regular handle) with the risk of damaging your reputation when it gets exploited without you even knowing...)

> you never know at signup whether this site is going to be "one you don't care about" 2 or 5 years later.

Yeah, I mean, my friends talked me into signing up for some stupid site back in 2005, "Face"-something? Seemed pretty trivial to me.

(IIRC in all seriousness Facebook's password requirements were hilariously trivial back when they first started.)

I recently had a fight with password selection on the Azure portal. They have some truly awful password rules, and I've ended up using something that isn't completely terrible but is much worse than normal, because I simply couldn't get it to accept anything decent.

Thinking about it, my account was added by a company using Azure, perhaps they are able to set the password restrictions for their sub-accounts...

Perhaps someone could come up with a service saying "sorry, this password has already been used somewhere on Internet, are you sure you want to proceed?". Sites would have to adopt it, a-la re-captcha

I ask, can we do away with passwords entirely? Trying to defeat computers with human memory seems like the wrong approach.

SSH keys all day. They can be troublesome for even an "expert" to look after, so I guess there's no hope for your average idiot. Still, logging in without using a password is the bomb

Keys are great until you find a sudden need to log in from your wife's cellphone or a public terminal..

opsec 101 - don't use other people's devices / machines

Do you never, ever, use devices not in your full possession?

Isn't that what you do?

If you have deals with many strangers do you not expect to get your hands dirty in some way?

I definitely don't store my SSH keys on stranger computers. I however used passwords on my relatives or customers devices on numerous occasions. Don't pretend you never did, I'm not going to believe you.

Sure, I've used other machines in the past. I prefer not to though in most circumstances and assume that any account / password that I use on said machine is compromised from then on.

This was something I changed when I realized that a tax related government agency's machine I was using about 10 years ago man in the middled SSL connections to my online banking. Who knows what was logged and what the retention on that was? I don't have time or the inclination to ensure every relative's / customer's devices are secure, so I use my own or go without.

That should be soluble though. E.g. standardized smartcards that cellphones and terminals know how to communicate with.

In theory yes, although with caveats. You'd need to match the degree of anti-tamper measures currently present in POS terminals to all consumer devices.

In practice, it would mean replacing most of the world's user-facing computer infrastructure.

You can get computers with smartcard readers from virtually every major manufacturer (except Apple, because Apple). The most frequent use case is government users who need to support the DOD Common Access Card (CAC) standard.

The card reader doesn't have to be any more tamper-resistant than the rest of the computer. On a public terminal, it should probably be built like an ATM's card slot (and the rest of the machine should be similarly armored), but on a personal computer it doesn't need to be any more robust than the keyboard a user would otherwise type passwords in with. The card-computer communication is all encrypted anyway, so even if it's built like any old USB peripheral it's still better than typing into a keyboard.

Key disclosure and key loss are things.

The first makes your public key useless for security. The second locks you out of everything.

So you've still got to have patterns-of-fraudulent-use detection, and some sort of token-reset mechanism.

Persistent data encryption is another option, but that compounds the key-loss problem in that you cannot access earlier data.

Yea this seems easy to set up. But, what about <insert generic website>? Like... HN.

I have an encrypted file with website|username|password on my laptop to allow for unique passwords across sites. But it's a pain, and definitely not something everyone will do.

SSL client certificates. If only the browser UX for them didn't suck.

We can certainly do without passwords for every stupid little website. Unless you're rightfully a central force in the user's life - say, their main bank - you really should have users log in through Google, or Facebook, or Twitter, or someone else who almost certainly can guard their passwords better than you can.

It's shameful that it's so much easier to find tutorials on how to store passwords "securely" (including several tutorials that tell you crazy insecure things, like storing with unsalted commodity hashes) than it is to find tutorials on how to integrate your brand new battling-fairies website game with OAuth for authentication.

Yes. Debian uses client-side X.509, OpenPGP and OpenSSH certificates for all service authentication (including websites).

That is just 2fac, isn't it?

Authy codes (as well as Google and Microsoft equivalents) can be the first factor, which would eliminate the need for passwords. Grandparent's question was about usage by groups and teams at the enterprise level, which Authy also supports.

I've often wondered if this is possible. I bet there's an academic paper somewhere about zero-knowledge multi-lookups or something.

This.

I think it's going to have to be legislated:

1. Mandate that all publicly disclosed passwords are collected in a compiled set.

2. Require that any Internet service vendor check against this set on password change revisions, and against different portions of the file, as maintainable, on each authentication.

Known passwords are rejected when set, and mandate changes when detected on login.

Asking a 76 year old mostly-computer-illiterate pereson to come up with a never-been-used-before password simply doesn't work.

This also means mandating password safes on all consumer-grade OSes. Apple already does, Microsoft and Android. For Linux, you might be semi- on your own, though most distros offer several options.

I'd also like to see 2FA via a keyfob generator rather than contact token (e.g., phone, email).

Coming up with appropriate password for ordinary user's is hard enough right now.lets imagine you are not being sarcastic-for the sake of argument-, then I think it is almost impossible to create good enough password, yet rememberable.

Lastpass does this. It will warn you when saving a password, and it also warns you when loading data for an already saved password.

Don't store passwords at all if you can avoid it. Then, bend over backwards to avoid it.

Do all login through OAuth or the related proprietary "login with" mechanisms Facebook and Twitter have. Offer your users a choice of mechanism, in the signup flow, and don't require that they first set up a password that they then replace with login-with-(whatever).

If you can't imagine what this looks like, open an incognito browser and go through the signup-for-an-account flow at stackoverflow.com. That should be what you're aiming for.

There are plenty of technical solutions to this problem.

None that will not dissuade potential paying customers, though.

Yeah, I was thinking more of dissuading employees.

Well, first off you make this (USE UNIQUE PASSWORDS) part of orientation, and maybe have part of orientation involve rolling dice and using the diceware list.

Then, you reinforce that by using some sort of SSO setup/service (you can outsource this to someone like okta.com if necessary), so that all internal systems never have a place to set a password. (e.g., don't make people set up separate accounts with passwords on the corporate jira or bitbucket server)

Basically, not training people to reuse passwords internally can help them to not reuse their one internal password externally.

Another possibility is to simply buy a password manager subscription for every employee and have it as a perk. That's a per-employee overhead of $20-30/year.

the best approach is implement 2FA so you're not solely reliant on user password choice.

At scale, there's no way you'll get everyone to use good passwords. Random generation is a bad idea, users just write them down if you do that.

For server-side, that'd be OpenID.

I generate them using Apple keychain

Indeed, or any major password manager. I use lastpass, which will automatically generate (and even fill in the appropriate fields) long, random passwords. I'm sure the others have a similar option.