4 ms·

Or god forbid you try and use a non-English password... Unicode exists for a reason.

Sammi 8y ago
All character related issues disappear when you hash the password. There is no problem here. Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
- ben509 8y ago
  You have to get the data out of the text form. Unicode passwords mean all text entry forms on all browsers using all operating systems must be returning identical data, or at data that can be normalized to be bitwise identical without discarding the accents. While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users. And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
  - Sammi 8y ago
    Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.
    - kccqzy 8y ago
      Differences in for example, NFC or NFD forms of text, which is relatively common. And even for UTF-8, certain platforms don't properly encode code points beyond the BMP; they do it by encoding to UTF-16 surrogates and encoding the surrogates separately.
      - Sammi 8y ago
        Web browsers don't normalize to NFC, NFD, or any other form, and you can control the normalization if you're making a mobile or desktop application. You as the login feature developer get to control and define in your backend interface what form you expect and handle. In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. There is no problem here. More info: https://nukep.github.io/progblog/2015/02/26/some-gotchas-about-unicode-that-every-programmer-should-know.html https://nukep.github.io/progblog/2015/02/26/some-gotchas-abo...
        kccqzy 8y ago
        That just answers your own question isn't it? It's more work for backend developers to normalize things. If you only allow ASCII, no such work is required.
        Sammi 8y ago
        I don't think there is much of a hassle to implement this. I can only imagine a handful of lines necessary to handle this. Decide which normalization form, if any, you are going to use and then do the normalization in one place on the backend. And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.

All character related issues disappear when you hash the password. There is no problem here. Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.

ben509 8y ago
You have to get the data out of the text form. Unicode passwords mean all text entry forms on all browsers using all operating systems must be returning identical data, or at data that can be normalized to be bitwise identical without discarding the accents. While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users. And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
- Sammi 8y ago
  Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.
  - kccqzy 8y ago
    Differences in for example, NFC or NFD forms of text, which is relatively common. And even for UTF-8, certain platforms don't properly encode code points beyond the BMP; they do it by encoding to UTF-16 surrogates and encoding the surrogates separately.
    - Sammi 8y ago
      Web browsers don't normalize to NFC, NFD, or any other form, and you can control the normalization if you're making a mobile or desktop application. You as the login feature developer get to control and define in your backend interface what form you expect and handle. In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. There is no problem here. More info: https://nukep.github.io/progblog/2015/02/26/some-gotchas-about-unicode-that-every-programmer-should-know.html https://nukep.github.io/progblog/2015/02/26/some-gotchas-abo...
      - kccqzy 8y ago
        That just answers your own question isn't it? It's more work for backend developers to normalize things. If you only allow ASCII, no such work is required.
        Sammi 8y ago
        I don't think there is much of a hassle to implement this. I can only imagine a handful of lines necessary to handle this. Decide which normalization form, if any, you are going to use and then do the normalization in one place on the backend. And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.