[deleted]
Creative usernames and Spotify account hijacking
41–50 of 83 posts
Re: Creative usernames and Spotify account hijacking
#42A fascinating account.
Re: Creative usernames and Spotify account hijacking
#43Earlier quoted context omitted.
>They could simply store two names Presumably you mean in the database? I don't see a reason to keep a copy of the lower() transformation of a string when it is incredibly cheap to transform a small string to lowercase. What exactly is the point of that? I would just call lower() as needed, personally.
Oh, my point was that two kinds of names should not be used interchangeably. To store or not the .lower() is a matter of taste.. (Personally, I would store both names, just to avoid wasting computing time)
I think the act of storing both names is bad, because you multiply the amount of data that could possibly become wrong by 2.
With lower(), we can expect we'll get the right transformation of string A each time. If instead, we store string A, and then store string B as A.lower() and copy it... A.lower() will always be A.lower, but it's much easier for someone to come along, screw with the database, and change B.
Re: Creative usernames and Spotify account hijacking
#44This seems odd. I mean, if their code was properly modular , they would have just one place where they "fetchUserIdByName(userName)", which returns one user ID or null if it's not used yet. When a new user is created, it then gets assigned a unique user ID. The email address is assigned to that user ID. Then, if they do a password reset on user = "bigbird", it should do the exact same lookup to find the email address…
Sounds like they are using the username as the key in their DBs, which sounds like the ultimate case of any pain:
Could the method for computing canonical usernames based on nodeprep.prepare() be salvaged? If not we would be in trouble since we use canonical usernames in various databases so that changing how to derive them in a non-backwards compatible way would be quite costly.
Re: Creative usernames and Spotify account hijacking
#45So is there a need for a TRULY idempotent equivalent of XMPP's nodeprep? Or one that handles more Unicode points? Or is it a calculated decision to support Unicode 3.2 points only? (Sorry for the nooby questions, but this was very interesting and I don't know a lot about Unicode)
Correct. And it would seem to me that such a function should probably be in its own separate library, or perhaps the standard library. It seems like a fairly basic need.
Re: Creative usernames and Spotify account hijacking
#46Earlier quoted context omitted.
Oh, my point was that two kinds of names should not be used interchangeably. To store or not the .lower() is a matter of taste.. (Personally, I would store both names, just to avoid wasting computing time)
I think the act of storing both names is bad, because you multiply the amount of data that could possibly become wrong by 2. With lower(), we can expect we'll get the right transformation of string A each time. If instead, we store string A, and then store string B as A.lower() and copy it... A.lower() will always be A.lower, but it's much easier for someone to come along, screw with the database, and change B.
Yeah, I see. I'm not a web developer, so maybe this is why I did not think about this way to break the data.
Well, I still think that it is better to have two (hopefully) correct fields in the database, rather than only one. (Consistency of the two fields can be checked once in a while).
Re: Creative usernames and Spotify account hijacking
#47Earlier quoted context omitted.
If you're saying canonicalise(canonicalise(name)) is not the same as canonicalise(name), that's going to be seriously bug-prone. Idempotence ftw.
That's exactly what they describe as the cause of the bug. They intended for the function to be idempotent but it wasn't because of a misunderstanding with the Python library spec.
Worse, it /did/ work that way in Python 2.4 but Python 2.5 stopped throwing an exception for invalid codepoints which broke the Twisted library which broke their canonicalization function.
Re: Creative usernames and Spotify account hijacking
#48Why does Unicode threat Omega and Ohm like different characters?
Because one is a greek letter, and the other is a unit of resistance. The fact that they're represented by the same symbol is irrelevant.
If that were the case, we'd need separate codepoints for every letter used as a unit of measurement, from A for ampere onwards. In fact, it's just there for legacy reasons, as pointed out elsewhere: the convention for units of measurement is to use normal letters, regardless of whether those are Latin or Greek.
Re: Creative usernames and Spotify account hijacking
#49Earlier quoted context omitted.
Oh, my point was that two kinds of names should not be used interchangeably. To store or not the .lower() is a matter of taste.. (Personally, I would store both names, just to avoid wasting computing time)
I think the act of storing both names is bad, because you multiply the amount of data that could possibly become wrong by 2. With lower(), we can expect we'll get the right transformation of string A each time. If instead, we store string A, and then store string B as A.lower() and copy it... A.lower() will always be A.lower, but it's much easier for someone to come along, screw with the database, and change B.
I'm not sure how they can avoid storing both.
They need to store the verbatim username in order to know how to display the username in the UI.
They need to store the canonical username in order to efficiently know whether a given canonical username is in use.
Re: Creative usernames and Spotify account hijacking
#50So is there a need for a TRULY idempotent equivalent of XMPP's nodeprep? Or one that handles more Unicode points? Or is it a calculated decision to support Unicode 3.2 points only? (Sorry for the nooby questions, but this was very interesting and I don't know a lot about Unicode)
The decision to only support Unicode 3.2 is simply because the StringPrep framework [1] (which XMPP's nodeprep and various other protocols use) is forever tied to that version of Unicode.
Current work is on the PRECIS framework [2] which uses the metadata for Unicode code points to determine how to handle them during canonicalization instead of relying on a hard coded set of mapping tables. There's still a lot of work to be done, mainly to review that the process works reliably and doesn't introduce subtle new issues. Peter Saint-Andre (one of the authors of PRECIS) has just started on a Python tool for testing how a given version of Unicode is handled by PRECIS (https://github.com/stpeter/PrecisMaker).
[1] https://www.ietf.org/rfc/rfc3454.txt
[2] https://tools.ietf.org/html/draft-ietf-precis-framework-08