4 ms·

Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com

Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%

Dylan16807 2y ago
A delimiter fixes the problem if you're sure the delimiter character can never be inside the username and password. Better would be to prefix the length of each field. Better still would be separately hashing each field and concatenating the results.
- akira2501 2y ago
  I tend to use '\0' as a delimiter for this reason.
  - Dylan16807 2y ago
    You still need to make sure nulls can't show up, and you need to consider possible truncation scenarios caused by those nulls and make sure they won't cause silent failures at any point.
    - akira2501 2y ago
      > You still need to make sure nulls can't show up Which is very easy to do without losing any desired functionality as opposed to delimiters in the ASCII character range. > and you need to consider possible truncation scenarios In particular hashing libraries worth using never have this problem. > and make sure they won't cause silent failures at any point. They literally only need to exist in the data to one function call. Afterwards they are not needed or significant.
      - brianshaler 2y ago
        Re the second quote and response: One pattern I bump up against from time to time is the delta between using a perfectly defensible technique for a given use-case (safe delimiters when constructing an input for a specific function) versus a desire to have each decision be driven by some universal law (e.g. "if you're streaming data between services, using null bytes as delimiters might not be safe if consuming services may truncate at null bytes, so NEVER use null bytes as delimiters because they can be unsafe") It's not even a matter of one "side" being right or wrong. You can simultaneously be right that this is perfectly safe in this use-case, while someone else can be right to be concerned ("need to consider possible") because the code will forever be one refactor or copy/paste away from this concatenated string being re-used somewhere else.
      - Dylan16807 2y ago
        > In particular hashing libraries worth using never have this problem. I'll note that the reason we're here in the first place is that they were using a password hash library with a completely unacceptable API.
- jrockway 2y ago
  Personally, I like a fixed uint8 or uint16 representing the length of each segment. Then, there are no forbidden characters or quoting required. Maybe I want to have \0 in my password.
deleted 2y ago
[deleted]
0x457 2y ago
By why does it matter? It's a one-way hash isn't? Also, we're talking about user_id not user_email, so it should be the same length always. Well, unless you're silly and using databases sequence for IDs.

Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%

Dylan16807 2y ago

A delimiter fixes the problem if you're sure the delimiter character can never be inside the username and password. Better would be to prefix the length of each field. Better still would be separately hashing each field and concatenating the results.

akira2501 2y ago
I tend to use '\0' as a delimiter for this reason.
- Dylan16807 2y ago
  You still need to make sure nulls can't show up, and you need to consider possible truncation scenarios caused by those nulls and make sure they won't cause silent failures at any point.
  - akira2501 2y ago
    > You still need to make sure nulls can't show up Which is very easy to do without losing any desired functionality as opposed to delimiters in the ASCII character range. > and you need to consider possible truncation scenarios In particular hashing libraries worth using never have this problem. > and make sure they won't cause silent failures at any point. They literally only need to exist in the data to one function call. Afterwards they are not needed or significant.
    - brianshaler 2y ago
      Re the second quote and response: One pattern I bump up against from time to time is the delta between using a perfectly defensible technique for a given use-case (safe delimiters when constructing an input for a specific function) versus a desire to have each decision be driven by some universal law (e.g. "if you're streaming data between services, using null bytes as delimiters might not be safe if consuming services may truncate at null bytes, so NEVER use null bytes as delimiters because they can be unsafe") It's not even a matter of one "side" being right or wrong. You can simultaneously be right that this is perfectly safe in this use-case, while someone else can be right to be concerned ("need to consider possible") because the code will forever be one refactor or copy/paste away from this concatenated string being re-used somewhere else.
    - Dylan16807 2y ago
      > In particular hashing libraries worth using never have this problem. I'll note that the reason we're here in the first place is that they were using a password hash library with a completely unacceptable API.
jrockway 2y ago
Personally, I like a fixed uint8 or uint16 representing the length of each segment. Then, there are no forbidden characters or quoting required. Maybe I want to have \0 in my password.

deleted 2y ago

[deleted]

0x457 2y ago

By why does it matter? It's a one-way hash isn't? Also, we're talking about user_id not user_email, so it should be the same length always. Well, unless you're silly and using databases sequence for IDs.