Also not helped by the fact that passwords have to include every symbol and their mother, cannot include sequential digits, cannot include sequential letters, cannot include any letter of your name, and a bunch of other inane rules that could be changed to simply having a minimum length of 12 instead of 8...

Always a joy when your generated password is refused:

    694*C73&4:Ekp>fy>SE&o![RC

(This is an example of what password-store generates.)

Not good enough, because it's too long. Nothing throws you back ten years in time like having to handcraft a password to comply with all the silly rules.

Not so long ago I had to register to a website allowing a comma (or was it a semicolon?) in a password during registration but refusing to login using said password. Fun times.

I once spent 15 minutes trying to register in a local Domino's website which kept bugging me about lack of a special character - even though I had one in it. Turned out to be that the app truncates the entered password after the first 20 characters and only considers the first part. Thankfully the special character was after the 20th position so I noticed the error and fixed it, but if it wasn't I'd be wondering the next time I'm logging in why it's not letting me login with a valid password.

Why do you need a secure account to order pizza?

How else are they going to run pepperoni-based big data analytics?

I've had the same problem with Verizon, in the past the password would only store the first 20 characters. Took me an hour or two to figure it out and fix the problem. I'm not sure if that's still the case, hopefully not.

My issue with Verizon is they lock an account after 3 bad attempts, and the "username" is the cell phone number for the account. Which seems to be slurped into some automated brute force engine.

Every single time I want to login, I have to do a password reset first. Makes me which I had the phone number to every manager in the company, so I could lock them all out every day.

Also, since having the phone is the only second factor for authentication, that's all you need to access an account.

You might not even have noticed if the login form truncated the input as well before hashing it. (You probably would have noticed after some update to their website removes the truncation though.)

Presumably it also truncates the password when doing sign-in?

I've had that with work passwords - using my password generator I give them a 64-character gibberish mess, but it turns out that they only accept 16 characters, and I rendered my account useless until they could reset it for me. How frustrating.

Hm, yes. I had that happen with a '#'. Presumably there was some nasty evaluation going on and the rest of the password was treated as a comment.

I wonder why I never pursued that.

You will usually get far better entropy by simply stitching together a random array of everyday words. Example: stitching better everyday words array entropy level. Anyway, as for the too-long problem, then I guess we're back to square one. :)

Strings of everyday words are better than the passwords most people choose, they're memorable, and they're often good enough from a practical perspective. But if you're using a password manager and don't have to remember passwords, you might as well use truly random passwords, which have more entropy.

I disagree. I use a 1Password, and I used to do the "totally random string of letters, symbols and digits", but I've dropped it for the "four or five random english words" alternative for all new passwords.

There are a couple of situations where having these symbol strings is really inconvenient. For instance, reading a password out loud to another person, or when logging in on a device where you can't (or don't want to) install your password manager on (e.g. a PS4 or an Apple TV). In those cases, "puncture-foible-irish-ducat-rejoice" is a lot easier to handle than "jh&6dQ#F]9.Z>u^t]6u+".

The "symbol" password has more entropy for sure, but the actual security benefit is essentially non-existent. No one's going to guess either password, and I'm never using the same password in two different places anyway. The extra convenience is totally worth it.

EDIT: as other people have pointed out in the thread, another example would be badly behaving sites that prevent "paste" or use other techniques to block password managers. Much easier to type in those words then.

... for the same length. But length doesn't really matter unless you're manually typing it in, in which case many people will be faster at typing words than random characters.

> [...] you might as well use truly random passwords, which have more entropy.

At what point is more entropy simply diminishing returns? Five random words gives you 64 bits, and six gives you 77 bits (each word = 12.9 bites):

* https://en.wikipedia.org/wiki/Diceware * https://www.rempe.us/diceware/#eff

The primary benefit of Diceware over a "random" string of characters is that it is easy to remember and truly random. With a password manager you don't need to remember the password and it will be generated truly randomly. A string of 11 random alphanumeric charatcers has more entropy than a 5 word diceware passphrase with the added benefit that it is less to type if you need to do so manually. But diceware can be a good idea for creating the master password for your password manager and if you do that you should probably use a 10 word passphrase rather than 5.

For anyone keeping score at home, some handy-dandy tables with entropy per symbol:

* https://en.wikipedia.org/wiki/Password_strength#Random_passw...

> Far better entropy

> random array of everyday words

No, that's not how entropy works. Random characters still score better.

Good try, but that doesn't apply to password managers. Several everyday words contain more bits than a garbled single word, but a string of dozens of truly random characters beat both.

You might be referring to https://xkcd.com/936/

That's the one! ^^ And you're of course correct.

A couple of years ago one of my banks "upgraded" its web site, forcing me to change my password to comply with its revised password guidelines since my old password was no longer permitted.

The result was a password that was shorter, less varied, and less secure than the previous one.

Good job, Chase.

I had a similar problem with Lloyds - every time I wanted to transfer money using the mobile app, I had to type in the password manually as they had disabled the "paste" option. Given my password was auto-generated and 16 characters long - and the password field wiped every time I did an app-switch, I just gave up.

"Don't Fuck With Paste"

http://browserengine.net/dont-fuck-with-paste-for-chrome-and...

It's very disturbing to see that your worst passwords are for your bank accounts. Each bank I've worked with has some weird limitation like this. Not to forget that the only form of MFA that most banks allow is SMS - assuming they even offer MFA.

Banks are probably still running on the old mainframe (old as in upgraded in 1998 when y2k forced it), with password storage that was state of the art in 1960 (plain text, but the file is actually protected well so hackers can't get it). That isn't to say better password cannot be used, just that they have never enabled it.

I don't understand that - I get that the system that holds the data is old, but when creating an online banking system shouldn't the piece that holds the data be a good half dozen steps removed from the website and authentication?

Not if you want a single sign on. Of course customers only use the web login, but internal people have to deal with all these different logins.

I have a Keepass app on my phone, Keypass2Android:

https://play.google.com/store/apps/details?id=keepass2androi...

It has a keyboard bundled into it that will ghost type in the currently opened username and password. Works awesome for stupid stuff like your story.

> my old password was no longer permitted.

But how did they know? They should just have the hash...

If they implemented it properly they could have checked the current password against the revised guidelines on the next login. No need to store it in plain text

The website can check the password during login without storing it in plaintext

The login form usually sends the password in cleartext and it's then hashed on the server-side prior to comparing it to the hash stored in the database.

So they can just determine the password's strength at the time when the user is logging in

FirstDirect's "digital secure key" Android app, which allows me (or someone else who happens to get hold of my phone while it is unlocked) to transfer a few grand out pretty easily, limits passwords to "between 6 and 9 characters". And offers fingerprint based auth as an alternative, because we all know how infallibly secure that method is.

People were forgetting their passwords and using up valuable support time.

Since the responsibility for password storage is on the customer anyway, we might as well make our password a maximum of 6 characters!

Some never memorize their passwords at all. Instead relying on 'forgot' emails and "Remember Me" features entirely.

Which isn't even that bad of an idea. Some website basically use this as the only way to log in.

Slack does this exceptionally well. If you forget which accounts you have, you can put in an email address and it will email you a list of your Slack accounts. If you forget your password, you can get a magic link that automatically signs in through a deep link into the app, no password needed.

It's such a cool idea. If you can reset your password using only your email, there's no security reason you can't just log in with it. It might even be better, since you can then add more annoying steps to the password reset strategy.

But Slack then must rely on the security of your email. If the site is dealing with sensitive information like credit cards, this could be a no go.

Any site that has a "enter your email for a reset link" feature relies on your email security.

Almost every website in existence except the most security sensitive like bank websites will allow you to reset your password with email.

What email based log in that doesn't use 2FA doesn't ultimately rely on the security of your email?

Indeed. On sites I have to register but know I won't go frequently I enter a random password I don't even write down, relying on the Forgot password feature if I ever need to come back later.

I have wondered if some web pages effectively have this as the main log in method. If you have a hurricane tracking page, everyone is going to forget their passwords in between hurricane seasons.

Steam has nearly done this for me.

Oh, it has a password. But if I remember my password I have to check my email and copy and paste a code from there. And if I forget my password I have to... check my email and copy and paste a code from there... really not much point to the password.

Bulb energy supplier in the UK trialled this - they soon switched due to complaints although I didn't really mind it.

Assume it was due to the inconvenience of not being able to remember password/stay signed in.

Yahoo Japan (not really related to the defunct original Yahoo and still very successful in Japan) recently abolished passwords for new accounts.

You can only login with reset emails or SMS codes, which is pretty annoying.

I wondered about this too and asked about it on the security stackexchange forum in case I was overlooking some glaringly obvious reason not to. Turns out that most thought it was reasonable too, though maybe too frustrating for some.

https://security.stackexchange.com/q/12828/8518

I've seen Blendle and a couple of other web sites do this.

You go to the login page, and your choices are federated login, standard login, or a one-time login e-mail.

medium.com is famous for email OTP authentication. They even blogged about it (search hacker news for more information)

In India, most mobile apps have phone number for username and OTP instead of password. Makes perfect sense for mobile apps. Except when OTP doesn't arrive due to congested sms networks. Or that your account gets hacked with sim takeover or sms MitM (both are currently unheard of in India).

I think you just jinxed it.

It is one way to go "passwordless" .. though you're piggy backing on the security that your email system already has.

Shameless plug of old post that describes how to restrict login to only the initiator even if login is initiated via an email link - http://sriku.org/blog/2017/04/29/forget-password/

You're relying on your email security either way, since anyone can trigger the password reset email if they get access to your email account.

This breaks my workflow -- I almost never open the forgot-password email on the same machine I used to initiate the request. Usually I need to briefly access a personal account from somebody else's computer or my work computer, and when I'm told I need to check my personal email, I only want to open that on my phone.

Honestly this just seems like there needs to be a better way. Maybe some multi-factor system that requires like a physical key and either a secret and/or some identifying thing.