3 ms·

Is there some good reason to prefer a blacklist in this case, that I'm not thinking of, that might change my reaction to this from "uh, maybe I need to entirely

Is there some good reason to prefer a blacklist in this case, that I'm not thinking of, that might change my reaction to this from "uh, maybe I need to entirely re-think my assumption that Auth0 is any better at this whole securing-users thing than I am"? My immediate and ongoing reaction to the headline was and is, "wait, a blacklist? WTF!"

user5994461 7y ago
The purpose of a blacklist is to seamlessly support newer algorithms invented later. For example consider SHA1 replaced by SHA256 by SHA512. If some components is hardcoded to only accept SHA1, it can't use the newer algorithms and potentially block adoption by other components. So it's somewhat normal design for future proofing, but it's a bit stupid for security/authentication stuff which sole purpose is to verify messages.
- karatestomp 7y ago
  I get why you'd use a blacklist in general, but it seems obvious to me that in a case like this you do not want to allow any algo you haven't cleared first. Especially since it may not be better! What if your underlying library decides it's gonna support md5 hashes for signatures?
- hinkley 7y ago
  What system of application deployment and maintenance are you picturing where a new crypto algorithm shows up on a machine without an opportunity to make a one-line commit to your codebase? And in a SaaS setting, what operational environment is going to want you to start using a new cryptographic algorithm with no formalism around the process? Someone is going to want to flip a proverbial switch.
  - user5994461 7y ago
    Look no further than OpenSSL and Windows SSL. These libraries doing the crypto, often managed by the OS, are upgrading the TLS protocol and ciphers on the fly with most applications having no awareness of what's going on.
    - hinkley 7y ago
      I would argue the opposite. openSSL is such a can of worms at this point that if you suggested this sort of magic thinking in a design meeting, you'd have a fight on your hands and I wouldn't be the only person arguing with you.

user5994461 7y ago

The purpose of a blacklist is to seamlessly support newer algorithms invented later. For example consider SHA1 replaced by SHA256 by SHA512. If some components is hardcoded to only accept SHA1, it can't use the newer algorithms and potentially block adoption by other components. So it's somewhat normal design for future proofing, but it's a bit stupid for security/authentication stuff which sole purpose is to verify messages.

karatestomp 7y ago
I get why you'd use a blacklist in general, but it seems obvious to me that in a case like this you do not want to allow any algo you haven't cleared first. Especially since it may not be better! What if your underlying library decides it's gonna support md5 hashes for signatures?
hinkley 7y ago
What system of application deployment and maintenance are you picturing where a new crypto algorithm shows up on a machine without an opportunity to make a one-line commit to your codebase? And in a SaaS setting, what operational environment is going to want you to start using a new cryptographic algorithm with no formalism around the process? Someone is going to want to flip a proverbial switch.
- user5994461 7y ago
  Look no further than OpenSSL and Windows SSL. These libraries doing the crypto, often managed by the OS, are upgrading the TLS protocol and ciphers on the fly with most applications having no awareness of what's going on.
  - hinkley 7y ago
    I would argue the opposite. openSSL is such a can of worms at this point that if you suggested this sort of magic thinking in a design meeting, you'd have a fight on your hands and I wouldn't be the only person arguing with you.