Hacker News Reader

Comment by Y-bar | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com