Hacker News Reader

Comment by koenraad | Hacker News Reader

By disabling user input the application security actually gets worse. Users that can’t copy e.g. passwords will use less complex passwords to overcome the trouble of typing in their initially good passwords. But also user experience is degrading when applications enforce complex input and users generate that input like a chad as they should. But now they cannot paste…

View on HN

I'll add to that systems that require particular characters to be used, like "must use capital, number and special character". I prefer to generate longer passwords but using only regular characters because I find it easier to type on the occasions I do have to do that.

Even worse, there are some that restrict what kind of special character you can use. So even when I've generated one I still have to edit to remove one particular character.

Would it really be that difficult to display password strength and say things like "use more characters, e.g. you could use four words".

> Even worse, there are some that restrict what kind of special character you can use

Even worse, there are some that restrict special characters, but don't tell you which!

Now you've got to go trial and error to find out which of the special characters in your password is not acceptable to that precious §("/$& website!

Even worse, when on top of all these they add an arbitrary length requirement: It can't be less than 8 letters OR more than 12. :|

"look, just tell me what you want my password to goddam be, and I'll go with that!"

“Sure but you can’t copy it out”

That one irks me too... When I built an auth/rbac app previously I did make Max length configurable and it would display a night if set. I set a hidden hard limit to 1k only to reduce attack surfaces that would only display and error if exceeded.

Default was a min-length of 15 as the only requirement with the default hint of "try using a short sentence"

I also had optional use of zxcvbn and haveibeenpwned checks during new passphrase creation.

I really wanted to open source the application but couldn't get approval to do so.

It was a pretty nice little simple auth application that issued RSA signed JWT to configured applications. It was interested into a few internal apps as well as for clients that didn't have something like azure ad, okta, etc. where we wrote bridge apps for auth.

If I had my configuration doc, I'd probably recreate it exactly, but with a Rust backend with HTMX instead of C#+react.

The date store used SQLite as a KV store, with simple methods for access that allowed an exception later for the values. Also wrote support for PostgreSQL and MS-SQL so they could be used where available.

Spent a lot of time on same defaults, hashing and encryption along with required configuration options for a few clients.

Aside: more devs really need to better understand public/private key generation and usage... Like not using the same keys for different environments.

Don’t worry, all of this is necessary because the passwords are stored in plain text in the database.

Even worse, some will simply arbitrarily silently truncate the password. But not everywhere! The sign up page might silently truncate and then the actual login page might not.

Wow. That would be a wonderful game of treasure hunt. Fortunately I've not come across that so far :D

What happened to me once is that a long-time password of mine got truncated as the website lowered it's maximum password length, and the login page didn't truncate, so my full correct password suddenly stopped working. The pain.

Pretty sure Microsoft did this at some point. Maybe for Hotmail.

Even worse, when the password has an arbitrary length requirement of 20, but the site doesn't tell you and just cuts of any trailing characters exceeding the requirement during account creation.

You have no idea how long it took me to figure that one out.

That sounds suspiciously like a VARCHAR(20) somewhere...

Slightly easier to figure out but no less annoying is when the maxLength attributes on the password fields for the two forms (create account and login) are different.

Several comments mention passwords getting silently truncated by input maxlength. FWIW my extension provides a visible warning when this occurs: https://underpassapp.com/StopTheMadness/

I love this extension so much. Nothing satisfies me more than forcing stupid websites into cooperation.

Proprietary, mac only, app store-ware. More madness.

> mac only

Also iOS.

This all reminds me of the password game: https://neal.fun/password-game/ I'd call it amusing if it weren't so often real.

For a more entertaining take, I really enjoy this use of it against scammers and thieves: https://www.youtube.com/watch?v=knhQ2f8anT8

Even worse are "secure answers." Aka osint. I just have my password manager create passwords for those too.

Are you referring to 'security questions' where the user must choose from a predetermined list? A predetermined list which is often questions whose answers may be know to close attackers (first school), not applicable to everyone (name of first pet), or anglocentrically blind to worldwide cultural diversity (mother's maiden name). I hate that so much.

Providing a list is fine as long as they let the user type their own question if they want to. I cannot trust the security of a single one of their crap questions if I were to answer them honestly. However, if they let me type my own question, I can absolutely guarantee it.

Yeah those. I choose them in order, no matter the subject, and put a password manager passphrase in.

The worst I've seen have uncommunicated password length maximums—but don't error when you exceed them. Instead, they just truncate your password, but only on creation. When authenticating, they don't truncate, so your password you just made with a password manager is "wrong".

Spotify did/does this. Made canceling my free trial really tricky, because I needed to log in again to do so.

SWIFT did it too. And a few other sites I forgot.

I added this check to my "why the fuck this password did not work" list of idiocies produced by incompetent developers

Obligatory: https://xkcd.com/936/

(Those of us who know, already know. I'd like to say that we all know here.

But if a reader does not recognize "correct horse battery staple", then you're obliged to click the above link -- you're one of today's lucky 10,000![1])

1: https://xkcd.com/1053/

I have multiple Google Accounts. One of them, I want to remember the password. The others, eh. I just want to copy paste. Doubly so for practically anything else. I wish they'd just let me copy paste.

I have developed a maybe irrational fear of space in strings such as passwords and paths. It always scares me when people use spaces in either case.

For passwords I have to actually remember and type in (os login, password mgr evs) I expressly use a short sentence, often with spacing and punctuation. Sometimes an intentionally misspelled word.

Yeah, haveibeenpwned is a great resource. More sites really need to integrate this kind of check.

tfw this xkcd has existed for your entire career.

Even Apple was so annoyed at this themselves that they actually went for a full open-source open-for-contributions GitHub repository at https://github.com/apple/password-manager-resources to get around these issues.

> Many password managers generate strong, unique passwords for people so that they aren't tempted to create their passwords by hand, which leads to easily guessed and reused passwords. Every time a password manager generates a password that isn't compatible with a website, a person not only has a bad experience but a reason to be tempted to create their password. Compiling password rule quirks helps fewer people run into issues like these while also documenting that a service's password policy is too restrictive for people using password managers, which may incentivize the services to change.

Ironically, apple.com itself is listed in this repository! Apparently they don't allow non-ASCII characters in passwords.

Jesus holy Apple pie!

ASCII only in 2023 seems positivity antique. And this from a supposed tech frontrunner! Wth...

Limiting characters can also be a feature, so users can't use emojis in their password (this is so fun), to realize later they can't login, because they don't know how to input emojis from their desktop computer.

Hopefully passwords will be gone soon (at least that's my hope).

There's only so much user hand holding you can do.

With how ubiquitous Apple is, introducing a small limitation to prevent user error can make a huge difference in reducing support requests.

I'd give them the emoji keyboard on the login page. Make a web version they can use. The wider the possible keyspace the better.

We all know how great a company Apple is(sigh), but even they make mistakes. Stop defending stupidity just because it's Apple being stupid this time.

Don't get me wrong, it's a stupid limitation indeed -- but sometimes decisions like these are meant to stop users from doing stupider things :)

I'm no fan of oversimplification, but Apple's audience is everyone, not just power users. In that case, I'd prefer having advanced options surfaced to me as "advanced" so I can do what I want, but leave the simple experiences for the simple folk.

You might have half a point about emojis, but that's not what Apple is doing here.

Is there a reason I as a Swede should be limited from using my full native alphabet in my passwords for example?

As an example, you know how people sometimes suggest using a short sentence as a password? Here's a phrase in a local dialect, which means "and in the river there's an island" Å i åa e ä ö

Notice how only 2 of those letters are available in ASCII.

ASCII only is not a feature, and I honestly doubt anyone would try to argue that it is if this was about any company other than Apple. Try to look past the "who" and focus on the "what".

In what platforms is it not possible to input 7-bit ASCII characters 020 -- 073 (octal)?

In what platforms is it not possible to input various Unicode or emoji characters, whether at all or reliably?

Try setting up your Linux desktop/laptop with a Cyrillic language keyboard only, and then try typing in your ASCII login password.

Aren't those keyboards usually readily switchable with a standard US keyboard layout (e.g., in Windows, MacOS, or Linux)?

Do you have any direct experience with this?

My point is that 7-bit ASCII underlies virtually all other keyboard / character encodings. Among the few cases where it doesn't (e.g., IBM mainframe EBCDIC, independent of ASCII), the principle encoding remains the Latin alphabet, and can readily be converted using standard system utilities.

They aren't readily switchable unless explicitly configured to be, and yes, I am speaking from direct experience.

I get your point, I am just saying that it is not universally true, even if my example is a stretched one (Cyrillic keyboard users always configure Latin-based layouts too, but it's not a default, and it's easy to forget esp if you install from a fully live env configured with both).

If it's still not clear, you can end up on a login screen with an ASCII password you can't type in, especially so without the GUI.

And how does one define a SHA512 hash of a Unicode string?

UTF-8? UTF-16? Others?

But that’s not the worst thing…

What about normalization? Skip or implement? Should “equivalent” code points cause differing hashes?

Should one be able to use the same password from systems with differing locales/languages ?

ASCII is insufficient, but Unicode is a royal mess!

I guess the plucky upstart password manager team has one problem to solve, the entrenched web services team has its own ways.

You don't even have to make a single line change to your backend to fix this. You can fix this entirely on the frontend by just applying a digest hash on the password before sending to the backend for proper password hashing. This way you can even support "unlimited" length password.

Yeah, just CRC32 the password on the frontend, should be fine

No, use a cryptographic hash function. If you use a CRC32 you will massively reduce the password space and make it easy to find collisions.

That's a very much backwards incompatible change: password that used to work no longer does.

Sure, just put your 500M users through a forced-password reset.

Theoretically, it might also lead to weaker passwords depending on the hash size (that's how you support unlimited lengths by transforming a larger space into finite one) or any issues with the hashing algorithm uncovered in the future.

One thing to keep in mind is that the hash actually becomes the password, so I can imagine plenty of buggy implementations where a developer does not do what you advise ("proper password hashing"): "hey, it's already hashed, I can just store it as-is".

This is a good thing. I won't accidentally make weird password without realizing it.

It's not for people with other locales and keyboards

For my own applications I typically require only three rules to be kept, two of which most users will never even encounter, the password must:

1. be long enough (e.g. 8 characters or more)

2. not be in the list of 10k most used passwords

3. not simply reuse words present in the username, email, birthday (if my application knows about it)

This keeps it open and only interferes with truly stupid (aka insecure) password choices.

Additionally I like to propose 8 passphrases to the user so they can choose one of their liking with one click (this also serves as a proposal what a good passphrase could look like).

I miss the old days of youtube when they had no restrictions. My password was x for ages. I think the only thing I use which still allows short passwords is my apple system password which thankfully is still three characters.

Good, except min 8 chars is not safe at all. Don't approach any semblance of security before min 12 chars. Min 14 is when you get into real security. The increase in entropy is exponential with password length, so security increases quickly after this.

The entropy doesn't increase exponentially if my password is just N copies of the same character or phrase, it only increases linearly.

Minimal password requirements allow people who know what they're doing to do the right thing. If you want to stop people who don't know what they're doing from doing the wrong thing, it will take a lot more than just length restrictions.

All that users do when they get hit with restrictions like that is repeat their password again, or fill it out with exclamation points. Not a lot of entropy getting added.

That is why I wrote e.g., actual length can be tuned to fit the purpose of the application. If there is really sensitive data or attackers gain privileges that could wreak havoc in the wrong hands I'd probably go with 12. If an attacker would gain next to nothing I'd go with 8 for comfort reasons.

This is in addition to other mechanisms of course, like rate limiting password attempts, fail2ban, salting, peppering, chosing the right hash, proper database separation etc.

The goal should be that only an attacker that has a copy of the database could profit from too short passwords, and only if they get the salt and pepper correct, to avoid rainbow-table-attacks.

Shout out to forms which error out with "Password too long! Must be at most ten characters. All from this subset of ascii". Which seems especially popular with banks.

Yeah, banks unfortunately have their opinionated checklists of “best practices”, also know as “what every other bank does”.

Very frustrating that any place where I can store code has way more security than what's more important to me: place where I store my money. Financial companies still using SMS for 2FA!

Sometimes I can understand this because banks work with old software that just has these restrictions.

But modern apps: just give us Unicode support. And maybe a limit of 255 characters, but not less.

Noticed the other day BCrypt has a max input size of 72 bytes.

Ah ofcourse. My bad. I was thinking about other restrictions like usernames. For passwords there should not be any.

That's what I'm saying. Passwords should probably have a reasonable limit like 72 bytes.

Ran into this with TikTok "Creator Marketplace" (for buying ads), password limit of 20 characters... $200B company.

I suspect, somehow, that this is stupidity with the bank's processing core systems, which ... things are weird with financials.

They buy someone out, and now there are two systems. Glued together with duct tape. Then they release a new web product, or mobile app, or whatever, and that gets taped on too. Duct tape and spit all the way down, with everything eventually limited by the most broken part (if you're lucky).

Also the rules sometimes show up saying you’ve violated them when you haven’t…

yes it’s longer than 8 characters

Yes I have one of your stupid special characters

Yes I’ve fulfilled all your other written rules

Oh… it also has to be LESS than 21 characters? Why did you not say that?

High quality complexity and password policy guidelines are provided by NIST and no one uses them. It’s called NIST 800-63b. Just use it!

Requiring special characters is just another type of security theatre.

You want to have weird password rules? Fine. Please make some standardized meta tags my password manager can find so it generates perfect passwords every time. Bonus points for a well-known URI facilitating touchless password rotation.

> You want to have weird password rules? Fine.

I'd be fine with storing the password policy in the password manager, and having it generate based on that policy next time.

And having all sorts of weird stuff in a password isn't necessary, so neither is the policy. To top it all off, many of the sites obsessed with password quality actually limit password length. Why?! You are comparing passwords hashes and storing them as hashes, right? So the length shouldn't matter.

Allow passwords of effectively unbounded length, set a reasonable minimum length, and don't obsess about password 'complexity'.

And for the love of all that is good, don't eff with paste.

All I ask is that the same restrictions are also displayed again whenever I have to enter my password for login.

In addition, they will probably also still try to copy to clipboard first, since they probably don't use that interface often enough to remember its special rule.

I generally agree that you should let the user use the facilities they're used to, but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing.

Firefox and Chrome's built-in password management tools would never accidentally enter your credentials on a lookalike site, but you very well might.

And both of those built-in password management tools are actively targeted by credential harvesting malware.

> I generally agree that you should let the user use the facilities they're used to, but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing

This is like advising that glass sidelights be installed next to the vault door.

That's all great, but then there are the times when they don't offer to copy the credentials where they should. Maybe the "correct" URL was too narrowly defined to be useful, or was taken from the setup context and is otherwise wrong for regular usage.... maybe the site changed their authentication process... etc. In the end, all of this tends to defeat the very resistance to the manual entry impulse you describe. If these password manager entry systems worked more flawlessly, your point would carry more weight... but having to defeat the protection your assertion relies upon is commonplace enough in legitimate purposes that it may well be nullified at all times.

In the end, as long as a site is going to use username/password authentication there will always be the need to educate users about what to expect sans the aid of tools.

> but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing.

non-sequitur.

getting phished results in the decision to enter the credentials. The mechanism for doing so is irrelevant to that decision.

Different security problem, not one that I have.

Reply on news.ycombinator.com