6 ms·

UPS is up there, too. I still get text messages about an old address on an account I can't log into for...reasons. (Special characters sound plausible! And of c

UPS is up there, too. I still get text messages about an old address on an account I can't log into for...reasons. (Special characters sound plausible! And of course the password reset flow doesn't work.) Wonder if they share a vendor.

judge2020 3y ago
UPS is better in my experience with them always requiring a code sent to me via USPS to verify access to UPS My Choice, except for when I signed up with a new construction address - It also seems to only show me packages with my last name on it, packages with just a company name did not show up.
ryandrake 3y ago
I can’t believe it’s 2024 and we are still seeing bugs with handling “special” characters. Unicode has been here for how long? Robust string handling is supported in every language. There is no such thing as a special character. My name should be able to contain Chinese characters. My password should be able to contain emojis. What is this Stone Age shit still running on companies’ backends?
- gjsman-1000 3y ago
  Most companies don't like rewriting their code. If it ain't broke, don't fix. (Weird password issues don't count as broke.) There's no guarantee, after all, that the rewrite won't have major edge cases and mistakes of it's own. The upper layer might change now and then, to give a veneer of modernity. But just like Windows being built on 90s technology, the stuff underneath could be even more ancient.
  - ryandrake 3y ago
    A software that can't accept a % as part of your password is absolutely, positively broken--in any industry or application. In many companies, this would be a P0 "don't go home until it's fixed" production emergency if a bug like this crept in to the software. We need to stop excusing long-standing bugs in horrible legacy software just because they are long-standing.
    - gjsman-1000 3y ago
      > In many companies, this would be a P0 "don't go home until it's fixed" production emergency if a bug like this crept in to the software. Would it, really? P0 would probably be "10% of our customers can't submit an order." Or "20% of our vendors are experiencing 404s."
      - ryandrake 3y ago
        If 10% of customers have passwords that now can't log in and submit orders, that would be an emergency. We're taking OP's word for it that FedEx doesn't allow certain characters as passwords (actually, from the description, it seems more like FedEx only allows specific characters which is even worse). If either of those are true, it is most certainly a defect. Whether FedEx treats that defect as an emergency is up to them I guess. I'm saying many modern companies would. You originally said "Weird password issues don't count as broke." I think this might just be a case where we have to "agree to disagree".
        gjsman-1000 3y ago
        > You originally said "Weird password issues don't count as broke." I think this might just be a case where we have to "agree to disagree". I meant broke in the sense of "if it ain't broke, don't fix." If there are over 300 microservices running code, connected to mainframes running code that was originally from the 80s, but they occasionally have password issues - the risks caused by trying to fix it might be greater than it's worth. That doesn't mean FedEx can't do a better job telling people not to use special characters - or detecting if their current password contains them and forces a password change.
        krisoft 3y ago
        > If there are over 300 microservices running code, connected to mainframes running code that was originally from the 80s, but they occasionally have password issues And we ended up where the thread originally begin "FedEx may have the worst and least secure digital platform for a major company." Besides that is horrible! There should be 1 microservice which deals with passwords, the authentication one. Everything else should just get a token attesting that the user is authenticated (or not).
- crazygringo 3y ago
  > My password should be able to contain emojis. It's probably better if it shouldn't. It's generally better to prevent passwords from containing characters that can't be entered on a decent proportion of devices you may encounter. Emojis are particularly problematic because new ones keep being added which require OS upgrades, and you might find yourself needing to log in from another device that just doesn't support those emojis yet. Also it's not like Unicode makes everything easy. For example, you have to remember to normalize the password before hashing. Otherwise something as simple as "ñ" may be a totally different byte sequence depending on which device you're using.
  - grodriguez100 3y ago
    If a system cannot handle ñ in a password then it is completely broken. We are not talking about the latest emoji here but about a character which is part of one of the most common languages in the world, included in 8859-1 / Latin-1, etc. It is no longer realistic to pretend that only ASCII exists and try to get away with that.
    - jerf 3y ago
      That's not what crazygringo means. ñ can be represented both as a single unicode U+00F1 https://www.compart.com/en/unicode/U+00F1 https://www.compart.com/en/unicode/U+00F1, or as an n with a combining tilde https://www.compart.com/en/unicode/U+0303 https://www.compart.com/en/unicode/U+0303, which looks like this: ñ. Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux >>> "ñ".encode("utf-8") b'\xc3\xb1' >>> "ñ".encode("utf-8") b'n\xcc\x83' A naive hashing algorithm will hash them to different things. For way too much information on this, see: https://www.unicode.org/reports/tr15/ https://www.unicode.org/reports/tr15/ Even a lot of Unicode-aware code written by a developer aware of at least some Unicode issues often fails to normalize properly, most likely because they're not even aware it's an issue. Passwords are a case where you need to run a Unicode normalization pass on the password before hashing it, but, unfortunately, if you're already stored the wrong password hash fixing it is rather difficult. (You have to wait for the correctly-incorrect password to be input, then you can normalize and fix the password entry. This requires the users to input the correctly-incorrect password; if they only input an incorrectly-incorrect password you can't do anything.) I'd suspect storing a lot of unnormalized passwords before learning the hard way this is an issue is the majority case for homegrown password systems. You hear "don't roll your own crypto" and think reaching for a bcrypt or scrypt library solves it, but don't realize that there's some stuff that needs to be done before the call to those things still.
- xenophonf 3y ago
  I'm in complete agreement about usernames, but if you're at the point where you want to use Unicode in a password, you might as well make the jump to WebAuthn. Going from a UTF-8 input to a normalized bitstream that gets fed into a KDF could be tricky.
- kansface 3y ago
  Companies aren’t rewriting their entire stack or even upgrading across major versions basically ever.
  - jabroni_salad 3y ago
    Alright cool but maybe they can put the exact phrase "IF you put an ampersand in your password, your account will be bricked and we wont help you with it" on the password form.

judge2020 3y ago

UPS is better in my experience with them always requiring a code sent to me via USPS to verify access to UPS My Choice, except for when I signed up with a new construction address - It also seems to only show me packages with my last name on it, packages with just a company name did not show up.

ryandrake 3y ago

I can’t believe it’s 2024 and we are still seeing bugs with handling “special” characters. Unicode has been here for how long? Robust string handling is supported in every language. There is no such thing as a special character. My name should be able to contain Chinese characters. My password should be able to contain emojis. What is this Stone Age shit still running on companies’ backends?

gjsman-1000 3y ago
Most companies don't like rewriting their code. If it ain't broke, don't fix. (Weird password issues don't count as broke.) There's no guarantee, after all, that the rewrite won't have major edge cases and mistakes of it's own. The upper layer might change now and then, to give a veneer of modernity. But just like Windows being built on 90s technology, the stuff underneath could be even more ancient.
- ryandrake 3y ago
  A software that can't accept a % as part of your password is absolutely, positively broken--in any industry or application. In many companies, this would be a P0 "don't go home until it's fixed" production emergency if a bug like this crept in to the software. We need to stop excusing long-standing bugs in horrible legacy software just because they are long-standing.
  - gjsman-1000 3y ago
    > In many companies, this would be a P0 "don't go home until it's fixed" production emergency if a bug like this crept in to the software. Would it, really? P0 would probably be "10% of our customers can't submit an order." Or "20% of our vendors are experiencing 404s."
    - ryandrake 3y ago
      If 10% of customers have passwords that now can't log in and submit orders, that would be an emergency. We're taking OP's word for it that FedEx doesn't allow certain characters as passwords (actually, from the description, it seems more like FedEx only allows specific characters which is even worse). If either of those are true, it is most certainly a defect. Whether FedEx treats that defect as an emergency is up to them I guess. I'm saying many modern companies would. You originally said "Weird password issues don't count as broke." I think this might just be a case where we have to "agree to disagree".
      - gjsman-1000 3y ago
        > You originally said "Weird password issues don't count as broke." I think this might just be a case where we have to "agree to disagree". I meant broke in the sense of "if it ain't broke, don't fix." If there are over 300 microservices running code, connected to mainframes running code that was originally from the 80s, but they occasionally have password issues - the risks caused by trying to fix it might be greater than it's worth. That doesn't mean FedEx can't do a better job telling people not to use special characters - or detecting if their current password contains them and forces a password change.
        krisoft 3y ago
        > If there are over 300 microservices running code, connected to mainframes running code that was originally from the 80s, but they occasionally have password issues And we ended up where the thread originally begin "FedEx may have the worst and least secure digital platform for a major company." Besides that is horrible! There should be 1 microservice which deals with passwords, the authentication one. Everything else should just get a token attesting that the user is authenticated (or not).
crazygringo 3y ago
> My password should be able to contain emojis. It's probably better if it shouldn't. It's generally better to prevent passwords from containing characters that can't be entered on a decent proportion of devices you may encounter. Emojis are particularly problematic because new ones keep being added which require OS upgrades, and you might find yourself needing to log in from another device that just doesn't support those emojis yet. Also it's not like Unicode makes everything easy. For example, you have to remember to normalize the password before hashing. Otherwise something as simple as "ñ" may be a totally different byte sequence depending on which device you're using.
- grodriguez100 3y ago
  If a system cannot handle ñ in a password then it is completely broken. We are not talking about the latest emoji here but about a character which is part of one of the most common languages in the world, included in 8859-1 / Latin-1, etc. It is no longer realistic to pretend that only ASCII exists and try to get away with that.
  - jerf 3y ago
    That's not what crazygringo means. ñ can be represented both as a single unicode U+00F1 https://www.compart.com/en/unicode/U+00F1 https://www.compart.com/en/unicode/U+00F1, or as an n with a combining tilde https://www.compart.com/en/unicode/U+0303 https://www.compart.com/en/unicode/U+0303, which looks like this: ñ. Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux >>> "ñ".encode("utf-8") b'\xc3\xb1' >>> "ñ".encode("utf-8") b'n\xcc\x83' A naive hashing algorithm will hash them to different things. For way too much information on this, see: https://www.unicode.org/reports/tr15/ https://www.unicode.org/reports/tr15/ Even a lot of Unicode-aware code written by a developer aware of at least some Unicode issues often fails to normalize properly, most likely because they're not even aware it's an issue. Passwords are a case where you need to run a Unicode normalization pass on the password before hashing it, but, unfortunately, if you're already stored the wrong password hash fixing it is rather difficult. (You have to wait for the correctly-incorrect password to be input, then you can normalize and fix the password entry. This requires the users to input the correctly-incorrect password; if they only input an incorrectly-incorrect password you can't do anything.) I'd suspect storing a lot of unnormalized passwords before learning the hard way this is an issue is the majority case for homegrown password systems. You hear "don't roll your own crypto" and think reaching for a bcrypt or scrypt library solves it, but don't realize that there's some stuff that needs to be done before the call to those things still.
xenophonf 3y ago
I'm in complete agreement about usernames, but if you're at the point where you want to use Unicode in a password, you might as well make the jump to WebAuthn. Going from a UTF-8 input to a normalized bitstream that gets fed into a KDF could be tricky.
kansface 3y ago
Companies aren’t rewriting their entire stack or even upgrading across major versions basically ever.
- jabroni_salad 3y ago
  Alright cool but maybe they can put the exact phrase "IF you put an ampersand in your password, your account will be bricked and we wont help you with it" on the password form.